> ## Documentation Index
> Fetch the complete documentation index at: https://docs.vinmake.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Follow accounting lineage

> Trace one fact from source evidence through matching, workpapers, subledger events and exact immutable journal entries.

# Follow accounting lineage

The lineage links described here are live in the GreatBook web application.

## The chain of custody

```mermaid theme={null}
flowchart TB
  E["Evidence<br/>document or bank statement"] --> M["Matching decision<br/>proposal or durable decision"]
  E --> N["Native record or workpaper<br/>authoritative source"]
  N --> A["Accounting event<br/>canonical transaction"]
  A --> J["Journal entry<br/>immutable GL write"]
  J --> R["Reversal<br/>new immutable entry"]
  A --> W["Audit workpaper or finding<br/>assurance context"]
  M --> W
  classDef evidence fill:#dbeafe,color:#172554
  classDef decision fill:#fef3c7,color:#451a03
  classDef record fill:#dcfce7,color:#14532d
  classDef assurance fill:#f3e8ff,color:#3b0764
  class E evidence
  class M decision
  class N,A,J,R record
  class W assurance
```

This is a chain of links, not a claim that every item is the same kind of record or that every event began in intake.
Evidence supports a decision; decisions may explain an accounting event; an event may lead to one or more journal entries; assurance records explain a control result.
Native subledger rows, approved workpapers, reversals and system events are valid sources alongside document intake.

## Accountant-originated work is durable

An Accountant adjustment, close calculation or import does not become auditable merely because a journal description names it.
GreatBook records an independently approved immutable `journal_workpapers` source with the exact `(source_type, source_id)` used by the journal.
The workpaper points to the containing accounting event and exact immutable journal entries, and Transactions or exact-entry detail resolves back to that same workpaper.

This is bidirectional lineage, not copied labels.
If the exact workpaper/source relationship cannot be established, the event remains `missing` or reviewed `legacy_unverified`; a descriptive key never upgrades it to resolved.

## Worked example: trace a transaction to source, workpaper and reversal

1. Start in **Books → Ledger** and select the Transactions event, or start in a Books native register and follow its accounting-event link.
2. Record the stable `greatbook.ref/v1` event reference rather than relying on row position or prose.
3. Inspect the source category and lineage state, then open the exact source or durable workpaper reference.
4. Open each journal-entry set inside the event and verify entry identity, status, date, complete debit/credit lines, posting actor and integrity state.
5. Follow `reverses` or `reversed_by` to the exact correcting entry. A reversal is a new immutable write; the original entry remains.
6. Return through the source link to the obligation, settlement, allocation, costing record, adjustment, intake item or workpaper that owns the accounting fact.
7. If assurance identified a residual, open its finding and stored run evidence. A waiver remains visible as a waiver; it is not silently treated as resolved.

## Honest failure behavior

Lineage is deliberately explicit about gaps:

* **Missing source** means the event's primary source could not be resolved.
* **Legacy / unverified** means the event can be read but its older lineage was not established.
* An unavailable detail or malformed response is an error, not a substitute source.
* A partial Books family or tie-out cannot establish complete native-to-GL coverage.

The system preserves exact decimal representations across these reads and separates a statement's evidence amount from a settlement or GL amount.
When a period is closed, a correction is a new reversing accounting write rather than an edit to prior history.

## Auditor jobs and browser access

The Auditor has two operator paths.
A person can ask a conversational, read-only assurance question in the browser; scheduled or event-triggered audit jobs run in **job mode** with the job definition's check family and scope.

The browser cannot select job mode, privileged audit scope or an arbitrary job thread.
The frontend passthrough accepts only `messages` in a browser-originated Auditor input; `mode`, requested check families and job-only scope are absent from that allowlist.
If a browser request attempts them, it is rejected instead of becoming a scheduled run.
The server job runner creates `mode="job"`, selects the recognized family and scope, and sends the narrowed state through the graph.
For an operator, the practical flow is simple: use the Audit workspace to read the durable findings, acknowledge or waive only through its stated controls, and let the scheduling path own job execution and retries.
An audit read failure becomes inconclusive coverage, never a clean result.

## Related

* [Match evidence without posting it](/greatbook/guides/matching-workflow)
* [Asking the Auditor](/greatbook/guides/audit-your-books)
* [Immutability and the hash chain](/greatbook/capabilities/immutability-and-hash-chain)