Traceability: what the platform records

Overview

There is no single audit page. Traceability works the other way round: individual objects carry their own history, and you go to the object.

So the question "what happened to this?" is answerable. The question "what happened across the organisation today?" is not, at least not from one screen.

What you'll learn

• Where history lives, object by object

• Which two traces are strongest

• What to tell someone who asks about controls

• The limitation to state rather than imply

The two strongest traces

Process history is genuinely detailed. A subscription's history records each state a transaction passed through: seller invited, account created, bank info received, verified, payment received, incomplete, reminded, signed, cancelled. That is a narrative of what happened to that participant, and it is the closest thing the platform has to an audit log — scoped to a process rather than to the platform.

History records who acted, not just what happened. Each item carries the user who performed the action. That is what makes process history usable in a diligence conversation rather than merely descriptive — the question is usually who changed this, and the record answers it.

Two honest limits on that. An item with no user attached is a defect rather than a normal state: the backend can create one in rare circumstances, and it should be reported. And not every action currently writes a history item, so an absent record is not proof that nothing happened — the coverage is being extended.

The document chain is the strongest trace of all, and it is not a history feature. A cap-table position leads to a transaction, which leads to the document that evidences it (A5.7). That is traceability in the sense a lawyer or auditor means: not a log of clicks, but a link from a recorded fact to the instrument that makes it true.

Worth establishing which of those someone is actually asking for. "Show me your audit trail" usually means "show me the instrument behind this number" — and the answer to that is A5.7 rather than anything else in this lesson.

What to tell someone who asks about controls

Three honest answers:

1. Every position traces to a document. Registry → transaction → signed instrument (A5.7).

2. Every process records its progression, and who drove it. Each state a participant's transaction passed through is retained, with the user who performed the step.

3. Access is role-based and per project — there is no account-wide level (A1.4).

And one honest limitation: there is no single, queryable, platform-wide activity log.

Where this matters

Reconciliation — A5.6 depends on being able to trace a movement to its document.

A disputed position — the timeline says which event changed it (A5.4), the registry says which movement, the document says on what authority.

Client diligence — expect to be asked. The answers above are the ones you have.

Common problems

"No history found" on an object. Usually nothing has changed since it was created, which is not a fault. But because history coverage is still being extended, do not read an empty history as proof that nothing was done — corroborate with the document chain.

A history item with no user against it. Not normal. Records carry the acting user; one that does not is a defect to report.

You need activity across the organisation. Not available from one place. Go object by object, or process by process.

Someone asks for "the audit trail". Establish what they actually want. Usually it is the document chain (A5.7), which is stronger than a log.

Related

• A5.7 — The registry: tracing a transaction to its signed document · the strongest trace

• A5.6 — Reconciling and correcting the record · where traceability earns its keep

• A5.4 — The timeline · history read as a sequence