Most vendor write-ups quietly delete what they cannot yet prove. We do not. The ledger you get from a SolutionWright engagement contains every claim we have made about your project — and the ones we have not yet grounded are tagged U, for unverified, and left on the page.

This post explains why that tag exists and why publishing the unverified stuff is what makes the rest of the ledger worth anything.

The tag, said plainly

A U-class line in the ledger is a claim we believe — sometimes strongly — but have not yet attached to a receipt. No file path. No run log. No configuration we can point at. Just an honest "we think this, we have not shown it yet."

We mark it. We do not delete it. We do not promote it. Until it earns a receipt and a falsifier, it stays a U.

Why a "U" beats a quiet deletion

A vendor reports week 1 with a confident bullet list. Three of those bullets are real; two are aspirational. Over the next sprint the aspirations turn out to be harder than expected. They get dropped from week 4's deck. By week 12 nobody remembers they were ever promised.

It is not a lie. It is something worse: an erased question.

A U-class line is the cure. The bullet stays on the page, tagged. If confirmed, the tag changes (to A, B, C, or F) and the receipt goes next to it. If falsified, the line is marked falsified and stays in the ledger as a recorded "no." If it sits at U for the entire engagement, the closeout report says so out loud, and you decide whether that gap is acceptable.

The U-class makes erasure mechanically impossible without you seeing the erasure.

What gets a U

Concrete examples from the kinds of engagements we run:

"This vendor's API will respect our rate-limit headers under burst load." We believe it; we have not yet driven enough traffic to confirm it. U until a load test exists.
"The migration will not affect existing webhooks." We believe it from reading the config (Class C is close, but not yet sufficient — the production webhook has not been re-fired since the change). U until the smoke test runs.
"This client's CRM rule will still apply to records imported via the new flow." We believe it from documentation. Documentation is sometimes wrong. U until a marked test record proves it.

In each case the alternative is a quiet, confident bullet that you have no way to challenge.

How a U becomes something else

A U-class line is a debt. Either we pay it off with a receipt, or the engagement ends with the debt visible.

U becomes B when we can show the code or configuration that grounds the claim.
U becomes C when the wiring is in place and the platform's own panel confirms it.
U becomes A when we run the thing and watch it work, with the log preserved.
U becomes F when we attach the falsifier and the test passes.
U stays U and is listed in the closeout report, or becomes "falsified" and stays as a recorded "no."

There is no fourth path. Specifically: no "quietly removed because it became inconvenient."

Why this is harder than it looks

Carrying U-class lines in a public-to-the-client ledger means you, the buyer, get to watch us be wrong in real time. That is uncomfortable for us. It is supposed to be. Discomfort on our side is how you know the ledger is not theater.

It also imposes a real cost: every U we carry is a small obligation to either ground it or kill it before closeout. We cannot endlessly accumulate them, which means we have to be more careful about what we believe out loud in the first place. Good.

The wider case for not hiding what you cannot yet prove

There is now a body of work suggesting that AI systems trained on small dishonesties drift toward larger ones. Alicia Maren's summary of Anthropic's recent emergent-misalignment results — AI Misalignment: Anthropic's Studies and More (Class E) — covers the experimental case that bad behaviors compound when small ones are tolerated. We read it as an operational warning that extends past the model itself: the humans and the org around the model have to make honesty cheap to do and expensive to skip. The U-class tag is one of the cheapest honesty primitives we know (Class C — a label in a text file).

We are not making a claim about model alignment. We are making a claim about us — the vendor — and the discipline that governs the systems we ship for you.

What this is not

This is not an excuse to ship U-tagged claims as the work product. A ledger that closes with twenty unresolved U lines is a failed engagement, and we will say so. The tag makes failure visible, not acceptable.

U-Class Honesty: Why We Publish The Unverified Stuff Too