The living AssuranceProgram

The AssuranceProgram is not a document drafted at the outset and filed away. It is a living register that grows during development, following the continuous risk identification mandate of ISO 23894 §6.4.2.

---

git blame as the identification audit log

In Venturalítica, the AssuranceProgram is not a separate file: it lives inline in sei.yaml, in the risk: section (alongside context: and system.potential_misuses). Each risk added to the register is a versioned change to that file: it has an author, a date, and a commit message explaining why it was identified.

Audit the risk identification history

git log --follow -p sei.yaml             # full history of the manifest, including the risk: section
git blame sei.yaml                       # who added each risk and when
git log -S "unfair-credit-exclusion"     # first commit that introduced this risk

This traceability satisfies the continuous identification requirement of ISO 23894 §6.4.2 without any additional infrastructure. The question “who identified this risk and when?” has an exact answer in the git history.

---

Provenance per risk

Each risk in the AssuranceProgram carries a provenance field that classifies its origin:

Value	Meaning
declared	The operator identified it directly and added it to the register
proposed_by_kag	The KAG proposed it in a sei assess run; the operator accepted and committed it
derived_from_gap	The KAG detected a data gap (EU AI Act Art. 10(5)) and propagated it as a bias risk

Provenance does not affect the treatment of the risk: a proposed_by_kag risk follows the same ISO 23894 cycle as a declared one. Its function is auditing: it allows identifying which part of the register comes from automated analysis and which from direct human judgment.

---

The KAG as recurring proposer

The KAG (Knowledge Assessment Graph) acts as a recurring proposer of undeclared risks. It is invoked via sei assess:

Invoke the KAG for risk identification

sei assess          # the KAG analyses the bundle and proposes candidate risks

The triggers that activate a KAG invocation are:

• Detected drift — sei status reports a STALE artifact
• Data gap — the KAG detected statistical insufficiency (UNDERPOWERED) and propagates it as a risk
• Reporting cycle — periodic conformance review (EU AI Act Art. 72 for serious incidents)
• Direct invocation — the operator runs sei assess at any point in development

The KAG is advisory: its proposals are not automatically added to the AssuranceProgram. The operator reviews them, accepts or rejects them, and commits the changes. The human curates; the KAG proposes.

The KAG proposes; sei.yaml is the register; sei compile generates OSCAL

The KAG output (sei assess) is a structured report (classification + candidate risks), advisory. The human curates it into sei.yaml (the risk register lives there). The OSCAL (assessment_plan, Open Security Controls Assessment Language) is NOT emitted by the KAG: it is generated by sei compile from sei.yaml. Since the register lives in git, git blame over sei.yaml is the identification audit log; no external traceability system is needed.

---

The loan_growth scenario: an emergent risk

The loan_growth scenario — a variant of the loan scenario, not a standalone demonstrator — illustrates how the AssuranceProgram grows during development. Midway through the credit model development cycle, an age discrimination risk emerges that was not declared in the initial register.

The flow is:

1. The KAG, invoked via sei assess, detects that the age group >60 has a significantly different approval rate from the rest.
2. The KAG proposes the risk age_discrimination with provenance proposed_by_kag.
3. The operator reviews the proposal, accepts it, and runs:

Accept a risk proposed by the KAG

# Add the risk to the risk: section of sei.yaml
git add sei.yaml
git commit -m "risk(loan): add age_discrimination risk (proposed by KAG)"

4. The new risk activates a new iteration of the ISO 23894 cycle: identification → analysis → evaluation → treatment → residual.
5. sei reconstruct can reconstruct that arc from the commit in which the risk appeared (git log -S "age_discrimination" sei.yaml).

This pattern demonstrates that the AssuranceProgram is not a static initial compliance artifact; it is the operational register of the risk lifecycle during development.

---

Compiling the AssuranceProgram

The complete AssuranceProgram (risks + analysis + evidence) is compiled into the signed bundle via:

Compile the AssuranceProgram into the bundle

sei compile         # reads the risk: section of sei.yaml and generates the OSCAL assessment_plan
sei run             # re-measures and writes the signed bundle (.sei/bundle.json)

See the sei CLI reference for details on sei assess and sei compile.