> ## 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. # Technical flows and authority > Where a GreatBook document lives as evidence, structured intake, approved work and a posted accounting fact. # Technical flows and authority A document does not move as one mutable file through GreatBook. It becomes a sequence of linked artifacts, and each artifact has one location and one job. The two end-to-end traces are [upload to journal entry](/greatbook/technical/upload-to-ledger) and [Typewriter to journal entry](/greatbook/technical/typewriter-to-ledger). This page names the authority at each stage so that retrieval, mapping and mirrors are not mistaken for accounting stores. ## The three document artifacts **The original artifact is the exact uploaded byte sequence in the private `documents` object-storage bucket at `raw-intake/sha256//`.** Its job is evidence: the digest is its content identity, and `file_uploads.source_storage_reference` plus `file_uploads.source_sha256` record the exact object and digest in Postgres. The original filename is metadata, not identity, and neither Cognee, Teable nor Drive is a second original-byte store. **The structured artifact is `intake_queue.payload`, a JSONB column in Postgres.** Its job is to hold the Clerk's extracted `fields`, `lines`, projected master-data `resolutions` and source provenance while a human decides whether to accept the document. It is not a journal entry, and an unflagged payload is not an approved accounting fact. **The accounting artifact is one posted row in `journal_entries` with its `journal_entry_lines` and `event_stream` event in Postgres.** Its job is the immutable accounting fact. Only `LedgerService.post_entry` creates it, after a separate posting checker approves the Bookkeeper's proposal and all 18 GL invariants pass. No canonical raw Markdown version of the parsed document exists. When the Clerk raw-intake retrieval store is configured, it can publish a `.txt` retrieval document to Cognee containing extracted text plus the storage reference and SHA-256. That text helps retrieval; it is not the original evidence, the accepted structured payload or an accounting fact, and the upload path can proceed without treating it as any of those things. ## What the other systems are for **Teable holds master data that the Clerk and Bookkeeper read to resolve names and codes, such as counterparties and accounts.** Its job in this flow is mapping. The parsed document does not land in Teable, the Clerk does not create a missing master, and only document types with a bound master table receive that resolution pass. **Git holds the reviewed SOP and skill source.** Its job is operational authority for agent knowledge, identified by commit, path and SHA-256. The runtime reads the rendered manifest through the deterministic in-process SOP index; it does not use a remote retrieval service for procedures. **Cognee is optional derived raw-intake storage only.** When configured, its separate Clerk-only dataset can receive extracted customer-document text with source lineage. It is not the SOP runtime and cannot approve intake, mint a posting mandate or write the ledger. **Drive is an output-only human mirror.** Its job is convenient human browsing of rendered knowledge and governed upload placements. It is not read back as document or accounting authority, and this documentation does not claim that OAuth or an external connector is activated. ## The human gates The **document approval gate** applies to Typewriter output. It signs the stored PDF's exact hash and refuses the author, an undesignated approver, a superseded version or bytes whose current hash differs from the saved hash. It does not approve intake and it does not post. The **intake approval gate** applies to both uploaded and Typewriter documents. It accepts the structured `intake_queue` row for accounting work and refuses a submitter, drafter or resubmitting editor who tries to approve their own work. Approval moves the row to `active` and atomically records an `intake_launch_outbox` job; it still does not create a journal entry. The **posting approval gate** applies to the Bookkeeper's balanced proposal. It refuses every maker on the record, including the intake approver, and refuses an agent identity as checker. The server signs the organization, source record, checker and verdict into a posting mandate; the checkpoint itself “decides nothing,” as the Bookkeeper source puts it. For an uploaded document, the minimum successful chain therefore has three distinct authenticated people: submitter, intake approver and posting checker. For a Typewriter document, the author also cannot sign the document, so the ordinary chain has four distinct people: author, document approver, intake approver and posting checker. ## Evidence boundary These flows were rechecked against backend `3c17397e120e91bda33d4bbb55d8963d82a17ba7` and web `057bc2f535bd1d9e55f3244acf301f6fae8e8d08`. The backend flow after an authorized Clerk attachment and the Typewriter service flow are traceable in source. The current web source carries the backend-minted `upload_authority` through upload storage and Clerk attachment metadata; the browser neither mints nor decodes it. The Typewriter and upload handoff contracts are present in source, but neither complete workflow was exercised end to end for this documentation cut. ## Verified at source The authority contract is in `docs/contracts/greatbook-knowledge-pipeline.md`; raw evidence handling is in `langgraph_chat/agents/clerk/raw_intake.py` and `uploads/drive_mirror.py`; intake authority is in `agents/clerk/queue.py` and `devcenter/intake_service.py`; and ledger authority is in `agents/bookkeeper/ledger_bridge.py` and `backend/app/services/ledger_service.py`.