Varra Assurance

Do not just trust the answer. See what supports it — and see, just as plainly, where nothing does yet.

Why this page exists

Almost everything an AI product claims about its own accuracy is unfalsifiable. A benchmark you cannot re-run, a percentage with no denominator, a promise that the system “reduces hallucinations”. This page is the opposite bet: publish the actual values Varra defers to, publish how much ground they cover, and publish the part that is not covered at all, so that anyone can check the claim rather than take it.

Varra Assurance is one layer of Varra's architecture, not the whole of it. It is the layer that sits between the work and acting on it, and decides whether the rest is safe to act on. This page is the evidence behind that name — what it covers today, and what it does not.

The substitution, shown happening

Left is what a language model hands back. Right is the string the engine puts in its place, caveat included, taken verbatim from the published table. This panel used to sit on the home page, doing the whole verification argument in the middle of a product pitch; it belongs on the page that is about it.

The published tables

How the verification actually works

It is one mechanism, and it is worth stating precisely because a vague description of a safety property is worth nothing.

• The figure is made addressable. The engine asks the model to put the exact value an answer turns on — a gauge, a board size, a part — in a structured field, rather than leaving it buried in prose. A number nobody can locate is a number nobody can check.
• The value is reduced to a canonical key. “12 AWG copper”, “12awg” and “12 gauge” have to reach the same row, or the table silently stops matching and the answer looks identical either way.
• A match replaces the model's text. If the key names a row, the table's entry — caveat included, verbatim — replaces what the model wrote, and the answer is stamped with where it came from. In the app that shows as a BUILT-IN TABLE badge under the answer.
• A miss is logged rather than swallowed. A mode that has a table but stopped matching it would otherwise fail invisibly. That has happened before, which is why the log line exists.

Current coverage, stated plainly

This is the number that matters, so it is not buried:

Most Varra answers today are not independently verified. They are the model's own reasoning, and Varra says so rather than implying otherwise. Nine rows is a narrow slice of a broad idea. It is also a real one, which at this stage is the right way round — a wide claim nobody can test would be worth less than a small one anybody can.

Those counts are what Syntur publishes. What an account can add for itself is a separate thing, and it is the next section.

Your values, not just ours

Live in the product today: in any mode you can add your own verified reference values from the account menu. Yours take precedence over the built-in table, which takes precedence over whatever the model remembered. When your entry is what answered, the reply is stamped as coming from your account rather than from the built-in reference.

This is the smallest complete version of the whole argument — a model produces an answer, a trusted source overrides it, and the answer says which source won. A shop that has checked a figure against its own equipment, its suppliers or a local code amendment knows something a general table cannot, and this is the one place Varra already lets it say so.

What it is not: it is account-level reference data, entered deliberately, one value at a time. It is not a system that has read your documents, learned your vendors, or worked out how your business runs — that is the company context layer, and it is planned rather than built. Your entries are not published here, so they widen what Varra will defer to for you without widening what a stranger can check.

Known limitations

• Coverage is thin. Thirteen of the sixteen modes have no verified reference data at all. In those, every figure is the model's own.
• Torque specifications are deliberately unpublished. The values held today carry no vehicle, and a fastener torque without the vehicle it belongs to is exactly the confidently wrong number this whole approach exists to prevent. They stay out until they carry the vehicle.
• The tables are conservative, not universal. The electrical figures in particular depend on terminal temperature ratings, conductor material, installation method and local amendments. Each published page carries the conditions; none of them replaces the code that governs your job.
• Verification runs on values, not on reasoning. A checked figure inside an otherwise unchecked argument is exactly that. Varra can tell you the breaker rating came from a table; it cannot yet tell you the argument around it was sound.
• Nothing here verifies against your documents. Checking an answer against a contract, a schedule of values or a company policy needs the company context layer, which is planned rather than built.

From a verified value to a verified piece of work

Everything above verifies a value. A piece of work needs more than that: which documents were read, which number came out of which one, what could not be found, where two sources disagree, what a person changed, and what state the whole thing was approved in.

None of that is built. There is no workflow provenance in Varra today, no record of evidence assembled across documents, and no reviewer trail. It is written down here because it is the shape verification has to take before Varra can prepare work rather than answer questions — and because a page arguing for checkable claims should be the first to say which of its own are still architecture. What exists today is the substitution described above and the account-level values in the section before it.

Verification is what execution waits on

Verification matters more, not less, once a system can act. Varra is being built to move from answering work to completing approved work through Varra Runtime, its planned execution layer — and the whole point of putting a gate in front of it is that Runtime does not act because a model is confident.

Before a consequential action, the design is for Varra to check permissions, the evidence the action requires, the task's risk, the verification conditions attached to it, company policy, and whether a person has to approve it. None of that gate is built today, and nothing executes today either — which is the correct order to build them in.

Why these pages cannot drift

The tables are generated from the engine's own source, and a checker compares every published value against varra/modes.py on every change. A page that disagrees with the engine fails the check; a page carrying a reference table that is not registered with the checker also fails, so a new table cannot be published unchecked by forgetting a step. The engine may hold rows that are not published yet — that is fine, and the checker lists them.

The point is not that the checker is clever. It is that a value here being wrong is a build failure rather than something a reader has to catch.

What comes next

Widening what Varra can validate before returning or executing work is 03 — Verify on the roadmap, and filling in the checked values behind every mode is 02 — Specialize. The order is deliberate: execution stays behind verification, because a system that can act is only as safe as its ability to know when it should not.

Try Varra →