
Eclipse Sourceseal
Per-fact retrieval receipts over fixture source stores — each answer ships with its primary-source pointer plus a retrieval receipt (fetcher, time, content hash), provenance at the granularity of one fact. PASS(local) — local stdio MCP, fixture stores only, value_class "test"; 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.
status: in-developmentclass: mcpTrust & Receipts
Vendor: Cyan Eclipse Technologies
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) — provenance 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_seal · sourceseal_receipt_get · sourceseal_receipt_verify · sourceseal_source_reverify
Platforms
- MCP over stdio
Certification
Bench verdict: PASS(local)
Certified 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.
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
Live state note: Bench evidence: argus101-program-20261027/wave2/bench-sourceseal.md (Verity bench of v0.1.0, PASS-CONDITIONAL(local), conditions C1–C2, builder suite re-run clean-state twice 22/22, F-S9 decisive fixture independent in fresh processes both directions, adversarial pass: record-supplied key refs ignored, forged seals fail at seal, single-field receipt tampers fail at named steps, forgery/duplication pins, presented-verdict substitution ignored, 60-call malformed-args battery with store byte-identical, refusal-must-not-mutate, key custody 600/gitignored) + rebench-sourceseal.md (v0.1.1: C1+C2 CLOSED, suite 27/27, new C3+C4) + rebench2-sourceseal.md (v0.1.2: C3+C4 CLOSED, suite 34/34, new C5+C6) + rebench3-sourceseal.md (v0.1.3: C5+C6 CLOSED, C1–C6 all CLOSED, suite 39/39, 152 independent in-process checks PASS / 0 FAIL, gate sweep defecting at the same named step on every serve surface, F-S9 re-confirmed, no new conditions). No test-bench scorecard was issued for this verdict and none is claimed (scorecard_ref/card_url null).
Pricing
PRICED — $0.01/answer, via the Eclipse Bazaar bench-order/intake path only. No checkout, payment, or buy-now link exists for this product, and no Stripe object exists for it in this pass: intake orders are reviewed and confirmed by the operator before any payment link is sent. Metering shape per SPEC §9 (metering points only in v0.1.3, no charge path built): exactly one Meter record per completed sourceseal_answer_seal reaching SEALED — the sealed answer is the priced unit; verification and re-fetch emit no metering event, and idempotent re-seals emit no second event. The local package is the reference implementation. Repository is PRIVATE (priced-product policy).
Install / verify
No install command is published for this product in the catalog or its registry record.
Official MCP Registry name: io.github.CYAN-ECLIPSE-TECHNOLOGIES-LLC/eclipse-sourceseal-mcp
Registry listing: https://registry.modelcontextprotocol.io/v0.1/servers/io.github.CYAN-ECLIPSE-TECHNOLOGIES-LLC%2Feclipse-sourceseal-mcp/versions/0.1.3
Repository: https://github.com/CYAN-ECLIPSE-TECHNOLOGIES-LLC/eclipse-sourceseal-mcp
Verify any MCP server in your client configs against this catalog with bazaar check (Eclipse Bazaar MCP / CLI — see llms.txt).