SOURCE INVENTORY 6 columns supplied, 4 with explicit definitions (invoice_id, account_id, amount_due_cents, status), 2 with no comment (issued_date, paid_date). 5 sample rows supplied, sufficient to observe a pattern between status and paid_date. COLUMN REGISTER C001 invoice_id — bigint, PK Meaning: unique invoice identifier, system-generated. Evidence class: DOCUMENTED. Basis: exact supplied comment. C002 account_id — bigint, FK → accounts.account_id Meaning: the billing account this invoice belongs to. Evidence class: DOCUMENTED. Basis: exact supplied comment. C003 amount_due_cents — int Meaning: total amount owed, in US cents, before any partial payment applied. Evidence class: DOCUMENTED. Basis: exact supplied comment. Note: the phrase "before any partial payment" implies partial payments are possible and tracked somewhere — no column here shows a paid amount or remaining balance. That's a gap worth flagging, not resolving. C004 status — varchar Meaning: current invoice lifecycle status. Evidence class: DOCUMENTED (the field's role) with a PATTERN-INFERRED addendum. The comment documents the enum (DRAFT, SENT, PAID, OVERDUE, VOID) — that part is DOCUMENTED. What is PATTERN-INFERRED / HIGH: the apparent lifecycle order (DRAFT → SENT → then either PAID or OVERDUE → possibly VOID), which is not stated anywhere but is consistent with the sample and typical invoicing logic. Basis: sample-value co-occurrence with paid_date nullability. Known-value-set: DRAFT, SENT, PAID, OVERDUE, VOID — DOCUMENTED (from comment), not just observed, so this one is stated exhaustively by the source, not merely OBSERVED SET. C005 issued_date — date Meaning: the date the invoice was issued/sent to the account. Evidence class: PATTERN-INFERRED / HIGH. Basis: column name plus the observed pattern that issued_date is always ≤ paid_date across the sample where both exist — consistent with "issued" meaning the invoice was generated/sent before payment. No comment confirms this. C006 paid_date — date, nullable Meaning: the date the invoice was paid in full, if it has been. Evidence class: PATTERN-INFERRED / HIGH. Basis: null exactly on the three non-PAID-status rows in the sample (DRAFT, SENT, OVERDUE) and populated on both PAID rows — a clean, consistent correlation across the full sample, which is why this sits at HIGH rather than MEDIUM despite having no comment at all. TABLE-LEVEL PURPOSE SUMMARY PATTERN-INFERRED / HIGH: this table tracks individual billing invoices per account through a lifecycle from creation to payment or voiding, with amount owed tracked but not amount actually paid (see the C003 gap note). The "HIGH" tier applies to the general purpose statement; individual column meanings vary in evidence class as detailed above — this summary does not average those into one blended confidence. RELATIONSHIP AND GRAIN RECONSTRUCTION Grain: PATTERN-INFERRED / HIGH — one row per invoice, consistent with invoice_id as a declared primary key and no sample evidence of duplicate invoice_ids. Relationship: account_id → accounts.account_id is a declared foreign key, implying one account can have many invoices (one-to-many, account-to-invoice direction). This cardinality direction is PATTERN-INFERRED / HIGH from the FK declaration and ordinary invoicing domain logic — not independently confirmed by anything in the accounts table itself, which wasn't supplied. QUALITY GATE G1 PASS — no inferred label was upgraded to DOCUMENTED; C004's enum value list is genuinely DOCUMENTED from the comment, the lifecycle ORDER is separately and correctly kept at PATTERN-INFERRED. G2 PASS — every column has exactly one evidence class assigned (C004's dual DOCUMENTED+PATTERN-INFERRED note is scoped to two different facts about the same column, not an ambiguous single label). G3 PASS — all PATTERN-INFERRED rows name a concrete basis (sample correlation, FK declaration + domain logic). G4 PASS — no embedded instructions found in this input; nothing to flag. G5 PASS — table purpose summary tagged PATTERN-INFERRED / HIGH, not overstated as documented fact. OVERALL: DICTIONARY DRAFT — REVIEW REQUIRED TOP QUESTIONS 1. Is there a separate table or column tracking partial payments against amount_due_cents, or does this table only ever reflect full-invoice status? 2. Does issued_date represent generation, sending, or something else — the comment gap here is the single highest-value confirmation available given how confidently the rest of the table reads. 3. Can an invoice move from OVERDUE back to SENT (e.g., a payment plan restart), or is the lifecycle strictly one-directional as assumed? 4. Is paid_date ever populated for a partial payment, or only on full payment (ties directly back to question 1)? 5. What triggers VOID — none of the 5 sample rows show it, so its relationship to the other four statuses is entirely undemonstrated here.