Cyan Eclipse Allowance

Vendor: Cyan Eclipse Technologies · Platforms: MCP over stdio

What it does

• Novel mechanism (SPEC §2.1, verbatim) — category caps, merchant lists, and amounts are sealed by the account holder; every spend lands in a family ledger as a receipt the agent cannot edit.
• Decisive fixture F-A13 stands from the bench record — in a fresh process from the export alone, empty data dir, Verity-generated pinned keys: ALLOWANCE_VERIFY_PASS, spends_checked: 5 (regression spot, delta re-bench 2); the 99999 cap-breaching attempt is present only in the refusal log, never in the ledger; tampered entries fail verification by hash/chain/Herald counter-signature while the untampered chain verifies.
• Integrity (v0.1.2, R1–R7 closed at delta re-bench 2) — each mandate's ledger entries form their own hash chain under a per-mandate signed head anchor; metering is sealed per-mandate and store-wide, so wiping, fabricating, or subset-rolling metering is detected; offline verification fails closed on absent/invalid/unverifiable holder signatures (step 1, by name); seal inputs carry exact field sets (unknown keys refused by name, never echoed); serves are constructed from verified components; amendments must be timestamped after every existing record; malformed store shapes are named store defects on every entry path with zero raw exceptions and zero writes on mutation paths.
• Condition 1 — R8 — cross-mandate transplant id↔hash pairing is detected only indirectly (transplanted record never served/counted/exported); Tier-G structural check or README fence stands as the condition.
• Condition 2 — O1 — ledger_get VERIFIED slice-export vs downgraded faces on a Tier-G-defected store (documented slice semantics; no false data).
• Rollback fence (README Integrity model (v0.1.2), verbatim): Honesty fence — rollback residual: within this local file model, a rollback that restores *every* local artifact (mandates, ledger, refusals, revocations, all anchors, and metering) to one consistent earlier snapshot is undetectable; the per-mandate anchors and the sealed-metering cross-checks detect partial rollbacks, subset restores, and single-artifact tampering, not a complete coordinated snapshot restore. Detecting a full coordinated restore requires an external anchor outside the local store; an external anchor is required for any live or multi-party use and is not built in this local/simulator scope. No stronger claim is made.
• Key-fact label (SPEC §11.2, verbatim): ledger receipts are Herald-counter-signed; the household agent holds no ledger signing key. It is never shortened to "tamper-proof" or "immutable": the claim is specifically about the agent, and detection (§6.4 offline recomputation), not metaphysical impossibility. A refused spend is a check result — "refused at mandate check (simulator)" — not a protection outcome: enforcement of a refusal at an actual purchase step is the consuming platform's act, and a spend a platform never presents produces no refusal and no record.
• Downgrade law (SPEC §6.5) — an export that cannot be recomputed (chain, Herald counter-signatures, mandate seal) receives only a labelled UNVERIFIED_LEDGER_EXPORT (agent_editable: unknown, recomputable: false) on its face; no tool path removes a refusal, repairs a broken chain, re-signs an entry, or converts a refusal into a spend.
• Format attribution is exact and minimal: mandates are Till mandate objects carrying the Allowance profile (Till consumed, never redefined), counter-signing is Herald's pattern (fixture HMAC stand-in), and metering points are emitted in Meter grammar — consumed, never redefined. Cyan Eclipse Verity Bench and Eclipse Cupel are internal tools, not products: this product has no dependency on them, no integration with them, and no buy path, price, licence, or checkout for them anywhere.

Tools

Problems it addresses

• Household agents are being handed purchasing power under rules that live in a settings screen the agent's operator can change, a prompt the agent can be talked out of, or a log the agent itself writes — parents get a dashboard summary authored by the very system it summarises
• I need the three roles separated: the holder seals the rules (category caps, merchant lists, amounts), the mandate check enforces them at spend time before any ledger entry exists, and the ledger is counter-signed by a key the agent does not hold
• I need a cap-breaching spend refused whole — logged as a named refusal beside, never inside, the signed spend chain, moving no totals and appearing nowhere as a compliant spend — and a ledger any family member can recompute offline from the export alone

Not tested

• Cross-mandate record transplant, id↔hash pairing — CONDITION 1 (bench, verbatim): R8 — cross-mandate transplant id↔hash pairing is detected only indirectly (transplanted record never served/counted/exported); Tier-G structural check or README fence stands as the condition. Bench condition text (verbatim): R8: add the id↔hash pairing to the structural/Tier-G check (an entry whose `mandate_id` and `mandate_hash` name different mandates defects the store on every path, incl. target-mandate spend), or fence the pairing class in the README integrity section. The README fence stands in v0.1.2: the transplanted record is never served, counted, or exported as the target mandate's; the source mandate goes SEAL_DEFECT and the target mandate's history downgrades; the hash-also-switched variant is fully detected (SEAL_DEFECT, verify FAIL step 2).
• ledger_get slice semantics on a Tier-G-defected store — CONDITION 2 (bench, verbatim): O1 — ledger_get VERIFIED slice-export vs downgraded faces on a Tier-G-defected store (documented slice semantics; no false data). Bench condition text (verbatim): O1: make `ledger_get` downgrade when Tier-G defect exists outside the served slice, or document the slice-only semantics on the export face. The slice-only semantics are documented on the export face and in the README: the export attests only the clean per-mandate slice it serves, no false data is served, and status/history/refusal faces downgrade on the same store.
• Full coordinated restore of all local artifacts to a consistent earlier snapshot — Honesty fence — rollback residual: within this local file model, a rollback that restores *every* local artifact (mandates, ledger, refusals, revocations, all anchors, and metering) to one consistent earlier snapshot is undetectable; the per-mandate anchors and the sealed-metering cross-checks detect partial rollbacks, subset restores, and single-artifact tampering, not a complete coordinated snapshot restore. Detecting a full coordinated restore requires an external anchor outside the local store; an external anchor is required for any live or multi-party use and is not built in this local/simulator scope. No stronger claim is made.
• Counsel-gated phase (SPEC §10, named, unbuilt/unclaimed): any live household spend — real payment rails, real merchant presentment, mandates governing minors' actual purchases, custodial or stored-value anything, platform contracts making refusals financially effective — is out of v0.1, hard. The live phase is a separate post-gate, re-benched build: counsel review of consumer-finance / payments exposure, minors'-finance and consent questions (who may seal for whom), and the §11 label set first. No dormant rail path and no real-money shape exists in v0.1.2 — the startup fence refuses payment-rail / bank / card configuration, non-local endpoints, and agent-side ledger signer keys.
• Real money and real households — fixture mandates only: fixture holders, members, agents, merchants, categories, and spends under a deterministic seed + fixture clock; merchant/category refs name no real merchant or family, and every artifact carries value_class "test"
• Live Herald signing — v0.1.2 signing is a fixture HMAC stand-in for the Herald RS256 pattern, disclosed on the product's face; verification keys are pinned out-of-band in code — a presented record can never select its own verification key
• Production key custody — fixture keys live split per role in keys/ (keys/holder-key.json, keys/recorder-key.json, keys/herald-key.json, keys/holder-token.json; chmod 600, gitignored, never committed); an agent-surface process loads only the recorder and Herald role files and never loads holder key material or the holder token; a fresh clone must create its own per-role fixture key files to run the full suite
• Hosted or live operation / charge path — local stdio only; metering points only per SPEC §9.1 (mandate_active — one per ACTIVE mandate per fixture period; premium_mandate_active; spend_recorded / spend_refused counts, informational), no charge path is built, no payment is taken, and no live Meter ingest is claimed; downgraded exports and refused spends are not premium metering points