Cyan Eclipse Continuity — Cyan Eclipse Bazaar

Vendor: Cyan Eclipse Technologies · Platforms: MCP over stdio

Certification scope

CERTIFIED (local/fixture) — Verity spot re-bench of v0.1.2, 2026-10-27 (argus101-program-20261027/spot-continuity-012.md), closing condition C1 from the v0.1.1 re-bench (rebench-continuity.md; original bench bench-continuity.md): the pin parser fails closed on every probe constructed (the 4 N1 shapes refuse on both tools x both anchor chains + empty chain + stdio surface, 28/28, no verdict/receipt; 51 unconsumable variants x both tools, 102/102 refuse; nested wrappers, descriptor abuse, double secret aliases, scalar/bool/None values all refuse), every supported pin shape provably binds, and N2 (stdio non-JSON line -> named JSON-RPC parse error -32700 / MALFORMED_INPUT) is fixed. No-regression spots pass (A5/A6/A7, F-C14 recomputed by independent bench code from SPEC text alone, builder suite 49/49). Scope binds exactly: signed identity-continuity chains (genesis, typed append, fork freeze, principal-only resolution, revocation, offline + prefix verification) over fixture principals/models/keys, local stdio only — no live registry or production identity claim (SPEC SS11). Refusal-vs-support ruling on its face: the spec names no pin shape, C1 allowed either branch, and refusal is the fail-closed direction.

What it does

Novel mechanism — agent identity-continuity chains across model/config changes: every change in an agent's life appends a signed link to a single hash-chained identity chain rooted at a genesis link, so a counterparty verifies offline, recomputably, that the agent in front of them descends link by link from the principal they originally trusted — 'same principal, new model' instead of re-trusting from zero. Continuity proves continuity, not trustworthiness: a verifying chain asserts same-principal lineage only, nothing about the new model's capability, safety, or fitness.
Fork freeze + principal-only resolution — key rotation and model change are distinct link types, never conflated (a combined change is two links, rotation first). Two valid children of one head freeze the chain FORKED; only a signed resolution link naming the surviving and repudiated branch heads resumes it, and the repudiated branch stays in exports, labelled. Revocation is terminal: the full chain verifies REVOKED, a prefix verifies CONTINUOUS_AS_OF:<seq> labelled historical, never current standing. A missing link is BROKEN:missing-link:<seq> — there is no partial-continuity verdict — and unwitnessed link sets receive no receipt at all, only a DOWNGRADED_CHAIN_EXPORT.
Consume-or-refuse caller pins (v0.1.2, condition C1) — continuity_verify / continuity_verify_prefix take the presented chain plus public keys: a caller pinning a principal to a key ref, or an expected head hash, is honored (a chain anchored under a different key does not verify against that caller's anchor). Every part of a supplied public_keys argument must resolve to a pin (supported shapes enumerated in README: key-ref lists; principal -> key ref / ref list / secret / descriptor; key ref -> secret or descriptor; sole keys/key_refs/public_keys wrappers) or the call refuses PIN_SHAPE_UNRECOGNISED with no verdict and no receipt — pin material is never silently ignored (spot re-bench: 28/28 named-shape + 102/102 variant probes refuse; every supported shape provably binds).
Honest scope — LOCAL / fixture ONLY: v0.1.2 builds and verifies chains over fixture identity events with fixture principals/models/keys (HMAC fixture keys via a fixture Herald interface stub; signing material lives only in the local gitignored keys/ store, mode 600, never in source). No live registry, no network fetch, no production identity store, no live identity claim. Startup fails closed with CONFIG_FENCE_REFUSED:<class> on any live-registry URL, non-fixture Herald endpoint, non-test value class, or key material outside keys/. Verification never writes the chain store (metering is an in-memory record only).

Tools

chain_genesischain_appendchain_headchain_exportcontinuity_verifycontinuity_verify_prefix

Problems it addresses

My agent changed models last week and every counterparty wants to re-onboard it from zero — I need a signed identity chain so they can verify 'same principal, new model' offline instead
An agent's key rotated and its config changed in the same week and nobody can tell which happened, or in what order — I need rotation and model change as distinct, ordered link types in one recomputable chain
Two branches of the same agent identity are both presenting as current — I need the chain to freeze on a fork and resume only on a principal-signed resolution, with the repudiated branch kept on the record, labelled

Not tested

Live identity scope — none claimed and none exists in the tree: no live registry, no production identity store, no real principals; any scope beyond local/fixture requires asymmetric keys + re-bench (SPEC SS11)
Trustworthiness of a chained agent — Continuity proves same-principal lineage only; nothing about a new model's capability, safety, or fitness is attested or implied
Production signing custody — signing is consumed through a fixture Herald interface stub (HMAC fixture keys, local gitignored keys/ store mode 600); Continuity stores key refs in links, never private key material, and defines no signing scheme of its own
Hosted/networked operation — local stdio only in v0.1.2; no charge path exists (metering records only, SS9.2)

Evaluation-intake listing

This listing records the tool's place in the Bazaar's evaluation and monitoring pipeline, with the evidence gathered so far printed above — verdict, scope, and not-tested items included. It is not sold on this site, and its presence in the catalog is not a claim beyond that evidence. The service behind every verdict is the bench: what a bench run buys →