Verity ยท the harness
Know what must be true before you ship.
Verity turns the requirements that actually matter into constraints, scenarios, approvals and evidence. It looks for the gap between what software appears to do and what the operation requires, while that gap is still cheap.
Testing asks whether the code works. Verity asks whether it is the right system.
Conventional tests check an implementation against itself: given what we built, does it behave as built? That question can pass completely while the system still fails, because the thing being tested was never the thing that mattered.
Verity connects three things that are usually kept apart: the specification, the running system, and evidence gathered from the world. A claim about readiness has to be supported by an observation, not by a confidence score.
What it checks
- Rules. Does the system enforce the conditions that must hold?
- Permissions. Can each actor see and do only what is allowed?
- Exceptions. What happens when the happy path times out, conflicts, or needs judgment?
- Integrations. Do external dependencies behave under failure and change?
- Evidence. Is there enough proof to justify this release or approval?
- Runtime. Does the deployed system stay inside the envelope it was approved for?
Four principles it enforces
These are the four structural limits from Convergence Programming, restated as rules a system can be held to. Each one is a way confident systems get things wrong, and each is enforced rather than recommended.
- Critical blockers do not average
- One missing permission boundary outweighs dozens of passing cosmetic checks. A single veto is not a low mean, and a release gate should not treat it as one.
- Readiness requires evidence
- A model's confidence is not proof that an operational requirement has been satisfied. Self-reported satisfaction without a supporting trace does not count.
- Autonomy spends evidence
- As a system acts with more independence, its authority should stay bounded by evidence that is current. Permission recedes; it does not accumulate.
- Change reopens the question
- A release that was safe yesterday may not be after a dependency, policy or model changes. Verification is scoped to what actually moved.
Capabilities
| Capability | What it does |
|---|---|
| Living constraints | Turns critical requirements into machine-checkable conditions tied to the mission. |
| Scenario simulation | Exercises workflows, edge cases and failure conditions before users meet them. |
| Trace and evidence | Keeps decisions, tests, approvals and observations attached to the claims they support. |
| Release gates | Stops a critical blocker from vanishing inside an aggregate readiness number. |
| Runtime envelopes | Bounds autonomous behavior by permission, evidence, time and context. |
| Targeted regression | Retests what matters when the system, policy, dependency or model changes. |