Cyan Eclipse Rebuttal

Vendor: Cyan Eclipse Technologies · Platforms: MCP over stdio

What it does

• Novel mechanism — auto-translation of the sealed Procure/Till mandate chain into generic reason-code evidence format (SPEC §3): ingest_dispute seals the dispute + mandate-chain + receipt records into one case with a chain hash; map_evidence translates that sealed chain, per dispute reason class, into evidence sections where every evidence element is traced to a specific mandate/receipt/dispute record id (source_record_id) — an untraced element cannot be emitted. The mandate facts translated are exactly the agent-commerce facts incumbents do not carry: who authorized what (authorized_by, agent_id, action), the authorization scope, transaction-within-scope derivation, and the drift-abort log (out-of-scope attempts the agent aborted), included whenever present. Bench P1: 11/11 elements traced to existing record ids, source_type consistent, values faithful; within_scope derivation arithmetic verified.
• Completeness honesty — a packet built from an incomplete mandate chain is marked INCOMPLETE with each missing element named (dispute_id, dispute_reason_class, dispute_amount, dispute_order_ref, mandate_chain, mandate_authorization, mandate_scope, receipt_record, receipt_order_ref_match, receipt_amount); a missing evidence section renders MISSING with zero elements and evidence is never fabricated. Bench anti-fabrication battery PASS: each gap case validated INCOMPLETE naming the exact gap, packet marked INCOMPLETE, section MISSING/empty, zero banned evidence strings in evidence JSON or text rendering; drift-abort absence handled honestly (no_events_declared, zero elements, nothing invented).
• Seal-gated translation + full-packet seal (v0.1.1 fixes for bench defects D1/D2, both HIGH): map_evidence/build_packet recompute the case seal before translating — a tampered stored case is a hard refusal (SEAL_INVALID), no packet is stored and the attacker value is emitted nowhere (re-bench C1: 6/6). The packet seal covers the FULL packet including text_rendering — appended/fabricated text, stored text tamper, and an edit-any-field sweep (12/12) all verify INVALID (re-bench C2: 5/5).
• Receipt attribution + no null elements (v0.1.1 fixes for bench defects D3/D5): the receipts[0] fallback is removed — only a receipt whose order_ref equals the dispute's is receipt evidence; a mismatched receipt (ORD-OTHER-999 under both unauthorized and processing_error) renders receipt sections MISSING with zero elements, the packet is INCOMPLETE, and the mismatched record_id/order_ref/amount/merchant occur nowhere in packet JSON or text (re-bench C3: 8/8). Null-valued dispute fields emit no elements — order_identification renders MISSING when no present values exist, partial nulls emit only present values (re-bench D5: 6/6).
• Keyed seal + honest scope: seals are HMAC-SHA256 with a runtime-generated local DEMO key (keys/demo.key, gitignored, mode 0600) — external re-seal attacks (unkeyed SHA-256, wrong-key HMAC, foreign-key store) all verify INVALID while the legitimate key-holder flow verifies VALID (re-bench C4: 7/7); the demo key proves 'unchanged since sealed under this local demo key' only, not a production/network signature. LOCAL/fixture scope only — packet generation only: no card network, issuer, merchant, or platform is contacted, no network calls, and the tool never files, submits, or transmits anything. Reason-code mapping is a small generic table (GEN-* codes) labelled generic — not any card network's proprietary reason codes, no network affiliation claimed. Python 3 standard library only; MCP over stdio; exactly 5 tools (submit_packet/file_chargeback/transmit_packet -> NO_SUCH_TOOL); no payment or checkout code — the $5.00/filing term is a pricing statement only.

Tools

Problems it addresses

• My agent made a purchase that is now disputed — I need a chargeback rebuttal evidence packet built from the original Procure/Till mandate and receipt chain, with every evidence element traced to its source record
• If the mandate chain is incomplete or a receipt does not match the disputed order, the packet must say INCOMPLETE and name the gap — evidence must never be fabricated or borrowed from another order
• I need the packet sealed so any tampering — including editing its human-readable text rendering — is detectable, and a tampered case must never be re-sealed into a valid packet

Not tested

• Filing, submission, or transmission to any card network, issuer, merchant, or platform — not in v0.1.1 by design (SPEC §9 non-goals): packet generation only, no network calls at all
• Hosted or remote serving — v0.1.1 is local stdio only, operating on caller-supplied fixture dispute + mandate-chain + receipt data
• Payment, checkout, or per-filing metering enforcement — none exists in v0.1.1 by design: the $5.00/filing term is commercial metadata (PC-7 pattern); no payment or checkout code is in the server
• Proprietary network reason codes or network affiliation — mapping is a small generic GEN-* table, labelled generic; no legal advice or win/loss prediction is provided
• Production key custody — seals use an HMAC-SHA256 demo key generated locally (gitignored keys/demo.key); the seal proves unchanged-since-sealed under that local demo key only, no production key claim is made