Audit
The audit trail is Connect's accountability record: for each consequential action it stores the workspace, the actor and the capacity they acted in, the action, what it was done to, the before and after state, and the result. Refusals are recorded alongside successes, because deciding not to do something is a decision somebody may later need explained.
Six facts, and a thread to pull them back together#
- Workspace
- Which business this happened in. Every row is scoped like every other record.
- Actor and role
- Who, and in what capacity — a person, Connect acting under a rule, or the platform operator.
- Action and target
- What was done, and to which record.
- Before and after
- The state either side of the change, by name and value.
- Result
- Whether it worked, including a refusal and its reason.
- Correlation id
- The thread that ties one decision to everything it caused, so an incident can be reassembled rather than reconstructed from memory.
Not everything is audited, and that is deliberate. The trail covers actions with money, data, access or irreversibility attached. Auditing every read would produce a record too large to search, which is the practical way an audit trail stops being used.
Two absolute rules#
Never a secret. The before and after hold what changed by name and by state, and a credential appears as the fact that it is now set — never as its value. Redaction happens at the one place that writes to disk rather than being remembered at each call site, because a rule applied in fifty places is a rule that will be missed in one.
Never break the thing being audited. A failure to write an audit row is reported and swallowed. Losing the record of a payment is bad; failing the payment because its audit row would not write is worse, and the second failure mode is the one that takes a business down.
Three records that are not the audit trail#
| Record | Answers | Written for |
|---|---|---|
| Activity | What has Connect been doing? | A customer reading their own workspace |
| Operational events | Why did that fail? | Diagnosing a fault |
| Audit | Who did this, in what capacity, and did it work? | An auditor, or the aftermath of an incident |
The Decision Log screen is where the audit trail is read in the application, and it is the answer to *why did Connect do that* rather than *what did Connect do*. A held reply that never went out appears there with the rule that held it — which is the case people are most often surprised to find recorded, because nothing visibly happened.
Recording a refusal is the part that turns the log into an explanation. An employee who declined to do something and never mentioned it has not been cautious, they have been silent, and silence is what makes an automated system impossible to supervise.
Questions#
Can a person edit or delete an audit row?
The trail is written by the actions themselves rather than by hand, and it is not an editable list. A correction is a new action with its own row, which is what keeps the sequence readable as a history.
Does the audit trail contain message content?
It records what changed and its state, not the body of a customer's message. The message itself lives in the conversation, where workspace isolation governs it like any other record.
How long is it kept?
Retention is a workspace data question rather than a property of the trail, and what Connect does with your business data is where the handling is set out.