Inspect activity

A proposal looks different than it did last week, and nobody on your team remembers changing it. Activity at /admin/activity is where you go to answer that question with evidence instead of a guess: who changed a record, what action was recorded, and exactly when it happened.

Finding a change

1. Narrow the time range

   Set the window to roughly when you think the event occurred; a tight range surfaces the right event faster than scrolling a long list.

2. Filter it down

   Filter by actor, action, source, or entity type where those filters are available for what you're looking for.

3. Open the linked record

   Find the matching event and open the record it points to, rather than trusting the event summary alone.

4. Compare against current state

   Check the recorded action against the record's current state and any related execution or provider receipt to see whether they agree.

For example, if a proposal appears to have changed right after a customer reviewed it, start with that proposal's own events around the time of the review, and keep the proposal's identifier with your findings so a colleague can pull up the exact same record later.

Reading the evidence correctly

An activity event records that something happened inside the application. For anything with an external effect, like a message going out, check the associated result too: an approved request, provider acceptance, and final delivery are three different facts, and an event must be read according to the state it records. Action results walks through the rest.

Events deliberately omit sensitive content, so a row can identify that a message was sent without containing its full body. Open the authorized business record itself for content you're allowed to read.

Audit ledger protection

The audit ledger (audit_log) is separate from the canonical activity records also shown on this screen. After 20261017050301_audit_log_append_only.sql is applied through the ordered catalog, signed-in clients can read and append audit entries but cannot update, delete, or truncate an existing audit row. Workspace and private-owner fields stay fixed once written. This migration does not add the same protection to the separate activities table. This is client-role mutation protection, not tamper-evidence: trusted server infrastructure and the database owner keep the governed retention and recovery paths they need, so this boundary does not block a privileged change.

Two limits matter when you rely on an audit entry as evidence:

• Insert provenance is not checked by the database. The application redacts sensitive keys and message bodies before writing, but a raw insert can record an action the application itself did not produce. Always read an event together with the record it points to.
• A change and its event are not always one transaction. Some workflows write the record and its receipt together; a workflow that records its audit in a separate call is not guaranteed to commit both. If a change and its event disagree, keep the record ID and the approximate time and escalate rather than assuming one of them is complete.

If the migration has not been applied to your installation, the protection is not active; ask your technical owner to apply it through the catalog. This boundary is not a substitute for reading the underlying record.

What to check

• If you can't find the event you're looking for, double-check the workspace, date range, and filters before assuming it's missing. If it's absent, keep the affected record's ID and approximate time to hand to your technical owner rather than guessing at what happened.
• Today shows you work to act on; Activity is for investigating what was already recorded, not for finding new work.