When the layout is prescribed by regulation, addressing beats inferring

A dev.to writeup on pulling structured fields out of a mortgage Closing Disclosure argues that this is the document where inferring structure is strictly worse than reading it off the specification, because the form's layout is prescribed by regulation and every section carries a letter you can address it by ^[1]. That is a design rule rather than a preference, and it tells you when to stop reaching for a model and go read an appendix. The appendix exists. According to the post, the Closing Disclosure was introduced by the Consumer Financial Protection Bureau under the integrated mortgage disclosure rules, and the form is published as a model form in the appendices to Regulation Z ^[2]; the CFPB also maintains the TILA-RESPA integrated disclosure resources, including annotated forms and completed samples, which the author treats as authority for any field question ^[3]. Closing cost details are grouped under letters: origination charges, services the borrower did not shop for, services the borrower did shop for and their total, then taxes and government fees, prepaids, initial escrow, other and their total, then overall total closing costs ^[4]. Those letters print on the page and are stable across lenders, across settlement software, and across every copy of the form ^[5]. So the instruction is not "find the appraisal fee" but "return the line items under each lettered section, in order, with the section letter attached" ^[6]. The payoff is threefold. A fee found by name has no context, because the same fee name can appear in two sections on one form and the section is what determines its regulatory treatment ^[7]. A fee found under a letter can be checked, because the section prints a subtotal its items must sum to ^[8]. And an empty section becomes detectable: "no items under this letter" is a fact, while "I did not find anything" is not ^[9]. The section letters are not where naive extraction actually dies ^[10]. It dies on the columns. A single line item can be paid by the borrower at closing, by the borrower before closing, by the seller at closing, by the seller before closing, or by someone else, and the form provides a column for each ^[11]. A schema with one amount field per line cannot represent that, so the extractor returns the first number it finds and the record asserts that the borrower paid the 1,240.00 owner's title policy the seller paid, and the 650.00 appraisal a lender credit covered ^[12]. Nothing foots afterwards, and because the totals are extracted rather than derived, the mismatch is invisible unless somebody checks ^[13]. The recommended shape is a column-keyed amount map plus a separate marker field for the letter annotating paid-by-others entries; a value read as "L 650.00" and stripped to 650.00 loses the only thing distinguishing a lender credit from a third-party payment ^[14][15]. Column-keyed amounts make the form self-checking: loan costs are the sum of three sections, other costs the sum of four, total closing costs the sum of those two, with lender credits on their own line ^[16]. On the post's synthetic disclosure, the borrower-at-closing column shows A 2,100.00, B 1,050.00 and C 1,830.00 ^[17], so a loan-cost total that is not 4,980.00 is a defect no human needs to spot ^[18]. The rule has a boundary, and the same author draws it. Where structure is not fixed, designing a schema before you have seen every variant is the harder problem ^[19]. Companion posts sit on that side: for trial protocols, the SPIRIT statement lists eligibility criteria as its own item and ICH good clinical practice sets out protocol contents, but neither prescribes a machine-readable format ^[20]; in clinical notes, the vitals label set varies by institution, with temperature as T or Temp and saturation as SpO2, O2 sat or Sat ^[21].