Keyboard shortcuts

Press ← or → to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

Lineage in pictures

The whole system on one page. Each picture shows one mechanism, and each is explained in depth elsewhere in the docs.

Where Lineage sits

Your agentClaude, DeepSeek, any codeLineage guardpolicy · budget · scarsToolsshell · email · paymentsOperatorsapprove · reject · killSigned audit loghash-chained · Ed25519Auditorsverify offline1. may I?2. allowed / denied / wait3. only if allowedapprove / rejectevery steppublic key + checkpoint
The guard sits between an agent and its tools. Operators approve what the policy holds back. Everything lands in a signed log that anyone can verify.

An agent never calls a tool directly. It asks the guard, and the guard answers from a policy the agent can’t change. Everything that happens, whether asked, allowed, denied, approved, failed or harmful, is appended to the agent’s signed log. How Lineage works →

What changes when you add it

Without Lineageagentreads injected textrun_shell ✓pay $9,800 ✓app.logeditable, unsigned, can be deletedWith Lineageagentsame textguardrun_shell ✗pay: waitssigned logrequest, denial, scar, approval: provable
The same prompt-injected agent, without and with the guard.

The model is the same, and so is the injected text. The difference is that the model’s requests now pass through something that says no, holds risky actions for a person, and keeps evidence. Why Lineage →

The checks, in order

alive?terminatedno scartool allowed?tool_not_allowedmoderatecall cap?tool_call_limitminorrate limit?rate_limitedminorbudget?insufficient_budgetno scarapproval?pending_approvalwaits for a humanall pass → allowed, budget charged
Checks run in this order and the first failure wins. The scar each denial leaves is shown underneath.

A request passes six checks. The first failure denies it; some denials leave a scar, because asking for a forbidden tool is itself a signal. Decisions and scars →

The life of an action

requestedpending_approvaldeniedallowedcompletedneeds a humana check failschecks passapproved + re-checkedrejectedoutcomesuccess · failure · harmful
The states an action moves through. Every transition is one signed record in the agent's log.

Pending actions cost nothing until approved, and they’re checked again at approval time. An action approved an hour later, after its agent was terminated, is denied. Approvals →

Scars add up

+1failure+3unlisted tool+1rate limit+10harmful…scar_limit = 100score 15 ≥ 10 → terminated: every later request is denied
Scar weights add up toward the policy's scar_limit. Crossing it terminates the agent, permanently.

Scars never heal. The weights (minor 1, moderate 3, severe 10) add toward the policy’s scar_limit. Policies →

Why the history can’t be rewritten

0 genesispublic keyhash · signature1 policybudget 100hash · signature2 requestedpay $120hash · signature3 allowedby alicehash · signature4 outcomesuccesshash · signatureedited: $120 → $12hash no longer matches contentchain broken from here onprev_hash links every recordto the one before
Each record carries the previous record's hash and is signed. Editing one breaks its hash, and every link after it.

Every record carries the hash of the one before it and an Ed25519 signature. Changing any byte breaks that record’s hash; recomputing the hash breaks the signature; deleting a record breaks the chain. Published checkpoints also catch the tail being cut off. The audit log →

Why restarts don’t help a misbehaving agent

agent.jsonlthe only state there isGuard::openverify, then replayspent budget: 6 / 20scars: 6 / 6pending approvals: 1alive: noreadrebuildtampered log → refused (quarantined on the server)
A restart doesn't reset anything. Guard::open verifies the log, then replays it into the same state it had before.

There is no state file to reset. The log is the state, and a tampered log is refused. Level 5 of Lineage Mastery →