Deliverables: specification and synthetic sample of every document AIAssuranceLabs produces
This page specifies every deliverable AIAssuranceLabs produces: sections, formats, the articles it is designed to satisfy, and the protocol that produces it. Each specification ends with a template-level sample filled with synthetic data. Every deliverable is a test record or an evidence structure inside the service boundary. The deliverables table on each service page links to the specification here, so the service item and the specification are one record. Nothing here is a document from an engagement.
How to read a specification
Each block below carries the same fields. Sections lists the numbered parts of the document in the order they appear. Formats names the file types handed over. Designed to satisfy links the obligation pages the document addresses. A robustness test report links Art. 15; an assembled technical file section links Annex IV. Produced by names the versioned protocol whose run yields the document, for example PR-15-ROB v1.0. The protocol pages on /methodology/ list the steps behind each output. Included in links the services that itemise the document, or states that every protocol run includes it. Every sample carries the label "Sample, synthetic data", and every value in a sample is invented for the layout.
Test report
The record of one protocol run against one system version: what was tested, under which conditions, with which metric, against which criterion source, and the verdict per element.
Sections
- System under test: name, version hash, deployment context, intended purpose as stated in the instructions for use
- Protocol and version, with the derivation line copied from the methodology page
- Test environment: hardware, software versions, seeds, data set identifiers
- Results per testable element: metric, condition, value, criterion source, verdict
- Deviations from the protocol and their reason
- Findings passed to the findings register
- Attachments: raw result files, configuration, protocol run record
- Formats
- PDF with Markdown source; CSV result tables; JSON run manifest
- Designed to satisfy
- Produced by
- Included in
Sample, synthetic data
| Test id | Element | Metric | Condition | Value | Criterion source | Verdict |
|---|---|---|---|---|---|---|
| ROB-ACC-01 | Art. 15(1) accuracy on held-out data | balanced accuracy | held-out set HO-A, synthetic, 2 000 records, seed 17 | 0.912 | provider declaration, instructions for use section 4 (synthetic target 0.90) | meets |
| ROB-SHIFT-02 | Art. 15(1) accuracy under distribution shift | balanced accuracy | shifted set SH-B, synthetic, age band 55+ upweighted | 0.874 | provider justification record, step 21 of PR-15-ROB | below declared target; finding F-03 |
| ROB-PERT-05 | Art. 15(4) robustness to input perturbation | output stability rate | Gaussian noise sigma 0.05 on numeric inputs, 500 synthetic cases | 0.996 | ISO/IEC TR 24029-1:2021 empirical category; threshold set by provider | meets |
Results table of a robustness test report, three rows.
Protocol run record
The executed copy of a versioned protocol: each step with its timestamp, operator function, configuration, and the record it produced. It accompanies every test report and lets a third party repeat the run.
Sections
- Protocol id, version and derivation line as published on the methodology page
- Run identifier, system version hash, environment manifest
- Step log: step number, executed or skipped with reason, configuration, record reference
- Data set manifest: identifiers, hashes, synthetic or client-provided
- Operator function (no individual names) and independent check
- Formats
- JSON run log; Markdown rendering
- Designed to satisfy
- Produced by
- Included in
- every engagement that runs a protocol
Sample, synthetic data
| Step | Status | Configuration | Record |
|---|---|---|---|
| PR-15-ROB step 12 | executed | held-out set HO-A, seed 17, metric balanced accuracy | results/ho-a.csv (synthetic) |
| PR-15-ROB step 16 | skipped | system does not learn after deployment; feedback-loop test not applicable | reason logged in run manifest |
| PR-15-ROB step 34 | executed | report template v1.0 | report/R-2026-A.md (synthetic) |
Step log excerpt of a protocol run record.
Traceability matrix
One row per obligation element: the article paragraph, the test or document that addresses it, the evidence file, its location in the technical file, and the current status.
Sections
- Matrix: obligation element, type (testable, documentation, process), protocol step or document, evidence artifact, technical file location, status
- Coverage summary per article: elements covered, open, not applicable with reason
- Change log of the matrix itself, keyed to system versions
- Legend: status values and their meaning
- Formats
- XLSX; CSV; Markdown table for the technical file
- Designed to satisfy
- Produced by
- Included in
Sample, synthetic data
| Id | Obligation element | Type | Addressed by | Evidence | Technical file location | Status |
|---|---|---|---|---|---|---|
| TM-015-01 | Art. 15(1): accuracy on held-out data at the declared level | testable | PR-15-ROB steps 12 to 15 | Robustness test report R-2026-A, table 3 (synthetic) | Annex IV section 2(g) | covered |
| TM-013-02 | Art. 13(3)(b)(ii): accuracy metrics declared in the instructions for use | documentation | PR-11-DOC step 18, consistency check | Instructions for use draft 4, section 4 (synthetic) | Annex IV section 1(h) | open: value differs from measured |
| TM-009-04 | Art. 9(2): risk management as a continuous iterative process | process | PR-17-QMS step 9 | Risk management procedure RM-02, review minutes (synthetic) | Annex IV section 2(f) | covered |
Three rows of a traceability matrix.
Evidence pack
The assembled set of documents an assessor or a market surveillance authority asks for, with an index that names each item, its version, its source protocol and the gaps that remain.
Sections
- Index: item, version, source protocol or author function, Annex IV section, status
- Assembled technical file sections drawn from test results, in Annex IV order
- For general-purpose AI models: Annex XI documentation contribution and the Annex XII downstream information pack
- Gap list: Annex IV sections without evidence, with the protocol step that would produce it
- Version and hash of every included file
- Formats
- Folder with index (PDF, Markdown); ZIP with hash manifest
- Designed to satisfy
- Produced by
- Included in
Sample, synthetic data
| Item | Version | Source | Annex IV section | Status |
|---|---|---|---|---|
| General description of the system | v0.4 (synthetic) | provider documentation function | 1(a) to 1(h) | present |
| Robustness test report R-2026-A | v1.0 (synthetic) | PR-15-ROB output | 2(g) | present |
| Post-market monitoring plan | none | provider QMS function | 9 | gap: PR-17-QMS step 27 produces the template |
Evidence-pack index, three rows.
Findings register
Every gap, deviation or failed criterion from a run, a gap analysis or a mock assessment, with severity, the article reference, the evidence, and the action and re-test criterion that closes it.
Sections
- Register: id, finding, severity, article or annex reference, evidence, owner function, action, re-test criterion, status
- Severity scale with definitions (blocks the route, gap in evidence, documentation defect, observation)
- Summary per article and per Annex VI or VII point
- Remediation plan or corrective-action plan ordered by severity, without dates typed by the company
- Re-test criteria that a follow-up run verifies
- Formats
- XLSX; CSV; PDF summary
- Designed to satisfy
- Produced by
- Included in
Sample, synthetic data
| Id | Finding | Severity | Reference | Evidence | Action | Re-test criterion | Status |
|---|---|---|---|---|---|---|---|
| F-03 | Accuracy under the age-band shift is below the value declared in the instructions for use | gap in evidence | Art. 15(1), Art. 13(3)(b)(ii) | R-2026-A table 3 row ROB-SHIFT-02 (synthetic) | provider revises the declared value or the training set; re-run PR-15-ROB steps 13 to 15 | shifted-set balanced accuracy at or above the revised declaration | open |
| F-07 | Logs record the model output but not the input data version | blocks the route | Art. 12(2)(c) | PR-12-LOG step 14 completeness table (synthetic) | add input version field to the log schema; re-run PR-12-LOG steps 12 to 16 | every sampled log record carries the field | open |
| F-11 | Human oversight measures are described without the override test evidence | documentation defect | Annex IV section 2(e), Art. 14(4)(d) | technical file draft 4 section 2(e) (synthetic) | attach PR-14-OVR report section 3 | section cites the report | closed |
Findings register, three rows.
Assessment memo
A reasoned technical assessment of one question: classification, marking architecture, a design review, a consistency check or an impact assessment. It states the question, the evidence read, the reasoning by article, and the conclusion for discussion with counsel.
Sections
- Question and system version
- Evidence read: documents, configuration, test results, with versions
- Reasoning by article or annex point, each step citing the text or a guideline with its status
- Conclusion, labelled as a reasoned technical assessment for discussion with counsel, never as a legal opinion
- Open points and the evidence that would close them
- Formats
- PDF with Markdown source
- Designed to satisfy
- Produced by
- Included in
- Classification and readiness assessment
- Article 50 transparency and marking/watermark testing
- Bias and fairness testing under the Omnibus sensitive-data provision
- Logging and human-oversight verification
- Technical documentation and evidence-pack preparation
- Pre-conformity mock assessment
- FRIA facilitation and evidence structuring
- Data governance and dataset quality testing
- Regression testing after substantial modification
Sample, synthetic data
| Step | Question | Evidence read | Reasoning | Result |
|---|---|---|---|---|
| 1 | Role of the organisation | product description v2 (synthetic), contract template | The organisation develops the system and places it on the market under its own name: Art. 3(3) provider definition | provider |
| 2 | Annex III match | intended purpose statement, user manual section 1 (synthetic) | The system ranks job applications: Annex III point 4(a) | Annex III match: yes |
| 3 | Art. 6(3) exception | system architecture note (synthetic) | The output is a ranking that materially influences the hiring decision; Art. 6(3) second subparagraph: profiling excludes the exception | high-risk; exception not available |
Reasoning table of a classification memo, three rows.
Register or checklist
A structured list the client maintains after the engagement: an obligation register with the applicability dates from the regulation data, a readiness roadmap ordered by deadline and effort, an incident tracking template, a notification checklist or an internal audit checklist.
Sections
- Rows: item, article reference, applicability entry from the regulation data (never a typed date), owner function, status
- Ordering rule where the list is a roadmap: deadline first, effort second, both stated per row
- Column definitions and status values
- Version and the regulation change-log entry the register was built against
- Formats
- XLSX; CSV; Markdown
- Designed to satisfy
- Produced by
- Included in
Sample, synthetic data
| Id | Obligation | Reference | Applicability entry | Owner function | Status |
|---|---|---|---|---|---|
| OR-01 | Risk management system established and documented | Art. 9 | annex-iii-high-risk | quality function | in progress |
| OR-05 | Logging capability records the Art. 12(2) minimum content | Art. 12(1), 12(2) | annex-iii-high-risk | engineering function | not started |
| OR-12 | Chatbot interaction disclosed to the natural person | Art. 50(1) | article-50-transparency | product function | done |
Obligation register, three rows.
Dataset profile and dataset cards
The measured properties of the training, validation and test sets against the Art. 10 quality criteria, with one dataset card per set that states origin, collection, preparation, coverage, gaps and the bias examination performed.
Sections
- Profile per set: size, sources, collection period as a range of versions (no typed dates), representativeness measures per attribute, coverage gaps, error and label-noise rates with the sampling method
- Lineage: transformations from raw data to the set, with hashes
- Dataset card per set following the Art. 10(2) points (a) to (h)
- Bias examination summary with the metrics and the subgroups examined
- Open gaps and the data-governance measure that addresses each
- Formats
- Markdown dataset cards; CSV profile tables; JSON lineage manifest
- Designed to satisfy
- Produced by
- Included in
Sample, synthetic data
| Set | Attribute | Subgroup | Share in set | Share in reference population | Reference source | Gap |
|---|---|---|---|---|---|---|
| TRAIN-01 (synthetic) | age band | 55 and over | 0.08 | 0.19 | provider's stated deployment population, intended purpose statement section 2 (synthetic) | under-represented |
| TRAIN-01 (synthetic) | sex | female | 0.47 | 0.51 | same | within the provider's tolerance of 0.05, recorded at PR-10-BIAS step 9 |
| TEST-01 (synthetic) | region | rural | 0.12 | 0.27 | same | under-represented; test results for the subgroup carry a low-count flag |
Representativeness table of a dataset profile, three rows.
FRIA record
The structured fundamental rights impact assessment record for a deployer under Art. 27, aligned to the clause structure of ISO/IEC 42005, with the affected-groups mapping and the bias and accuracy evidence it draws on.
Sections
- Description of the deployer's processes in which the system is used, in line with its intended purpose (Art. 27(1)(a))
- Period and frequency of use (Art. 27(1)(b))
- Categories of natural persons and groups likely affected (Art. 27(1)(c)), as a mapping table
- Specific risks of harm per category, with the evidence drawn from bias and accuracy test reports (Art. 27(1)(d))
- Human oversight measures as implemented (Art. 27(1)(e))
- Measures when risks materialise: governance, complaint mechanisms (Art. 27(1)(f))
- Notification record and the questionnaire template where issued
- Relationship to the data protection impact assessment
- Formats
- PDF with Markdown source; XLSX affected-groups mapping
- Designed to satisfy
- Produced by
- Included in
Sample, synthetic data
| Group | Right engaged | How the system touches it | Evidence | Risk of harm | Measure |
|---|---|---|---|---|---|
| Applicants aged 55 and over | non-discrimination (Charter Art. 21) | ranking score used to shortlist | R-2026-A row ROB-SHIFT-02, subgroup table B-04 (synthetic) | lower shortlisting rate at equal qualification | human review of every rejection in the subgroup; re-test after model update |
| Applicants with a disability | non-discrimination, integration (Charter Art. 21, 26) | CV parsing may drop non-standard formats | PR-10-BIAS step 11 coverage check (synthetic) | exclusion at parsing stage | manual intake channel; parsing error rate monitored |
| All applicants | data protection (Charter Art. 8) | profiling on application data | DPIA v3 (synthetic) | unlawful processing | DPIA reused under Art. 27(4); legal basis recorded |
Affected-groups mapping, three rows.
Formats and handover
Text documents are handed over as Markdown sources with a PDF rendering of each. The provider can place the Markdown source in its technical file under Art. 11 and version it there. Tables are handed over as CSV or XLSX. Every handover includes a JSON manifest that lists each file with its hash. With the manifest a third party can verify that a file in the technical file is the file produced. Where a register carries an applicability entry, the entry id points to the regulation data and the register records the change-log entry it was built against. There is no portal and no tracking: files are transferred once, and the site collects nothing.
Every inquiry receives a reply within 24 hours. Scope and availability are discussed per request.