Skip to content
OPERATIONS

Versioning & auditing

Nothing in Lore Index changes silently. Every edit snapshots the previous state, and every meaningful action writes an append-only audit record — both are things you can read back.

Version snapshots

Every time an entry is created or edited, a full snapshot is written to entry_versions by a database trigger — not by application code, so it cannot be bypassed. Each snapshot captures the complete state of the entry at that version: type, title, body, scope, tags, priority, status, source, expiry, and a monotonically increasing version number, along with who made the change and when.

The table is append-only: the application role can insert new versions but has no permission to update or delete existing ones. History is therefore immutable — you get a complete, tamper-resistant record of how an entry evolved.

Audit events

Alongside version history, audit_events records actions across the workspace. It too is append-only (update and delete are revoked from the application role). Each event stores the actor, the action, the object type and id, and before/after JSON where relevant, timestamped.

Entry create and edit events are trigger-written; workflow and system actions are logged by the application, including:

  • submit — a draft sent for review.
  • approve / reject — a reviewer's decision on a proposal.
  • update / remove — an entry edited or archived.
  • pack_compiled — a bootstrap pack compiled, with its token cost and entry count, and whether it was served to an agent (API key) or the web view.

Reading history in the app

  • Version history lives on each entry. Expand an entry in the list and choose View history to see its versions with a word-level diff between them — exactly what changed, highlighted.
  • The audit log lives under Settings → Audit log, giving admins a workspace-wide trail of who did what and when.
Continue reading
Versioning & auditing · Docs · Lore Index