Cyan Eclipse Lineage MCP — Cyan Eclipse Bazaar

Vendor: Cyan Eclipse Technologies · Platforms: MCP over stdio — local v0.1 build; records stay on the operator's machine

Certification scope

CERTIFIED(local) — Eclipse Bazaar Test Bench 2026-10-26, standing card run 3 (scoped re-bench): 10 pass, 0 na of 10 checks — L10/L14/L4, minors m1–m3 and spot regressions L1/L5/L8 re-probed PASS; all other lines stand as scored on run 2. Runs 1 and 2 FAILED and are retained append-only (test-bench/results/eclipse-lineage-mcp-2026-10-26.json, eclipse-lineage-mcp-2026-10-26-2.json); run 3 closed D1 (corroboration forgery), D2 (unvalidated hash values) and D3 (behavior_relevant laundering parameter) at the mechanism level, not the fixture level. CORROBORATION HONESTY — read exactly: in v0 there is no per-agent key registry, so presented corroboration strings are UNVERIFIABLE by construction; they are labeled corroboration_unverified in the signed, hash-chained record body (tamper-evident, proven at L10), and absence shapes stay claim_only. Self-emission is labeled a subject-provided claim forever; no surface upgrades a claim to a fact. CEILING: CERTIFIED(local), self/consented emission only — framework emission adapters are NOT built (G-LIVE per framework), external/hosted lineage is NOT built (G-OWNER); v0 signs with a local seed key (keys/, gitignored) and production findings-key custody is a gated decision.

What it does

Generation semantics: a behavior-relevant config change (model id, system-prompt hash, tool-surface hash, policy ref) MINTS a new generation identity as a new append-only record — a write aimed at an existing generation refuses GENERATION_IMMUTABLE by name
Per-root hash chains, signed: lineage_verify recomputes each root's chain and names the first broken link; system prompts and configs are recorded as hashes + owner-held refs only — there is no prompt_get
Lineage labels that never overclaim: self-emission is a subject-provided claim forever; parent+child signature corroboration is labeled corroborated — and in v0, presented corroboration strings are unverifiable by construction (no per-agent key registry), so they are labeled corroboration_unverified inside the signed record body; a spawn without a mandate ref is recorded UNMANDATED, visible, never hidden
Hash values are shape-validated everywhere they enter (SHA-256, 64 hex chars) — non-digest values refuse HASH_VALUE_INVALID with nothing stored
Self/consented emission only: framework emission adapters (G-LIVE per framework) and any external or hosted emission surface (G-OWNER) are held, not built; family T3 is empty — no rewrite, prune, delist or enforcement verb exists

Tools

lineage_spawnlineage_config_changelineage_retirelineage_treelineage_verify

Problems it addresses

When an agent misbehaves I need its spawn tree and exact config ancestry — which model, which prompt hash, which tool surface — not a changelog someone edited
Self-reported provenance is a claim, not a fact; the labeling has to say so instead of laundering claims into corroboration
A config change must mint a new generation identity — editing history in place destroys the audit

Not tested

Framework emission adapters — NOT built (G-LIVE per framework); v0 emission is self/consented only via the MCP tools
External emission / hosted lineage for enterprises — NOT built (G-OWNER); records stay on the operator's machine
Production findings-key custody — v0 signs with a local seed key (keys/, gitignored, chmod 600); custody is a gated decision

Bench scorecard: test-bench/results/eclipse-lineage-mcp-2026-10-26-3.json

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 →