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 froga.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 froga.yaml             # full history of the manifest, including the risk: section
git blame froga.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 (default)	The operator identified it directly and added it to the register
proposed_by_kag	Reserved for assisted-identification risks (the future KAG’s domain). Today the operator may set it by hand to distinguish an emergent risk —detected mid-development— from those declared at inception
derived_from_gap	Emerged from a data_gap detected by the engine (EU AI Act Art. 10(5)) and propagated 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 assisted identification and which from direct declaration.

---

Identification today (human) and the KAG (future line)

Today risk identification is performed by the human: the team declares risks by hand in the risk: section of froga.yaml. The KAG (Knowledge Assessment Graph) will, in the future, be the component that assists that identification by proposing candidate risks from the system context. It is not available today —the deterministic mock was removed so as not to simulate automation— and froga assess is an honest stub that reminds you to declare the evaluation by hand.

The moments when it is worth reviewing whether new risks have emerged (today the team does it; the KAG will assist in the future):

• Detected drift — froga status reports a STALE artifact
• Data gap — the engine detects statistical insufficiency (UNDERPOWERED) and flags it as a data_gap
• Reporting cycle — periodic conformance review (EU AI Act Art. 72 for serious incidents)
• Direct review — the team reviews the register at any point in development

Identification is human and deliberate: no component adds risks to the AssuranceProgram automatically. The team declares them, analyses them, and commits the changes.

The human declares; froga.yaml is the register; froga compile generates OSCAL

The evaluation (classification + risks) is declared by hand in froga.yaml (the risk register lives there). The engine infers and proposes nothing: froga run reads that declaration directly. The OSCAL (assessment_plan, Open Security Controls Assessment Language) is generated by froga compile from froga.yaml. Since the register lives in git, git blame over froga.yaml is the identification audit log; no external traceability system is needed. The KAG, when it exists, will assist this declaration without replacing human judgment.

---

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 team identifies, through analysis of the decision, that the age group >60 has a significantly different approval rate from the rest.
2. It declares the risk age_discrimination by hand, with provenance proposed_by_kag (assisted identification: the class the future KAG will propose).
3. It adds it to the register and commits:

Declare an emergent risk (assisted identification)

# Add the risk to the risk: section of froga.yaml
git add froga.yaml
git commit -m "risk(loan): add age_discrimination risk (assisted identification)"

4. The new risk activates a new iteration of the ISO 23894 cycle: identification → analysis → evaluation → treatment → residual.
5. froga reconstruct can reconstruct that arc from the commit in which the risk appeared (git log -S "age_discrimination" froga.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

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

See the froga CLI reference for details on froga compile and froga run, and the risk identification guide for the complete flow.