Risk identification (froga assess)
🟡 Partial — The KAG (risk identification assistant) is a future line: it is NOT available today. `froga assess` is an honest stub and the evaluation (classification + risks) is declared by hand in froga.yaml.
ISO 23894 §6.4.2 requires that risk identification be continuous: risks are not declared once and frozen — the register grows as the system evolves. The risk program (the AssuranceProgram, today a section — risk: — of froga.yaml itself) is that living register.
Today that identification is performed by the human: the developer or quality manager declares by hand, in froga.yaml, both the system classification (tier/basis/rationale) and the risk program (each risk with its domain/rationale). The engine infers and proposes nothing: froga run reads that declaration directly from the manifest and fails explicitly if the classification is missing.
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 — see The KAG (future line).
What froga assess does
Section titled “What froga assess does”While the KAG does not exist, froga assess is an honest stub: it fabricates and proposes nothing. It reminds you that the evaluation is declared by hand and shows the shape of the classification: block. It is hidden from the public help and its exit code is always 0 (advisory).
froga assess --repo .froga assess: KAG no disponible aún.Declara la evaluación (clasificación + riesgos) a mano en `froga.yaml`:
classification: tier: high # high | limited | minimal | prohibited basis: - "EU AI Act Annex III §..." rationale: "..."
La evaluación queda en tu repositorio (manifiesto + bundle firmado); `froga run` la lee directamente.Consulta la documentación para cada dominio (crédito §5b, empleo §4, SaMD, educación §3...).The KAG (future line)
Section titled “The KAG (future line)”The KAG will close the risk identification loop (ISO 23894 §6.4.2) by assisting the human: it will look at the system context (Croissant metadata, historical metrics, etc.) and propose candidate risks not yet in the AssuranceProgram, so the team can curate them. It will be advisory, non-blocking — the decision to add a risk will remain human.
The real service (Python over an API) is future work; it is announced on the Roadmap. The deterministic mock that existed in earlier versions was removed so as not to simulate an automation that does not exist: until the KAG is ready, hand declaration is the source of truth. The component’s contract (its input/output) is preserved in the code so that today’s human declaration fits without rewriting when it arrives.
Living-register flow
Section titled “Living-register flow”The register growth cycle, in accordance with ISO 23894 §6.4.2, has four steps. Today the detection step is performed by the human (through analysis, review, or measurement); in the future the KAG will assist it.
- Identification — the team detects a new risk (through analysis, detected drift, or periodic review) that the register did not cover.
- Declaration — it is added to the
risk:section offroga.yamlwithimpact,likelihood,treat, andprovenance(see provenance), or the team decides it does not apply and documents that. - Commit — the commit that adds the risk to the program is itself the dated and attributable identification act.
froga reconstructretrieves it later as “①Identification”. - Recompilation —
froga compileregeneratesassessment_plan.oscal.yamlwith the new risk. The engine re-measures on the nextfroga run.
Provenance per risk
Section titled “Provenance per risk”Each risk carries a provenance field that classifies its origin, for auditing purposes (it does not affect treatment):
| Value | Meaning |
|---|---|
declared (default) | The team identified and declared it directly. |
proposed_by_kag | Reserved for risks that arise from assisted identification (the future KAG’s domain). Today the team may set it by hand to mark an emergent risk, detected mid-development through analysis, as distinct 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 travels to the signed evidence bundle, where froga reconstruct displays it distinguishing each origin.
Example: emergent age-discrimination risk
Section titled “Example: emergent age-discrimination risk”The loan_growth scenario illustrates this cycle. The initial risk program (the risk: section of froga.yaml) declares five risks (unfair credit exclusion, data governance, opacity, model robustness/security, and insufficient human oversight). Mid-development, the team identifies an emergent risk the initial register did not cover — age discrimination — and declares it by hand in the risk: section, marking it with provenance: proposed_by_kag to record that it is an assisted-identification risk (the class the future KAG will propose):
risk: # … appetite, criteria, overall_residual_criterion, previous risks … risks: - id: risk.age-discrimination title: "Age-based Credit Discrimination" affects: [sys.creditscore] sources: [ctx.historical-bias] provenance: proposed_by_kag # assisted identification (hand-declared today) impact: { individual: HIGH, society: MEDIUM } likelihood: POSSIBLE # ISO 6.4.3 analysis — POSSIBLE×HIGH = HIGH treat: - method: REDUCE action: "Constrain demographic parity of the decision also by age group." controls: [eu/ai-act@2024#art-15] residual_likelihood: UNLIKELY measures: - id: age-discrimination metric: demographic_parity_diff constraint: "< 0.03" severity: high enforcement: gate lifecycle: [validation] article: "15" inputs: { prediction: prediction, dimension: age_bucket, age_bucket_method: quantiles, age_buckets: 3 }After declaring and committing, recompile and re-measure:
froga compile --repo .froga run --repo .# → the age-discrimination control FAILS (age DP ≈ 0.14 ≫ 0.03)# → gate RED: mitigating gender alone left the age dimension unfairThis result is the ISO iteration: the register grew, the engine detected the empirical gap, and the team must apply a new treatment (V3, which mitigates gender and age simultaneously). At the end of the cycle, froga reconstruct shows the dated, attributable identification (the proposed_by_kag provenance renders as “assisted identification”):
① Identification <sha> <date> «GROWTH: +risk.age-discrimination» · provenance: assisted identification (proposed_by_kag)The git history of froga.yaml (the risk program) is the identification audit log, dated and attributable, in accordance with ISO 23894 §6.4.2.
For the complete step-by-step flow, including dvc exp exploration and V3 treatment, see Level 1.
References
Section titled “References”- Living AssuranceProgram — continuous identification cycle and declaration
frogaCLI reference —froga compile,froga run- Roadmap — the real KAG as future work