Proof-Carrying Capabilities: The Core Innovation

What is a capability?

In most software teams, a "capability" is a feature described in a ticket and implemented in a pull request. Its completeness is assessed by a human reviewer reading the code and checking if it seems right. Its correctness is verified by a set of tests that may or may not cover the important edge cases.

We define capability differently. A capability is a unit of software behavior that ships with four things:

1. Contracts — formal descriptions of what the capability promises. API schemas, event formats, input validation rules, error shapes. These are not documentation. They are executable specifications.

2. Invariants — the rules that must always be true. "No cross-tenant data access." "All datetime values are timezone-aware." "Every authenticated endpoint checks RBAC." Invariants are non-negotiable.

3. Tests — including negative cases. It is not enough to test that login works. You must test that login fails correctly with invalid credentials, expired tokens, missing headers, and malformed inputs.

4. Evidence — machine-readable records proving that contracts were validated, invariants were checked, and tests passed. This evidence is permanent, auditable, and reproducible.

Why proof matters

Without proof, software delivery is based on social trust. "I reviewed it." "The tests pass." "It looks right to me." Social trust works in small teams where everyone knows each other and the codebase is small enough to hold in your head.

Social trust breaks down at scale. When dozens of developers ship hundreds of changes per week, the probability that a critical edge case is missed grows rapidly. When AI agents generate code, the trust model breaks entirely — you cannot rely on the agent's "understanding" of your domain.

Proof replaces trust with evidence. It does not matter who wrote the code — human or AI. What matters is whether the evidence exists to demonstrate that the capability is correct.

The capability passport

Every capability in a proof-carrying system has a passport — a structured document that records what was promised, what was verified, and what evidence exists. Think of it as a birth certificate for a feature.

The passport is not written by the developer. It is generated automatically from the contracts, tests, and gate results. It is updated every time the capability is modified. It is the single source of truth for "is this capability production-ready?"

When a capability's passport is incomplete — missing contracts, failing tests, or absent evidence — it is not "done." It is either blocked (cannot ship) or escrowed (can ship with an explicit, time-bounded exception that must be resolved).

Hidden hardening is impossible

The most important property of proof-carrying capabilities is that they make hidden hardening structurally impossible. You cannot quietly skip security testing and hope nobody notices. You cannot ship without contract validation and claim it was "good enough." The evidence ledger is append-only and auditable.

This sounds restrictive. In practice, it is liberating. Teams stop debating whether a feature is "ready enough." The passport tells them. The conversation shifts from subjective assessment to objective evidence. And the software that ships is measurably more reliable because of it.