Cyan Eclipse Adproof

Vendor: Cyan Eclipse Technologies · Platforms: MCP over stdio

What it does

• Novel mechanism — a claim cannot pass the publish gate without a sealed pointer to its substantiation document; the published artifact carries the pointer (SPEC §2.1). Load-bearing label (SPEC §11.1, verbatim): the pointer proves substantiation was BOUND, not that it substantiates — substantiation adequacy is the publisher's/counsel's call.
• Seal, gate on verification, carry — at bind time claim_hash and substantiation_doc_hash plus document ref, binder ref, and bind time are sealed into a hash-chained bind record with two signatures (binder counter-signature + Herald RS256 JWS). At publish the gate recomputes both hashes from the artifact and document as presented and verifies the seal — a pointer merely present, stale, or pointing at a different document does not pass; there is no override verb, manual pass, or publish-first-bind-later path. The published fixture artifact embeds the pointer triple (bind_id, claim_hash, substantiation_doc_hash) on its face in an in-band footer block.
• Offline pointer verification (SPEC §6.4) — a pure function of the published artifact + the document + the pointer (+ optional gate receipt / chain segment) + the pinned public keys in keys/pinned-public.json: recompute claim and document hashes from source bytes (presented digests are never trusted), verify both signatures against pinned keys only (a key carried on a pointer, receipt, or tool argument is never consumed), walk the chain, and check the gate receipt. Failing steps are named VERIFY_FAIL:1..5. Unverifiable material exports only as UNVERIFIED_EXPORT, verified: false — downgrade law: no tool path upgrades it and no path from it leads to a gate pass.
• Decisive fixture + C1 closure — bench F-A10: end-to-end bound/gated/published fixture artifact verified VERIFY_PASS in a fresh subprocess with an empty data dir (no store created), and every tamper fails at its named step. At v0.1.1 the state machine is closed as specced (SPEC §3.1): adproof_bind refuses a claim_hash with no submitted claim record as CLAIM_NOT_SUBMITTED — no state change, no metering — so BOUND without CLAIM_HASHED does not exist, and the zero-submit sequence that previously reached PUBLISHED/VERIFY_PASS now refuses at bind.
• F5 scope fence (standing, exactly as benched) — RSA key generation uses the random module (Mersenne Twister), not a CSPRNG. That is acceptable only for these fixture keys at this local/fixture scope. Before any scope above fixture is ever contemplated, key generation must move to a CSPRNG and be re-benched; no scope claim above local/fixture is made or implied by this code.
• Honest scope — LOCAL stdio, fixture claims/documents ONLY: no live publisher, ad platform, or marketing system is touched, no real claim or real substantiation document enters a fixture, and every emitted artifact carries value_class "test". Adproof binds, gates, and stamps: it does not read a document and judge it, does not rewrite claims, and does not approve claims — closed surface of exactly 6 tools; no adequacy/score/approve/pay/charge verb exists. Startup is fail-closed (CONFIG_FENCE_REFUSED:<class>) on a live endpoint, an enabled network client, a non-fixture source, or value_class other than 'test'; no network or publisher client exists in the tree.

Tools

Problems it addresses

• My agent generates marketing claims and the substantiation lives in a separate folder or an approver's memory — after publication nothing in the artifact itself says which document was supposed to support which claim, and a claim edited after review silently inherits the earlier approval
• I need publication gated structurally, not by checklist: an unbound claim cannot pass, an edited claim no longer matches its pointer, and the pointer travels with the published artifact so a later reader can recompute which document was bound to which claim at publish time — offline, from the artifact plus the document and public keys alone
• I need the binding claim kept honest on its face: the pointer proves substantiation was BOUND, not that it substantiates — adequacy stays the publisher's/counsel's call, and unverifiable links downgrade to UNVERIFIED_EXPORT instead of being upgraded post-hoc

Not tested

• Real claims, real substantiation documents, or any live publisher / ad-platform / marketing use — fixture claims/documents only; the SPEC §10 advertising-claims counsel gate is unbuilt by design, named, with no dormant live mode: before any live use counsel must clear (a) §11's label language, (b) the gate's marketing description, (c) what, if anything, a carried pointer may be represented as to advertisers, publishers, and regulators
• Substantiation adequacy — whether a document actually substantiates a claim, and whether a claim may lawfully run, is the publisher's/advertiser's call with their counsel, outside Adproof entirely; never claimed for v0.1.1 are 'substantiated', 'verified claim', 'compliant advertising', 'FTC-safe', 'legally cleared', or any implication that a gate PASS means a claim is true, supported, or lawful to publish; no tool reads, scores, or reviews a substantiation document's contents (no adequacy verb exists)
• F5 — RSA key generation uses the random module (Mersenne Twister), not a CSPRNG: acceptable only for fixture keys at local/fixture scope; any scope above fixture requires CSPRNG key generation and a re-bench, and no such scope is claimed
• Bench C2 notes F3/F4, left as documented notes at v0.1.1 — the key-argument blocklist is enumerative rather than an allowlist (inert: no code path consumes a key from a pointer, receipt, or tool argument; verification uses pinned public keys only), and the function layer tolerates extra/irrelevant fields (server schemas declare additionalProperties: false but server.handle does not enforce schemas; no malformed required field was accepted in any bench test)
• Production key custody — fixture keys are local-only in keys/ (gitignored, mode 600, never committed); a fresh clone generates its own fixture keys on first run to run the full suite
• Hosted or live operation — local stdio only; metering point only per claim bound ($0.05/claim shape), no charge path built and no live Meter ingest