# Who can read the audit trail

There is one audit trail and two doors onto it — the operator's own screens and the customer facade — and both read the same service. Each door answers inside the workspace of the session that opened it, because an audit entry is a scoped record like any other. Anyone who can sign in to a workspace can read that workspace's decisions; nobody reads another workspace's through either door.

- **Status:** Available
- **Audience:** both
- **In the app:** #/autonomy-audit, #/activity
- **Last verified:** 2026-09-10
- **Canonical:** https://connectbyjbrh.com/docs/security/audit-access/

## What the trail records

An entry answers four questions about one decision: what was decided, by what — a person or the engine — under which rule, and what happened next. Refusals are recorded alongside actions, because a refusal is a decision, and a trail that only holds successes cannot answer the question people actually ask months later, which is why something did *not* go out.

**The decision** — What was proposed and what was done about it.
**The actor** — A named person, or the engine acting under a rule.
**The rule** — The autonomy mode and scope that applied at the time, not the one set today.
**The outcome** — What the action produced, including a provider's own acknowledgement where one exists.

## The two doors

| Door | Who uses it | What it answers |
|---|---|---|
| The operator's screens | The platform operator, in the operator workspace | The decisions taken in that workspace, and platform-level operational records that belong to running Connect rather than using it |
| The customer facade | Anyone signed in to a customer workspace | The decisions taken in that workspace, over the same service and the same fields |

The doors differ in the path a browser takes, not in the implementation behind it. That is deliberate: a second audit implementation for one audience is how one side quietly loses a field the other has. [One implementation, two audiences](/research/two-audiences-one-implementation/) is the general argument; the trail is one of the clearest cases for it.

> **Note** Two screens present the same record for different questions. The Decision Log answers "why did Connect do that" for one action; Activity answers "what has been happening" across a period. Neither is a different trail.

## What is not in it

- No credential, key or token — those are sealed on save and are never rendered to a screen, an export or a log entry.
- No copy of message bodies. The trail points at the record a decision concerned; the content stays where it lives, under the same scoping.
- No other workspace's activity, in either direction.
- No free-text explanation invented after the fact. An entry says which rule applied, not a narrative reconstruction of the reasoning.

## Reading it when it matters

1. Start from the action rather than the date. Open the record — the conversation, the call, the follow-up — and read the decision attached to it.
   - Result: You get the rule that applied at the time, which is the question worth asking, rather than today's setting.
2. Widen to the Decision Log when the question is about a pattern rather than one action.
   - Result: Repeated refusals for one reason are visible as a run, which a single entry never shows.
3. Check what changed, not only what happened, when a behaviour changed without anybody expecting it.
   - Result: A permission or autonomy change leaves its own entry, so "who altered this and when" has an answer that does not depend on memory.

How long entries survive is a retention question rather than an access one, and it is answered on [How long the record is kept](/docs/autonomy/audit-retention/) and [What is kept and for how long](/docs/security/data-retention/).

## Limits worth knowing

**It is not a change history of every field** — It records decisions and the actions that followed them, not every edit a person makes to a record.
**It cannot explain a model's reasoning** — It records the rule that permitted or refused an action. Why a draft said what it said is a different question with a different answer.
**An entry cannot be edited** — That is the property that makes it worth reading. A trail people can tidy is a trail nobody can rely on.
**Absence is evidence too** — If an action happened and no entry exists, that is a fault worth reporting rather than a gap to work around.

## Questions

### Can a colleague see decisions I made?

Yes, within the workspace. The trail is a workspace record rather than a personal one, and that is the point of it: accountability that only its author can read is not accountability. What it does not do is reach outside the workspace.

### Does the platform operator read a customer's decisions through their own screens?

Each door answers inside the workspace of the session that opened it, and an audit entry is scoped like any other record. Operating the platform — payments, pricing, enquiries addressed to the operator — is a separate surface with its own records, and it is not the customer's trail.

### Is a refusal recorded even though nothing happened?

Especially then. A refusal is the decision that explains an absence, and an absence with no entry behind it is the hardest thing in any system to investigate afterwards.

## Related

- [The decision log](https://connectbyjbrh.com/docs/autonomy/audit-trail/)
- [How long the record is kept](https://connectbyjbrh.com/docs/autonomy/audit-retention/)
- [What is kept and for how long](https://connectbyjbrh.com/docs/security/data-retention/)
- [Authorisation](https://connectbyjbrh.com/docs/security/authorization/)
- [Responding to a suspected access problem, end to end](https://connectbyjbrh.com/docs/workflows/incident-response/)

## What this page is based on

- Connect source pack section 5 — the audit trail records refusals as decisions (`docs-source/sources/GENERAL.md`)
- Connect source pack section 1 — the two audiences and the shared implementation (`docs-source/sources/GENERAL.md`)
- Connect capability registry (`docs-source/facts.py`) — `audit_trail`, `rls_isolation`, `website_enquiries`