git closes the ISO 23894 treatment loop

RDD loop: commit → measure → treat → re-anchor → commit

The diagram shows the full cycle: each treatment ends in a commit that updates the bundle anchor, and the cycle measures again on that basis.

The core thesis

The risk treatment (ISO 23894 §6.5) is a change: to code, to a parameter, to a dataset. That change, when committed to git, becomes:

versioned — identifiable by hash and attributable to an author with a date
anchored — the engine signs the evidence bundle with ECDSA-P256+DSSE+in-toto against the triple (code digest, model digest, dataset digest)
traceable by clause — sei conformance projects the bundle onto the ISO 23894 and prEN 18228 catalogues

This was the limitation of the previous product: treatments were code changes that had to be collected by hand into the risk register. Making git close the loop — making the git log of the bundle be the treatment register — is what Venturalítica is.

`sei reconstruct`: replay of the cycle per risk

sei reconstruct reconstructs the treatment cycle per risk by replaying the git history of the evidence bundle (.sei/bundle.json). The process is deterministic and requires no language model.

For each identified risk, the report traverses five phases:

Phase	What `sei reconstruct` does
① Identification	Locates the commit that introduced the risk in the AssuranceProgram (`git log -S <risk_id>`)
② Analysis	Retrieves the likelihood × impact → inherent level from the historical bundle
③ Evaluation	Checks the inherent level against the appetite declared in `sei.yaml`
④ Treatment	Reconstructs the empirical arc FAIL → PASS by commit (the applied treatment)
⑤ Residual	Classifies the cycle: CLOSED / OPEN / DISCREPANCY / ACCEPTED (ISO 23894 §6.5)

The output can be written as a signed artifact with --out (.sei/reconstruct.json + .sig).

See the sei CLI reference for flag and artifact details.

git blame = the audit log

In Venturalítica, git blame over the AssuranceProgram — the risk: section of sei.yaml — is the identification audit log: each risk has an author (who identified it), a date (when), and a commit message (why it was added). git log -S "<risk_id>" sei.yaml locates the commit that introduced each risk.

This satisfies the traceability requirement of ISO 23894 §6.4.2 (risk identification) without any additional infrastructure: the git history already contains all the information.

The Annex IV comes out by construction

Because each treatment is a versioned change and the evidence bundle is signed against the triple, the cloud (control plane) can assemble the Annex IV (EU AI Act Art. 11) directly from the signed bundle.json. The engine does not emit the Annex IV: it only leaves the signed evidence.

Field provenance is declared/derived-bundle/derived-git
There is no manual Annex IV drafting step
The Annex IV reflects the real state of the system at the time of the last sei run

The mechanism is built and demonstrated in the loan scenario. Completeness is partial: Annex IV §7 and §8 are never pending; §2/§3/§4/§9 can be pending if their input is missing. In loan, with data, controls and measures present, only §3 and §9 would appear pending (see Status & gaps).

Normative relevance

Clause	How Venturalítica covers it
ISO 23894 §6.4.2 — identification	`git blame` + `sei assess` (KAG proposes undeclared risks)
ISO 23894 §6.4.3 — analysis	Likelihood × impact 5×5, inherent level in the bundle
ISO 23894 §6.4.4 — evaluation	Inherent level vs appetite; per-criterion blocking in `sei conformance`
ISO 23894 §6.5 — treatment and residual	Empirical arc FAIL→PASS by commit; cycle classification in `sei reconstruct`
EU AI Act Art. 9 — risk management system	`sei run` gate (blocking controls); continuous monitoring via `sei status` in CI/CD
EU AI Act Art. 11 — technical documentation	The cloud assembles the Annex IV from the signed bundle (partial)