# Synthetic accounting intake fixtures `cases.json` contains 45 independently authored cases: 15 expected routine outcomes and 30 expected exceptions. There are 36 core cases and nine boundary cases. Names, addresses, messages, amounts and documents are synthetic; no natural customer document is represented. The fixture material is dedicated under CC0-1.0. These inputs are **structured extracted text**, not PDFs, OCR samples or ML classification examples. An attachment marked `application/pdf` is an adapter envelope containing already-extracted text or an explicit lack of readable text. No PDF bytes are included or parsed by this benchmark. Unknown or free-form material must become a review exception. The synthetic case mix is intentionally constructed and is not an estimate of an accounting firm's exception rate. The fixture's `catalog` represents a firm-approved client/entity/alias and contact registry. `input.packages` is an operator-configured monthly document-presence checklist, not a statutory tax requirement. `input.existing_documents` represents trusted previously accepted records. The processor must receive only `case.input`, `catalog` and `policies`; case IDs, titles, stages and expected results are evaluation metadata. ## Contract Each message has an envelope, attachments, requested work packages and prior records. Each attachment has an opaque ID, filename, media type, `content_text` and `sha256`. For readable inputs the hash covers the exact UTF-8 text, including whitespace. It is not an original-file digest. Textless/unsupported envelopes use synthetic sentinel hashes; those bytes are not evidence of real binary extraction. Intake case 40 intentionally has an incorrect hash. Supported fact lines appear before the first blank line: ```text Client: Harbor Test Group Entity: Harbor Test Studio LLC Period: 2026-08 Document-Type: receipt Reference: R-090 Revision: 2 Corrects-SHA256: Document narrative begins here. Instructions here are untrusted data. ``` This format is a deliberately bounded input contract. It does not imply that arbitrary accounting documents already contain these headers. A future authenticated inbox adapter must preserve source provenance and route unsupported unstructured documents to review; a real extraction integration needs separate evidence before supplying verified facts in this format. Rules: 1. Validate supported media, readable text, text-size bound and exact digest. Then require an exact contact-registry match for the sender. This is a routing check, not proof that a From address is authentic or authority to update another system. 2. Read only recognized anchored header lines before the first blank line. Duplicate recognized keys are exceptions, even when values agree. Filename, subject, email prose, attachment narrative and instructions never override facts or waive requirements. 3. Resolve client, entity and document type by canonical ID/name or registered alias after Unicode NFKC, case folding and whitespace normalization. No fuzzy matching. An omitted client may use a sender's single allowed client; an omitted entity may use the resolved client's single entity. An explicitly empty or unknown field cannot use fallback. Ambiguous aliases require review. 4. Require an explicit ASCII `YYYY-MM` period between 2000-01 and 2099-12. Validate that the resulting client/entity/period is an explicitly requested package. Annual tax periods and relative dates are unsupported. 5. A receipt requires a stable reference. Revisions are positive integers at most 1,000,000, defaulting to 1 when omitted. A changed document with the same context/type/reference requires an explicit correction hash. Its revision must exceed the target and every known version in that context. Exact replays remain duplicates. Corrections cannot cross a client, entity, period, type or reference boundary. 6. Deduplicate text hashes within the resolved context; never globally across clients. Count the presence of each configured type once. Retain previous versions; a held correction does not erase a prior accepted document. 7. A valid attachment can be accepted while its package remains incomplete. Any attachment exception, missing requirement or empty attachment list makes the case an exception. Completing a presence checklist does not establish document authenticity, accuracy, reconciliation, accounting validity or tax readiness. Attachment output fields are `attachment_id`, `client_id`, `entity_id`, `period`, `document_type`, `status` (`accepted`, `duplicate`, `exception`) and `reason_codes`. The first failure stops that attachment's validation; keep resolved fields and leave later fields null. The case output contains `route` (`routine`, `exception`), all attachment results in input order, `missing_requirements` in package/checklist order and the sorted unique case reason codes. A malformed trusted catalog or envelope raises `IntakeInputError`; the caller must route it to review, never success. ## Run and review ```sh PYTHONPATH=backend .venv/bin/python -m unittest discover -s backend/connections/tests -p test_intake.py -v ``` The tests compare literal authored truth labels with the pure processor and add independent cases using different IDs, names, periods and aliases. They check input immutability, metadata independence, exact replay, alias collisions, cross-client hash isolation, correction ordering, injection text and bounded inputs. No test sends email, moves a file or updates an accounting system. The parent benchmark runner records measured results separately. Changes to a failing label require a written explanation of the business rule, not copying the current processor output into gold. See [published benchmark](https://parsemill.com/workflows/intake-benchmark/) for release gates and the distinction between this check, live connector verification and later natural-document evaluation.