AssuranceProgram / OSCAL

✅ Stable

The AssuranceProgram is the declarative source of the Art. 9 risk management system of the EU AI Act: it contains the system’s risks, control measures, evaluation and residual risk. It is what froga compile transforms into assessment_plan.oscal.yaml — the risk gate contract.

The AssuranceProgram is not a separate file: it is the risk section of the froga.yaml manifest (together with context.applicable_standards and system.potential_misuses). A repository governs a single system with one froga.yaml. froga compile reads the risk section directly from the manifest:

context:
  applicable_standards:        # applicable standards (the first one, highest priority)
    - eu/pren-18228@2026
    - iso/23894@2023
risk:                          # Art.9 assurance program (froga compile reads it from here)
  appetite: { individual: MEDIUM, society: MEDIUM, organization: HIGH }
  criteria: { scale: "5x5" }
  overall_residual_criterion: HIGH
  risks: [ ... ]
  applicability: {}

See referencia/froga-yaml for the full manifest specification.

Structure of the `risk` section

The risk section of froga.yaml has the following top-level skeleton:

risk:
  appetite:                     # appetite per impact dimension (evaluation threshold 6.4.4)
    individual: MEDIUM
    society: MEDIUM
    organization: HIGH
  criteria: { scale: "5x5" }    # analysis matrix scale
  overall_residual_criterion: HIGH   # GLOBAL residual criterion (prEN 18228 cl. 10)
  risks:        # concrete risks with their treatment and measures
  applicability: {}             # control Statement of Applicability

The regulatory context is declared outside risk, in context.applicable_standards; foreseeable misuse in system.potential_misuses. See referencia/froga-yaml.

`context.applicable_standards`

Canonical standard ids that froga conformance supports with a clause catalog:

Canonical id	Standard
`eu/pren-18228@2026`	prEN 18228 — AI risk management (Art. 9)
`iso/23894@2023`	ISO/IEC 23894 — AI risk management

Anatomy of a risk

Each entry in risk.risks follows this structure (real fields from loan/froga.yaml):

risk:
  risks:
  - id: risk.unfair-credit-exclusion
    title: "Unfair Credit Exclusion of Minorities"
    impact:
      individual: HIGH
      society:    HIGH
      organization: HIGH
    likelihood: LIKELY            # ISO 6.4.3 analysis — inherent LIKELY×HIGH = HIGH
    treat:
      - method: REDUCE
        action: "Cap the demographic parity of the decision and the class balance per group."
        controls: [eu/ai-act@2024#art-15]
        residual_likelihood: UNLIKELY  # 6.5 target; held-out n=200: the CI crosses the threshold → control INCONCLUSIVE (does not confirm)
        measures:
          - id: unfair-credit-exclusion
            metric: demographic_parity_diff
            constraint: "< 0.092"
            severity: high
            enforcement: gate          # gate → blocking; audit → advisory
            lifecycle: [validation]
            article: "15"
            frameworks: [eu/dora@2022#art-6]
            control_tier: protective
            standard_clauses:
              - "eu/pren-18228@2026#9.2"
              - "eu/pren-18228@2026#7"
              - "iso/23894@2023#6.5"
            inputs: { prediction: prediction, dimension: gender }

Risk fields

Field	Description
`id`	Unique risk identifier; `froga reconstruct` traces it via `git log -S`
`title`	Human-readable title
`impact`	Impact per dimension (`individual`, `society`, `organization`): `NEGLIGIBLE` / `LOW` / `MEDIUM` / `HIGH` / `CRITICAL`
`likelihood`	Inherent likelihood before treatment: `RARE` / `UNLIKELY` / `POSSIBLE` / `LIKELY` / `ALMOST_CERTAIN`
`treat[].method`	Treatment method: `REDUCE` / `AVOID` / `TRANSFER` / `ACCEPT`
`treat[].residual_likelihood`	Post-treatment target likelihood (ISO 23894 §6.5); confirmed by the blocking control

Measure fields (`measures[]`)

Field	Description
`id`	Measure id; links to `control_results` in the bundle and is the key of each `metrics.json` entry (`{ id: value }`). The pipeline must write the value under the `id`, NOT under the `metric` name.
`metric`	Name of the metric evaluated by the pipeline (a documentary label that travels to OSCAL as `metric_key`); it is not the `metrics.json` key — the `id` is.
`constraint`	Threshold in `< 0.092` / `> 0.25` / `>= 2` notation
`severity`	`high` / `medium` / `low`
`enforcement`	`gate` → blocking (red risk gate if it fails); `audit` → advisory
`lifecycle`	Lifecycle phases: `data_preparation` / `validation`
`article`	EU AI Act article justifying the measure (`"10"`, `"15"`, etc.)
`frameworks`	Additional regulatory frameworks (`eu/dora@2022#art-9`, etc.)
`control_tier`	Control hierarchy level (prEN 18228 cl. 9.1.2): `inherently_safe_design` / `protective` / `information`
`standard_clauses`	Clauses this measure satisfies; used by `froga conformance` to project coverage
`inputs`	Input parameters for metric evaluation

Risk provenance (`provenance`)

The bundle records, per risk, its identification provenance:

Value	Meaning
`declared`	Human declared it directly in the `risk` section
`proposed_by_kag`	Reserved for assisted identification (future KAG); today the team sets it by hand on an emergent risk
`derived_from_gap`	Emerged from a `data_gap` (EU AI Act Art. 10(5))

Provenance is part of the living registry arc: froga reconstruct shows it alongside the ISO 23894 §6.4.2 commit that introduced the risk. See metodologia/assurance-program-vivo.

`froga compile` — from DSL to OSCAL

froga compile crosses the risk section of froga.yaml with the control catalog and generates assessment_plan.oscal.yaml (the gate contract that froga run executes):

froga compile --repo .
# froga compile: froga.yaml (risk section) → assessment_plan (shared_data/policies/assessment_plan.oscal.yaml)

The assessment plan is the ex-ante contract: it defines which metrics are measured, with which threshold and severity. froga run executes it against the pipeline and writes the signed bundle.json.

froga.yaml (risk section)  →(froga compile)→  shared_data/policies/assessment_plan.oscal.yaml
                                                  ↓
                                          (froga run executes)
                                                  ↓
                                         .froga/bundle.json + .sig

See referencia/froga-cli for the complete subcommand reference.

System identity and foreseeable misuse

The AssuranceProgram (the risk section) does not stand alone: it relies on other sections of the same froga.yaml:

system.potential_misuses — reasonably foreseeable misuse (ISO 42001 §6.1.4 / EU AI Act Art. 9(2)(b)): unintended but anticipable uses. Each entry (id, description, addressed_by) links to the risk(s) that address it. froga impact crosses the misuse against the risk registry and flags unaddressed cases (advisory).
system (name, intended_purpose, organization, version, decisions, affected_persons, component_type) — the identity and scope of the evaluated AI system.
context.applicable_standards — the applicable standards against which froga conformance projects the same risk register.

See referencia/froga-yaml for the detail of each section.

Relationship to the rest of the system

The AssuranceProgram lives in froga.yaml, in the user’s repo, versioned in git like any other code file.
Every commit that adds, modifies, or closes a risk is an auditable act: froga reconstruct replays it from the git history of the bundle.
The cloud does not recalculate: it reads the committed signed .froga/* artifacts and renders them (including Annex IV, which it assembles from the signed bundle.json). See referencia/froga-artifacts.
For the full living-registry flow (the human declares, the commit is the ISO 23894 §6.4.2 identification; the KAG will assist in the future): metodologia/assurance-program-vivo.

AssuranceProgram / OSCAL

Structure of the risk section

context.applicable_standards