Build1 publisher3 min readPublished
Enhanciar resolves every citation to a file and line before grading the sentence beside it
Enhanciar builds a wiki page per service at ingest, makes the model cite those pages, then checks each claim against the cited file before the answer ships. Claims it cannot judge are tagged unverifiable.
The Engineer · Build desk

What happened
- Enhanciar forces every answer to cite, resolves each citation to a repo file and line, and then re-reads the cited source to grade each claim supported, partial, unsupported or unverifiable.
- Prose claims go to a model that has to re-read the cited source and return a quoted span plus the line it was found at before it is permitted to grade the claim supported.
- When the oracle has no data or the critic has no key, the claim stays unverifiable and the interface reports what was not checked.
Compiled by The EngineerSomething wrong?How this is made
Why it matters
- constraint The frontmatter written at ingest sets the ceiling on verification: if a page's source list omits the file that actually holds the behaviour, no grader downstream can check the sentence against it.
- decision Anyone evaluating a code Q&A tool now has a concrete acceptance test to run: remove the grader's API key and see whether the output still comes back supported.
- cost The bill for this design is an ingest pipeline and a maintained tree-sitter index per language; repos in languages with a thin grammar pay instead in claims nobody can grade.
The rule about broken checkers came out of a bug. Early on, tier 1 reported every React hook in a repo as unsupported [14]. The fix was to give the missing-data path its own grade, so a claim the oracle cannot see stays unverifiable and the interface reports what was not checked [13]. Enhanciar's stated rule now is that every "cannot judge" path returns unverifiable, because silently marking things supported when the checker broke would be the worst failure the feature could have [16].
Tier 1 settles what it can by lookup. Symbols, routes and dependencies are extracted with tree-sitter at ingest, so a claim like "this file defines generateMetadata" is answered from the index. It comes back supported with evidence {file, line} when the index puts the symbol at app/layout.tsx:42, unsupported when the symbol is nowhere in the repo [9][10]. Tier 1 makes no model call, needs no API key and spends no tokens [9]. The writeup is blunt about why the ordering exists: "Anything tier 1 can judge, tier 1 judges. Tier 2 never sees it. That's the whole cost story." [11]
Two things have to hold for that cost story to transfer to another codebase. The languages in the repo need tree-sitter grammars good enough to produce the symbol and route index at ingest [9]. And a large share of the claims in the answers have to be structural ones. The post calls structural claims "a surprising share" and does not publish the distribution [17]. The question the tool is pitched against, which service handles refunds for cancelled orders, is prose [3]. Prose claims go to tier 2, and tier 2 has to return a quoted span and the line it was found at before it is allowed to say supported [12].
There was a real fork in the design: drop unverified claims, or tag them. Tagging won, on the grounds that "a wrong verifier that silently destroys real information is far worse than a wrong verifier that mislabels it" [15]. So a published page can carry a sentence graded unsupported, and a reader can see it and click through [15].
The adoption cost is the ingest pipeline. It builds one Markdown page per meaningful unit, a service, a route, a module, a decision, each with frontmatter recording which repo files the page was built from [4]. The same pipeline builds the AST index that turns a file into a line [7]. And it needs a parser for the handles in a finished answer: a regex that dedupes, caps at 16, and tolerates a section suffix and a trailing .md because models add them anyway [6]. The example page in the writeup carries the slug entities/cart-service and lists src/services/cart.ts and src/routes/cart.ts as its sources [18].
What to watch
- A published grade distribution from a real repository would show whether tier 1 absorbs most claims or a minority of them.
- How far the unverifiable count rises on languages whose tree-sitter grammars produce a thin symbol index.
- Whether other code Q&A tools adopt an explicit ungraded state instead of labelling unchecked claims supported.