The audit log

PathWise keeps a persistent record of every operation it runs, so you can check what it did and confirm it never remediated.

What it is

PathWise writes a local audit trail to a SQLite database, users.db, in the engine's data directory, the writable volume you mount when you start the container. It stays on the machine PathWise runs on. Every operation the engine runs during an investigation is recorded there, as it happens, not reconstructed afterward.

Why it exists

The rest of this documentation states that PathWise never remediates. The audit log is how you check that claim instead of taking it on trust. It gives you a persistent, after-the-fact record to read, not just a behavior you happened to observe once.

What gets recorded

Two tables hold the trail.

audit_operations holds one row per tool call: the tool's name, its effect label (read, write, or unknown), whether the call ran, was denied, or errored, and a bounded summary of the arguments and the result.
audit_investigations holds one row per investigation: when it opened and closed, and four counts, total operations, reads, non-read attempts that were denied, and remediations executed.

The zero that matters

The remediations-executed count is not a claim. It is a number the engine queries from the recorded rows every time an investigation closes. It reads zero because the effect gate denies every non-read effect before its underlying function can run. A denied attempt still gets its own row, tagged denied, because a refused attempt to act is the event most worth keeping.

If a request were somehow able to reach a remediation tool, that call would be denied and logged as denied, not silently dropped. The trail would still show exactly what was asked and what happened.

What you can inspect

Every tool the engine called during an investigation, in order.
Whether each call was allowed, denied, or errored.
A bounded summary of what was sent and what came back. Each summary is capped in length, so one very large or malformed result cannot bloat the log.
Denied attempts, including anything that looked like a request to remediate.
Per-investigation totals, so you can confirm the remediations-executed count is zero without reading every row by hand.

There is no dedicated audit screen in the web interface today. You read the trail by opening users.db with any SQLite client, on the machine it lives on. The two tables above are the whole schema you need.

Where it lives, and what leaves your machine

The trail is local. It stays in users.db on the machine PathWise runs on. Nothing in it is sent to Silo7.

Status

This capability has shipped and merged into the engine. It records every operation the engine runs and proves the absence of remediation with a test that reads the persisted trail, not just a passing behavior.

Not yet shipped

Audit-trail wiring for the command-line path is deferred. Today the trail is wired into the web server and the reasoning loop, which covers the shipped product path.

Under the hood technical detail

The audit sink attaches at the same point the engine already emits its live step events. The write is wrapped in a try/finally, so the closing summary is written even if an investigation stops early, for example by hitting its turn cap.

Recording is best-effort: a sink that throws never changes the outcome of a run. The no-remediation guarantee lives in the effect gate, not in the logging path, so a logging failure cannot mask or fake a result.

Each investigation id carries a per-process prefix, so restarting the engine cannot produce two different investigations that collide under the same id in the trail.

Arguments and results are each capped in length before they are stored, so one very large or malformed payload cannot bloat a row.