What is the audit trail?
The audit trail is the record of every action a Digital FTE proposed and everything that was decided about it. For each action it holds the proposal, the evidence the proposal carried, the decision, approved, edited, sent back with a reason, or auto-approved under a promoted class, who made it and when, the autonomy level that applied to that class at the time, and the effect: what was published, sent, posted, or spent.
It also holds the management of the role: promotions and step-backs on the autonomy ladder with the grantor, budget changes, connections added and removed, manager changes, and key rotations. Token spend is an immutable ledger inside it, so cost is part of the record.
How is it built on ftes.ai?
On ftes.ai the trail is a by-product of the mechanisms rather than a separate step. Every proposal passes through the approval gate, which records it; every decision is made there, which records it; every effect is logged when it happens; every management change is a permissioned action, which records itself. Per-run trails show what the FTE did step by step within one piece of work, such as a mission or a close.
Nothing is written up afterwards by a person, which is where trails usually fail. The record exists because the work could not happen without producing it.
What is it for?
It serves three purposes. Incident review: when something went wrong, the question of what happened has an answer that is a record rather than a memory, and the incident plan's trace step reads it. Autonomy decisions: the approval history for a class of action, which is the evidence for promotion, is in the trail. And periodic audit: a sample of actions traced end to end, quarterly, to confirm the controls are working.
It also answers the accountability question directly. For any action, the trail names the approver, or the person who granted the autonomy an auto-approved action ran under, or the person who performed a never-automated action.
- Incident review: what happened, traced in a minute
- Autonomy: the clean run that justifies a promotion
- Audit: sampled actions traced end to end, quarterly
- Accountability: a named person for every action
What does a traced action look like?
As a labelled example, one published page traces as: the topic proposal with its worth-it verdict and the data it drew on; the draft with sources; the fact-gate result including any blocked claim and its resolution; the approval by a named person with the date and any edit; the publish event with the route and confirmation; the measurement samples afterwards; and the tokens consumed at each stage.
One auto-approved reconciliation match traces as: the proposal with the bank line and invoice; the note that it was auto-approved under the exact-match class at its level; the grant of that level by a named controller on a stated date on a record of a stated number of unchanged approvals; the effect in the ledger; the tokens consumed.
What is it often confused with?
It is confused with application logs, which record system events for engineers; the audit trail records decisions for managers and auditors. It is confused with the morning brief, which summarises a day; the trail is the complete record the brief draws on. And it is confused with a report; it is the data a report would be built from, and it can be exported.
It is sometimes assumed to be optional or configurable. It is not; every action produces its record, and a manager cannot turn it off.
Where do you see it in the workspace?
Per proposal in Approvals, where its history is shown; per run in Missions and Pipeline; per role in the audit view, filterable by property, class, and period; and exportable. The vendor security questions guide asks every vendor what their trail contains and whether it can be exported; a trail you cannot export is not yours.
Related terms: approval gate, autonomy ladder, accountability, incident response, token ledger.
A practical habit is to trace one action end to end in the first week, while nothing is wrong, so that the day something is wrong the manager already knows what the record looks like and how quickly it answers. The incident plan's rehearsal step is exactly this, and an hour spent on it is the cheapest governance work the organization will do.