Cyan Eclipse Namesake

Vendor: Cyan Eclipse Technologies · Platforms: MCP over stdio

What it does

• Novel mechanism (SPEC §2.1, verbatim) — similarity scoring over registered agent identities (name, purpose, capability profile) issues a collision verdict before an agent launches under a confusing identity. Scoring version namesake-score/1.0 is pinned and purely mechanical — no model call, no randomness, no discretionary adjustment — so every component score recomputes offline from the candidate, the snapshot, and the pinned scoring version alone.
• Scoring + verification recompute everything — per registered identity: name similarity (normalised edit similarity + token-set Jaccard over case/diacritic/punctuation-folded names; exact normalised match = 1.0), purpose similarity (token Jaccard over declared-purpose token sets), capability similarity (Jaccard over capability-profile ref sets); composite = 0.5·name + 0.3·purpose + 0.2·capability (rounded 6dp); verdict over the maximum composite (REVIEW ≥ 0.40, COLLISION ≥ 0.70, exact-normalised-name match forces COLLISION regardless of composite), with the top-3 identities, full component breakdowns, thresholds, and snapshot id + hash on the verdict's face. namesake_verify recomputes candidate/snapshot hashes, re-derives the normalised name + purpose tokens, recomputes every component score + composite + top-k, re-derives the verdict (incl. the exact-name override), recomputes the §4.5 chain head (candidate → snapshot pin → score records → verdict), and verifies the builder submission signature + Herald signature against pinned out-of-band keys only (a key supplied inside a record fails). Any failing step returns NAMESAKE_VERIFY_FAIL:<step> and the export downgrades to UNVERIFIED_EXPORT with verdict_claim null — there is no path from a downgraded export back to a sealed verdict.
• Stored-read verification (v0.1.1, delta-bench C1 closure) — namesake_verdict_get, namesake_breakdown_get, namesake_screen_list, and the idempotent path of namesake_screen recompute-verify the stored screen via the full §6.2 procedure over the stored source artifacts before serving: verified intact → the sealed verdict is served normally (screen_list verified entries additionally carry verified:true / export_label VERIFIED_EXPORT); ANY failure → the §6.3 downgrade form only (verified:false, export_label UNVERIFIED_EXPORT, verdict_claim:null, verify_failure NAMESAKE_VERIFY_FAIL:<step>) — no verdict, no top_k/score_records, no signature served, unverified screens are excluded from verdict-filtered lists, and metering never changes on a stored read. A snapshot envelope without snapshot_ref refuses SNAPSHOT_INCOMPLETE (Finding 2, also closed at delta).
• Decisive fixture F-N9 — bench-reproduced at v0.1.0 and as a delta regression at v0.1.1: a candidate + snapshot authored as an independent fixture registry's records (SNAP-IND, 3 entries), screened and re-verified in a fresh process from the artifacts alone, with the bencher's scorer rewritten from the spec text (builder scorer NOT imported): agent-harborlight name 0.628205 / purpose 0.6 / capability 0.666667 / composite 0.627436 → REVIEW, server top_k[0] identical to the independent record, fresh-process stdio verify verified:true / verdict_claim REVIEW / VERIFIED_EXPORT. Boundary pins exact: exact name composite 0.500000 → COLLISION by override; near name 0.454286 → REVIEW; stem-only 0.242424 → CLEAR.
• Honest scope — LOCAL stdio, fixture registry snapshot ONLY: no live registry is read, no agent is registered, blocked, or cleared by anything in v0.1.1, snapshot coverage is exactly the fixture set (a real registry's coverage is never implied), and every emitted artifact carries value_class 'test'. A Namesake verdict is a similarity screen over a stated snapshot — it is not a trademark opinion, not a legal clearance, and not permission to launch. Closed surface of exactly 7 tools (4 builder + 3 operator, disjoint); no verb registers, reserves, assigns, blocks, renames, or revokes an identity, edits a snapshot, adjusts a score, or issues a legal opinion. Startup is fail-closed (CONFIG_FENCE_REFUSED:<class>) on a live-key string, a non-local endpoint, value_class other than 'test', a registry-write/registration/identity-issuance module, or a non-deterministic scoring component anywhere in the tree. Signing is a fixture HMAC stand-in for the Herald pattern, disclosed in README + code; verification uses pinned fixture keys only (not public-key verification); the pinned key file holds shared HMAC secrets, not public keys, and no public-key or third-party verifiability is claimed.

Tools

Problems it addresses

• Agent registries are filling with look-alike identities — same or near-same names, overlapping purposes, overlapping capability claims — and today the collision is discovered after launch, by a confused counterparty or the impersonated agent, when changing the name is no longer free
• I need a cheap, mechanical, recomputable pre-launch screen: score a candidate identity against every identity in a stated registry snapshot and return a signed collision verdict with the full score breakdown, so the discovery happens before launch — not a registry's exact-duplicate check, which lets near-names with overlapping purpose/capabilities pass silently
• I need the screen kept honest on its face: it is a similarity screen over a stated snapshot, never a trademark opinion, legal clearance, or launch permission; every verdict names its snapshot, scoring version, and thresholds; stored readings are never served without recompute-and-verify; and unverifiable material downgrades to UNVERIFIED_EXPORT with no verdict claim and no path back

Not tested

• Live-registry screening, any verdict carrying consequences in a real registry, or any real agent identity — fixture registry snapshot only; the SPEC §10 counsel gate is unbuilt by design, named, with no dormant live mode: screening against a live registry, a verdict carrying consequences in a real registry (blocking, flagging, or delaying a real launch), or any public marketing of the screen as clearance — each is a separate, counsel-cleared, re-benched build, with counsel review of (a) trademark-adjacent claim language and (b) the consequences a verdict may carry
• Any trademark opinion, legal clearance, or permission to launch — a Namesake verdict is a similarity screen over a stated snapshot (SPEC §11.2): a CLEAR verdict does not mean a name is legally available, non-infringing, or registrable anywhere, and a COLLISION verdict does not mean a name infringes anything; a CLEAR verdict means only 'no collision above threshold in this snapshot under namesake-score/1.0'. The SPEC §11.4 forbidden claim strings are never claimed for v0.1.1 (they are listed in SPEC §11.4 only and are not reproduced on this surface); no wording implies live registry coverage, registration, or legal advice, and no wording implies a verdict outcome can be bought (SPEC §9 / L7: metering attaches to the screen, identical for CLEAR, REVIEW, and COLLISION). Cross-script and homoglyph collisions are a known blind spot of v0.1 scoring (SPEC Q-N3): the fixture normaliser covers the Latin-script fixture set only, and no listing implies coverage the scorer does not have
• Production signing / public-key verification — v0.1.1 signing is a fixture HMAC stand-in for the Herald pattern (local fixture keys, keys/ gitignored, mode 600, never committed); the live RS256 Herald signing form is unbuilt and counsel-gated. Verification uses pinned fixture keys only — keys are pinned out-of-band and never read from, or selected by, a record under verification; the pinned key file holds shared HMAC secrets, not public keys, and no public-key or third-party verifiability is claimed. A fresh clone generates its own fixture keys to run the full suite
• Hosted or live operation — local stdio only; metering points only per SPEC §9 (exactly one Meter record per completed namesake_screen reaching a sealed verdict; refusals and same-snapshot idempotent re-screens emit none; CLEAR, REVIEW, and COLLISION meter identically), the $5/screen shape is a book reference with no charge path built and no live Meter ingest