This is a submission for the Hacktoberfest Open-Source AI Challenge Week 3: Slow and Steady
N 86°29' E, 103.2 feet.
That is one line of a propert...
For further actions, you may consider blocking this person and/or reporting abuse
Your program looks coole, my vote on you! Sure I don't have right to vote - but yo know I up your project.
Thank you so much!! This means a lot to me❤️
Testing the validator against your generator's own answers is the detail I'd keep next to the accuracy score. Before adding more training data, I'd freeze a small set where the polygon closes but a landmark or unit is wrong, then track whether each check catches it. That's the distinction I'd want to explain in a prachub ML question too like how I tested the model and how I tested the checker.
Thanks, that's a great point. A deed that closes but has a wrong landmark or unit is exactly the case the closure check can't catch. I'll freeze a small set like that and track which check catches each one.
The most convincing result here is not the accuracy jump itself, but the change in failure mode: a wrong answer that is flagged is manageable, while a wrong answer presented as certain is not. Separating reading from arithmetic, and requiring the parcel to close before anything is drawn, turns the model output into a claim that can be checked rather than a verdict to trust. I would be curious how this approach holds up on real deeds where the description uses deflection angles or station and offset formats, which the post notes are not yet covered. If those cases are routed to review with the suspect line highlighted, rather than forced through the same checks, the safety argument becomes even stronger.
Thank youu, that's exactly the point I was going for. A flagged wrong answer is something you can fix. A confident wrong one is the dangerous kind. And you're right about deflection angles and station/offset formats. The plan is to send those to review with the suspect line highlighted, not force them through checks that weren't built for them.
the 500-deed row is where this post actually earns its trust claim: $0.08 and the silent-error count is zero, long before the 99.6% column. that jump matters more than the accuracy numbers for anyone who would put this in front of a title examiner. one gap i would poke at before real deeds: the generator writes prose from known truth, so the model has never met a deed that is wrong but self-consistent — a clerk error that parses, closes to 1:5,000, and matches its own sentences. the varas test shows the decoder rejects the unknown token, but a wrong number that still satisfies all five checks is the shared blind spot. how would you catch that kind of deed?
Thanks for pointing this out! You're right that a deed can be wrong while still passing all our checks. I'm working on addressing this by adding a cross-validation layer that compares extracted bearings, distances, and monument references against independent survey records wherever available. This would help catch errors that are internally consistent but don't match the actual survey data.
The model-reads/code-does-math split is the real headline here. The LoRA bump is nice, but the 5 to 0 drop in wrong-and-unflagged answers comes from never letting the model grade its own geometry. Closure checking works because deeds have a physical ground truth to fail against - most document extraction has none, which is exactly why this pattern rarely ports cleanly to invoices or contracts. One question: what happens on old deeds written before survey adjustments, where systematic magnetic declination offsets every bearing but the polygon still closes? The one-digit search would find nothing wrong and the closure check would pass. Does the NEEDS HUMAN REVIEW stamp ever fire on self-consistent but globally wrong data?
Thanks for highlighting it! We use multiple independent checks, including closure, clause-level validation, and a separate regex reader. But you're right that a systematic offset could pass these checks. The next layer would be validating bearings against the deed's survey date and reference system.
The one-digit-fix search is a great touch. A classic surveyor’s trick might make it cheaper and more trustworthy: the direction of the misclosure vector hints at which side is wrong. If it’s roughly parallel to a side, suspect that side’s distance; if it’s roughly perpendicular, suspect its bearing. Ranking candidate fixes by that alignment would help when more than one single-digit change closes the parcel. What does DeedReader show in that case, all candidates or only unique fixes?
Great tip, thank you @khushighosh! Right now DeedReader shows all candidates, not just unique ones: up to three fixes that close the parcel, ranked by how tightly each one closes, and each gets its own "apply" button. So if two fixes both work, you see both and the human picks. Ranking by misclosure direction is a really nice idea. A fix that agrees with the error vector (along the side means distance, across it means bearing) should go to the top. It's cheap and easy to explain, so I'm adding it to the list.
Refusing to draw the parcel beats a confident map that is 27 feet off and smiling about it
Agreed. It flags the bad line and shows the one-digit fix instead of drawing a wrong parcel.
yeah, flag the line, not a redrawn parcel.
Damnnn I loved your concept!
Thankyouu!!😊
This amount of significant change is crazy asf!! Can you share your claude memory or anything you explicitly mentioned it to focus on, in order to get such low cost while sft
Thanks! No special memory or prompt. Most of the gain comes from the checks around the model and the training itself.
I really enjoyed reading both the articles of yours. Agreed with flagging the feet off rather than a false structural confidence. The results are very impressive!!
Glad that you liked both of them! Thank you sm!!😊
Interesting read Advik, great stuff
Thank you!! @sarthak_narula_5789cd042d 😊
Calibrated uncertainty on a dollar-fifteen budget will always out-engineer burning enterprise compute on bloated frontier models that hallucinate with confidence.
Thank you @hordii_bohdan! That's the whole idea. A small model that says "check this line" is more useful than a big one that's confidently wrong. And because plain code does the math, the confidence actually means something.
Impressive results! A great example of how focused fine-tuning and the right data can outperform brute-force model scaling!!
Coming from you is great bro! Thankyou!!
great work
Thankyouu!☺️
Unbelievable work!!
Thank you!!😄
Really strong explanation of the whole thing, good read!!
Thank you so much!! 😊
This is great!!
Thankyouu!!😊