# Evolution 16 — Top-100 delta

**The registry is unchanged.** `artifacts/commercial/TOP100_PRODUCT_REGISTRY.json` still lists 100 products; nothing was
added, merged, retired or renumbered, and no grade was changed. Evolution 16 built mechanisms that belong inside
products already on the list. A separate product needs a different customer, deployment or technical boundary, and
none of the candidates has one yet.

The registry at inspection has no `family` field on any product (the Guard / Verify / Comply / Passport / Kernel /
Quorum / Sentinel / Frontier families named in the specification are not recorded in this file), so the mapping below
is by rank and name.

## Where the Evolution 16 mechanisms land

| Mechanism | Existing product (rank) | What it adds there | Maturity of the addition |
|---|---|---|---|
| Write-ahead dispatch, dispatch-time re-check, ambiguity quarantine | CAIN-45 Agent Hypervisor (21) | the step between "admitted" and "the tool was called" | tested and adversarially tested in a simulator; **not wired to the product's live path** |
| Observer-gated reconciliation, contradiction reopening | Epoch 6 World-State Integrity & Postcondition Reconciliation (78) | what to do when the outcome is unknown | same |
| Contract succession | Governance Contract Fabric (23, 39/40) | versions of a mission contract with bound approval | same |
| Clean-room journal verifier | E38 Clean-Room Mission Verifier (88) and Independent Verifier (8) | verification of runtime decisions and dispatches, five verdicts | tested; runs standalone today |
| Decision-checked replay | Trust Runtime Kernel (6) | durable governance state | tested |
| Bounded exploration, mutation harness | Compound Adversarial Simulator 2.0 (64/65) | evaluation method | tested |
| F16-01 fix | Evolution 10 coordinator (execution chain) | defect removed | tested |

## Candidates considered

Scores 1 (weak) to 5 (strong); for "security and liability exposure" and "support and maintenance cost" 5 means **low**
exposure or cost. These are the author's judgements from this session's evidence. There is **no customer evidence** for
any of them: columns 4 and 8 are guesses and are marked so.

| Candidate | 1 Tech. diff. | 2 Impl. evidence | 3 Prior-art distance | 4 Customer pain (guess) | 5 Integration advantage | 6 Deployability | 7 Liability (5 = low) | 8 Recurring revenue (guess) | 9 Support cost (5 = low) | 10 Evidence maturity | Decision |
|---|---|---|---|---|---|---|---|---|---|---|---|
| Recovery-Aware Agent Execution / Agent Transaction Recovery (one thing) | 3 | 4 | 2 | 4 | 4 | 2 | 2 | 3 | 2 | 3 | **Merge** into rank 21 and 78. Closest published work: Atomix, Cordon, Temporal |
| Verifiable Mission Contracts | 3 | 4 | 2 | 3 | 4 | 3 | 3 | 3 | 3 | 3 | **Merge** into rank 23/39. Closest: AP2 mandates |
| Independent Mission Evidence | 2 | 4 | 2 | 3 | 4 | 4 | 4 | 2 | 4 | 3 | **Merge** into rank 88 and 8 |
| Continuous Mission Assurance | 2 | 2 | 2 | 3 | 3 | 2 | 3 | 3 | 2 | 2 | **Merge**; overlaps ARGUS and rank 21 |
| Delegation Chain Verification | 2 | 3 | 1 | 3 | 3 | 3 | 3 | 2 | 3 | 3 | **Merge** into Universal Agent Passport (18). Crowded: Biscuit, AIP, CAPMAS, IETF draft |
| Agent Skill Admission and Attestation | 2 | 3 | 2 | 4 | 3 | 2 | 2 | 3 | 2 | 2 | **No change**: already rank 50 and governed_evolution; nothing built |
| Agent Reliability and Recovery Benchmarking | 2 | 4 | 2 | 2 | 3 | 4 | 5 | 1 | 4 | 3 | **Merge** into rank 64/65. Could be published as an open benchmark |
| Governed Enterprise Workflow Runtime | 2 | 2 | 1 | 4 | 3 | 1 | 1 | 4 | 1 | 1 | **Reject** as a product now: competes with Temporal-class engines; no evidence |
| Agentic Compliance Evidence Automation | 2 | 2 | 2 | 4 | 3 | 2 | 2 | 4 | 2 | 1 | **Research further**: the journal is the raw material; no regulator mapping was done |
| (specification's "Verifiable Autonomy" as a family) | — | — | — | — | — | — | — | — | — | — | **Reject**: a label, not a mechanism |

## The strongest merged capability, described as it would be offered (hypothesis)

| | Recovery-aware execution inside the Agent Hypervisor |
|---|---|
| Customer | a team running agents that write to systems of record (tickets, databases, deployments) |
| Problem | after a timeout or crash nobody knows whether the agent's write happened, and a retry may double it |
| Mechanism | journaled intent, no blind retry, observer-settled outcome, authority re-checked at dispatch |
| Integration point | the tool adapter (MCP proxy) calls `execute()`; a read-after-write probe acts as observer |
| Deployment model | library in the customer's adapter process; one journal file per mission |
| Evidence level | E4 (author-run tests in a simulator) |
| Pricing hypothesis | none set. No price is published for any carve-out and none is proposed here |
| Competitive alternative | Temporal or a hand-written outbox; Atomix-style research runtimes |
| Validation plan | wire one real adapter; run one design partner's own failure drills; measure duplicate writes before and after |