Platform · Audit trail
Every decision,provable.
Talara writes an immutable record of who did what, when, and what changed, built so it survives a GDPR erasure request intact.
What does the Talara audit trail record?
Every consequential action is written to an immutable, attributable log: the actor, the subject, the time, and the before-and-after change. It is keyed to resource identifiers rather than personal data, which resolves the usual conflict between an audit trail and the right to erasure: you can erase a candidate and still prove how decisions were made.
The premise
Why delegation needs a record.
Handing the admin layer to an agent only works if one question always has an answer: who decided that? The audit trail is that answer, kept automatically. It’s what lets a team move at machine speed without wondering, later, how a candidate advanced or an offer went out. Trust in an agentic partner isn’t a feeling. It’s a record you can open.
In practice
What the log actually looks like.
Rows expand to their context and metadata, and to the stored record underneath.
Every row carries the time, the action, who did it and in what role, and what it applied to. Subjects are resource identifiers, and the export anonymizes candidate data by default. The employee name is blurred here, not in the product.
Raw row
{
"id": "bb00b6bb-0e8b-4e7b-a934-4d2afd79d83c",
"action": "global_search",
"resource_type": "search",
"resource_id": "06207035-1626-49d6-b788-d67cf924a23d",
"actor_id": "9f41c2ae-77b0-4c6e-8d13-5a0e6b2f14d7",
"actor_name": "Dana Mercer",
"subject_label": "Search",
"payload": {
"actor": {
"user_id": "9f41c2ae-77b0-4c6e-8d13-5a0e6b2f14d7",
"role": "superadmin"
},
"subject": {
"type": "search",
"id": "06207035-1626-49d6-b788-d67cf924a23d"
},
"context": {
"source": "top_bar"
},
"metadata": {
"q": "vp of sales",
"total": 3,
"counts": {
"candidates": 1,
"roles": 1,
"jds": 1
}
}
},
"created_at": "2026-09-12T08:53:25.598Z"
}Open any row and the stored record is there in full: the action, the resource type and id, the actor and their role, the subject, and the context it came from. Actor name and id are pseudonymised here.
How it works
Append-only, attributable, PII-safe.
The log is append-only and enforced below the application, so it cannot be quietly edited. It carries resource identifiers, not personal data, so a candidate’s erasure request never destroys your record of how a decision was reached. Human approvals are written here too, which is what makes human oversight provable.
GDPR & erasure
Erase the candidate. Keep the proof.
GDPR’s right to erasure and an immutable audit trail sound like a contradiction: one demands deletion, the other forbids it. Talara resolves it by what the log contains. Rows are keyed to resource identifiers, not personal data, so when a candidate asks to be erased, their data is erased, and the record of how decisions were made stays whole.
What survives is proof of process: that a named person approved each step, on stated reasoning, at a recorded time. What’s gone is the person. That’s the point.
Why it matters
The evidence an auditor asks for.
When a works council, regulator, or candidate asks how a decision was made, you can show it: who approved, what the AI proposed, what reasoning it gave, and what the human did with it. That is the difference between a policy and proof.
FAQ
Questions, answered.
What should a hiring audit trail record?
Does an audit trail conflict with GDPR’s right to erasure?
Can the log be edited after the fact?
How long are records kept?