Cyan Eclipse Sourceseal — Cyan Eclipse Bazaar

Vendor: Cyan Eclipse Technologies · Platforms: MCP over stdio

Certification scope

PASS(local) — Verity bench of v0.1.0 (2026-10-27, argus101-program-20261027/wave2/bench-sourceseal.md) PASS-CONDITIONAL(local) with conditions C1–C2; delta re-bench of v0.1.1 (rebench-sourceseal.md): C1+C2 CLOSED, new C3 (major, stored bundle not bound to requested answer) + C4 (minor, malformed store shapes crashed); delta re-bench round 2 of v0.1.2 (rebench2-sourceseal.md): C3+C4 CLOSED, new C5 (major, pack face/duplicated fields unbound and echoed verified on stored serve) + C6 (minor, store keys/siblings/metering unvalidated on the mutating path); delta re-bench round 3 of v0.1.3 (rebench3-sourceseal.md): C5+C6 CLOSED, C1–C6 all CLOSED, zero new findings, no new conditions — CONDITIONS CLOSED, Sourceseal — PASS(local). Builder suite re-run clean-state by the bencher at every bench: 22/22 at v0.1.0, 27/27 at v0.1.1, 34/34 at v0.1.2, 39/39 at v0.1.3; R3 independent probes: 152 in-process checks PASS / 0 FAIL plus subprocess wire/envelope/F-S9 battery PASS. Decisive fixture F-S9 independently reproduced at every bench in fresh processes from the shipped bundle + pinned keys alone, with content hashes also recomputed by bencher code straight from the raw store files: receipt_verify valid, source_reverify f1–f4 SOURCE_UNCHANGED; f1 mutated after seal → receipt chain still valid AND reverify SOURCE_CHANGED for exactly f1 (SPEC §6.4 asymmetry, both directions). PASS(local) is not CERTIFIED — certified is false, and nothing beyond the PASS verdict at its exact scope is claimed. Scope is exactly: local stdio MCP, fixture stores only, value_class:"test" throughout, fixture HMAC Herald stand-in (pinned herald-fixture); the SPEC §10 counsel gate (live/web fetch, reliance, republication) is unbuilt, confirmed — no code path exists; no claim about any real source's truth or any answer's faithfulness. Novel mechanism (SPEC §2.1, verbatim): each answer ships with its primary-source pointer plus a retrieval receipt (fetcher, time, content hash) — provenance at the granularity of one fact. Stored serves in v0.1.3 are verify-before-serve (C1), bind-before-serve (C3), malformed-store hardened (C4), canonical constructed faces with exact key sets and no echoed injections (C5), and whole-store validated before any write (C6). Non-blocking observations F3 (source_reverify by design never checks chain/seal — it carries no verified/sealed claim and must be paired with receipt_verify), F4 (HMAC fixture stand-in; fetcher identity is a named field, not a signature, Q-S2; primary-source adjudication is fixture-declared, Q-S3), and R3 O1–O3 remain observations, no conditions. SPEC §11.2 blunt scope limit: the receipt proves a fetch of specific bytes at a time by a named fetcher — it does not prove the source was truthful, nor that the answer faithfully represents the source.

What it does

Novel mechanism (SPEC §2.1, verbatim) — each answer ships with its primary-source pointer plus a retrieval receipt (fetcher, time, content hash) — lineage at the granularity of one fact. A bibliography or link list without a per-fact retrieval receipt is not this product (SPEC §0.6).
Per-fact retrieval receipts, hash-chained and sealed — for each fixture answer fact, the named fixture fetcher (fixture-fetcher/1.0) retrieves exactly the pointed-to bytes from a fixture source store; each receipt seals source_pointer (store_ref, locator, byte_range | record_ref) + fetcher identity/version + retrieved_at (RFC 3339 UTC, validated at seal and on verify) + content_hash + byte_length; receipts chain per answer (record_hash = sha256(canonical(record minus hash/seal fields) || prev_hash), seq 1-based gapless), and the receipt-stream head is sealed with the pinned fixture HMAC Herald stand-in (herald-fixture). No skipping: a sealed answer has a receipt for every fact — FACT_WITHOUT_RECEIPT, POINTER_UNRESOLVABLE:<fact_id> (draft UNSEALABLE), RECEIPT_DUPLICATE, and FETCHER_UNNAMED are named refusals that mutate nothing; sealing is idempotent on (answer_hash, receipt_set_hash) with exactly 1 metering point per sealed answer.
Offline verification + re-fetch verdicts, reported separately — sourceseal_receipt_verify recomputes answer_hash, every record_hash, the chain, receipt_set_hash, and the pinned seal from a presented bundle alone (no re-fetch); sourceseal_source_reverify re-fetches each pointer and returns per-fact verdicts only (SOURCE_UNCHANGED / SOURCE_CHANGED with both hashes / SOURCE_GONE), never a rolled-up verdict. Downgrade law (SPEC §6.4): an answer whose receipts do not verify exports only as UNSEALED_EXPORT (sealed:false); a later source change does NOT downgrade the original receipt — a valid receipt over a since-changed source is both receipt: valid and SOURCE_CHANGED, never conflated.
Stored-serve hardening (bench conditions C1–C6, all CLOSED at v0.1.3) — sourceseal_receipt_get and the idempotent re-serve path of sourceseal_answer_seal verify before serving (full receipt_verify recompute), bind the stored bundle to the requested answer (answer_id / answer_hash / receipt_set_hash against entry, key, and recomputation), survive malformed store shapes with structured downgrades/refusals (no uncaught exception escapes), serve only canonical constructed faces (code-constant face fields, computed sealed/verified booleans, exact key sets at bundle/answer/fact/pointer/receipt level; injected extra keys, face tampers, and receipt seal/signature keys are stripped or defect, never echoed verified), and validate the whole store (keys, entries, metering bijection) before any write — a garbage sibling, renamed key, or inconsistent metering refuses a fresh seal with MALFORMED_STORE and zero writes.
Decisive fixture F-S9 — bench-reproduced at v0.1.0 and as a regression at every delta re-bench through v0.1.3: in fresh processes, from the shipped bundle + pinned keys alone, receipt_verify confirms every receipt and source_reverify recomputes every content_hash from the fixture stores (all SOURCE_UNCHANGED; bencher also recomputed hashes independently from raw store files); one source mutated after seal → receipt chain still valid, reverify returns SOURCE_CHANGED for exactly that fact. A pointer-only (hash-blind) verifier cannot pass this test.
Blunt scope limit (SPEC §11.2, verbatim in substance) — the receipt proves a fetch of specific bytes at a time by a named fetcher — it does not prove the source was truthful, nor that the answer faithfully represents the source. Faithfulness checking is Quoteline's surface; Sourceseal claims neither property, and no receipt is ever worded as a claim about a source's truth or an answer's faithfulness.

Tools

sourceseal_answer_sealsourceseal_receipt_getsourceseal_receipt_verifysourceseal_source_reverify

Problems it addresses

Answers cite sources at document granularity, if at all: a link proves a page existed, not which bytes supported which fact, when they were read, or whether they have since changed
A source my answer relied on changed after I shipped it — I need that surfaced as a named, per-fact verdict with both hashes recorded, not silently hidden and not treated as a defect in the original receipt
I need provenance a holder can recompute offline: per fact, the primary-source pointer, the named fetcher, the retrieval time, and the content hash of exactly the retrieved bytes, sealed in a hash-chained receipt stream

Not tested

Live or web source fetching, shipping receipts relied on as attribution or evidence for real answers, or any republication of retrieved content beyond hashes/pointers — the SPEC §10 counsel gate is unbuilt by design, named, with no dormant live mode: each live phase is a separate, counsel-cleared (copyright/terms/reliance review), re-benched build. v0.1.3 has zero network code; fixture reads are local file reads by pointer, and the fail-closed fence refuses URL-fetch config, non-fixture endpoints, live keys, and value_class other than "test" at startup and per-tool
Any claim about a real source's truth or a real answer's faithfulness — a Sourceseal receipt proves a fetch of specific bytes at a time by a named fetcher; it does not prove the source was truthful, nor that the answer faithfully represents the source (SPEC §11.2). Faithfulness checking is Quoteline's surface, never performed or implied here. The SPEC §11.4 forbidden claim strings are never claimed for v0.1.3 (they are listed in SPEC §11.4 only and are not reproduced on this surface)
Production signing / public-key verification — v0.1.3 signing is a fixture HMAC stand-in for Herald (pinned ref herald-fixture, local fixture key in keys/, gitignored, mode 600, never committed); live RS256 Herald is unbuilt and counsel-gated. The pinned key file holds a shared HMAC secret, not a public key, and no public-key or third-party verifiability is claimed. Fetcher identity is a named field, not a signature (SPEC Q-S2, stated not solved), and primary-source determination is fixture-declared in v0.1.3 (Q-S3) — bench observation F4. A fresh clone generates its own fixture keys to run the full suite
source_reverify alone as a verification — by SPEC §6.2 separation it never checks chain/seal and carries no sealed/verified claim (bench observation F3); a holder must pair receipt_verify (chain + pinned seal recompute) with source_reverify (per-fact SOURCE_UNCHANGED / SOURCE_CHANGED / SOURCE_GONE verdicts)
Hosted or live operation — local stdio only; metering points only per SPEC §9 (exactly one Meter record per completed sourceseal_answer_seal reaching SEALED; verification and re-fetch emit no metering event), the $0.01/answer shape is a book reference with no charge path built and no live Meter ingest

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 →