EU AI Act reviewer pack

Report eu-ai-act-demo · generated 2026-05-03T11:37:19.944Z

Technical evidence statusnot ready

Execution qualityhealthy

Coverage snapshot24 covered / 1 partial / 0 missing · 7 technical evidence collected / 5 awaiting operator / 2 outside toolkit scope (covered only) EU AI Act clause(s)

Package closing verdicthandoff_ready (ready_for_handoff, sections 9/9, approval approved_for_handoff, 16 referenced legal artifact(s))

Human review queue1 approval case(s), 1 blocking case(s)

How to read this pack

Start with the reviewer PDF or reviewer HTML, not with raw JSON files.
Read sections in Annex order; each section answers what it is for, what is generated here, what the operator still completes, and what is still open.
Use the claim-to-evidence map before opening deeper technical files.

If you are not reading from engineering tooling

Read the summary at the top of each section first.
Focus on 'Completed by the operator' and 'Still open' to see what remains outside the generated machine layer.
Use the reviewer PDF for handoff, printing, procurement, or counsel-facing review.

If you are doing technical verification

Use the reviewer HTML as the readable map, then open the linked Compare report, Expanded technical pack, and Manifest where deeper verification is needed.
Check claim-to-evidence rows before opening raw artifacts so you know which file answers which reviewer question.
Treat filenames as secondary; Annex order and section purpose come first.

What this pack proves

Which exact evaluated system version produced this package.
How the release performed on the reviewed case suite.
Which machine-derived risks, review actions, and monitoring signals were observed.
Which supporting files back each reviewer-facing section.

What this pack does not complete for you

That the provider has completed every operator-authored Annex IV or Annex V field.
That sector-specific legal, actuarial, clinical, or financial validation obligations are fully satisfied.
That the declaration of conformity or market-placement decision can be signed without human review.

Linked outputs

Reviewer PDF — Printable reviewer-facing dossier generated during EU packaging.
Reviewer HTML — Linked reviewer-facing dossier for browser review.
Article 50 transparency marking — Article 50 transparency evidence scaffold; strongest technical verification is the Article 50(2) marking path.
Reviewer Markdown — Editable reviewer-facing dossier source.
Expanded technical pack — Full engineering-facing Annex IV dossier with raw tables and detailed scaffolds.
Annex IV JSON — Structured machine-readable Annex IV export.
Package completion — Closing gate derived from the builder draft, evidence register, and approval block.
Section completion — Role-aware legal section completion for the selected package path.
Legal record register — Manifest-level register of referenced, draft-only, missing, and not-applicable legal records.
Legal artifact manifest — Handoff-facing manifest of bundled attachments, external references, and declared-only legal artifacts.
Article 10 data governance — System-specific data-governance scaffold for the evaluated release.
Article 16 provider obligations — Provider-obligations scaffold tied to the evaluated system version.
Article 43 conformity assessment — Conformity-assessment scaffold and route inputs for the evaluated system.
Article 47 declaration scaffold — Declaration-of-conformity scaffold for the evaluated system version.
Annex V declaration content — Structured Annex V declaration-content scaffold.
Compare report — Underlying runtime qualification report for this run.
Manifest — Portable evidence index for artifact integrity.
Technical evidence review — Machine-generated technical evidence status and reviewer checklist.

Review this pack in Annex order

1. General description of the system
2. Detailed description of development
3. Monitoring, functioning, and control
4. Performance metrics and limitations
5. Article 50 transparency evidence
6. Risk management system (Article 9)
7. Changes over the lifecycle
8. Standards and alternative controls
9. EU Declaration of Conformity boundary (Annex V)
10. Post-market monitoring and serious incidents

1. General description of the system

What this section is for

This section identifies the exact agent, model, prompt, tools, and report scope used for the evaluated release.
It is the reviewer-first entry point for understanding which system version produced the evidence in this package.

Generated here (machine-generated)

Report ID eu-ai-act-demo with generated timestamp 2026-05-03T11:37:19.944Z.
Environment identity: agent golden-eu-agent / golden-eu-agent-v2, model golden-model-v1 / 2026-03-01.
Package scope: cases _source_inputs/cases.json, baseline _source_inputs/baseline, new _source_inputs/new.
Transfer class internal_only and redaction status none.

Completed by the operator before handoff

Provider legal identity, authorised representative, and external contact details.
Narrative intended purpose and target user/deployer description.
Market placement form, hardware/software integration context, and user-interface description.

Still open

Provider legal identity, authorised representative, and external contact details remain required.
Intended purpose and target user/deployer description remain required.
Market placement form, hardware/software integration context, and user-interface description remain required.

Claim	Status	Why it matters to the reviewer	Evidence
The package identifies the exact evaluated system version and run scope.	Generated here	Confirms that the dossier is tied to one concrete evaluated system rather than a generic product description.	Annex IV JSON (System identity block.) Compare report (Release scope and runtime provenance.) Manifest (Integrity index for included artifacts.)
Provider legal identity and intended-purpose narrative still need to be completed by the operator.	Completed by the operator	Separates the technical identity already present from the provider-authored context still needed for formal dossier completion.	Annex IV JSON (System identity block.)
The generated bundle does not itself supply market-placement form or UI-description narrative.	Still open	Prevents a reviewer from mistaking technical identity for a full product-description section.	Annex IV JSON (System identity block.)

Evidence file	Path	Why it matters
Annex IV JSON	eu-ai-act-annex-iv.json	System identity block.
Compare report	../compare-report.json	Release scope and runtime provenance.
Manifest	../artifacts/manifest.json	Integrity index for included artifacts.
Legal artifact manifest	legal-artifact-manifest.json	Package-level handoff manifest for legal attachments and references.

2. Detailed description of development

What this section is for

This section captures how the evaluated release was exercised and which machine-verifiable artifacts back the technical record.
It is evidence-backed, but it does not replace provider-authored architecture and data-governance writing.

Generated here (machine-generated)

36 manifest-backed artifact(s) indexed across 25 EU AI Act coverage clause(s).
2 case artifact row(s) with response, replay, and trace references where available.
Execution exercised on suite(s): release.

Completed by the operator before handoff

Architecture narrative, algorithmic design decisions, trade-offs, and computational resources.
Training/data provenance, labelling, cleaning, and datasheet material.
Cybersecurity design narrative beyond the emitted runtime and scanner evidence.

Still open

Art_9: Operator-owned risk governance still sits outside the evaluator.
Art_9: Annex III classification and legal interpretation still require counsel.
Art_10: Dataset provenance, representativeness review, bias review, and preparation records remain provider-authored legal inputs.
Art_11: Annex IV technical documentation is referenced in the package record, but document completeness, currency, and final operator approval still need to be maintained outside the evaluator for Art_11.
Annex_IV: Annex IV technical documentation is referenced in the package record, but document completeness, currency, and final operator approval still need to be maintained outside the evaluator for Annex_IV.
Art_12: Provider logging-retention periods, production log controls, and system-specific logging scope remain provider-owned.
Art_13: Operator-authored intended-use, deployer-facing instructions, and operating constraints remain required.
Art_13: Human oversight procedures for deployers still require operator-authored narrative.
Art_17: Article 17 QMS record is referenced in the package record, but document completeness, currency, and final operator approval still need to be maintained outside the evaluator for Art_17.
Art_50: Machine-readable marker robustness and downstream preservation remain provider-owned.
Art_50: Article 50 legal applicability, deployer disclosure wording, and production-channel preservation tests remain operator/provider-authored.
Art_14: Deployer-facing oversight procedures, staffing, escalation rules, and operating playbooks remain operator-authored.
Art_15: Sector-specific validation thresholds, production robustness targets, cybersecurity controls, and acceptance criteria remain provider-owned.
Art_72: Recurring monitoring cadence, escalation workflow, and regulator-facing reporting remain operator responsibilities.
Art_73: Provider-owned incident classification, authority notification timing, and production escalation records remain required.
Art_16: Provider-owned records for Section 2 compliance, declaration, marking, registration, and authority-facing obligations remain required.
Art_18: Article 18 documentation-keeping record is referenced in the package record, but document completeness, currency, and final operator approval still need to be maintained outside the evaluator for Art_18.
Art_19: Article 19 automatic-log retention record is referenced in the package record, but document completeness, currency, and final operator approval still need to be maintained outside the evaluator for Art_19.
Art_20: Article 20 corrective-action and duty-of-information record is referenced in the package record, but document completeness, currency, and final operator approval still need to be maintained outside the evaluator for Art_20.
Art_21: Article 21 authority-cooperation record is referenced in the package record, but document completeness, currency, and final operator approval still need to be maintained outside the evaluator for Art_21.
Art_22: For providers established outside the Union, the written mandate and named authorised representative record remain required.
Art_26: The deployer-owned operating record, instructions-of-use alignment, oversight assignment, log handling, and authority or provider notifications remain required where Article 26 applies.
Art_27: The deployer-owned FRIA, updates, consultation path, and any linked impact-assessment records remain required where Article 27 applies.
Art_43: Article 43 conformity assessment record is referenced in the package record, but document completeness, currency, and final operator approval still need to be maintained outside the evaluator for Art_43.
Art_47: Article 47 declaration of conformity is referenced in the package record, but document completeness, currency, and final operator approval still need to be maintained outside the evaluator for Art_47.
Art_48: The provider-owned CE marking record, including digital or physical placement and notified-body identification where applicable, remains required.
Art_49: The provider-owned EU database or national registration record remains required where Article 49 applies.
Annex_V: Annex V declaration support record is referenced in the package record, but document completeness, currency, and final operator approval still need to be maintained outside the evaluator for Annex_V.

Claim	Status	Why it matters to the reviewer	Evidence
The bundle preserves enough runtime artifacts to reconstruct how the evaluated release was exercised.	Generated here	Lets the reviewer verify that development-stage claims are backed by retained evidence rather than narrative alone.	Article 10 data governance (Data-governance scaffold for sources, representativeness, and preparation steps.) Evidence index (Clause-to-artifact mapping for the bundle.) Manifest (Artifact-level integrity data.) Expanded technical pack (Detailed tables and clause-by-clause scaffolds.)
Architecture, training-data, and broader development-process narrative still need provider-authored text.	Completed by the operator	Shows where the evidence engine stops and provider engineering documentation still needs to be attached.	Article 10 data governance (Data-governance scaffold for sources, representativeness, and preparation steps.) Expanded technical pack (Detailed tables and clause-by-clause scaffolds.) Evidence index (Clause-to-artifact mapping for the bundle.)
The generated section does not claim complete training-data governance or full architecture coverage.	Still open	Avoids over-reading runtime evidence as if it were the whole development record.	Article 10 data governance (Data-governance scaffold for sources, representativeness, and preparation steps.) Evidence index (Clause-to-artifact mapping for the bundle.)

Evidence file	Path	Why it matters
Article 10 data governance	article-10-data-governance.json	Data-governance scaffold for sources, representativeness, and preparation steps.
Evidence index	evidence-index.json	Clause-to-artifact mapping for the bundle.
Expanded technical pack	eu-ai-act-report.html	Detailed tables and clause-by-clause scaffolds.
Manifest	../artifacts/manifest.json	Artifact-level integrity data.

3. Monitoring, functioning, and control

What this section is for

This section gives reviewers a short view of how the evaluated release is meant to be operated, overseen, and escalated.
It combines deployer-facing Article 13 scaffolding with human-oversight and release-review outputs.

Generated here (machine-generated)

Execution quality is healthy across 2 executed case(s).
1 case(s) require approval and 1 case(s) are blocked in the current review queue.
2 case(s) show missing assumption-state capture.

Completed by the operator before handoff

intended purpose statement for deployers
known limitations and acceptable operating conditions
human oversight and escalation instructions
monitoring and maintenance contact path
Named oversight roles, escalation owner, and customer/deployer contact path.
Final instructions-for-use text and safe operating boundary wording.

Still open

Operator-authored intended-use, deployer-facing instructions, and operating constraints remain required.
Human oversight procedures for deployers still require operator-authored narrative.
Provider logging-retention periods, production log controls, and system-specific logging scope remain provider-owned.

Claim	Status	Why it matters to the reviewer	Evidence
The package shows the current oversight queue, technical evidence status, and deployer-facing instruction scaffold for this release.	Generated here	Lets the reviewer see whether oversight and operation controls are grounded in the actual evaluated release.	Article 13 instructions (Instructions-for-use scaffold.) Human oversight summary (Reviewer queue and action map.) Technical evidence review (Technical evidence status and review expectation.)
Named oversight roles, escalation ownership, and final instructions-for-use wording must be completed by the operator.	Completed by the operator	Separates generated release and review facts from the deployer instructions that still need human ownership.	Article 13 instructions (Instructions-for-use scaffold.) Human oversight summary (Reviewer queue and action map.)
Known limitations and assumption-state gaps remain open until the operator closes them in the final dossier and workflow.	Still open	Keeps the reviewer focused on whether the operating boundary is complete enough for handoff.	Article 13 instructions (Instructions-for-use scaffold.) Technical evidence review (Technical evidence status and review expectation.)

Evidence file	Path	Why it matters
Article 13 instructions	article-13-instructions.json	Instructions-for-use scaffold.
Human oversight summary	human-oversight-summary.json	Reviewer queue and action map.
Technical evidence review	release-review.json	Technical evidence status and review expectation.

4. Performance metrics and limitations

What this section is for

This section is where a reviewer sees whether the release is technically healthy, what changed, and what limitations were observed.
It is backed by comparable runs, but the business acceptability of those metrics remains operator-owned.

Generated here (machine-generated)

Execution quality status healthy; highlighted cases 2; cases with new security signals 2.
Security signal snapshot: 2 case(s) with new signals; top kinds prompt_injection_marker, unsafe_code_execution.
Technical evidence status not ready with 1 approval case(s) and 1 blocking case(s).

Completed by the operator before handoff

Domain-specific acceptance thresholds and explanation of why these metrics are sufficient for deployment.
Business-harm narrative, acceptable error levels, and customer impact interpretation.

Still open

Operator-authored intended-use, deployer-facing instructions, and operating constraints remain required.
Human oversight procedures for deployers still require operator-authored narrative.

Claim	Status	Why it matters to the reviewer	Evidence
The current technical evidence status is backed by comparable-run evidence and technical evidence review outputs.	Generated here	Supports a fast decision on whether the technical release evidence is healthy enough to read further.	Compare report (Comparable run results and execution-quality details.) Technical evidence review (Technical evidence summary and rationale.) Expanded technical pack (Detailed highlighted cases and signal summaries.)
Acceptance thresholds and harm interpretation still need operator judgment.	Completed by the operator	Shows that technical metrics are present, but deployment acceptability is still a human decision.	Compare report (Comparable run results and execution-quality details.) Technical evidence review (Technical evidence summary and rationale.)
Any unresolved known limitations remain open unless explicitly dispositioned by the operator.	Still open	Prevents a reviewer from treating the measured outputs as a complete deployment approval by themselves.	Expanded technical pack (Detailed highlighted cases and signal summaries.) Technical evidence review (Technical evidence summary and rationale.)

Evidence file	Path	Why it matters
Compare report	../compare-report.json	Comparable run results and execution-quality details.
Technical evidence review	release-review.json	Technical evidence summary and rationale.
Expanded technical pack	eu-ai-act-report.html	Detailed highlighted cases and signal summaries.

5. Article 50 transparency evidence

What this section is for

This section records the requested Article 50 obligations, with the strongest technical verification focused on the Article 50(2) machine-readable marking path from retained outputs and referenced artifacts.
Treat documented_for_handoff as package-level sufficiency for reviewer or counsel handoff after scope, confirmations, and evidence references are recorded; it is not a formal legal opinion that Article 50 compliance is conclusively established.

Generated here (machine-generated)

Retained generated output found: true.
Marking status: partial; marker types: schema, metadata, human_disclosure.
Verification result: machine_readable_evidence_found; machine-readable evidence found: true; human-readable disclosure found: true. Requested obligations: synthetic_content_marking.

Completed by the operator before handoff

Production-channel marker preservation test and deployer-facing disclosure wording.

Still open

Machine-readable marker robustness and downstream preservation remain provider-owned.
Article 50 legal applicability, deployer disclosure wording, and production-channel preservation tests remain operator/provider-authored.
Cryptographic C2PA credential-chain validation, deep binary watermark extraction beyond supported metadata carriers, and any formal legal opinion remain outside this verifier.

Claim	Status	Why it matters to the reviewer	Evidence
The package records Article 50 transparency evidence separately from general transparency and instructions-for-use evidence.	Generated here	Lets the reviewer distinguish Article 50 obligation evidence from broader Article 13 operating instructions.	Article 50 transparency marking (Article 50 transparency evidence scaffold.) Compare report (Shared Article 50 summary and retained-output references.)
Machine-readable marking, downstream preservation, role allocation, and disclosure presentation still need provider or deployer validation.	Completed by the operator	Prevents retained evidence from being treated as a completed Article 50 determination for every obligation.	Article 50 transparency marking (Article 50 transparency evidence scaffold.)
The bundle does not claim that every Article 50 obligation is fully satisfied or that every downstream channel has been proven.	Still open	Keeps the report boundary aligned with evidence support rather than formal compliance signoff.	Article 50 transparency marking (Article 50 transparency evidence scaffold.) Manifest (Integrity index for retained output artifacts.)

Evidence file	Path	Why it matters
Article 50 transparency marking	article-50-transparency-marking.json	Article 50 transparency evidence scaffold.
Compare report	../compare-report.json	Shared Article 50 summary and retained-output references.
Manifest	../artifacts/manifest.json	Integrity index for retained output artifacts.

6. Risk management system (Article 9)

What this section is for

This section gives reviewers a machine-derived draft risk register tied to observed runs, review decisions, and monitoring signals.
It is a starting point for Article 9, not a complete provider-authored risk management system.

Generated here (machine-generated)

8 machine-derived risk entry(ies): 2 from case behaviour, 2 from coverage gaps, 0 from execution quality, 4 from monitoring.
1 blocking, 7 review, and 0 monitor entry(ies).
Post-release monitoring status no_matching_history with 0 drift signal(s).

Completed by the operator before handoff

likelihood and severity rationale owned by the operator
control owner and target review date for each open risk
residual-risk acceptance rationale for any accepted risk
provider decision linkage for block or review risks
Residual-risk acceptance, control owners, and target review dates.

Still open

Operator-owned risk governance still sits outside the evaluator.
Annex III classification and legal interpretation still require counsel.
Trend ingest disabled for this run.
Trend ingest was disabled for this run, so the monitoring window is not refreshed with the current release.
No matching historical runs are available for this monitoring scope.
No prior run is available to compute change-over-time deltas.
This register is generated from runtime evidence and still requires operator-owned likelihood, impact, and acceptance rationale.

Claim	Status	Why it matters to the reviewer	Evidence
The bundle generates a machine-derived draft risk register from observed runs, review outcomes, and monitoring signals.	Generated here	Lets the reviewer see that Article 9 starts from runtime evidence rather than from a blank narrative template.	Article 9 risk register (Machine-derived risk register scaffold.) Technical evidence review (Current technical evidence status and escalation rationale.) Post-market monitoring (Signals that reopen or update risks after release.)
Likelihood rationale, owners, review dates, and residual-risk acceptance still need operator completion.	Completed by the operator	Shows exactly which parts of Article 9 remain human-owned even after the machine-derived draft is present.	Article 9 risk register (Machine-derived risk register scaffold.)
Open residual gaps remain visible until the operator dispositiones them in the final governance workflow.	Still open	Prevents a reviewer from misreading the generated register as a final approved risk-management system.	Article 9 risk register (Machine-derived risk register scaffold.) Post-market monitoring (Signals that reopen or update risks after release.)

Evidence file	Path	Why it matters
Article 9 risk register	article-9-risk-register.json	Machine-derived risk register scaffold.
Technical evidence review	release-review.json	Current technical evidence status and escalation rationale.
Post-market monitoring	post-market-monitoring.json	Signals that reopen or update risks after release.

7. Changes over the lifecycle

What this section is for

This section links Article 17 QMS scaffold controls and monitoring continuity into one lifecycle view.
It shows whether the evaluated release triggered additional review, remediation, or follow-up process requirements.

Generated here (machine-generated)

Article 17 QMS scaffold covers 6 process area(s) with 1 approval-required case(s) and 1 blocking case(s).
Monitoring status no_matching_history; execution quality healthy.
0 run(s) in monitoring window and 2 monitored case(s).

Completed by the operator before handoff

named quality management owner and document approver
written change-management procedure and approval workflow
incident, complaint, and corrective-action handling workflow
document-control, retention, and versioning policy
training, competency, and supplier-management responsibilities
authority and customer communication procedure for material issues
Formal change-control procedures, ownership matrix, training, and communications outside the generated scaffold.

Still open

Article 17 QMS record is referenced in the package record, but document completeness, currency, and final operator approval still need to be maintained outside the evaluator for Art_17.
Operator-authored instructions for use are still required before deployer handoff.
This export summarizes technical evidence; it does not replace deployer-facing operating instructions.
Operator-authored intended-use, deployer-facing instructions, and operating constraints remain required.
Human oversight procedures for deployers still require operator-authored narrative.
Operator-owned risk governance still sits outside the evaluator.
Annex III classification and legal interpretation still require counsel.
Trend ingest disabled for this run.
Trend ingest was disabled for this run, so the monitoring window is not refreshed with the current release.
No matching historical runs are available for this monitoring scope.
No prior run is available to compute change-over-time deltas.
This register is generated from runtime evidence and still requires operator-owned likelihood, impact, and acceptance rationale.
Recurring monitoring cadence, escalation workflow, and regulator-facing reporting remain operator responsibilities.
This plan is a technical scaffold and still requires operator-owned monitoring ownership, cadence, retention, and authority-reporting decisions.
This Article 17 QMS scaffold is a technical scaffold, not a complete quality management system.
Competency management, supplier management, authority communication, and formal document-control procedures remain operator-authored.

Claim	Status	Why it matters to the reviewer	Evidence
The bundle shows a machine-generated lifecycle view across Article 17 QMS scaffold controls and monitoring continuity.	Generated here	Lets the reviewer check whether lifecycle evidence exists for this release instead of inferring process continuity from static prose.	Article 17 QMS scaffold (Lifecycle and process scaffold.) Technical evidence review (Current technical evidence status and checklist.) Post-market monitoring (Monitoring continuity and drift signals.)
Formal procedures, accountable roles, and training expectations still need operator-authored process documentation.	Completed by the operator	Keeps the reviewer aware that the Article 17 QMS scaffold is a technical scaffold, not a complete QMS document set.	Article 17 QMS scaffold (Lifecycle and process scaffold.)
Residual process gaps remain open until they are closed in the provider's management system.	Still open	Makes lifecycle incompleteness visible instead of hiding it behind technical evidence status alone.	Article 17 QMS scaffold (Lifecycle and process scaffold.) Post-market monitoring (Monitoring continuity and drift signals.)

Evidence file	Path	Why it matters
Article 17 QMS scaffold	article-17-qms-lite.json	Lifecycle and process scaffold.
Technical evidence review	release-review.json	Current technical evidence status and checklist.
Post-market monitoring	post-market-monitoring.json	Monitoring continuity and drift signals.

8. Standards and alternative controls

What this section is for

This section is intentionally narrow: the toolkit can point to the evidence that would support standards mapping, but it does not infer harmonised standards or common-specification claims.
Reviewers should treat this as a support layer, not as an auto-generated conformity statement.

Generated here (machine-generated)

Coverage snapshot: 24 covered, 1 partial, 0 missing · 7 technical evidence collected, 5 awaiting operator, 2 outside toolkit scope (covered clauses only).
Package closing verdict handoff_ready with readiness ready_for_handoff, section completion 9/9, 8/8 referenced record(s), and 16 referenced legal artifact(s).
Machine-readable evidence selectors and bundle artifacts that can be referenced inside a standards-mapping appendix.

Completed by the operator before handoff

Harmonised standards or common specifications actually relied upon.
Alternative control rationale where harmonised standards are not used.
Notified body references and any external conformity-assessment narrative.

Still open

Art_9: Operator-owned risk governance still sits outside the evaluator.
Art_9: Annex III classification and legal interpretation still require counsel.
Art_10: Dataset provenance, representativeness review, bias review, and preparation records remain provider-authored legal inputs.
Art_11: Annex IV technical documentation is referenced in the package record, but document completeness, currency, and final operator approval still need to be maintained outside the evaluator for Art_11.
Annex_IV: Annex IV technical documentation is referenced in the package record, but document completeness, currency, and final operator approval still need to be maintained outside the evaluator for Annex_IV.
Art_12: Provider logging-retention periods, production log controls, and system-specific logging scope remain provider-owned.
Art_13: Operator-authored intended-use, deployer-facing instructions, and operating constraints remain required.
Art_13: Human oversight procedures for deployers still require operator-authored narrative.
Art_17: Article 17 QMS record is referenced in the package record, but document completeness, currency, and final operator approval still need to be maintained outside the evaluator for Art_17.
Art_50: Machine-readable marker robustness and downstream preservation remain provider-owned.
Art_50: Article 50 legal applicability, deployer disclosure wording, and production-channel preservation tests remain operator/provider-authored.
Art_14: Deployer-facing oversight procedures, staffing, escalation rules, and operating playbooks remain operator-authored.
Art_15: Sector-specific validation thresholds, production robustness targets, cybersecurity controls, and acceptance criteria remain provider-owned.
Art_72: Recurring monitoring cadence, escalation workflow, and regulator-facing reporting remain operator responsibilities.
Art_73: Provider-owned incident classification, authority notification timing, and production escalation records remain required.
Art_16: Provider-owned records for Section 2 compliance, declaration, marking, registration, and authority-facing obligations remain required.
Art_18: Article 18 documentation-keeping record is referenced in the package record, but document completeness, currency, and final operator approval still need to be maintained outside the evaluator for Art_18.
Art_19: Article 19 automatic-log retention record is referenced in the package record, but document completeness, currency, and final operator approval still need to be maintained outside the evaluator for Art_19.
Art_20: Article 20 corrective-action and duty-of-information record is referenced in the package record, but document completeness, currency, and final operator approval still need to be maintained outside the evaluator for Art_20.
Art_21: Article 21 authority-cooperation record is referenced in the package record, but document completeness, currency, and final operator approval still need to be maintained outside the evaluator for Art_21.
Art_22: For providers established outside the Union, the written mandate and named authorised representative record remain required.
Art_26: The deployer-owned operating record, instructions-of-use alignment, oversight assignment, log handling, and authority or provider notifications remain required where Article 26 applies.
Art_27: The deployer-owned FRIA, updates, consultation path, and any linked impact-assessment records remain required where Article 27 applies.
Art_43: Article 43 conformity assessment record is referenced in the package record, but document completeness, currency, and final operator approval still need to be maintained outside the evaluator for Art_43.
Art_47: Article 47 declaration of conformity is referenced in the package record, but document completeness, currency, and final operator approval still need to be maintained outside the evaluator for Art_47.
Art_48: The provider-owned CE marking record, including digital or physical placement and notified-body identification where applicable, remains required.
Art_49: The provider-owned EU database or national registration record remains required where Article 49 applies.
Annex_V: Annex V declaration support record is referenced in the package record, but document completeness, currency, and final operator approval still need to be maintained outside the evaluator for Annex_V.

Claim	Status	Why it matters to the reviewer	Evidence
The bundle can support standards mapping by exposing clause coverage and evidence selectors.	Generated here	Lets the reviewer anchor standards discussion to actual evidence instead of to unlinked narrative references.	EU coverage export (Clause status and residual gaps.) Article 43 conformity assessment (Conformity-assessment route and supporting record scaffold.) Evidence index (Selectors and manifest-backed links.) Annex IV JSON (Structured coverage-ready dossier data.)
Any actual standards reliance or alternative-control rationale must be completed by the operator.	Completed by the operator	Prevents readers from treating coverage selectors as if they were already a standards claim.	EU coverage export (Clause status and residual gaps.) Article 43 conformity assessment (Conformity-assessment route and supporting record scaffold.) Annex IV JSON (Structured coverage-ready dossier data.)
This section does not itself establish harmonised-standard or common-specification compliance.	Still open	Keeps the boundary explicit between technical evidence support and formal conformity positioning.	EU coverage export (Clause status and residual gaps.)

Evidence file	Path	Why it matters
EU coverage export	eu-ai-act-coverage.json	Clause status and residual gaps.
Annex IV JSON	eu-ai-act-annex-iv.json	Structured coverage-ready dossier data.
Article 43 conformity assessment	article-43-conformity-assessment.json	Conformity-assessment route and supporting record scaffold.
Evidence index	evidence-index.json	Selectors and manifest-backed links.

9. EU Declaration of Conformity boundary (Annex V)

What this section is for

The toolkit does not generate the legal declaration itself.
What it does provide is the technical record that can support the declaration's factual statements about system identity, review scope, and supporting evidence.

Generated here (machine-generated)

Versioned system identity and technical evidence status that can be cited in a declaration pack.
Portable evidence links that can be attached or referenced from the declaration package.

Completed by the operator before handoff

The Annex V declaration text, legal basis, and provider-responsibility statement.
Applicable-law references, notified body details, date, place, signer name, and title.

Still open

Declaration drafting and legal signoff remain outside the generated toolkit outputs.

Claim	Status	Why it matters to the reviewer	Evidence
The bundle provides technical facts that can support declaration drafting.	Generated here	Lets the reviewer reuse verified system identity and release evidence when assembling a declaration package.	Annex IV JSON (Technical support for declaration drafting.) Article 43 conformity assessment (Conformity-assessment route backing the declaration path.) Article 47 declaration scaffold (Provider declaration scaffold for the evaluated system version.) Annex V declaration content (Required Annex V declaration-content items and gaps.) Compare report (Technical release results backing the declaration.) Technical evidence review (Current technical evidence status for the evaluated system version.)
The legal declaration text and sign-off remain operator-owned.	Completed by the operator	Makes it explicit that the technical pack supports the declaration but does not replace it.	Article 43 conformity assessment (Conformity-assessment route backing the declaration path.) Article 47 declaration scaffold (Provider declaration scaffold for the evaluated system version.) Annex V declaration content (Required Annex V declaration-content items and gaps.) Technical evidence review (Current technical evidence status for the evaluated system version.)
No declaration of conformity is generated by the toolkit outputs.	Still open	Prevents a reviewer from mistaking technical support for a completed Annex V declaration.	Article 47 declaration scaffold (Provider declaration scaffold for the evaluated system version.) Annex V declaration content (Required Annex V declaration-content items and gaps.)

Evidence file	Path	Why it matters
Annex IV JSON	eu-ai-act-annex-iv.json	Technical support for declaration drafting.
Article 43 conformity assessment	article-43-conformity-assessment.json	Conformity-assessment route backing the declaration path.
Article 47 declaration scaffold	article-47-declaration-of-conformity.json	Provider declaration scaffold for the evaluated system version.
Annex V declaration content	annex-v-declaration-content.json	Required Annex V declaration-content items and gaps.
Legal artifact manifest	legal-artifact-manifest.json	Which declaration-path legal artifacts are bundled, external, or still declared-only.
Compare report	../compare-report.json	Technical release results backing the declaration.
Technical evidence review	release-review.json	Current technical evidence status for the evaluated system version.

10. Post-market monitoring and serious incidents

What this section is for

This section groups the post-market monitoring plan and serious-incident triage into one reviewer-facing end-of-dossier section.
It is designed for fast external reading: what is being watched, what triggered concern, and what still requires human reporting judgment.

Generated here (machine-generated)

Monitoring plan status no_matching_history with 0 run(s) in window.
Serious-incident machine triage review_for_serious_incident with 4 trigger(s).
2 high/critical signal(s) and technical evidence status not ready.

Completed by the operator before handoff

named monitoring owner and backup owner
monitoring cadence and SLA by deployment context
incident, customer, and authority notification workflow
retention period and archive location for monitoring artifacts
corrective-action and rollback authority for repeated drift or blocking findings
named serious-incident owner and escalation backup
human determination of whether the event meets Article 73 serious-incident threshold
authority, customer, and internal notification routing by jurisdiction
incident impact assessment and affected-person analysis
reporting deadline calculation and external communications approver
Legal incident threshold assessment, authority routing, and disclosure decision.

Still open

Trend ingest disabled for this run.
Trend ingest was disabled for this run, so the monitoring window is not refreshed with the current release.
No matching historical runs are available for this monitoring scope.
No prior run is available to compute change-over-time deltas.
Operator-owned risk governance still sits outside the evaluator.
Annex III classification and legal interpretation still require counsel.
This register is generated from runtime evidence and still requires operator-owned likelihood, impact, and acceptance rationale.
Recurring monitoring cadence, escalation workflow, and regulator-facing reporting remain operator responsibilities.
Operator-authored instructions for use are still required before deployer handoff.
This export summarizes technical evidence; it does not replace deployer-facing operating instructions.
Operator-authored intended-use, deployer-facing instructions, and operating constraints remain required.
Human oversight procedures for deployers still require operator-authored narrative.
This plan is a technical scaffold and still requires operator-owned monitoring ownership, cadence, retention, and authority-reporting decisions.
This export does not decide whether the legal threshold for a serious incident has been met.
Authority reporting workflow, deadlines, and jurisdiction-specific notification content remain operator-authored.
Final incident narrative, impact assessment, and external communications approval remain outside the evaluator.

Claim	Status	Why it matters to the reviewer	Evidence
The package provides machine-generated monitoring and incident-triage scaffolds tied to current and historical signals.	Generated here	Gives the reviewer a fast end-of-dossier view of what is being monitored and whether serious-incident triggers are already visible.	Article 72 monitoring plan (Technical monitoring-plan scaffold.) Post-market monitoring (Observed history and drift/watchlist summary.) Article 73 serious-incident pack (Machine-generated incident triage scaffold.)
Monitoring ownership, reporting obligations, and incident routing still need operator completion.	Completed by the operator	Shows where operational and legal reporting duties still sit outside the generated machine layer.	Article 72 monitoring plan (Technical monitoring-plan scaffold.) Article 73 serious-incident pack (Machine-generated incident triage scaffold.)
Open monitoring and incident gaps remain visible until the operator closes them in the final post-market workflow.	Still open	Keeps unresolved monitoring and reporting gaps visible instead of burying them inside the technical scaffolds.	Post-market monitoring (Observed history and drift/watchlist summary.) Article 73 serious-incident pack (Machine-generated incident triage scaffold.)

Evidence file	Path	Why it matters
Article 72 monitoring plan	article-72-monitoring-plan.json	Technical monitoring-plan scaffold.
Post-market monitoring	post-market-monitoring.json	Observed history and drift/watchlist summary.
Article 73 serious-incident pack	article-73-serious-incident-pack.json	Machine-generated incident triage scaffold.