What is Risk-Driven Development

Risk-Driven Development (RDD) is an established idea in software engineering: making risk the driver of the process. Venturalítica does not coin the term; it specializes it for AI regulatory risk treatment, where the unit of work is the risk treatment, not the feature. The compliance cycle drives development in the same way that tests drive test-driven development (TDD).

Where the term comes from (lineage)

Risk-driven development has decades-old roots in software engineering. Venturalítica builds on that tradition; it does not invent it.

Boehm’s spiral model (1986/1988). Barry Boehm proposed the first explicitly risk-driven software process model: on each turn of the spiral you do as much of each activity (analysis, design, prototyping) as the project’s risk justifies, and the explicit recognition of risk is what sets it apart from linear models. This is where the adjective “risk-driven” entered the field.
Fairbanks’s risk-driven architecture (2010). George Fairbanks brought the idea to architectural design with the “risk-driven model”: you spend architecture effort in proportion to risk, neither over-designing the low-risk parts nor neglecting what threatens success.
The name “Risk-Driven Development (RDD)” itself is in common use in software delivery, with a loop very close to ours: identify and assess risks, express requirements as controls, prioritize, verify those controls, and re-evaluate residual risk.

What Venturalítica specializes

Venturalítica does not coin RDD; it specializes it for AI conformity. The novelty is not in the term, but in how it binds the term to a concrete substrate:

The unit of work is an ISO 23894 risk treatment (a regulatory mitigation), not generic project risk or features.
The “test” is a control = pair (measure, threshold) (for example, demographic_parity_diff < 0.03), with the same red/green analogy as TDD.
git closes the loop: the treatment is a versioned change; the git log of the signed bundle is the treatment register, and sei reconstruct reproduces it as the formal ISO 23894 cycle.
It is complemented by signed evidence (ECDSA-P256+DSSE+in-toto), dual-standard projection, and typed drift.

The red / green analogy

In TDD a test fails (red) until the code makes it pass (green). The “refactor” removes duplication without breaking the test.

In RDD the mechanism is analogous:

RDD	TDD
Red — the metric exceeds the threshold or evidence is missing	Failing test
Green — the treatment has been implemented and measured; the metric crosses the gate	Passing test
Refactor — the lowest-cost treatment that brings the residual below the declared appetite	Refactor without breaking tests

The concrete measure — a demographic parity difference, a fairness metric, a test coverage figure — is compared against its threshold. That pair (measure, threshold) is the control that defines the cycle state.

git closes the loop

Each treatment is a versioned change anchored to the triple (code, model, dataset) via ECDSA-P256+DSSE+in-toto. The git log of the evidence bundle (.sei/bundle.json) is the treatment register; sei reconstruct converts it into the formal ISO 23894 cycle.

As a result, the Annex IV (EU AI Act Art. 11) is assembled from the bundle — it is not drafted by hand. The mechanism is as described; the completeness of the Annex IV remains partial (see Status & gaps).

Normative frame

RDD operates on two standards:

ISO 23894:2023 — specifies the AI risk management process: identification, analysis, evaluation, treatment, and residual risk (§6.4–§6.5). Venturalítica implements this cycle in the Rust engine and makes it reconstructible by git replay.

EU AI Act Art. 9 — requires a continuous risk management system for high-risk AI systems classified under Art. 6 and Annex III. The sei run → sei conformance cycle implements the continuous monitoring requirement of Art. 9.

These two standards are not equivalent: ISO 23894 defines the process; the EU AI Act sets the regulatory threshold. sei conformance projects the bundle onto both via separate clause catalogues and emits conformance reports independently.

Map of this section

The red/green loop (measure vs threshold) How a control defines red/green state and what UNDERPOWERED means.

git closes the ISO 23894 treatment loop The core thesis: treatment as a versioned change and sei reconstruct.

Typed drift Drift types A/B/C and how sei detects what is stale without recomputing.

The two gates The risk gate (controls) and the normative compliance gate.

Treatment modalities Code change, parameter adjustment, and prompt-tuning (deferred).

The living AssuranceProgram The risk register that grows during development, audited by git blame.

References

Boehm, B. (1988). “A Spiral Model of Software Development and Enhancement”. IEEE Computer, vol. 21, no. 5, pp. 61-72. (Initial version published in 1986.)
Fairbanks, G. H. (2010). Just Enough Software Architecture: A Risk-Driven Approach. Marshall & Brainerd.