Logging completeness and reconstruction protocol (PR-12-LOG)
PR-12-LOG tests the logging capability of a high-risk AI system against Art. 12 and the deployer's log duties under Art. 26(6). The protocol reviews the log design against an expected event set, runs the system to check automatic recording and continuity after an update, tests tamper evidence and retention, and reconstructs sampled decisions from the logs alone. The protocol produces a logging design review record, a completeness, integrity and retention test report, and a decision reconstruction record with a synthetic sample layout.
| Field | Value |
|---|---|
| Protocol | PR-12-LOG |
| Version | v1.0 |
| Articles | |
| Derived from |
|
PR-12-LOG v1.0 is built from prEN 18229-1Enquiry, prEN ISO/IEC 24970Approval and the minimum log content in Art. 12(1) to Art. 12(3) of Regulation (EU) 2024/1689, read with the deployer retention duty in Art. 26(6).
Scope
The protocol covers high-risk AI systems under Art. 6 of Regulation (EU) 2024/1689 that carry the record-keeping duty in Art. 12. The protocol also covers the logs under a deployer's control under Art. 26(6). The duties apply from the Annex III application date Deferred for systems classified under Art. 6(2). For systems classified under Art. 6(1), the duties apply from the Annex I application date Deferred.
The protocol covers five groups of elements. The first group is the logging design: the event catalogue and the fields per event. The protocol compares the design against an expected event set built from prEN ISO/IEC 24970Approval and prEN 18229-1Enquiry. The second group is completeness: automatic recording during normal operation, continuity after an update, and the presence of the events that serve the purposes in Art. 12(2)(a) to (c). The third group is integrity: the tamper-evidence mechanism that protects stored records, tested by altering a copy. The fourth group is retention: the configured retention period and the oldest retained record, compared against the policy and Art. 26(6). The fifth group is reconstruction: sampled decisions rebuilt from the logs alone, on the provider side and on the deployer side. For remote biometric identification systems in Annex III point 1(a), the protocol adds the four minimum items in Art. 12(3)(a) to (d).
The protocol does not cover the human oversight elements of Art. 26(1) to (3) and Art. 26(5); PR-14-OVR v1.0 covers them. The protocol does not cover input data representativeness under Art. 26(4); PR-10-BIAS v1.0 covers it. The protocol does not test the content of the risk management file under Art. 9 or the post-market monitoring plan under Art. 72. The protocol takes both documents as inputs and tests whether the logs supply what each document names. The protocol does not assess the retention period a provider or deployer selects under other Union or national law. The protocol records the stated legal basis for that period and tests whether the configuration matches the policy.
Articles covered
The testable elements are quoted from the obligation records. The Steps column names the steps that produce the observable result for each element.
| Article | Testable element | Steps |
|---|---|---|
| Art. 12(1) | Events are recorded automatically by the system, without an operator action, during normal operation (Art. 12(1)) | 14, 15 |
| Art. 12(1) | Logging continues to function, with the same event set and format, after a model, software or configuration update over the lifetime of the system (Art. 12(1)) | 16, 17 |
| Art. 12(2) | A sampled decision can be reconstructed from the logs alone: the input, the model version, the configuration in force, the output and the timestamp of the event (Art. 12(2)) | 29, 30, 32, 34 |
| Art. 12(2) | Each risk indicator named in the risk management file under Art. 9 has a log event that records it, and the event fires when the indicator condition is met (Art. 12(2)(a)) | 18 |
| Art. 12(2) | A model version change, a threshold change or a configuration change after placing on the market produces a log event that identifies it as a candidate substantial modification (Art. 12(2)(a)) | 19 |
| Art. 12(2) | Each data point the post-market monitoring plan under Art. 72 consumes is present in the logs with the field definition the plan expects (Art. 12(2)(b)) | 20 |
| Art. 12(2) | The logs the deployer needs for monitoring operation under Art. 26(5) are readable and exportable by the deployer through the mechanism described in the instructions for use (Art. 12(2)(c)) | 21 |
| Art. 12(3) | For Annex III point 1(a) systems, each use has a logged start date and time and end date and time, and the two timestamps bound the observed session (Art. 12(3)(a)) | 13, 26 |
| Art. 12(3) | For Annex III point 1(a) systems, each match records the identifier of the reference database checked and the input data that produced the match (Art. 12(3)(b) and (c)) | 13, 27 |
| Art. 12(3) | For Annex III point 1(a) systems, each verified result records the identification of the natural persons who performed the verification under Art. 14(5) (Art. 12(3)(d)) | 13, 28 |
| Art. 26(6) | The logs automatically generated by the system and under the deployer's control are complete and readable: a sampled decision can be reconstructed from the retained logs (Art. 26(6)) | 21, 31, 32 |
| Art. 26(6) | The retention configuration of the log store enforces the period of at least six months in Art. 26(6), or the different period that applicable Union or national law sets (Art. 26(6)) | 24, 25, 35 |
The remaining testable elements of the Art. 26 record, under Art. 26(1) to (5), belong to PR-14-OVR v1.0 and PR-10-BIAS v1.0. Steps 22 and 23 test log integrity. The integrity test supports the reconstruction elements, because a reconstructed decision has evidential value only when the source records are shown to be unaltered.
Inputs required
| Input | Format | Provided by |
|---|---|---|
| Instructions for use with the intended purpose and the log mechanism description under Art. 13(3)(f) | PDF or Markdown, version identified | Provider, or deployer for a deployed system |
| Log schema and event catalogue from the technical documentation, Annex IV section 3 | Schema file (JSON Schema, Avro, Protobuf or table) plus the event list | Provider |
| Risk management file under Art. 9 with the list of risk indicators | Document with one row per indicator and its condition | Provider |
| Post-market monitoring plan under Art. 72 with the data points the plan consumes | Document with one row per data point and its field definition | Provider |
| Traceability rationale: the justified traceability level and the event set, where one exists | Document, or a written statement that none exists | Provider |
| Log retention policy and the legal basis for any period that differs from Art. 19 or Art. 26(6) | Document | Provider for logs under provider control; deployer for logs under deployer control |
| Read access to the log store, with the store type and the query interface | Credentials for a read-only role, connection details | Provider or deployer, per store |
| The deployer export mechanism described in the instructions for use, with deployer credentials | Export tool, API or interface access | Deployer |
| A test environment in which the system runs and accepts updates and configuration changes | Environment with the version under test and a change procedure | Provider |
| A model, software or configuration update to apply in the test environment | Versioned artifact with a change note | Provider |
| Access to the system output store as the record of truth for the reconstruction comparison | Read-only query access | Provider or deployer |
| For Annex III point 1(a) systems: a test reference database, a matching input and an assigned verifier | Database identifier, input sample, named role under Art. 14(5) | Provider and deployer |
| Test input set and sampling method | test-plan, generated in step 10 | Protocol |
| Expected event set | expected-event-set, generated in steps 6 and 7 | Protocol |
Steps
Preparation
Record the system identity, the role as provider or deployer, and the intended purpose from the instructions for use.
Record scope-record: system name, version under test, role, intended purpose statement
[AIAssuranceLabs procedure]
Record whether the system is a remote biometric identification system under Annex III point 1(a).
Record scope-record: Art. 12(3) branch set to applies or does not apply, with the reason
[Regulation (EU) 2024/1689, Art. 12(3)]
Collect the log schema and event catalogue from the technical documentation.
Record log-schema-input: the document reference, the version collected and the storage location named
[Regulation (EU) 2024/1689, Annex IV section 3]
Collect the risk management file, the post-market monitoring plan and the log mechanism description in the instructions for use.
Record purpose-inputs: references to the Art. 9 file, the Art. 72 plan and the Art. 13(3)(f) text
[Regulation (EU) 2024/1689, Art. 12(2)]
Record the provider's traceability rationale and the event set the provider justifies against the intended purpose.
Record traceability-rationale-record: the justified traceability level and the event set, or a note that no rationale exists
[Regulation (EU) 2024/1689, Art. 12(2)]
Build the expected event set from the reference event model and the purposes in Art. 12(2)(a) to (c).
Record expected-event-set: one row per event with purpose, trigger and required fields
[prEN ISO/IEC 24970, approval, clause on the logging information model]
Assign to each expected event the fields the logging requirements name for that event type.
Record expected-event-set: field list per event, with the source clause per field
[prEN 18229-1, enquiry, clause on log content and fields]
Obtain read access to the log store and the deployer export mechanism, and record the access path.
Record access-record: store location, credentials role, export mechanism name, access stamp read from the store
[AIAssuranceLabs procedure]
Record the retention policy and the retention period claimed for logs under provider and deployer control.
Record retention-policy-input: policy reference, claimed period per log class, legal basis for any different period
[Regulation (EU) 2024/1689, Art. 19 and Art. 26(6)]
Define the test input set and the sampling method for reconstruction, and record both with the reason.
Record test-plan: input set description, sample size, selection method, reason for each choice
[AIAssuranceLabs procedure]
The expected event set from steps 6 and 7 takes the layout below. The values are synthetic; the event names and fields are placeholders that the schema under test replaces.
# expected-event-set (synthetic)
- event: decision.issued
purpose: [Art. 12(2)(a), Art. 12(2)(b), Art. 12(2)(c)]
trigger: the system returns an output to the deployer interface
fields: [event_id, ts, event_type, source_id, correlation_id,
input_ref, model_version, config_hash, output]
- event: risk.indicator.fired
purpose: [Art. 12(2)(a)]
trigger: an indicator in the risk management file meets its condition
fields: [event_id, ts, event_type, source_id, correlation_id,
indicator_id, observed_value, condition]
- event: config.changed
purpose: [Art. 12(2)(a)]
trigger: the model version, a threshold or a configuration value changes
fields: [event_id, ts, event_type, source_id, actor_id,
before, after, candidate_substantial_modification]
- event: session.opened / session.closed # Annex III point 1(a) only
purpose: [Art. 12(3)(a)]
trigger: a use of the system starts or ends
fields: [event_id, ts, event_type, source_id, session_id, reference_db_id]
- event: match.found # Annex III point 1(a) only
purpose: [Art. 12(3)(b), Art. 12(3)(c)]
trigger: a search returns a match
fields: [event_id, ts, event_type, source_id, session_id,
reference_db_id, input_ref]
- event: result.verified # Annex III point 1(a) only
purpose: [Art. 12(3)(d)]
trigger: an assigned person verifies a result under Art. 14(5)
fields: [event_id, ts, event_type, source_id, session_id,
match_event_id, verifier_ids]Execution
Compare the event catalogue against the expected event set and record each missing or extra event.
Record design-review-table: one row per expected event with status present, missing or extra
[prEN 18229-1, enquiry, clause on required log events]
Check that each catalogued event carries a time-zoned timestamp, an event type, a source identifier and a correlation identifier.
Record design-review-table: field presence per event for timestamp, event type, source identifier and correlation identifier
[prEN ISO/IEC 24970, approval, clause on log record structure]
For Annex III point 1(a) systems, check that the schema defines the four Art. 12(3) fields.
Record design-review-table: period of use, reference database identifier, matched input data and verifier identification, each present or missing
[Regulation (EU) 2024/1689, Art. 12(3)(a) to (d)]
Run the test input set through the system in normal operation with no operator action on logging.
Record run-log-A: the exported events for the run, with the run identifier and the version under test
[Regulation (EU) 2024/1689, Art. 12(1)]
Count the recorded events per input against the expected event set and record each gap.
Record completeness-table-A: expected against recorded events per input, gaps listed
[prEN 18229-1, enquiry, clause on completeness of recorded events]
Apply a model, software or configuration update in the test environment and repeat step 14.
Record run-log-B: the exported events after the update, with the update identifier
[Regulation (EU) 2024/1689, Art. 12(1)]
Compare the event set and the record format of
run-log-Bagainstrun-log-A.Record continuity-table: events and fields present before and after the update, differences listed
[prEN ISO/IEC 24970, approval, clause on logging across the AI system lifecycle]
Trigger each risk indicator condition from the risk management file and record whether the mapped event fires.
Record risk-indicator-table: indicator, mapped event, trigger applied, event observed yes or no
[Regulation (EU) 2024/1689, Art. 12(2)(a)]
Change the model version, one threshold and one configuration value, and record the event each change produces.
Record modification-event-table: change applied, event observed, candidate substantial modification marker present yes or no
[Regulation (EU) 2024/1689, Art. 12(2)(a)]
Locate in the logs each data point the post-market monitoring plan consumes and compare the field definitions.
Record pmm-data-point-table: plan data point, log field, definition match yes or no
[Regulation (EU) 2024/1689, Art. 12(2)(b) and Art. 72]
Export the logs with deployer credentials through the mechanism the instructions for use describe.
Record deployer-export: export file, format, mechanism used, fields readable yes or no
[Regulation (EU) 2024/1689, Art. 12(2)(c) and Art. 13(3)(f)]
Record the integrity mechanism that protects stored log records: hash chain, signature, write-once storage or none.
Record integrity-design-record: mechanism, scope of records covered, verification method
[prEN ISO/IEC 24970, approval, clause on log integrity and protection]
Alter one field in a copy of the exported logs and run the integrity verification.
Record tamper-test-record: record altered, field altered, verification result detected or not detected
[prEN ISO/IEC 24970, approval, clause on log integrity and protection]
Read the retention configuration of each log store and record the configured period and deletion rule.
Record retention-config-record: store, configured period, deletion rule, configuration export or screen capture
[Regulation (EU) 2024/1689, Art. 26(6)]
Locate the oldest retained record in each store and record its timestamp against the configured period.
Record retention-observation: store, oldest record timestamp, configured period, consistent yes or no
[prEN 18229-1, enquiry, clause on log retention]
For Annex III point 1(a) systems, run one observed session and record the logged start and end timestamps.
Record period-of-use-record: observed start and end, logged start and end, session bounded yes or no
[Regulation (EU) 2024/1689, Art. 12(3)(a)]
For Annex III point 1(a) systems, produce one match and read the reference database identifier and matched input.
Record match-record: match event, reference database identifier present, matched input data present
[Regulation (EU) 2024/1689, Art. 12(3)(b) and (c)]
For Annex III point 1(a) systems, let an assigned person verify one result and read the verifier identification.
Record verifier-record: result verified, natural persons identified in the log yes or no
[Regulation (EU) 2024/1689, Art. 12(3)(d) and Art. 14(5)]
Select the reconstruction sample from the retained logs with the method in
test-planand record the identifiers.Record sample-list: decision identifiers, selection seed or rule, store of origin per decision
[AIAssuranceLabs procedure]
A log record that passes steps 12, 22 and 23 carries the fields below. The record is synthetic. The digests and identifiers are placeholders, and the timestamp is written as a format instruction rather than a value.
{
"event_id": "evt-000000",
"ts": "<RFC 3339 timestamp with UTC offset>",
"event_type": "decision.issued",
"source_id": "scoring-service",
"correlation_id": "req-000000",
"input_ref": "sha256:<digest of the input record>",
"model_version": "<model identifier and version>",
"config_hash": "sha256:<digest of the configuration in force>",
"output": "<system output as returned to the deployer interface>",
"prev_hash": "sha256:<digest of the previous record in the chain>",
"record_hash": "sha256:<digest of this record without record_hash>"
}Analysis
Reconstruct each sampled decision from the logs alone: input, model version, configuration in force, output and timestamp.
Record reconstruction-record: one row per sampled decision with each of the five elements found or missing
[prEN ISO/IEC 24970, approval, clause on traceability of AI system events]
Repeat step 30 on the deployer export from step 21 and record the result per decision.
Record reconstruction-record: deployer-side rows, source set to the export from step 21
[Regulation (EU) 2024/1689, Art. 26(6)]
Compare each reconstructed decision against the system output store and record each match or mismatch.
Record reconstruction-record: match status per element per decision, mismatch detail
[AIAssuranceLabs procedure]
Classify each gap as missing event, missing field, unreadable format, broken linkage or retention loss.
Record gap-classification: gap identifier, class, affected element, affected step
[AIAssuranceLabs procedure]
Compare the reconstruction result against the traceability level recorded in step 5 and record the outcome.
Record traceability-assessment: justified level, achieved level, met yes or no, reason
[Regulation (EU) 2024/1689, Art. 12(2)]
Compare the configured and observed retention against the policy and the period Art. 26(6) sets.
Record retention-assessment: store, policy period, configured period, observed period, legal basis for any different period, consistent yes or no
[Regulation (EU) 2024/1689, Art. 26(6)]
Rate each finding against the pass criteria in the thresholds section and record the criterion source.
Record findings-table: finding, criterion, hierarchy level of the criterion source, result
[AIAssuranceLabs procedure]
The reconstruction record from steps 30 to 33 takes the layout below. The rows are synthetic.
decision_id | input_ref | model_version | config_hash | output | ts | source_records | side | result
req-000000 | found | found | found | found | found | evt-000000, evt-000001 | provider | reconstructed
req-000000 | found | found | found | found | found | evt-000000, evt-000001 | deployer | reconstructed
req-000001 | found | missing | found | found | found | evt-000002 | provider | gap: missing field (model_version)
req-000002 | found | found | found | found | found | none in retention | deployer | gap: retention lossReporting
Write the logging design review record from the design review table and the traceability rationale record.
Record Logging design review record (PR-12-LOG output)
[AIAssuranceLabs procedure]
Write the log completeness, integrity and retention test report from the execution and analysis records.
Record Log completeness and continuity test report (PR-12-LOG output), with the integrity and retention sections
[AIAssuranceLabs procedure]
Write the decision reconstruction record with the sample list, the per-decision rows and the gap classification.
Record Decision reconstruction record (PR-12-LOG output)
[AIAssuranceLabs procedure]
Record each deviation from this protocol, its reason and its effect on the results.
Record deviation-log: step number, deviation, reason, effect on the results
[AIAssuranceLabs procedure]
Compute a checksum for each artifact and hand over the set with the checksum list.
Record handover-manifest: artifact name, version, checksum
[AIAssuranceLabs procedure]
Thresholds and criteria
Regulation (EU) 2024/1689 sets no numeric threshold for Art. 12: no event count, sampling rate, storage limit or clock precision. Art. 12(3) sets a minimum event content for Annex III point 1(a) systems; that content is a list of items and carries no number. The pass criteria of this protocol come from the hierarchy in the obligation records, applied as follows.
| Criterion | Pass condition | Source and hierarchy level |
|---|---|---|
| Design completeness (steps 11 to 13) | Every event in expected-event-set is present in the catalogue with every field assigned in step 7; for Annex III point 1(a) systems, the four Art. 12(3) fields are defined | Level 2: prEN ISO/IEC 24970Approval for the record structure, prEN 18229-1Enquiry for the event and field list; Art. 12(3)(a) to (d) for the minimum content |
| Automatic recording (steps 14, 15) | Every expected event fires for every test input with no operator action | Art. 12(1); the expected event set from level 2 |
| Continuity (steps 16, 17) | run-log-B has the same event set and record format as run-log-A | Art. 12(1); prEN ISO/IEC 24970Approval clause on logging across the lifecycle |
| Risk indicators and modifications (steps 18, 19) | Every indicator condition produces its mapped event; every change produces an event with the candidate substantial modification marker | Art. 12(2)(a); the mapping is the provider's, recorded in step 4 |
| Post-market monitoring data points (step 20) | Every data point in the Art. 72 plan has a log field with a matching definition | Art. 12(2)(b) |
| Deployer readability (step 21) | The export succeeds with deployer credentials and every field of the expected event set is readable in the export | Art. 12(2)(c) and Art. 13(3)(f) |
| Integrity (steps 22, 23) | An integrity mechanism exists and the altered copy is detected by the verification method recorded in step 22 | Level 2: prEN ISO/IEC 24970Approval clause on log integrity; no published detection threshold, so the criterion is binary |
| Retention (steps 24, 25, 35) | The configured period is at least the period in Art. 26(6) for deployer logs and the period in Art. 19 for provider logs, or the different period whose legal basis step 9 records; the oldest retained record is consistent with the configured period | Art. 19 and Art. 26(6); a different period is accepted only with the legal basis recorded in step 9 |
| Reconstruction (steps 30 to 32) | Every sampled decision yields all five elements from the logs alone, and every element matches the output store | Art. 12(2) and Art. 26(6); prEN ISO/IEC 24970Approval clause on traceability |
| Traceability level (step 34) | The achieved level meets the level the provider justified in step 5 | Level 6: no published threshold; the provider justifies the level against the intended purpose in step 5, and step 34 tests the justification |
| Annex III point 1(a) content (steps 26 to 28) | The logged start and end bound the observed session; the match record carries the reference database identifier and the matched input; the verifier record identifies the natural persons | Art. 12(3)(a) to (d) |
Hierarchy level 1 is empty: no harmonised standard is cited in the Official Journal as of the anchor date. No presumption of conformity attaches to any criterion in this table for that reason. The standards page shows the stage of each standard named above. No published document sets a sample size for the reconstruction exercise. Step 10 records the sample size and the reason, and the decision reconstruction record carries both.
Outputs
| Artifact | Contents | Deliverable |
|---|---|---|
| Logging design review record (PR-12-LOG output) | scope-record, expected-event-set, design-review-table, traceability-rationale-record, each missing or extra event with the source clause | Logging design review against Article 12 minimum content, in Logging and human-oversight verification |
| Log completeness and continuity test report (PR-12-LOG output) | completeness-table-A, continuity-table, risk-indicator-table, modification-event-table, pmm-data-point-table, deployer-export, integrity-design-record, tamper-test-record, retention-config-record, retention-observation, retention-assessment, findings-table | Log completeness, integrity and retention test report, in Logging and human-oversight verification |
| Log retention configuration evidence (PR-12-LOG output) | retention-policy-input, retention-config-record, retention-observation, the legal basis for any different period | Log completeness, integrity and retention test report, in Logging and human-oversight verification |
| Decision reconstruction record (PR-12-LOG output) | test-plan, sample-list, reconstruction-record for the provider side and the deployer side, gap-classification, traceability-assessment, one synthetic sample row | Decision reconstruction exercise from logs, sample included, in Logging and human-oversight verification |
| Protocol deviation log (PR-12-LOG output) | deviation-log, handover-manifest | Attached to every deliverable above |
The deliverable specifications with synthetic samples are on the deliverables page. The scope limits of every service are stated on what we cannot do.
Limitations
The protocol shows what the logs record and what a reader can rebuild from them at the time of the test. The protocol cannot show that the event set is sufficient for a purpose the provider has not stated. Step 5 records the provider's rationale, and step 34 tests against that rationale only.
The retention test observes one point in time. The protocol cannot show that records survive for the whole retention period. Steps 24 and 25 show the configured rule and the oldest record present on the test date.
Steps 14 to 19 run in a test environment. The protocol cannot show that the production deployment records the same events. The deployer export in step 21 and the deployer-side reconstruction in step 31 are the only steps that read production logs.
The integrity test in step 23 detects an alteration in a copy. The protocol cannot show that the production store rejects or detects alteration by a privileged operator. Step 22 records the mechanism and its scope.
The Annex III point 1(a) steps run only for remote biometric identification systems. For other systems, the protocol records no period of use, reference database or verifier identification.
prEN 18229-1Enquiry is at enquiry stage and prEN ISO/IEC 24970Approval is at approval stage. Neither document is cited in the Official Journal. The clause references in this protocol describe the clause topic and carry no clause number, because the texts are still moving. A later version of either document changes the expected event set, and a revision of this protocol follows any such change.
The protocol tests the logging capability and the retained logs. The protocol does not decide whether the system meets Art. 12 or Art. 26. That decision remains with the provider or deployer, their notified body where one is required, and their counsel.
Sources
prEN 18229-1Enquiry: AI trustworthiness framework, part 1, logging; the expected events, fields and retention requirements for an Art. 12 log.prEN ISO/IEC 24970Approval: AI system logging; the information model, record structure, integrity and traceability clauses used in this protocol.- Regulation (EU) 2024/1689, consolidated text on EUR-Lex: Art. 12, Art. 13(3)(f), Art. 14(5), Art. 19, Art. 26(6), Art. 72 and Annex IV.
Revision history
Each revision names the regulation entry whose verified-on date anchors the version; the date renders from data.
| Version | Note | Anchor |
|---|---|---|
| v1.0 | Initial version, written from the standards in the derivation line as they stood on the verified-on date of the entry. | Verified on K&L Gates, EU Digital Omnibus on AI Enters Into Force (31 July 2026) |