Activity Ledger
The Activity Ledger is a workspace's own tamper-evident account of what happened inside it. It is append-only, per-workspace, and hash-chained, and it is deliberately distinct from per-cell logging: logs are operational telemetry for diagnosis, while the Activity Ledger is the durable, verifiable record of activity, who did what, which governance decision was made, and what was refused. It is where the platform's audit trails converge for a workspace owner, and it is also scoped to a clean room where work is multi-party.
Append-only and hash-chained, per workspace
Each event is a normalized activity record, a wide carrier that also holds the
provenance and governance fields for the action. When an event is recorded, the
store assigns the chain fields per workspace: a monotonic seq, the
prev_hash of the record before it, and this record's entry_hash.
Because each entry commits to the one before it, deleting, editing, or reordering
any record breaks the chain, tampering is detectable, not merely discouraged.
Sensitive content never persists in the clear. A field-hash redactor hashes sensitive payload values before they are written, and where an event's classification is at or above a sensitive threshold, the entire payload is hashed, so raw secrets or PII never land in the ledger while the chain over them stays intact.
Figure F3: the per-workspace Activity Ledger. Each action is redacted, then
appended with a sequence and a prev_hash linking it to the record before it
(green). A verify call recomputes the chain and returns a tamper-evidence
result, and the verification is itself recorded as an activity_ledger.verify
event. Altering any record leaves a recomputed hash that no longer matches
(amber), so tampering surfaces on the next verify.
Table equivalent
| Property | How it works |
|---|---|
| Append-only | Events are added, never edited in place |
| Per-workspace scope | The chain fields (seq, prev_hash, entry_hash) are assigned per workspace; also clean-room scoped |
| Hash-chained | Each entry commits to the previous entry's hash |
| Redaction before persist | Sensitive values are hashed; a whole over-classified payload is hashed |
| Verifiable | A verify endpoint recomputes the chain and returns a tamper-evidence result |
| Self-auditing | The verification is itself recorded as an activity_ledger.verify event |
Where the audit trails converge
The Activity Ledger is the plane where governance stops being invisible. The decisions the platform makes on the work boundary, placement, residency, and egress, and the refusals it issues surface here, so an owner can see not only what succeeded but what was stopped and why. Reads converge here too: because reads are audited, not just writes, the ledger can answer "who looked" as a first-class question, not only "who changed something."
This is the owner's-eye view of the same tamper-evident discipline the platform applies everywhere, the meter audit chain, the read-audit trail, and this ledger all share the property that the record commits to itself and can be checked without trusting the system that wrote it.
What an owner sees
An owner queries the ledger for their workspace or clean room and gets an ordered, attributed history: the action, the entity behind it, the governance verdict, and the chain position, with sensitive fields already reduced to hashes. Running the verify endpoint tells them whether the chain is intact end to end.
The ledger is scoped to a workspace or clean room; there is no single global ledger every cell writes into, each scope keeps its own chain, consistent with the store-scoping rule. A complementary crypto-shred design (a per-subject data-encryption key so an erasure request can destroy a payload without breaking the chain) is a design direction under review rather than a shipped capability.
In the console
The ledger has two operator surfaces. The workspace / clean-room tab is at
/workspace/:id/activity and /cleanroom/:roomId/activity ("Activity,
resource activity timeline (governance-aware)"), gated on the membership capability
workspaces.console.read and pinned to that scope. A node-scoped view is at
/core/activity-ledger in the Core System console, which exposes the workspace
as a filter rather than pinning it, this surface carries no client-side
capability check and is guarded only by access to the console and the server-side
ledger API.
Both render the append-only, hash-chained ledger as a read-only timeline: columns for time, action, resource, actor, outcome, severity, and cell, with filters for resource type, outcome (success / deny / error) and severity, and a distinct badge and count for governance denials. The view is a lens only, and reading the ledger is itself an audited action. See Administration & Configuration for the surface map.
Across the deployment matrix
- Single-cell: the workspace's chain is a local artifact on the cell; verify recomputes it locally.
- Multi-cell: each workspace or clean room keeps its own hash-chained ledger; the ledger is a per-scope chain across cells, not a central service every cell depends on.
- Sovereign / air-gapped: recording and verification run locally, with no phone-home; the tamper-evidence property needs only the local records and their hashes.
- Cloud-enabled: the same model; the ledger remains the workspace's own account, not a hosted log the customer cannot verify.
Related topics
- Compliance and audit, the audit plane this ledger converges into, and the read-audit trail behind "who looked."
- Audit and tamper-evidence, the hash-chain contract shared across the platform's ledgers.
- Data residency, the placement and egress decisions whose outcomes and refusals surface here.
- Monitoring & logging, per-cell logging, the operational plane this ledger is deliberately distinct from.