Every workers' compensation case management system records who took each action. A task gets created — the record shows who created it. A task gets completed — the record shows who completed it. A note gets logged — the record shows who logged it. The "who" matters. It is the audit trail.

When an AI assistant operates on top of a case management system, the AI does not have its own identity in that system. It writes through an API token. The token belongs to a user — typically the firm's admin user — and every write the assistant makes is attributed in the underlying system to that user. From the assistant's side, the writes are happening on behalf of whichever attorney or paralegal is sitting at the keyboard. From MerusCase's side, the writes all look like they came from the same admin user.

This is not a bug. It is how API tokens work. Most firms set up their tokens this way deliberately — a single firm-level token is easier to manage than per-user tokens, and the firm's internal records of who did what are kept in the assistant's own audit log, not in MerusCase's. But the distinction was implicit. The task walker showed the attorney a filter — "you're walking the paralegal's tasks" — and the attorney could reasonably believe that completing a task from that view would be attributed to the paralegal in MerusCase. It would not. It would be attributed to whichever user the API token belongs to.

We made this distinction explicit in the latest release of the walker.

What changed

Three additions, all of them in the user interface, none of them changing what writes actually happen.

At startup, the walker now queries the API for the token's own identity and prints a line confirming it:

Identifying writer (MERUS_TOKEN owner)...
  Writer: [Full Name] ([email], user_id 12345)

The attorney sees, right at launch, the user record that every write in this session will be attributed to. If that's not the user the attorney expected, they know before doing anything.

On the header bar above the task list, the writer identity is shown again next to the filter:

aaicase — task walker   |   Filter: [Staff Name]   |   115 tasks
Writing as: [Full Name] (email)   user_id 12345
══════════════════════════════════════════════════════════════

Filter and writer side by side. If they match, the header is unremarkable. If they don't, the header gives the attorney the data to notice.

On every task card, the writer is shown as a small annotation in the title row:

Task 1 of 115 OVERDUE 247 days   [filter: Staff Name]   [writer: Full Name]

This is for the case where the attorney scrolls past the header during a long walk and forgets the writer. The marker travels with every card.

And when the filter and the writer are different, a yellow warning fires in both the header and the card:

⚠ Filter is for user_id 12345 but MerusCase will attribute every write to
"[Full Name]" (the token's identity). Audit logs in MerusCase will not show
the filter user as the actor.

The warning is not a refusal. It does not block the write. It is the system being honest about what is going to happen.

Why this matters

Three reasons.

Audit reconstruction. Six months from now, if a question arises about who completed a task, the attorney's mental model of who did what may not match what MerusCase records. The attorney might remember "I had the paralegal walk through that batch of tasks one Tuesday afternoon." MerusCase will show every one of those completions as having been done by the firm's admin user. Without transparency about the writer identity at the time the walk happened, the attorney is left explaining a discrepancy. With transparency, the attorney knows in advance that the API token is the actor of record and can plan accordingly — for example, by exporting the walker's own audit log alongside any MerusCase audit query.

Privilege boundaries. Some firms have policies about which users can modify which records. If a paralegal is supposed to be the one closing certain types of tasks, and the AI assistant has been writing under the admin user's identity, the policy has been quietly bypassed. Making the writer identity visible lets the firm see, in real time, whether the policy is being honored.

Trust calibration. An AI tool that operates in a law firm needs the attorney to know exactly what it is and is not doing. Hiding the fact that all writes share a single attribution would not improve the user experience; it would just defer the discovery to whichever moment the attorney first noticed and lost trust. Showing it up front, in plain text, with a warning when there's a mismatch, is how we tell the attorney: this is the thing. You can decide what to do about it.

What this does not solve

It does not change the underlying attribution. A firm that wants per-user attribution in MerusCase needs per-user API tokens, and the assistant needs to know which token to use for which user. We have not built that yet. It is a real piece of work — token rotation, secure storage, switching tokens mid-session, handling the case where a staff member's token has been revoked. The transparency upgrade we shipped is a prerequisite to that future work, not a substitute for it.

It also does not solve the case where the firm has not set up per-user tokens and accepts the firm-level token as the actor of record. For those firms, the warning is just informational — they already know every write is attributed to the firm admin and that's the operational model they want. The walker accommodates that case by not refusing the write, just by noting the attribution.

And it does not affect the assistant's own audit log at ~/.aaicase/audit.log. That file already records who was using the assistant when each write happened, with timestamps, change details, and the local OS user. The audit log is internal to the firm and complements (rather than replaces) MerusCase's attribution. Most firms that need a per-user audit trail will rely on this log, not on MerusCase's record.

The general principle

This is a small change. The walker has one new function (about 25 lines), three new lines of header output, and two new warning blocks. It is not the kind of release that justifies a press release. We are writing about it because the underlying principle is worth stating clearly:

The user interface should make implicit attributions visible.

Whenever the assistant is operating with credentials that are not the credentials the human at the keyboard might assume, the assistant should say so. Whenever an action is being performed on behalf of one user but recorded as having been performed by a different user, that fact should be on the screen, not buried in a help document. The cost is a few lines of UI. The benefit is that the attorney's mental model of what is happening matches what is actually happening.

We expect to apply this principle to more places as the assistant grows. The mail processing flow, the email filing flow, the audit-case sweep — each of these has writes that go through the same shared token, each of them should show the writer identity the same way. We will work through them.

The current release adds the transparency to the task walker only. It is a small upgrade. It makes the assistant a little more honest about what it is doing on the attorney's behalf. We expect more upgrades like this to follow.