% Generated by code/make_tables.py from results/ledger/log\_summary.json, throughput.json, backfill\_block.json, resume\_batch1\_vs\_expected.csv. Do not edit by hand.
\begin{table}[H]
\centering\footnotesize
\caption{Reconciliation of the October 2026 extraction outage: log, ledger and the suspect post-resume batch}\label{tab:outage}
\begin{threeparttable}
\begin{tabular}{p{9.3cm}r}
\toprule
Quantity & Value \\
\midrule
\multicolumn{2}{l}{\itshape Panel A: rows removed from the ledger after the credit-exhaustion outage (research log: 149{,}352)} \\
Sections reported complete by the October log, all batches ($\sum$ ``Extraction complete'') & 1{,}117{,}479 \\
Sections pending at the second start of the run & 968{,}127 \\
Difference = sections ledgered during the outage and re-submitted & 149{,}352 \\
Ledger rows with a timestamp inside the largest gap (01:25--06:40, 5.25~h) & 0 \\
Log batches returning zero mentions inside the outage window (batch ids 47--60) & 14 \\
\midrule
\multicolumn{2}{l}{\itshape Panel B: failed-call lines in the October log (94{,}609 lines; the ledger records none of them)} \\
Retryable HTTP 429/5xx, all lines & 94{,}593 \\
\quad of which inside the outage window 01:10--06:22 & 94{,}465 \\
\quad of which in the twenty seconds after it (to 06:22:21, the end of the log window) & 128 \\
Connection resets & 2 \\
JSON-decode failures outside the outage (ledgered as ``no project'': silent empty results) & 14 \\
``Section failed'' lines & 0 \\
JSON-decode failures in the June log (of 153{,}894 sections) & 3 \\
\midrule
\multicolumn{2}{l}{\itshape Panel C: first batch after the resume (06:38--06:40, 19 issuers)} \\
Sections in the batch (log) / ledgered rows & 5{,}198 / 4{,}769 \\
Mentions returned (log) / ledgered & 34 / 30 \\
Gate-passing calls & 2{,}686 \\
Productive sections observed & 23 \\
Productive sections expected at the form $\times$ item rates of the rest of the run & 536.2 \\
Failed-call lines logged inside the batch window & 0 \\
\bottomrule
\end{tabular}
\begin{tablenotes}\footnotesize
\item Panel A reconciles the research log's figure with the run log and the ledger timestamps; the ledger stamps every row individually (968{,}134 distinct timestamps), so the per-flush test proposed at review is replaced by per-minute and per-batch productivity tests (\texttt{results/ledger/}). Panel B classifies the ``LLM call failed'' lines of the log by reason; a JSON-decode failure returns an empty list that the ledger records as zero mentions, indistinguishable from ``no project''. Panel C: the first batch after the resume returned 23 productive sections where 536 were expected, with no failure logged, which is consistent with HTTP-200 empty answers while the quota was being restored; only a re-submission of its gate-passing sections (authorisation request AR-LLM-4, not granted in this revision) can separate ``no project'' from ``empty answer''. Expected counts apply the productive share of each form $\times$ item outside the batch to the batch's calls.
\end{tablenotes}
\end{threeparttable}
\end{table}