Skip to content
Venturalítica

View the Annex IV

🟡 Partial — The Annex IV assembled by the cloud can mark §2/§3/§4/§9 as PENDING when their input is missing; §7 and §8 are never pending. In the loan scenario, with data/controls/measures present, only §3 and §9 would stay pending.

The EU AI Act, Art. 11 + Annex IV, requires providers of high-risk AI systems to maintain technical documentation covering nine sections: general system description, description of elements and development process, detailed information on operation, monitoring, logging, etc.

In Venturalítica, the engine does not assemble or emit the Annex IV. The engine only produces signed evidence in .sei/ (the bundle, the conformance reports, and the cycle reconstruction). The Annex IV is assembled and rendered in the cloud plane from that evidence already committed to the repository. There is no sei annex-iv command and no .sei/annex-iv.json artifact.

Who assembles the Annex IV

Section titled “Who assembles the Annex IV”

The cloud plane reads the signed .sei/bundle.json committed to the repository and, combining it with the sei.yaml manifest, builds the nine-section document. The two sources are:

  1. The sei.yaml manifest — fields declared by the provider (system name, intended purpose, modality, risk classification, regulatory frameworks, the risk program in the risk: section, etc.).
  2. The evidence bundle .sei/bundle.json — measured and signed results (controls, risk analysis, lineage, data governance, treatment events).

From both sources combined, the cloud determines the provenance of each field and builds the nine sections.

The nine sections, with the titles the cloud assembles (messages/en.json, annex.section):

§1 General description of the system
§2 Data and data governance                          ⏳ PENDING (if data_governance is missing)
§3 Monitoring, functioning and control               ⏳ PENDING (if misuse/residuals/Art.14 means are missing)
§4 Suitability of performance metrics                ⏳ PENDING (if control results are missing)
§5 Risk management (Art. 9)
§6 Changes throughout the lifecycle
§7 Harmonised standards applied
§8 EU declaration of conformity
§9 Post-market monitoring system                     ⏳ PENDING (if 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. §2/§3/§4/§9 can be marked PENDING if their input is missing: §2 if data_governance (Croissant) is missing, §3 if the ex-ante pillars are missing (foreseeable misuse, residual risks, Art.14 oversight means), §4 if control results are missing, and §9 if the manifest declares no post-market measures. In the loan scenario —with data, controls and measures present— only §3 and §9 would appear as pending.

Field provenance

Section titled “Field provenance”

When assembling the document, the cloud assigns one of four provenances to each field:

ProvenanceMeaning
declaredProvider explicitly declared it in sei.yaml
derived_gitDerived from the signed bundle, dvc.lock, or git history
derived_bomDerived from the bundle BOM/metrics (e.g. the §4 control values)
pendingNo value in the current version (only in §2/§3/§4/§9 when their input is missing)

Sections marked PENDING correspond to fields with pending provenance. §2/§3/§4/§9 can be in this state when their input is missing (data / misuse + residuals + Art.14 means / control results / post-market measures); §7 and §8 never. This is documented in State & gaps.

The cloud plane: renders, does not compute

Section titled “The cloud plane: renders, does not compute”

The Venturalítica cloud plane is stateless and read-only with respect to conformance computation: the cloud does not execute the Rust engine or the MLOps pipeline. Instead, it reads the already-signed and committed .sei/* artifacts, verifies their signatures, and assembles the Annex IV from them.

Specifically, the cloud/lib/sei/ module (TypeScript):

  • verify.ts — reproduces sei verify in pure TypeScript (ECDSA-P256 + DSSE + in-toto, using @noble/curves). Verifies the signature of each artifact before using it.
  • load.ts — loads and validates artifacts against JSON Schema v1.
  • The Annex IV assembly (assembleAnnexIv / parseAnnexBundle) builds the nine sections with their provenances from the loaded bundle.json.

The Annex IV is rendered on the web and exported as a PDF (Typst) from the cloud. Depositing the signed evidence (.sei/*) in the repository is the human act of “placing on the market”: the developer commits the bundle after sei run, and the cloud reads, verifies, and builds the Art. 11 document without reprocessing the computation.

This design preserves traceability: the artifact vault (Art. 18, retention) is the git repository, and the cloud is a read window over it that derives the Annex IV from the evidence, without creating a new artifact that would have to be signed and kept in sync.

Full operational flow

Section titled “Full operational flow”
Typical flow for the cloud to render the Annex IV
# 1. Run the cycle (measure, anchor, sign the bundle)
sei run --repo .


# 2. Verify the bundle signature
sei verify --repo .


# 3. Commit the signed evidence (the cloud will read it and build the Annex IV)
git add .sei/
git commit -m "evidence: cycle T1 (signed bundle)"

From there, the cloud plane reads the repository, verifies the bundle.json, and displays the Annex IV on the web, with the option to export it to PDF. There is no engine step that writes or signs an annex-iv.json.

References

Section titled “References”