Audit Trail
Every decision Freya makes. Every action a human approves. Every outcome that follows. Recorded permanently, in full, from the first moment of deployment.
Antarious maintains a complete, immutable, and forensically retrievable record of every operation across your organisation. Not summaries. Not logs. The full chain — what happened, who authorised it, what data informed it, and what the outcome was. For as long as you need it.
Section 01 — The Case for Radical Transparency
Why Audit Trails Are Not Enough — and What Ours Does Differently
Most enterprise software keeps logs. Antarious keeps a ledger.
The difference is intentional. A log records that something happened. A ledger records what happened, why it happened, who authorised it, what context existed at the time, and what followed. One is useful for debugging. The other is useful for governance — and for the kind of accountability that enterprise procurement teams, government audit committees, donor review missions, and regulatory inspectors actually require.
In high-stakes operational environments, the audit trail is not a back-office function. It is the evidence base for institutional accountability. It is how a minister demonstrates that a policy action was properly authorised. It is how an NGO proves to a donor that funds were managed with integrity. It is how a GTM director shows a board that a campaign was approved and executed by the right people. It is how a procurement committee validates that an AI system operated within defined governance boundaries.
Antarious is built to make that evidence complete, retrievable, and incontestable — at any point, for any action, going back to the beginning.
Section 02 — What the Audit Trail Captures
A Complete Record, Not a Selective One
Every event in the Antarious system generates an audit record. There are no gaps by design, no categories of action that are excluded, and no period of operation that falls outside the record.
The Seven Layers of Every Audit Record
Layer 1 — The Trigger
What initiated this chain of events? A scheduled task, a live data anomaly, a user instruction, an incoming data feed, or a system-generated alert. The trigger is recorded with its source, timestamp, and the conditions that caused it to fire.
Layer 2 — Freya's Reasoning
What did Freya analyse, and what did she conclude? The full reasoning chain is recorded — which data sources were queried, what patterns were detected, what recommendation was formed, and what alternatives were considered and discarded. This is not a summary. It is the complete analytical thread.
Layer 3 — The Review Package
What was presented to the human approver? The exact content of the approval request — the proposed action, the supporting data, the risk flags, the recommendation — is stored at the moment of delivery. This record does not change if the action is later modified.
Layer 4 — The Human Decision
Who approved, rejected, or revised the action? The approver's identity, role, and user ID are recorded alongside the precise timestamp of their decision. If edits were made, a tracked diff records every change. If a reason was stated, it is stored verbatim.
Layer 5 — The Executed Output
What was actually done? The final version of every executed output — the email sent, the report published, the workflow triggered, the data submitted — is stored exactly as it was executed. This is the definitive record of what went out under your organisation's name.
Layer 6 — The Outcome Signal
What happened next? Where measurable outcomes are available — a reply received, a KPI shift, a compliance deadline met, a delivery milestone reached — these are linked to the originating action record, creating a causal chain from decision to outcome.
Layer 7 — The Exception Record
What didn't happen, and why? Rejected actions, failed executions, system errors, and unresolved escalations are all recorded with full context. The absence of an action is as important as its presence in a complete governance record.
Section 03 — Immutability
Why the Record Cannot Be Changed
The Antarious audit trail is write-once by architecture. Once an event is recorded, it cannot be edited, deleted, or overwritten — by any user, at any permission level, including system administrators and Antarious personnel.
This is not a policy. It is a technical constraint.
Every audit record is:
- Cryptographically timestamped at the moment of creation, producing a unique hash that changes if any field is altered
- Append-only — new information (such as outcome signals) is added as new linked records, never as edits to the original
- Independently verifiable — the hash chain can be inspected to confirm that no record has been modified since creation
- Redundantly stored — records are held across geographically separated storage locations to prevent loss through infrastructure failure
The practical consequence is simple: if an audit record exists in Antarious, it reflects exactly what happened. It cannot have been sanitised, corrected, or adjusted after the fact. For regulatory inspectors, donor auditors, and legal proceedings, this matters enormously.
Section 04 — Retrieval and Query
Finding Exactly What You Need, When You Need It
An audit trail that cannot be interrogated efficiently is a liability, not an asset. Antarious makes the full record searchable, filterable, and exportable across any dimension relevant to governance.
Query Capabilities
By time period
Retrieve all records within any date range — a fiscal quarter, a programme phase, a calendar year, or a precise window defined by an audit scope.
By agent or workflow
Retrieve all records generated by a specific Freya agent, a specific workflow type, or a specific automated process.
By approver
Retrieve every action approved by a specific individual — useful for understanding decision patterns, supporting performance reviews, or responding to investigations.
By action category
Filter by action type: all external communications, all compliance submissions, all financial actions, all document publications.
By outcome
Retrieve records linked to a specific outcome — all actions that contributed to a closed deal, a submitted donor report, a resolved compliance gap, or a service delivery milestone.
By data source
Retrieve all actions that drew on a specific data source or integration — useful for data lineage queries and impact assessments when a source is found to have been inaccurate.
By exception
Retrieve all rejected actions, all pending approvals past their deadline, all system errors — the exception record is as queryable as the success record.
Export Formats
Audit records can be exported in the following formats for use in external review processes:
- PDF — formatted audit report, suitable for committee presentation and formal submission
- CSV / Excel — structured data, suitable for analysis and reconciliation
- JSON — machine-readable format, suitable for integration with external audit management systems
- Custom report — Freya can generate a narrative audit summary for any scope, structured to the requirements of a specific review body or donor
Section 05 — Governance Use Cases
How Different Roles Use the Audit Trail
The audit trail serves different functions for different people in your organisation. Each of the following is a first-class use case, not an edge case.
For Executive Leadership and Ministers
Complete visibility of every significant action taken under organisational authority. The ability to ask "what happened on this date, who authorised it, and why" and receive a complete, sourced answer in seconds — not hours of manual reconstruction.
For Compliance Officers
A continuously updated evidence base that eliminates the pre-audit scramble. Every compliance obligation tracked, every action recorded, every deadline met (or missed, with reason) — compiled into an audit-ready portfolio on demand. No evidence gaps. No surprises.
For Finance and Procurement
A complete record of every action with financial consequence — budget recommendations acted upon, procurement triggers, campaign spends approved. Line-by-line visibility from authorisation to outcome, available for internal finance review or external auditor inspection.
For Donor and Grant Management
Every action taken on a funded programme — field data submissions, beneficiary records updated, partner communications sent, compliance reports filed — recorded with approver identity and timestamp. The evidence base for any donor review mission, pre-assembled and exportable.
For Legal and Risk Functions
A forensically complete record for any legal, regulatory, or disciplinary proceeding. The ability to reconstruct the exact sequence of events, decisions, and authorisations for any incident — with cryptographic proof that the record has not been altered.
For Board and Governance Committees
Periodic audit summary reports generated by Freya — covering the scope, volume, and distribution of approved actions, exception rates, approval chain adherence, and any anomalies — delivered in board-ready format on any schedule.
For External Auditors and Regulators
A self-contained, exportable evidence package for any defined audit scope. Auditors receive exactly the records they request, in the format they require, with the provenance and verification information they need to rely on the record.
Section 06 — Audit Trail in Regulated Environments
Meeting the Evidence Standards That Matter
| Regulatory / Framework Context | Audit Trail Capability |
|---|---|
| UK GDPR / EU GDPR — Article 5(2) Accountability | Full record of all data processing activities, decision basis, and human oversight points — available for supervisory authority inspection |
| EU AI Act — High-Risk AI Logging Requirements | Automated logging of system operation sufficient to assess outputs and enable post-hoc monitoring, as required under Article 12 |
| ISO 27001 — Annex A.8 Asset Management | Asset-linked activity records supporting information asset accountability and access control audit requirements |
| Public Sector / Government Accountability | Named officer approval record for every public-facing action; full ministerial accountability chain; Freedom of Information-ready retrieval |
| World Bank / IDA Fiduciary Standards | Complete evidence chain for programme actions, financial decisions, and compliance submissions — exportable for supervision missions |
| USAID / DFID Donor Compliance | Approval records for all grant-funded activities, communications, and submissions — structured for standard donor audit formats |
| Financial Conduct Authority (FCA) — Conduct Rules | Decision and approval chain for all material actions — supporting individual accountability requirements under Senior Managers and Certification Regime |
| Anti-Bribery and Corruption Frameworks | Transparent record of all external engagements, approvals, and communications — supporting adequate procedures defence |
**Note:** Compliance mapping should be confirmed with your organisation's legal and compliance advisors. Antarious provides the evidential infrastructure; compliance determinations remain the responsibility of your organisation.
Section 07 — Retention and Data Governance
How Long Records Are Kept and Who Controls Them
Default Retention
Audit records are retained for a minimum of seven years from the date of creation, in line with common regulatory and donor requirements. Retention periods are configurable to meet your organisation's specific obligations.
Retention Hierarchy
Where multiple retention requirements apply — for example, a government department subject to both public records legislation and a donor compliance requirement — Antarious applies the longest applicable retention period unless specifically instructed otherwise.
Data Sovereignty
Audit records are stored in the jurisdiction specified during deployment. Organisations with data residency requirements — including government entities subject to national data sovereignty rules — can configure storage locations accordingly.
Access to Audit Data
Access to audit records is governed by role-based permissions configured during deployment. Typical access tiers:
| Role | Access Level |
|---|---|
| System Administrator | Full read access across all records; no write or delete access |
| Compliance Officer | Full read access; can generate and export audit reports |
| Department Head / Director | Read access scoped to their department or function |
| Approver | Read access to their own approval record |
| External Auditor (temporary) | Scoped read access granted for the duration of a review; access logged and revoked on schedule |
No user has write or delete access to audit records. This includes Antarious personnel. If records require correction due to a technical error (which should not occur given the write-once architecture), the correction process requires documented justification and produces a new linked record — the original is never altered.
Section 08 — Frequently Asked Questions
Q: How quickly is an audit record created after an action occurs?
A: Audit records are generated in real time — at the moment each event occurs, not in batch processes. There is no gap between an action and its audit record.
Q: Can our internal audit team access the trail directly, or do they need to go through Antarious?
A: Your internal audit team can be granted direct read access to the audit trail through the platform. No Antarious intermediary is required for routine access. For bulk exports or custom audit report formats, Antarious's support team is available.
Q: What if an audit record is needed as legal evidence?
A: Audit records include cryptographic timestamps and hash verification that support their use as evidence in legal proceedings. We recommend working with your legal counsel to confirm the evidential requirements in your jurisdiction. Antarious can provide technical documentation of the audit architecture for legal proceedings on request.
Q: Does the audit trail capture Freya's internal reasoning, or just the actions?
A: Both. The full reasoning chain — what Freya analysed, what she concluded, and why — is recorded alongside every action. This is particularly relevant for AI Act compliance and for any proceeding where the basis of an AI recommendation is scrutinised.
Q: Can we integrate Antarious audit data with our existing audit management or GRC system?
A: Yes. Audit data can be exported in JSON format for integration with external governance, risk, and compliance (GRC) platforms. API-based integration is available for organisations requiring continuous sync.
Q: Is there an alert if someone tries to access or modify audit records inappropriately?
A: Yes. Attempts to access audit records outside configured permissions generate an automated alert to the system administrator. Attempts to modify records are blocked at the architecture level and logged.
Section 09 — Related Trust Pages
- Human Approval → — The approval events that generate audit records
- Role-Based Control → — How access to audit data is governed by role
- Security → — How audit records are protected, stored, and verified