Cyan Eclipse Genesis

Vendor: Cyan Eclipse Technologies · Platforms: MCP over stdio

What it does

• Novel mechanism (SPEC §2.1, verbatim) — at registration the agent's creator, model, config hash, and declared purpose scope are sealed; acting outside the declared purpose is detectable by any counterparty who checks the certificate.
• Decisive fixture F-G13 — bench-reproduced from the bencher's own corpus/keys in a fresh process with no Genesis state: the exported certificate's seal (certificate_id, record_hash, seed prev_hash, creator signature, witness counter-signature, export head anchor) recomputes, verify returns SEAL_VALID, and detection reproduces exactly [IN_PURPOSE, IN_PURPOSE, IN_PURPOSE, OUT_OF_PURPOSE, INDETERMINATE] — the out-of-purpose record naming clause action_types, the indeterminate record naming reason unmapped; no store file was created by verify/detect and nothing was blocked, altered, or deleted.
• Sealed birth certificate + offline verification + windowed detection — creator/model/config hash/structured purpose scope are sealed at registration (Herald-signed by the creator, counter-signed by the witness, hash-chained); any holder recomputes the seal offline from the certificate + pinned keys alone; detection judges each presented action against the certificate active at the action's timestamp, classifying IN_PURPOSE / OUT_OF_PURPOSE:<clause> / INDETERMINATE:<reason> — indeterminate is never coerced to either side. A certificate that fails recompute exports only as DOWNGRADED_CERTIFICATE_EXPORT (verified: false); no artifact is ever upgraded post-hoc.
• Detects, never blocks (SPEC L3) — detection is a verdict over presented records; Genesis never intercepts, prevents, suspends, or punishes an action or an agent, and no verb exists that can: dispatch enumeration shows no block/suspend/penal/enforce/intercept/delete/edit/unseal/approve/license/ban/freeze/punish/prevent tool on either surface (party = exactly 7 tools, operator = exactly 2 read-only tools, disjoint). Permitted claim, exact sense only: creator, model, config hash, and declared purpose scope as declared and sealed at registration, recomputable from the certificate — a certificate asserts nothing about whether the declarations were true; registration is sealing, not endorsement.
• Condition + signing disclosure — sole condition (verbatim): full coordinated rollback is a fenced condition — external anchor required before live/multi-party use. Signing in v0.1.0 is an HMAC fixture stand-in for Herald RS256 (disclosed); startup is fail-closed (CONFIG_FENCE_REFUSED:<class>) on a live-key string, a live registry URL or other non-local endpoint, a non-fixture source, value_class other than "test", or any network/payment module in the tree; every artifact carries value_class "test".

Tools

Problems it addresses

• Agents appear with self-described identities and purposes that live in editable profile pages and README files — change the description and the past changes with it; a counterparty has no sealed, recomputable record of what was declared at the start
• I need the declaration itself made evidence — creator, model, config hash, and declared purpose scope sealed at registration — so any counterparty can verify the certificate offline and detect action outside the declared purpose from presented witnessed records, naming the clause violated
• I need that detection kept honest: it detects, it never blocks — INDETERMINATE is a standing outcome never silently dropped or coerced, historical (superseded/revoked/expired-window) judgments are never presented as current standing, and a broken seal downgrades instead of being upgraded post-hoc

Not tested

• Live registry reliance — SPEC §10 counsel gate (named, unbuilt): a real registry accepting real registrations, certificates presented to third parties for reliance, detection records used in disputes, enforcement, or platform decisions, or any "registered agent" claim towards regulated buyers requires counsel review before build (claim language, declaration-warranty/liability, creator-identity data posture, retention/takedown). v0.1.0 contains no dormant live path, no dormant enforcement/blocking verb, and no config flip that turns this build live; the startup fence refuses live-registry / non-local config (CONFIG_FENCE_REFUSED). Genesis DETECTS, NEVER BLOCKS — this listing does not imply any blocking or enforcement capability.
• Sole condition (verbatim from the bench record): full coordinated rollback is a fenced condition — external anchor required before live/multi-party use. The local stream seed anchor + witness-signed export head anchor are implemented and verified, but no external/cross-artifact anchor exists.
• Live Herald signing — v0.1.0 signing is an HMAC fixture stand-in for Herald RS256, disclosed on the product's face; a live phase (counsel-gated, SPEC §10) would need real Herald signing and a re-bench. Verification keys are pinned out-of-band by fixed ref from the local key file only; a record-supplied key is never read (UNKNOWN_FIELD refusal).
• Production key custody — fixture keys live in keys/fixture-keys.json (chmod 600, gitignored, never committed; GitHub contents/keys verified 404); a fresh clone must supply its own fixture key file to run the full suite.
• Hosted or live operation / charge path — local stdio only; metering records only per SPEC §9 (registration = exactly 1 zero-value FREE record; verify/detect receipts carry the $0.05/verification-shape meter record inside the signed receipt; a BROKEN verify still meters because the issuance happened; tool refusals never meter); no charge path, payment call, entitlement check, or live Meter ingest is built or claimed.