spb/firc0001_uqo

1% 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.2\begin{table}[H]3\centering\footnotesize4\caption{Reconciliation of the October 2026 extraction outage: log, ledger and the suspect post-resume batch}\label{tab:outage}5\begin{threeparttable}6\begin{tabular}{p{9.3cm}r}7\toprule8Quantity & Value \\9\midrule10\multicolumn{2}{l}{\itshape Panel A: rows removed from the ledger after the credit-exhaustion outage (research log: 149{,}352)} \\11Sections reported complete by the October log, all batches ($\sum$ ``Extraction complete'') & 1{,}117{,}479 \\12Sections pending at the second start of the run & 968{,}127 \\13Difference = sections ledgered during the outage and re-submitted & 149{,}352 \\14Ledger rows with a timestamp inside the largest gap (01:25--06:40, 5.25~h) & 0 \\15Log batches returning zero mentions inside the outage window (batch ids 47--60) & 14 \\16\midrule17\multicolumn{2}{l}{\itshape Panel B: failed-call lines in the October log (94{,}609 lines; the ledger records none of them)} \\18Retryable HTTP 429/5xx inside the outage window 01:10--06:22 & 94{,}593 \\19Retryable HTTP 429/5xx in the outage tail (first ledger window definition, 20 s after the log window) & 128 \\20Connection resets & 2 \\21JSON-decode failures outside the outage (ledgered as ``no project'': silent empty results) & 14 \\22``Section failed'' lines & 0 \\23JSON-decode failures in the June log (of 153{,}894 sections) & 3 \\24\midrule25\multicolumn{2}{l}{\itshape Panel C: first batch after the resume (06:38--06:40, 19 issuers)} \\26Sections in the batch (log) / ledgered rows & 5{,}198 / 4{,}769 \\27Gate-passing calls & 2{,}686 \\28Productive sections observed & 23 \\29Productive sections expected at the form $\times$ item rates of the rest of the run & 536.2 \\30Failed-call lines logged inside the batch window & 0 \\31\bottomrule32\end{tabular}33\begin{tablenotes}\footnotesize34\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.35\end{tablenotes}36\end{threeparttable}37\end{table}38