Skip to content

Status & gaps

🟡 Partial — The Annex IV the cloud assembles from the engine's bundle is not yet complete; this page enumerates the gaps.

Venturalítica is built in parallel with its documentation and is incomplete by design-honesty. We declare gaps rather than hide them. This page is the source of truth for project maturity and the path towards a complete Annex IV under EU AI Act Art. 11.


StatusMeaning
StableImplemented and covered by integration or e2e tests
🟡 PartialWorks in documented cases; full coverage is missing
🚧 PlannedDesigned in spec, not yet implemented
🧪 ExperimentalPrototype; the API may change without notice

The following items are identified gaps between the current state of the froga engine and the requirement for a verifiable Annex IV (EU AI Act Art. 11; ISO/IEC 42001 Annex B).

StatusGapRelevant clause
🚧Keyless identity anchoring (Sigstore): ECDSA-P256+DSSE+in-toto signing is implemented, but anchoring the signer to an external trust root is pending.Sigstore (keyless signing); in-toto (chain integrity)
🚧Post-market monitoring: the continuous monitoring model of Art. 72 is not yet modelled in the engine.EU AI Act Art. 72; Annex IV §9
Overall system residual risk (prEN 18228 cl. 10): already a criterion in froga conformance cl. 10 (criterion: overall_residual, aggregated by evaluate_overall_residual() and persisted in EvidenceBundle.overall_residual) and blocks the lifecycle gate; it is only advisory in the froga run gate.prEN 18228 cl. 10
🚧Explicit hazard→harm chain and control hierarchy (prEN 18228 cl. 9): the current model follows ISO 23894 (risk management process); the product-safety chain and hierarchy of control measures are not yet built.prEN 18228 cl. 9; ISO 23894 §6.4
🚧Fundamental rights (FRIA): the Fundamental Rights Impact Assessment (EU AI Act Art. 27) is not yet explicitly covered in the bundle.EU AI Act Art. 27
🚧Prompt-tuning treatment modality (LLM case): only code-change and parameter-adjustment modalities are built. The prompt-tuning modality has been deferred.ISO 23894 §6.5; EU AI Act Art. 10
🚧Annex IV §2/§3/§4/§9 conditionally pending: §2 (data) if data_governance is missing; §3 (monitoring/functioning/control) if the ex-ante pillars are missing (foreseeable misuse, residual risks, Art.14 oversight means); §4 (suitability of metrics) if control results are missing; §9 (post-market monitoring) if the manifest declares no post-market measures. §7 (harmonised standards) and §8 (EU declaration of conformity) are NEVER pending: the engine always emits their state derived from the bundle. In the current scenarios, with data/controls/measures present, only §3 and §9 appear pending.EU AI Act Annex IV §2, §3, §4, §9
The portal enforces the aggregate appetite verdict (with conscious acceptance): RESOLVED — the field-name mismatch is fixed (the cloud reads overall_residual.evaluationaboveAppetite). If the aggregate residual exceeds appetite, approving requires a conscious-acceptance override with a reason (not a hard block, nor a silent allow; integrity violations do hard-block). The engine signs the verdict; the portal projects and enforces it.prEN 18228 cl. 10 (portal projection)

The two-role workshop (James, QM/owner via the UI; Martha, engineer/maintainer via the CLI) is structured today in three parts:

  • Foundations (/foundations/*): what a risk is, standards & presumption, sector overlays, the notified body, the data gap, and the supply chain.
  • RDD methodology (/metodologia/*): Risk-Driven Development and how git closes the treatment loop.
  • Levels N1–N6 (/cursos/level-1-iris/cursos/level-6-supply-chain): the clean spine N1–N2, the sector overlays N3 (health/MDR), N4 (finance/DORA) and N5 (employment), and the N6 supply-chain capstone.

The Guides, Concepts and Reference complete the material. Its maturity is NOT uniform, and we declare it:

StatusLevelValidation
N1 · Iris (your first system)Validated end-to-end live: a real walkthrough against platformpre + froga 0.1.0 + a fork of the starter.
🟡N2–N6 (student selection, retina/MDR, credit/DORA, employment, supply chain)Written and reviewed (anti-fabrication, tied to the code and the real product state) and commit-linked to public vldemo-* repos, with a nightly reproduction gate that re-derives each level’s verdict. Lighter validation than N1: without the live agent-as-student loop.

The full treatment cycle — how the portal enforces the aggregate appetite verdict with a conscious acceptance: the engine signs the verdict, the portal projects and enforces it — is developed in depth in git closes the treatment loop.


The following subsystems are stable and covered by tests:

  • ECDSA-P256+DSSE+in-toto signing of .froga/* artifacts.
  • ISO 23894 §6.4.2–6.4.4 and §6.5 risk model (likelihood × impact 5×5, hybrid residual, appetite).
  • Dual conformance by projection: prEN 18228 (priority) + ISO 23894, from a single bundle.
  • froga reconstruct — replay of the treatment cycle per risk from the git log.
  • Annex IV assembly in the cloud (control plane) from the signed bundle; the engine only emits the evidence.
  • Treatment modalities: code change (loan-scoring: mitigate: false→true in params.yaml, fairlearn DemographicParity) and parameter adjustment (retina-screening: mitigate: false→true in params.yaml, retrains the DR screener with class balancing + decision threshold 0.30).
  • Three MLOps backends tested in the e2e scenario harness (pre-merge / self-hosted runners; ci.yml only runs cargo test --workspace --lib): DVC (cat1), MLflow (cat2), Dagster (cat3).

The above gaps are not just documentation: froga conformance and froga soa already emit per-clause and per-control gaps from the signed bundle. See the froga CLI reference; froga conformance accepts the --standard and --out flags.