Appearance

Use Case: EU AI Act-Compliant Credit Scoring ​

How to wrap an existing credit-scoring model so every "denied" decision comes with a cryptographically replayable audit certificate that supports Article 13 transparency requirements.

Access

Production integrations (HLM3 scoring model, distillation mirror, certificate library) are delivered through a commercial engagement. This page describes the mechanism and what it buys you legally.

Who this is for ​

  • Fintech / bank compliance officers navigating the EU AI Act's high-risk AI system classification
  • ML engineers who shipped a credit-scoring transformer and are now being asked "prove why it denied that application"
  • Regtech product leads selling XAI tooling into EU-regulated industries

The problem you're solving ​

EU AI Act Article 13 requires high-risk AI systems be "designed and developed in such a way as to ensure that their operation is sufficiently transparent to enable deployers to interpret the system's output and use it appropriately."

The standard toolkit fails this bar. SHAP and LIME produce attribution heatmaps — but those heatmaps come from a surrogate model (a sampled local approximation), not the production model. When a regulator asks "prove this explanation corresponds to the inference that actually ran," SHAP cannot answer. The explanation and the prediction come from two different objects.

This isn't a philosophical gap — it's a legal gap. A denied applicant has the right to appeal. An auditor has the right to verify. Current XAI gives them approximations of explanations. It does not give them proofs.

What the integration delivers ​

A wrapper around your existing transformer (or an HLM3 scoring model) that emits per inference:

  1. A prediction (denied / approved / refer-to-human)
  2. A SHA-256 audit certificate binding the input features, model weights, and per-layer inference trajectory
  3. A compliance log entry replayable by any third party with access to the weights hash

The certificate is ~650 bytes as JSON, or ~20 bytes as a bare digest. Generation cost: sub-millisecond per inference. No impact on prediction latency.

The stack ​

PieceDelivery
HLM3 scoring model (Option A)HLM3 + Energy Language surgery
Distillation mirror (Option B)Commercial engagement — see option B below
Audit certificate libraryBundled with commercial release
Your existing credit-scoring pipelineKept unchanged on the decision-making side
Compliance log storageWhatever you already use (S3, Postgres, etc.) — certificates are tiny, just store alongside each decision

How it works ​

1. What the certificate proves ​

The certificate proves three simultaneous facts:

  1. This specific input was fed to this specific model
  2. This model produced this specific trajectory (sequence of basin states)
  3. This trajectory produced this specific output

If any of those three links are broken (input altered, weights swapped, prediction fabricated) the certificate fails replay-verification.

It does not prove the prediction was correct, fair, or legal. It's a chain-of-custody primitive — evidence that a specific computation happened, not evidence that the computation was the right one to run.

2. Option A — use HLM3 as the production model ​

If you're at model-selection stage, HLM3 has the certificate built in. Each inference returns a (prediction, certificate) pair. The certificate is stored alongside the decision in your compliance log (JSON body or bare digest).

3. Option B — wrap an existing transformer via a shadow HLM ​

If your production model is already a transformer and swapping it out isn't feasible, an HLM3 mirror can be distilled from it. The production flow becomes:

  • The transformer makes the decision (unchanged behaviour)
  • The HLM mirror runs in parallel and produces the certificate
  • A sanity check flags any mirror/teacher disagreement for human review

Option B is a partnership-level delivery. Contact us for current status of the distillation MVP.

4. Regulator / auditor replay flow ​

The regulator arrives with a redacted applicant file and asks "explain this specific decision." You hand them:

  1. The input feature vector (redacted to non-PII if needed)
  2. The certificate JSON
  3. Your model weights hash (not the weights themselves — just the hash)

They run the verification routine against the model (or a signed distribution of it). Either the certificate passes — the trajectory is the trajectory that produced the decision, cryptographically — or it fails, in which case the bank's record is contested.

Unlike SHAP, the regulator is not reading an approximation. They are re-running the actual decision computation and verifying cryptographic equality. The explanation and the decision are the same object.

5. Deposition-ready paper trail ​

In an appeal process the sequence becomes:

  • Applicant: "The AI denied me — why?"
  • Bank compliance: "Here's the certificate and the feature vector we used."
  • Applicant's lawyer or independent auditor: Runs the verification routine on their own machine with the signed weights. Either the certificate passes (the decision is as stated) or fails (the bank's record is contested).

This is a legally tractable object. SHAP's attribution heatmap is not.

  • This does not make a decision fair. It makes the decision's provenance verifiable. If the underlying model is biased, the certificate documents a biased decision — it does not correct it. Fairness auditing is a separate workstream.
  • Certificate security depends on signed weights distribution. The hash-chain is only as trustworthy as the weights-hash supply chain. Use a signed release process (cosign, Sigstore, or equivalent).
  • Regulator acceptance is a legal question. As of 2026-04-24, no EU AI Act auditor has accepted a cryptographic certificate as formal compliance evidence in a binding ruling. The technology is here; the legal precedent is the part that takes pilot deployments to establish.
  • Option B (distillation mirror) is not yet production-ready. Contact us for current status of the MVP.