16  Principle Six — Honesty by Design

Most software marketing has a section called “Roadmap” that is really a section called “Wishes.” The industry’s standard posture is to blur what exists, what is planned, and what is imagined. A trust product cannot afford this posture — not for moral reasons, but because its entire value proposition is the reliable separation of verified fact from unverified claim. A reporting platform that exaggerates about itself will exaggerate about your data; the buyer’s inference is correct and instant.

So: honesty is not a values statement on a wall. It is an engineering discipline with artifacts.

16.1 The honesty ledger

The discipline has a concrete center: every serious system should maintain, in public, a ledger that separates three states — implemented today, deliberately not done, and roadmap. Not a marketing page; a document with the same care as code, because it will be read by the people deciding whether to trust the system with a submission.

The second category is the one that reveals character. “Deliberately not done” entries name the limitation and the reason: this backend requires network keys the sandbox cannot have; this path routes to human review because no unattended system should approve its own output; this validation scope excludes that component because its failure mode is cosmetic. A limitation disclosed with its reasoning is trust-building. The same limitation discovered by the customer in production is trust-ending.

16.2 Labels that cannot lie

Beyond the ledger, honesty must be structural — embedded in the outputs themselves:

• Draft output is labeled draft. Anything produced by an unsupervised path — generated code that no human has approved, a table rendered by a newly connected engine — carries its status on its face, in the manifest and in the artifact, until a human signs. Unlabeled drafts launder themselves into deliverables the first time someone forwards a file.
• Not-verified is not pass. Every number carries or inherits its verification state; “no comparison available” is a visible, countable condition, never silently equivalent to green.
• Provenance of synthetic data is synthetic. Demos run on generated data must say so in the output itself, because a realistic-looking demo table photographed out of context becomes a fabricated clinical result with a life of its own.

16.3 The demo trap

The strongest temptation in this field is demonstrating capability that is ninety percent real. The demo that quietly finishes the last ten percent by hand, the screenshot of a feature that runs only on the founder’s machine — these are small lies that compound, because every subsequent conversation is calibrated against them. The discipline of the honest demo: show the live system, on public or synthetic data, with the run’s manifest visible, and narrate the gaps as gaps. It is a slower sell and a much faster procurement.

There is a compounding return, too. A team whose public ledger has never been caught overstating accumulates something rare and valuable: the benefit of the doubt. In a regulated market, that is the asset.

The test. Open any vendor’s (or your own) system documentation and ask: “Which sentence here would the engineering team themselves say is not true today?” If you can find one quickly, the ledger is broken. If the documentation makes the question hard to ask — no scope statements, no limitations, no not-done list — that is an answer too.