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).

---

Why risk drives ML development, not the feature

A machine-learning system is not ordinary software. The model retrains as new data arrives, the data drifts away from what you measured at build time, and bias is invisible — it does not raise an exception; it only surfaces when the system has already harmed a real subgroup. A green test suite tells you the code does what you wrote, but it does not guarantee the system is fair, accurate on the people who matter, or still correct a month from now. The danger lives in the data and the world, not in the function you can unit-test.

The UK A-level algorithm (2020) makes the point concretely. It was, by any conventional measure, a working model: with exams cancelled, it took each school’s data and produced grades. Yet it had learned from years of unequal results to downgrade students from disadvantaged state schools while lifting private ones — it did exactly what its biased data taught it. No test was red; the system simply encoded a harm nobody had measured, and the outcry forced a national U-turn. That is why risk, not the feature backlog, drives the work: the question that orders the development is not “does it run?” but “what could it get wrong, for whom, and how would we know?”

That risk-first stance is not a Venturalítica invention — it has a deep lineage in software engineering, which is the credibility we lean on next.

---

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.15), with the same red/green analogy as TDD (with the caveat that, if the evidence is underpowered, the control stays INCONCLUSIVE rather than green).
• git closes the loop: the treatment is a versioned change; the git log of the signed bundle is the treatment register, and froga 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 (.froga/bundle.json) is the treatment register; froga 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).

What froga does NOT yet do

The Annex IV the cloud assembles from the signed bundle is partial: §7 (standards) and §8 (DoC) are never pending; §2/§3/§4/§9 can be pending if their input is missing (data / misuse+residuals+Art.14 / control results / post-market measures). In this scenario, with data, controls and measures present, only §3 and §9 would appear pending. 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 froga run → froga 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. froga conformance projects the bundle onto both via separate clause catalogues and emits conformance reports independently.

For why any of this matters before a regulator ever shows up, see Why it matters.

---

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 loopThe core thesis: treatment as a versioned change and froga reconstruct.

Typed driftDrift types A/B/C and how froga detects what is stale without recomputing.

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

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

The living AssuranceProgramThe 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.