Event Ledger for AI Tools | Dweve Ledger

Choose the audience that matches your question

The page contains three selectable readings of the same subject.

Knowledge governance that uses Ledger as its audit spine.

Parse source into trees with content-addressed nodes.

Execution transcripts inside a sandbox. Ledger captures what happened; Selvedge captures how it executed.

Reasoning-step certificates inside a single decision, not event provenance across a system.

Ledger publishes in the second round of Dweve's foundation release programme; once it does, point the build at your storage backend and inspect your first append, hash check and replay in one local run.

Ledger ships as a Rust crate, a C ABI, a sidecar process, and a service binary. The sidecar pattern is the most common production deployment. The same event format flows through every variant.

Memory for tests. JSONL for portability. SQLite for embedded. Postgres for query power. S3 for archival. The log shape and hash chain are identical across all five. Migration between tiers is a copy operation, not a re-encoding.

Tool calls, approvals, artifacts, policy checks, and system changes each keep their own typed shape. That makes the history precise enough to query without flattening every event into an ambiguous log line.

Figures are an in-memory benchmark snapshot from the supplied Ledger source, not a published SLA. Run the included harness before sizing a workload.

In-memory snapshot, ledger_append_event.

One of 23 typed variants is added to the tail.

Events are typed, BLAKE3-hashed, Ed25519-signed at trust anchors, and persisted to a backend of your choice. The pipeline is the same regardless of storage. Hover a stage to read its contract.

Cannot reconstruct state from the log alone.

Multi-process clocks drift. No canonical order.

Tail-truncate, log-rotate, easy to alter.

Most AI systems write unstructured text logs that nobody can replay. SIEM dashboards summarise, but they cannot reconstruct a decision. Auditors are left with prose.

One command. The replay walks every event in order, verifies the BLAKE3 chain, and rebuilds the state at any timestamp. The figures below are an in-memory benchmark snapshot from the supplied Ledger source, not a published SLA. Run the harness on your own hardware.

Cut off from the internet, for the most sensitive records.

A cloud region pinned to a European country, under European rules.

It runs on the computers your own team manages, inside your walls.

Project properties and supported deployment modes; not a service-level or capacity claim.

None required to append, verify, or replay.

One chain across every supported backend.

A record designed to move with the system

Software bill of materials and attestation, recorded.

Requested, granted or denied, recorded in order.

An AI incident is recorded the moment it is detected.

Consent, DPIA, erasure and subject rights, each a typed event.

Replay any window directly from the recorded events.

Approval events keep the actor, scope, and outcome together.

Hash links make every deletion, reorder, or mutation visible.

One typed record replaces forensic joins across partial logs.

Keep the same event shape in memory, SQLite, Postgres, S3, or your backend.

Reconstruct state from the events instead of trusting a snapshot.

Every entry extends the chain, so quiet changes fail verification.

New events are appended without rewriting earlier history.

The hardest moment is when an auditor or regulator asks a pointed question and the team has to go digging. Ledger answers a different way: the things a review asks about, consent, incidents, approvals, supply chain, tool use, are each recorded as their own sealed event when they happen. Pick a question below and see which recorded event already holds the answer.

The other question a review asks is where the software is allowed to run. The same record format and the same storage choices work in your own building, in a European cloud region, or fully sealed off from the internet. Moving between them is a copy, not a costly rebuild, so the decision is never final.

A procurement review asks two plain questions: what does this save, and what does it de-risk? Ledger keeps teams from stitching evidence together across partial logs during an incident. Its append-only chain also exposes any attempt to alter history after the fact.

Applications change, providers move, and storage gets replaced. Ledger keeps one typed event history across those changes, with every entry linked to the one before it. Operations can trace an incident, answer an audit, or rebuild state without stitching together partial logs.

The record and its plain format belong to you, to read back anytime.

It stays beside the system it remembers, without another account or dashboard in the way.

It can sit on a computer in your own building, not a stranger’s far away.

It can stay on a computer in your own building, close to home.

It tells the very same story on every computer, every time.

You can read it back from any moment, like rewinding a home video.

Each line is sealed to the one before, so a quiet change shows itself.

Wonder later what happened, or when? It is written down for you.

Read it back on any computer and you get the very same story.

That line is sealed to the line before it, so no one can quietly change it.

When the AI does anything, one new line gets noted down.

The notebook stays with the system that uses it. There is no separate account to check and no distant dashboard to trust: your own team can read the same ordered story whenever a question comes up.

It is fair to wonder what happens if something goes wrong. What if the record gets changed? What if you forget? What if it says something different elsewhere? Pick a worry below and see, in plain words, how an honest record answers it, so there is one less thing to lie awake about.

You do not have to understand any of the machinery. Here is the whole thing, start to finish, as four everyday moments. Something happens, it gets written down and locked, it stays the very same on every computer, and you can always ask about it later.

Think of it as a notebook that an AI tool keeps for itself. Every time it does something, it writes one more line at the bottom, and it never goes back to erase what is already there. Flip through the plain-words pages below to see, with everyday pictures, what each part of that notebook is really doing for you.

Ledger is an event record for AI systems. It keeps an append-only history that cannot be quietly edited, so when an auditor or regulator asks what happened, you have a straight answer. It is built in the EU and can run entirely on infrastructure you control: one record of who called what, who approved what, and what happened next.

Ledger is the part of an AI system that quietly keeps an honest notebook. Every time the AI does something, it writes one new line and seals it, so nothing can be changed behind your back. Read it tomorrow, or on a different computer, and you get the same story in the same order.

When a regulator asks what happened in your system, you need more than logs: you need an append-only event record where every entry extends a BLAKE3 chain, every type is strongly typed, and any window of history can be replayed to reconstruct state. Ledger is event provenance for systems: who called what, who approved what, who read what, in order, without the possibility of quiet edits. Unlike AION, which certifies the reasoning steps inside a single AI decision, Ledger records what events happened across an entire system. Unlike Selvedge, which captures execution transcripts inside a sandbox, Ledger captures provenance across multiple actors and services.

A tamper-evident audit log in Rust for AI tool interactions. Ledger appends one typed event per action and links each entry to the previous one with BLAKE3 hashes. Ledger publishes in the second round of Dweve's foundation release programme, with its documentation at docs.dweve.com the same day.

Ledger is a tamper-evident audit log in Rust for AI tool interactions, publishing under Apache 2.0 terms in the second round of Dweve's release programme. Choose where Ledger stores the record, then hand it over when someone asks what happened.

Ledger is a tamper-evident audit log. When software uses it, the record can show what happened in order and link each note to the one before it.

When the repository publishes, choose a storage backend, append a first event and run an integrity check before adding another service. Publication is planned in fortnightly rounds; the repository and its documentation go live together.

Tool calls, approvals, artefacts, sessions, replays, rights, incidents, attestations and custom entries keep their own shape. The record is precise enough to query without flattening every action into an ambiguous log line.

The categories are named so the record can be asked a question later

The panel names Ledger's own vocabulary. It is not a scorecard: each kind gives a question a reliable shape before anyone starts searching through prose.

The categories are real, and a selection runs over the entries themselves. Ask for denied approvals in March and the answer is a query over the record, not a reconstruction.