Five Chron updates for AI audit trails you can inspect

An AI tool answering a prompt and an audit record being saved are two different events.

That distinction has shaped our recent work on Chron, a local-first logger for AI interactions. We want developers to inspect what was recorded, understand what a verification result establishes, and recover their evidence when something goes wrong.

Here are five capabilities shipped across recent releases, available in Chron 0.1.64.

1. Capture before release, without asking the model to log

MCP logging depends on the client calling a tool. Instructions can request that call, but they cannot make it inevitable.

chron run introduces a different boundary. It records the child's controlled stdin, stdout and stderr in a local journal and makes the covering records durable before forwarding input or releasing output. If capture fails, it stops forwarding and releasing rather than quietly continuing without a record.

For a small example:

npm install -g [email protected]
chron run -- node -e "console.log('hello from chron')"
chron history
chron verify --journal

The wrapper also attempts to project the run into the database. If projection fails independently of capture, chron project is the retry path.

The limit matters: this covers streams controlled by the wrapper. It does not force anyone to use the wrapper or capture everything a client does through files, subprocesses or network calls. Runs recorded with reduced directory durability do not receive the full enforced:wrapper classification.

2. Backup and recovery that checks the evidence

A logger should have a recovery path before it has a destructive command.

Chron now takes SQLite snapshots using VACUUM INTO, with a separate manifest describing the snapshot. Restore checks the file digest, database integrity and recorded evidence chains before installing the restored copy. Recovery drills exercise verification without replacing the live database.

Confirmed pruning requires an explicit backup destination and refuses to delete if that backup fails.

Backups and signed exports remain different tools: one restores a database; the other lets someone verify a portable evidence bundle. The backup manifest is unsigned, so its recorded creation time is not independently attested.

3. Reconcile what the client recorded with what Chron holds

chron reconcile compares local Claude Code transcript records with inspected Chron evidence. It is read-only: it does not import, merge or silently upgrade the provenance of a session.

The streaming reader can inspect large transcript files without retaining the whole file in memory. The comparison remains sampled, up to 200 messages per transcript, and reports its inspected scope and limits.

An unmatched record means no correspondence was found within that comparison. It is not proof that someone bypassed logging, and the correspondence fraction is not a capture-completeness score.

4. OpenTelemetry export with delivery receipts

Chron supports operator-initiated OTLP/HTTP JSON trace export for sessions and messages. Conversation content is excluded by default.

The useful part is distinguishing outcomes. A collector refusing an export is not the same as a connection failing before delivery. A request received by a collector that never answers has an uncertain outcome.

chron otel receipts exposes the recorded delivery state rather than flattening those cases into a success tick. This is manual trace export, not automatic telemetry, metrics or log export. A collector response is not proof of permanent retention.

5. HTTP transport defaults that are explicit

For deployments using MCP over HTTP, Chron 0.1.64 requires authentication and binds to loopback by default. It validates Host and Origin, and non-loopback binding requires explicit configuration.

The stdio path remains separate and does not require an HTTP API key.

These are specific controls, not a blanket security claim. Dependency hardening is ongoing and is being scoped separately from feature work.

Verification should explain its boundary

The common thread is keeping the claim close to the evidence.

A journal chain can establish internal consistency; an unanchored chain is not proof that nobody rewrote it. A successful package test does not establish that every AI client will invoke Chron. A local record does not establish that every interaction was captured.

Our latest published-package regression passed 44 release checks and nine streaming checks. Real authenticated client acceptance remains a separate, unfinished test leg, not something those numbers establish.

Chron is available on npm, with source and documentation on GitHub.

For teams using AI developer tools: which gap is hardest today: dependable capture, identifying missing records, or independently verifying the evidence you already have?