Impact, audit and replay

Three read-only surfaces tell you what happened. Mesh impact (/impact) rolls up the last seven days of outcomes, the Audit log (/audit) is the per-event trail, and the replay viewer (/replay) walks a single workflow run step by step. All three are in the Measure group of the left nav, except replay, which you reach from an audit row.

None of them changes anything. They exist because nothing auto-executes: the system proposes, you approve, and then you need a way to check that what you approved actually landed.

Where do I see what the system did this week?

Open Mesh impact from the Measure group. It answers “what did the mesh do for me” over a seven-day window as counted outcomes rather than a log, and it is scoped to your tenant.

The first card, What the mesh did, carries six tiles: mesh actions, drafts produced, auto-executed, inbound auto-handled, KR updates, and cost in euros. The second card, What needs you, is a point-in-time snapshot: pending approvals, tasks in progress, tasks done, escalations.

Below those, By Head lists actions and cost per head (top eight), and Daily trend breaks the window down day by day once there is more than one day of data. A window with no activity renders an All quiet state instead of zeroes dressed up as insight.

The window is fixed at seven days. There is no date-range picker on this screen. A Microsoft Clarity friction panel appears underneath when Clarity is connected and has data, and renders nothing at all when it is not.

What do the impact numbers mean, and what do they not mean?

They are counts of recorded events, not a productivity measure, and two of them need care. Mesh actions counts audit events whose actor is the system — work the platform did, not work you did. Cost is the euro amount attributed to that window.

Auto-executed is the one to read carefully. It counts events that reached the execute stage, including actions that a person approved first, so it is not evidence of unsupervised autonomy. Nothing runs without approval today — see autonomy and the hard floor.

Inbound auto-handled shows — rather than 0% when there is nothing to base a percentage on. That dash means “not knowable yet”, and it is deliberate: the screen would rather show you nothing than a number it invented.

How do I confirm an approved action actually ran?

Open the History tab on the approvals page and read the line beneath the decision. Approving is a decision; the outcome is the record of what happened to it, and the two can disagree.

Each settled row shows the decision (approved, rejected, edited, re-routed, superseded) and, for an action that runs an effector, an execution outcome:

• Executed — the action ran, with a short detail line.
• Staged, awaiting send — prepared, not yet out the door.
• Skipped — nothing ran, and nothing changed.
• Failed — it was attempted and did not complete, with the error shown.

An approved action with no recorded outcome shows “No execution recorded yet” instead of staying silent. Rows also carry a ran <time> stamp, which is distinct from the decision time.

Where the outcome produced a real artifact, the line becomes a link — a send opens its outbound ledger row, a created or forwarded task opens its board. When the reference cannot be resolved, you get a plain badge rather than a link that would 404.

Tip

After you clear a batch, scan the History outcomes. That scan is what separates “I approved that reply” from “that reply went out”. More on the routine in working the approval queue.

What does the audit log show?

The Audit log is the append-only, per-event trail: time, what happened as a one-line summary, who did it, what it acted on, the result, cost, and a details link. Reading it requires an admin role — the nav entry is visible to everyone, but the data behind it is gated.

Five filter pills narrow the list: All actions, Auto, Human-gated, Escalated, Failed. When the loaded page holds more than one event kind, a dropdown facet lets you show a single kind. Filtering happens over the events already loaded, not across your whole history.

Click any row to open a detail drawer with the actor, the target, the payload fields, the raw JSON, and the run’s step trace when there is one. Hovering the cost cell shows tokens and model where the event recorded them, and shows nothing where it did not.

The tax-audit package panel at the top of the page is not active yet: the download, send-to-tax-adviser and create-auditor-access buttons are all disabled.

Can I replay how a run happened?

Yes, for events that target a real workflow run. Those rows show a Replay link that opens the viewer for that run; rows without a run show Details instead, which opens the drawer.

The viewer gives you a timeline of the run’s steps sized by duration and coloured by status, a step-back and step-forward player, and per-step detail: the step id, its duration, its cost, the model used where one was, and the input and output snapshots.

Caution

Two things in the viewer are placeholders, not records. The “Why this pattern” text and the per-step Reasoning field are illustrative — the run service does not emit a rationale yet, so do not treat them as an explanation of the decision. The Re-run from here, Export trace and Ask Concierge buttons are disabled stubs and are deliberately not wired to anything that executes.

Everything else on the screen — timings, costs, statuses, snapshots — comes from the stored trace.

Can I see automation rate or time saved?

Time saved, yes — automation rate, no. The Cost page reports an hours-saved figure; there is still no operations analytics screen, so automation rate and playbook performance are not reportable and no page will show you those.

On the Cost page you get a Human-time saved figure and a Net mesh ROI figure for the current month. Read both for what they are:

These two numbers are an estimate, not a measurement

Nothing times your staff. The hours figure is your run volume multiplied by a fixed assumption about how long each run would have taken a person, and the ROI figure applies an assumed hourly rate to that result and subtracts the platform’s real spend. The run count and the spend are recorded facts; the minutes-per-run and the hourly rate are settings, not observations.

So the number moves when your volume moves — and it also moves if someone changes the assumption. Use it as a directional indicator, and never as a figure to put in front of a board or an auditor without saying how it was derived.

Judge a week by what you can verify instead: the state of your approval queue, the outcomes on the History rows, and the counts on Mesh impact. Those are recorded facts.

Next: work the queue in the inbound triage cockpit, or read how the whole inbound → approve → execute loop fits together.