Protocol extraction dies in the schedule-of-activities table, and the ways it dies are mechanical

A writeup on dev.to about extracting dosing schedules from a clinical trial protocol makes a narrow, checkable claim: the schedule of activities is the densest page in the document, a matrix with visits across the top, procedures down the side, and an X wherever the two intersect ^[1]. It matters because, according to that writeup, this is the only table in a protocol where the column headers are the data ^[3], which means the usual table-to-JSON reflex loses the payload rather than mangling it. Failure one is physical. The table is wider than the page, so it appears in landscape, split across two facing pages, or continued with the row labels repeated ^[4]. A continuation whose row labels repeat but whose column headers are new reads as a second table; the underlying problem is column misalignment across pages ^[5]. You end up with two objects where the protocol has one, and the second inherits no phase context. Failure two is the header itself. It is two rows deep: a top row grouping columns into Screening, Treatment and Follow-up, a second row carrying the actual visit numbers, so a parser reading one row gets either the phases or the visits but never the mapping between them ^[6]. Because the cells are usually a bare X, the information content is entirely positional and a value means nothing without both its row label and its column header ^[7]. The writeup's recommendation is a flat list of cells, visit identifier plus procedure plus present or absent plus footnote marker, rather than a nested object ^[8]. Footnotes earn their slot: a superscript letter frequently reads "only if clinically indicated" or "cycle 1 only", converting an instruction into a conditional, and the footnote text sits several hundred characters below the grid ^[9]. Failure three is the arithmetic, and it has one predictable error. There is no Day 0. Day 1 is the first day of the cycle and the day of the first dose, the day before is Day -1, and code treating cycle day as a zero-based offset is one day out on every calculation it performs ^[14]. In the sample table, treatment runs in 21-day cycles with visits on days 1, 8 and 15 ^[15], so C2D1 is study day 22 ^[22]; the off-by-one produces 21 ^[23]. The gap from C1D15 to C2D1 is seven days, matching the within-cycle spacing ^[24]. Windows then widen it: C2D1 carries a plus or minus three day window ^[15], so day 22 may legitimately occur anywhere from day 19 to day 25 ^[12], meaning the earliest permitted cycle 2 visit lands with three days of nominal cycle 1 still to run ^[25]. Some columns resolve to no day at all. EOT, EOS and FU are event-anchored: end of treatment is thirty days after the last dose, whenever that falls, so no absolute day can be computed ^[13]. And the schedule only tells you when. The dose lives in the treatment section in three incompatible forms ^[16]: flat, which extracts to a number ^[17]; per kilogram, a function of a measurement taken at a specified visit ^[18]; and per square metre, which depends on which named body-surface-area formula the protocol picked, because they do not agree with each other ^[19]. For the latter two the correct output is a dose_basis, a coefficient, a unit, and a reference to the input measurement, since emitting a number would require a patient and there is no patient at extraction time ^[20]. Caps and rounding-to-vial-size rules sit in prose beside the formula, not in the table ^[21]. The cheap regression test is a count. The sample header names seven visits across Screening, Treatment and EOT groups ^[15] over five procedure rows ^[27], which is 35 grid positions ^[26].