Cyan Eclipse Epitaph

Vendor: Cyan Eclipse Technologies · Platforms: MCP over stdio

What it does

• Novel mechanism (SPEC §2.1, verbatim) — a signed death/compromise record triggers cascade expiry: every outstanding mandate, alias, and delegation issued to the dead identity expires atomically and provably.
• Decisive fixture F-E14 stands from the bench record — produce in one fresh process, then verify + sweep in a separate fresh process from the receipt + snapshots alone; a doctored snapshot fails by name. Atomicity fuzz: failure injected at every expiry step 0–6 of 7, with same-nonce retry after each — the cascade is all-or-nothing, and a failed cascade is recorded as CASCADE_FAILED.
• Delta re-bench of v0.1.1 (wave4/rebench-epitaph.md): bench defects D-EPI-1..4 all CLOSED on independent re-probe (24 bencher scenario logs; builder suite 38/38 re-run by the bencher at commit 0c0b027) — cascade_verify now recomputes presented-snapshot integrity and chain_heads at §6.4 step 3 (C1), cascade_receipt_get serves the stored receipt verbatim plus the derived DISPUTED overlay (C2), corrupt store JSON raises typed STORE_INTEGRITY_FAIL (C3), and the operator token is enforced on all 5 operator verbs (C4). Prior conditions C1–C4 are satisfied by these closures; no new defect found.
• Death is a signed record, not an assertion: an unsigned claim, an operator note, or a missing heartbeat changes nothing. Death is not erasure: expired instruments and the cascade receipt remain verifiable history, and checks return EXPIRED_BY_CASCADE:<cascade_id>, never "never existed". Disputes are first-class — a disputed cascade is labelled DISPUTED on its face, and dispute never resurrects expired instruments.
• Rollback fence: cross-artifact cross-commitment (full coordinated rollback) is a fenced condition — external anchor required before live/multi-party use. The v0.1 store is single-process local state anchored by its signed head records and SET anchors; a pure local file store caps any verdict at PASS-CONDITIONAL.
• Counsel gate (SPEC §10) — named, unbuilt: any claim that a cascade has legal effect against third parties (estoppel, notice, liability cut-off); compromise declarations made by a platform against an owner's objection; legal consequences of a false-death adjudication; death records for identities bound to regulated/financial mandates; any real-registry integration. v0.1.1 contains no dormant live path — no network call, no live key, no real-registry integration exists in this tree, and the startup fence refuses such configuration by name.
• A receipt with only the service signature is labelled counter_signatures: partial and verifies only as PARTIAL, never as sweep-proof. Signing is an HMAC-SHA256 fixture stand-in for Herald RS256, disclosed on every artifact face as signature_scheme; verification keys are pinned out-of-band by fixed key ref. Herald (signing pattern) and Meter (metering grammar) are consumed by reference only.

Tools

Problems it addresses

• When an agent identity dies or is compromised today, its outstanding mandates, aliases, and delegations linger — revocation is a scattered, per-registry chore with no single provable moment at which everything bound to that identity stopped being valid
• I need one signed death/compromise record to expire every outstanding mandate, alias, and delegation issued to the dead identity atomically — all of them in one cascade, or none, with a signed cascade receipt proving the sweep
• I need the cascade verifiable by a third party from the receipt and registry snapshots alone, with disputes labelled on the face of the record and no path for a dispute to silently resurrect expired instruments

Not tested

• Legal effect against third parties — any claim that a cascade has legal effect (estoppel, notice, liability cut-off) is SPEC §10 counsel-gated and UNBUILT; no legal-effect claim is made at this scope
• Compromise declarations against an owner's objection, legal consequences of a false-death adjudication, and death records for identities bound to regulated/financial mandates — SPEC §10 counsel-gated, UNBUILT
• Real-registry integration — no external registry is written to in v0.1.1; there is no dormant live path (no network call, no live key) and the startup fence refuses such configuration by name
• External anchoring / multi-party reliance — full coordinated rollback is a fenced condition; the pure local file store caps any verdict at PASS-CONDITIONAL (local/simulator) until an external anchor exists
• Production key custody — signing is an HMAC-SHA256 fixture stand-in for Herald RS256 (fixture keys in keys/, gitignored, mode 600); a live phase would need real Herald signing and a re-bench