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 sei 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 sei.yaml manifest (together with context.applicable_standards and system.potential_misuses). A repository governs a single system with one sei.yaml. sei compile reads the risk section directly from the manifest:

sei.yaml (excerpt)

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

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

---

Structure of the risk section

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

sei.yaml — risk section (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/sei-yaml.

context.applicable_standards

Canonical standard ids that sei 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/sei.yaml):

sei.yaml — risk.risks (real excerpt)

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: confirmed by the blocking control
        measures:
          - id: unfair-credit-exclusion
            metric: demographic_parity_diff
            constraint: "< 0.03"
            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; sei 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
metric	Name of the metric evaluated by the pipeline
constraint	Threshold in < 0.03 / > 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 sei 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	The KAG proposed it; the human curated and committed it
derived_from_gap	Emerged from a data_gap (EU AI Act Art. 10(5))

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

---

sei compile — from DSL to OSCAL

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

sei compile --repo .
# sei compile: sei.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. sei run executes it against the pipeline and writes the signed bundle.json.

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

See referencia/sei-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 sei.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. sei 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 sei conformance projects the same risk register.

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

---

Relationship to the rest of the system

• The AssuranceProgram lives in sei.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: sei reconstruct replays it from the git history of the bundle.
• The cloud does not recalculate: it reads the committed signed .sei/* artifacts and renders them (including Annex IV, which it assembles from the signed bundle.json). See referencia/sei-artifacts.
• For the full living-registry flow (KAG proposes, human curates, the commit is the ISO 23894 §6.4.2 identification): metodologia/assurance-program-vivo.