Connect by JBRH Open Connect

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 What this means
Audience
both
In the app
#/autonomy-audit, #/activity
Last verified
Product version
6.3.2

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#

DoorWho uses itWhat it answers
The operator's screensThe platform operator, in the operator workspaceThe decisions taken in that workspace, and platform-level operational records that belong to running Connect rather than using it
The customer facadeAnyone signed in to a customer workspaceThe 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 is the general argument; the trail is one of the clearest cases for it.

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 and What is kept and for how long.

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.