Traceability: what to record and what evidence proves
Automatic logs, retention and custody: distinguish integrity, completeness and independent observation of an effect.
No legal review claimed. References describe the high-risk system regime where applicable. Engineering proposals are technical interpretations, not product certifications.
1. Record enough to reconstruct an operation
Article 12 requires automatic logging capabilities for high-risk systems. Events should support traceability appropriate to intended purpose and operational monitoring. It does not prescribe SQLite, a blockchain or a particular cryptographic format.
Technical proposal: connect inputs, policy version, authorisation, attempted operation, result and external observation through stable identifiers. Avoid using a model transcript as the sole explanation: what a system reports and what the resource shows are distinct observations.
2. Integrity does not establish completeness
A hash compares bytes against a reference. A signature can bind those bytes to a key when verification and key custody are adequate. Neither proves that no event was lost before recording.
A denial receipt needs an independent witness when the property under evaluation is absence of an effect. Define the resource observed and how a contradiction can be detected. Preserve failures, gaps and losses too; a custody chain recording only success gives an incomplete view.
3. Retention with purpose and control
Articles 19 and 26 address retention of logs under the control of high-risk providers and deployers. They provide for a period appropriate to intended purpose of at least six months, unless other applicable law provides otherwise, including data protection law.
That minimum does not make indefinite retention a goal. Operational proposal: define access, deletion, recovery and accountable owners. Capturing complete content can expose secrets or personal data; assess which context is necessary before copying it into a record.
4. The crash boundary
Writing a row does not demonstrate durability against power loss. Persistence configuration, the file system and ordering between an effect and its receipt constrain what can be recovered after interruption.
Proposed test: interrupt execution before and after each persistence boundary, then reconcile records against the resource on restart. Look for effects without receipts and receipts confusing an intention with confirmation. Label simulations and keep them separate from hardware results.
5. A reviewable package with visible limits
CORTEX and BABYLON document memory and records; NEMESIS supplies verification. The published snapshot exposes observed states and divergences. A verified state belongs to a test and its scope, not a global product certification.
Give a reviewer configuration, identifiers, reproduction steps, outcomes and limitations. Keep legal obligations, engineering interpretation and available evidence separate. This allows a claim to be audited without making its marketing label its own proof.