Read and filter the ledger

The Ledger is the surface you will spend the most time on. It lists every recorded change for one entity, newest first, with filters for narrowing to the question you are actually asking.

Filtering#

Filters combine, so tool plus event type plus a date range answers questions like "every permission change in GitHub last quarter" directly. The date range filters on occurred_at, the time the change happened, not the time Governax recorded it.

Paging through results#

Results come back twenty-five at a time, and a page can be widened to a hundred. Paging uses an opaque cursor rather than a page number, which keeps results stable while new events are arriving: with page numbers, an event landing mid-session would shift everything down and you would see the same row twice.

The live feed#

The Ledger holds an open connection to the server and new events appear as they are appended, without a refresh. A live indicator shows when the stream is connected.

The connection closes itself after about ten minutes and the page reconnects, which is normal behaviour rather than a fault. Reconnecting does not lose anything: the page reconciles against the ledger on reconnect, so events appended while the connection was down still appear.

Consuming this stream from your own systems is not possible today. Governax has no public API.

Opening an event#

Selecting a row opens a panel with three things:

• The normalised event. Actor, subject, event type and timestamps, in the shared shape every connector maps into.
• The raw payload. The tool-specific detail Governax kept, such as which channel or which repository.
• The cryptographic proof. The event's own hash and the hash of the event before it, with the hash recomputed at the moment you open the panel and compared against what is stored.

The proof answers "has this specific row been altered since it was written". It does not check the rest of the chain. For that, run a full verification, described in Verifying the ledger.

Why some actors show as codes#

Some tools identify people by an opaque id rather than an email address. Slack is the clearest example: a webhook carries a user id like U01ABCDEF and nothing more.

Governax stores exactly what the tool sent and resolves those ids to names when displaying them, rather than rewriting the stored row. This matters for integrity: the record keeps what was actually reported, and the friendly name is presentation applied on top. It also means a person who has since been renamed or deactivated still resolves correctly against the original id.