​

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 and Typewriter to journal entry. 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/<prefix>/<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.