Level 4 · In depth — Art. 12, DORA and the revisited articles

§4 — Article 12, deep: record-keeping is git-native logging

Levels 1–3 met Articles 9–15 lightly or one-at-a-time. Level 4’s first deep article is Art. 12 (record-keeping) — and it is deep in a way unique to this engine: the commit graph is the log.

Article 12 obliges a high-risk system to automatically record events (“logs”) over its lifetime so that its functioning is traceable. Most platforms read that as runtime telemetry — a stream of events emitted by a running model. This engine reads it ex ante and git-native: every governance event is a commit (plain text) and the record is the immutable, append-only git history itself; what is signed is the evidence (bundle.json and the conformances). Concretely, in the loan repo:

• The lifecycle is in signed acts, not a database. The request is the act .froga/acts/NNNN-request.json; the approval is .froga/acts/NNNN-approve.json (signed DSSE ECDSA-P256 envelopes, verified against signers:). There is no mutable “status” field anywhere — the state is which signed acts exist in the history. That is tamper-evident by construction: rewriting an act invalidates its signature and changes the commit hash and every descendant hash, and the signed evidence (bundle.json) separately pins what was approved.
• The evidence is anchored. The signed bundle.json carries a pipeline_lock_digest — the digest of the locked pipeline (data + code + params) that produced the measured numbers. The log does not just say “this was approved”; it pins exactly which model, on which data, with which threshold, yielding which residual was approved.
• The whole graph is replayable. Because every beat is a commit and the digests are pinned, the record-keeping requirement is satisfied not by a side-channel log file but by the versioned evidence itself — git log is the audit trail; git diff between two beats is the change record.

Article 12 here is a deliverable / paper-trail, NOT a gating control

This matters for honesty: Art. 12 is not a measured, blocking gate (like Art. 15’s robustness or this level’s fairness gate). It is a record-keeping obligation — the engine satisfies it by producing a complete, signed, replayable paper-trail, and surfaces it in the Annex IV dossier. There is no “Art. 12 RED”. The honest framing is: Art. 12 is documentation of record, git-native and ex-ante, and its quality is judged by completeness and tamper-evidence, not by a pass/fail threshold.

Why this is the right place to meet Art. 12 deeply — the SCHUFA anchor. A consumer-credit score is an automated decision about a person, which is exactly the territory of GDPR Art. 22 and the CJEU’s SCHUFA judgment (C-634/21): an automated credit-scoring output that effectively decides a person’s access to credit triggers data-subject rights — including a right to meaningful human review of the decision. A right to human review is only operable if there is a record to review: which model, which data, which threshold, which residual was accepted, and by whom. Article 12’s git-native log makes that review possible — git diff the model, the dataset, the decision threshold, and the signed residual, and the reviewer can see precisely what was decided and on what basis. (SCHUFA is the anchor for why record-keeping matters in credit; this level does not litigate the case — it grounds the obligation.)

The honest boundary of git-native Art. 12

Git-native record-keeping covers code, model, dataset, and decision reproducibility — what was trained, on what data, with what parameters, yielding what residual, approved by whom. It does not cover infrastructure resilience: backups and RTO/RPO targets, failover, penetration-test results, incident triage. Those are operational ICT records — and, notably, they belong to DORA’s world, not to Art. 12’s reproducibility log. Confusing “we have a complete git history of the model” with “we have ICT operational-resilience records” is exactly the kind of over-claim §5’s DORA section guards against.

---

§5 — DORA = the Register (a deliverable, not a verdict)

Now the finance overlay pays off — and so does the honesty. The system declared eu/dora@2022 with a dora.entity block, so the control plane assembles a DORA Register of Information from the signed bundle. The assembler (cloud/lib/froga/dora-roi.ts) is pure and deterministic: it derives the register from the already-verified bundle, mapping into the ESAs’ xBRL-OIM template (EBA Taxonomy 4.0). The minimum tables:

• B_01.01 — the reporting entity. LEI, legal name, country, entity type (credit_institution), reference date — straight from the dora.entity block.
• B_07.01 — the ICT function. A service id (<lei>-<system_name>), the function description (system name + intended purpose), the last risk-assessment date (the bundle’s commit date), and a risk-assessment result mapped from the engine’s residual level through DORA_VOCAB.
• B_05.01 — direct ICT third-party providers. Materialised from the ML-BOM (the CycloneDX bill of materials the DVC pipeline emits): each component’s PURL is matched against a curated list of known ICT providers, deduplicated by LEI.

The DORA Register is a signed deliverable + cross-map, NOT a conformity verdict

Read what the register is — and is not. It is a faithful, signed projection of what was measured and declared into the supervisor’s reporting template — a deliverable the entity’s compliance officer hands over, the finance counterpart of retina’s MDR crosswalk. It is documentation, not a statement that the system is DORA-conformant. The structural reason is the same as MDR’s: DORA is binding sectoral law, not a harmonised AI-risk-management standard cited for Article 9, so it sits outside the engine’s verdict-bearing authority chain and confers no presumption. Caption it: “signed deliverable + cross-map, NOT a conformity verdict.” Calling the system “DORA gobernada” because it carries this Register is the over-claim this course refuses. The conformity verdict on the model’s fairness is the AI Act / ISO 23894 verdict — and here it closes GREEN after treatment (measured with real power, OOF over all 1,000 rows).

The DORA catalog has no measure callers — so the clause projection is not the deliverable. If you ran froga conformance --standard eu/dora@2022, you would find that no measure in froga.yaml cites a dora.* clause — the only DORA reference anywhere is eu/dora@2022#art-6 carried as an advisory frameworks tag on the fairness measure, not as a standard_clauses caller. Whatever cross-mapped “covered” markers the DORA fold shows come from structural criteria (the system has a risk framework, has a residual evaluation), never from a measure proving a DORA clause. The lesson: teach the Register, not clause coverage. The DORA deliverable of value is the signed Register of Information, not a per-clause verdict the catalog was never wired to produce.

The honesty markers — stated, not glossed:

• The LEI is fictitious, and disclosed. The demo entity is NovaCredit with LEI 999999FAKEBANK999 — a deliberately invalid, clearly-fake identifier, carried with an OPSEC disclosure in froga.yaml. The assembler validates LEIs against the ISO 17442 format; in production the LEI must validate against GLEIF. Here it is an honesty marker: a demo register that visibly does not claim to be a real filing.
• B_05.01 is sparse — on purpose. Only providers with a GLEIF-verified LEI populate the third-party table; ICT components whose provider has no registered LEI are blocked out rather than fabricated. So B_05.01 is intentionally thin (most of the ML-BOM’s components are open-source libraries, not registrable ICT providers). Sparseness is the honest state, not a defect.
• The vocabulary is lossy. DORA_VOCAB maps the engine’s residual level onto DORA’s three-value scale — and the map is lossy: both MEDIUM and LOW collapse to “Low” (CRITICAL→Significant, HIGH→Moderate). One honest sentence: the register’s risk-result column is a coarse projection of the engine’s finer residual scale, not a one-to-one transcription.

---

§6 — Articles 9, 10, 11 revisited (under the second regime)

The credit model runs the same Articles 9–15 spine as the clean levels, but now it is also an ICT asset, so it is worth re-reading three of them through the overlay — briefly.

• Art. 9 (risk management). The same risk program drives the system: an appetite, a 5×5 matrix, the overall-residual criterion, the fairness risk and its treatment. DORA adds nothing to the verdict here — the fairness residual closes GREEN on the AI-Act / ISO machinery, full stop. DORA reuses the same residual (it maps it into B_07.01’s risk-result column), but it does not change it.
• Art. 10 (data governance). The system declares a data-governance commitment (balanced training data, minimisation), audit-only and declared. Caution — a name collision worth flagging: AI Act Art. 10 (data governance) ≠ DORA Art. 10 (ICT anomaly detection). Same number, two different laws, two different obligations. The AI Act’s Art. 10 is about the quality and governance of training data; DORA’s Art. 10 is about detecting anomalous ICT activity. When a finance system is in scope for both, “Article 10” is ambiguous unless you name the law — always qualify it.
• Art. 11 (technical documentation, Annex IV). The signed bundle is the source the control plane assembles into the Annex IV dossier — and into the DORA Register. One bundle, projected onto both the AI-Act documentation and the finance deliverable: the overlay’s “one bundle → N catalogs” idea made concrete.

The modality map — where this level sits

The course names the kind of treatment and the kind of control at every level. Here:

• Treatment modality: a fairlearn learner swap — the treatment replaces train.py (plain logistic regression → ExponentiatedGradient with the DemographicParity constraint). At every level the treatment is a versioned code change (the git diff of train.py), not a flag; what varies is its nature: Level 1 adds the discriminative features, Level 2 makes the same fairlearn learner swap (but resolves to amber differently) and Level 3 retrains with class balancing + a 0.30 threshold. All are versioned commits; the treatment is the git diff.
• Gate control: fairness — demographic_parity_diff — objective, blocking, measured with a cluster/bootstrap CI computed OUT-OF-FOLD over all 1,000 rows (5-fold StratifiedKFold, not a 200-row held-out). That CI is what makes V1 honestly AMBER and V2 honestly GREEN — never a glossed green.
• Record-keeping (this level’s deep article): Art. 12 — git-native, ex-ante logging — a deliverable / paper-trail, not a gating control.
• Sector deliverable: DORA Register of Information (xBRL-OIM) — a signed deliverable + cross-map, not a conformity verdict.

---