Cyan Eclipse Fairlend

Vendor: Cyan Eclipse Technologies · Platforms: MCP over stdio

What it does

• Novel mechanism (SPEC §2.1, verbatim) — each decision seals its feature set, model version, and adverse-action reason codes at decision time, making later disparate-impact audits a recompute.
• Fairlend never decides: it makes no credit decision and influences none — it has no scoring, approval, denial, pricing, override, or recommendation function. A Fairlend seal proves what was recorded at decision time — the presented feature set, model version, and reason codes, counter-signed then. It does not prove the decision was fair, lawful, unbiased, or correct.
• Bench path: v0.1.0 bench (wave4/bench-fairlend.md, defects D-1..D-10) + v0.1.1 delta re-bench (wave4/rebench-fairlend.md: D-1..D-6, D-8, D-9, D-10 CLOSED; D-7 closed for its probed class with residual Low defect D-11, named below; builder suite 36/36 reproduced).
• D-11 — NAMED standing condition (Low, residual of the D-7 class): the SPEC §7.3 identifier fence is still evadable by token-split spellings. Feature names that seal today when they should refuse: tax_id, tax_id_number, taxIdNumber, taxpayer_id, ein, ein_number, gov_id, govt_id, govtId, social_sec_no (government-id class), surname, home_street (name/address classes). Cause (from the re-bench): the checker matches whole tokens and a substring list that omits taxid; splitting a compound into tax+id tokens defeats both. D-11 must close before any non-fixture scope; it does not expand v0.1.1's fixture scope, and the same helper binds seal_verify and recompute step 3, so the gap is consistent, not divergent.
• Rollback fence: pure local file store caps verdict at PASS-CONDITIONAL — external anchor required before live/multi-party use. Fair-lending counsel gate (SPEC §10) — named, unbuilt: any use beyond fixture decisions — real applicants, a real model, a real lender's decision stream, real adverse-action reason codes, audit figures relied on by any party, or any applicant-facing artifact — is out of v0.1, hard, until fair-lending counsel clears it in writing; v0.1.1 contains no dormant live path.
• Cohort tags are fixture-supplied labels sealed with the record (synthetic cohorts — cohort-A / cohort-B over invented records); Fairlend never infers a cohort, and untagged records are counted and excluded from cohort rates visibly. Late-presented decisions export only as downgraded LATE_RECORDED_EXPORT — there is no backdating path. Hash construction is pinned in SPEC §4.1 and reproduced by the bench from the documented text alone. Herald (signing pattern), Meter (metering grammar), and Docket (pack shape) are consumed by reference only.

Tools

Problems it addresses

• A lending decision is made from inputs that are never frozen — feature set, model version, reason codes — so a later disparate-impact audit has nothing to recompute from but logs and memory
• I need each decision sealed at decision time with the exact inputs that produced it, so the audit is a deterministic recompute over seals — reproducible figures, not an argument
• I need the evidence tool itself to be incapable of deciding: no scoring, approval, denial, pricing, or recommendation function — and a seal that never claims the decision was fair, lawful, unbiased, or correct

Not tested

• Any use beyond fixture decisions — real applicants, a real model, a real lender's decision stream, real adverse-action reason codes, audit figures relied on by any party, or any applicant-facing artifact is SPEC §10 fair-lending-counsel-gated and UNBUILT; v0.1.1 contains no dormant live path
• Credit-decision correctness or fairness — Fairlend never decides: it has no scoring, approval, denial, pricing, override, or recommendation function, and a seal does not prove the decision was fair, lawful, unbiased, or correct
• Token-split identifier spellings (D-11, NAMED standing condition): tax_id, tax_id_number, taxIdNumber, taxpayer_id, ein, ein_number, gov_id, govt_id, govtId, social_sec_no, surname, home_street seal today when they should refuse — a known residual Low in the SPEC §7.3 fence that must close before any non-fixture scope
• External anchoring / multi-party reliance — the pure local file store caps any verdict at PASS-CONDITIONAL (local/fixture); an external anchor is required before live or multi-party reliance
• Production key custody — signing is an HMAC fixture stand-in for Herald RS256 (fixture keys in keys/, gitignored, mode 600); a live phase would need real Herald signing and a re-bench