Category: Evidence · Schema and assessment worksheet
Our vision is evidence people can question, not just collect. A decision record can explain which rule a system evaluated, what outcome it recorded and which approval it associated with an action. That is valuable. It cannot, on its own, establish that the underlying rule was appropriate, the output was accurate or a person understood what they approved. Start with the question you need to answer, then design the record around its limits.
This resource proposes a vendor-neutral schema and an assessment method. It is an editorial design recommendation, not a statement of legally sufficient recordkeeping. The examples are fully synthetic and do not describe a real system, firm, individual or Synainesi operation. “Unknown” is a valid answer throughout; replacing it with a plausible story makes the evidence worse.
Define the event before choosing the fields
A request decision, provider receipt, model response and completed business action are different events. An “allowed” record means that a particular decision point allowed something within its observed scope. It need not mean the network transmission happened, the provider processed the request or the resulting email was sent. Give each event a type and connect them with explicit references. Keep “no response observed” separate from “request failed”.
Likewise, an approval record is about an approval. To establish that the approved action was the action attempted, compare the relevant action fields or payload fingerprint, the scope, expiry and use status. To establish that the attempted action completed, seek the target system’s acknowledgement. This separation prevents one reassuring event from standing in for an entire chain that has not been observed.
A minimal schema you can adapt
| Field group | Record and test |
|---|---|
| Identity and type | Unique event identifier, schema version and event type; distinguish decision, approval, attempt and completion. |
| Scope | Workflow reference, observing component and boundary. Identify systems and paths not observed. |
| Actor context | Account or role reference, authentication context and device reference where justified. Record uncertainty about human attribution. |
| Time | Observed time, time source, receipt time and known clock uncertainty. Do not invent precision. |
| Policy | Policy identifier, immutable version reference, rule identifier and method for retrieving the rule that applied. |
| Destination and action | Provider, model or deployment reference, target tool, action type and destination scope as appropriate. |
| Decision | Allowed, refused, held or other explicitly defined outcome; reason code rather than sensitive copied narrative. |
| Approval binding | Approval reference, approver authority, exact approved scope, expiry and use record. Record absence explicitly. |
| Integrity and linkage | Parent event references, payload fingerprint method if used, integrity mechanism and collection-health information. |
| Record governance | Purpose, owner, permitted roles, retention rule reference and correction or supersession linkage. |
Do not use this table as a reason to collect every possible field. Start with the questions each field answers. An account identifier may be sufficient where a full employee name is unnecessary. A controlled reason code can avoid copying a confidential complaint into a log. Omit a field when its purpose cannot be explained, or record why the evidence is unavailable when that absence matters to interpretation.
Worked reconstruction: the approval changed, the evidence did not
Fully synthetic sequence: event EX-A records approval for an agent to draft a message for an internal queue, with no sending authority. Event EX-B records an attempt to send a message to an external destination. Event EX-C records refusal under rule ACTION-SCOPE, linked to EX-B. There is no target-system acknowledgement in the evidence supplied. The example contains no actual messages, identifiers or executable credentials.
A defensible account is narrow: the observed decision component recorded that the attempted send was refused; the linked approval covered drafting in an internal queue. The supplied records do not establish that the agent never tried another route, that another component could not send, or that no external message exists. Ask the target-system owner for relevant evidence and identify which alternative paths were within scope. Do not turn “no acknowledgement supplied” into “nothing was sent”.
If the policy version cannot be retrieved, you can still report its recorded identifier, but cannot independently assess its contents from that identifier alone. If the device clock was uncertain, preserve that uncertainty when ordering events. If two systems report different times, investigate receipt and observation time before declaring one account false. Reconstruction is a reasoned comparison of records, not a formatting exercise.
What a hash can and cannot establish
A cryptographic hash can support comparison: given a candidate payload, a specified representation and the same hash method, you can check whether its fingerprint matches the recorded value. Define which bytes were hashed, including encoding, attachments and any normalisation. Without the candidate material or a reliable description of the representation, the hash cannot reconstruct the content or explain its meaning. A changed line ending can matter when comparing raw bytes.
The hash does not establish who created the payload, whether an approval was informed, whether the recorded time is reliable or whether the collector saw every request. An attacker able to replace both an event and its unprotected hash can preserve their apparent agreement. Separate integrity protection of the record from fingerprinting of its subject. Also assess whether predictable content could be guessed and checked against a stored hash; do not treat fingerprints as automatically harmless or anonymous.
Missing records and uncertain attribution
No event can mean no activity, a collection failure, an offline device, a changed route, expired retention or a failed search. Ask about collection health, sequence gaps, retry behaviour, deduplication and the boundaries of the query. Keep an outage annotation with the relevant period. A dashboard with zero events is not evidence of zero activity unless you have a supported account of coverage and collection during that period.
An authenticated account is also not the same thing as certain human attribution. Shared sessions, unattended devices, automation and compromised access can complicate the story. State “account reference X was associated with this event” when that is what the evidence shows. Use additional authorised evidence if the question requires identifying the person responsible. Do not infer intent, negligence or understanding from a reason code or a button click alone.
Retention and access: a decision worksheet
The European Commission’s explanation of GDPR principles describes purpose limitation, data minimisation, storage limitation and accountability. Apply those principles to evidence containing personal data too. The Commission also explains that retention takes account of the processing purpose and relevant legal recordkeeping obligations. This resource supplies no universal retention period and no conclusion about your sector’s required records.
| Decision | Worksheet prompt |
|---|---|
| Purpose and evidence need | Which oversight question requires this record? What source content, if any, must remain available elsewhere? |
| Owner and authority | Who sets retention, confirms applicable requirements and authorises access? Record unresolved legal questions. |
| Access separation | Who can view aggregates, event details, actor mappings and source content? Which disclosures need a separate decision? |
| Lifecycle | What starts the retention period? What review, deletion, backup and justified preservation processes apply? |
| Correction and challenge | How can someone challenge an inaccurate attribution? How are corrections linked without silently rewriting the original account? |
| Disposal and evidence limits | Who checks deletion and records its scope? Which later questions will become unanswerable, and has that trade-off been accepted? |
Finish an evidence review with three short statements: what the supplied records support, what they do not support, and what additional evidence could resolve the gap. That discipline makes records more useful to decision-makers. A convincing story is easy to write. An honest boundary around what can be established takes care.
Related: all AI governance resources, our AI governance principles, prompt pseudonymisation examples, the shadow AI response plan, and Evidence without surveillance.
General information, not legal advice. Adapt this resource to your organisation, activities and applicable requirements with qualified advisers. Every worked example and reference identifier is fully synthetic.