Every file resolves to a status.
None resolves to silence.

A converter that cannot say what it did with every file will, sooner or later, drop your most important one without telling you. The manifest exists so that cannot happen quietly. Each file gets exactly one status, the status says what to do next, and the count is always of files — never of attempts.

The manifest is a plain table. Its columns are path, ext, route, status, bytes, chars, sha1, depth, top_folder and ingested. The sha1 is the file's fingerprint, and it makes a second run cheap: a file whose fingerprint has not changed is not read again. A run that stops resumes from the manifest and redoes nothing.

Both lanes read from it. The extraction lane writes a row for every file it meets; the OCR lane never walks the folder; it takes the rows tagged ocr-candidate as its worklist. A problem in one lane never blocks the other, and the expensive lane runs only over what needs it.

This is the whole list. Each status is a queryable worklist: group by this column and you have what is in, what is queued, what was set aside and why. Three exist because of a specific failure on the proving run, kept for the same reason the failures are published — a list with only ok on it would not be worth trusting.

Note what is not in the table: a status meaning "retrying". A failed extraction is terminal — it stays queryable, and is attempted again only inside a bounded re-sweep a person starts, never by the main loop. The next section is why.

On one run over the SIG tree the manifest reached 15,800 rows. Progress looked good. The unique files in it numbered about 4,400. The same files had been processed three and a half times over; the row count was measuring retries, not work.

Two bugs, compounding. The hidden lock stubs Office leaves beside an open document were picked up by the walk and failed, correctly, as unreadable. And resume treated every failed extraction as retryable, so every restart tried every failed file again, and each failure got another row. The fix, now the rule: the walk filters junk before it reaches a reader, and resume marks every path already in the manifest as done. Progress is measured in unique files. A row count can balloon while real coverage stands still.

A second lesson from the same period. A hard kill landed mid-append and left a truncated row; every restart read it, found no status, and died at the resume step until the reader was taught to skip a row with no path. The rule is now one writer per manifest and every row committed whole. A hard kill must never be able to poison resume.

A manifest can only account for the files the walk was shown. It cannot know about a file the storage layer hid, and it will faithfully record one the storage layer invented. On the proving run a storage layer reported files it did not hold — offloaded to a cloud drive, still in the listing. The reader opened what was not there, failed or hung, and quarantined them: 87% of the files in one region, none of them bad. The record puts it in these words: "the storage layer will lie to you before the file formats do." The skipped:<ErrorType> status exists so a file the disk does not hold is reported as absent, not corrupt; 962 files in the proving corpus are stuck that way today and reported that way.