August 11, 2026. A document can be safely filed and still be invisible to an AI assistant. I have that problem in VALESKA, the document and organizational-memory system I am building: the earlier ingestion path mainly read plain text, while deposited PDFs could retain no extracted text. Ingestion means bringing material into the system. Filing the original is not the same as making its contents searchable.
People send the formats their work produces: contracts in PDF, spreadsheets, presentations, email, and scanned pages. Asking everybody to convert everything first moves the burden onto staff and creates another opportunity to lose the connection to the original. I want the system to attempt the documents as received and report what it could actually read. A loading dock is not much use if it only accepts parcels already opened upstairs.
Format support is the beginning
Today's extractor, the component that turns a file into text, adds routes for PDF, Office, OpenDocument, email, HTML web pages, and other formats. Different reading engines handle different files, with alternatives when one fails. The code can report which engines are available on the host and which one produced a result. A recognized file extension is therefore a coverage claim in code, not proof that every machine can read every such file correctly.
OCR, optical character recognition, attempts to recover words from pictures of text. It is reserved for PDFs whose text readers do not produce enough content, rather than replacing an existing text layer. Its page limit bounds the amount attempted, and a marker identifies truncation. These are operating limits, not a promise of complete or accurate recovery. A mixed document with readable text and scanned pages still needs checking for omitted material.
The commit records extraction from thirteen difficult PDFs into 2,948 chunks, the smaller text sections prepared for later search. It also reports a rasterized page recovered verbatim by OCR in 0.2 seconds. Those are encouraging, specific observations, not an accuracy benchmark across all supported formats, languages, tables, or damaged scans. A chunk count measures output volume; it does not tell me whether a contract clause was preserved correctly.
The accompanying tests include generated Office and email examples, rejection of a corrupt document container, and checks for blank PDFs and OCR behavior. Some require optional software and can be skipped. The recorded full-suite result is 517 passed and two skipped. I treat that as historical test evidence, not a fresh test run or a certificate that every business document will survive intact.
The people making the changes also need boundaries
This week also exposes a separate risk: several coding agents working around the same repository, the versioned collection of project files. A commit is a recorded set of changes. An agent can accidentally include somebody else's unfinished work in it, even when the commit description sounds harmless. The new guard compares selected files with a baseline, a record of what was already changed when the session began.
Later changes check task declarations for possible duplicate effort and warn against treating a working copy unreachable from one machine as abandoned. Today I also fix the baseline placement in a newly created worktree, an isolated working copy, and make the guard announce when it is inactive. The worktree fix records a successful end-to-end check in a disposable repository. That supports the fix in that scenario, not universal protection.
The limits matter. Without a baseline or the program needed to run its check, the hook warns but still permits the commit. Its selected-file filter does not cover deletions. Topic-overlap checks depend on recorded tasks and can be overridden. These measures reduce particular risks; they cannot guarantee that agents never duplicate work, delete files, or interfere with changes made after the baseline.
What I need to see next
For a company decision-maker, both threads ask the same question: does success mean the work was checked, or merely that no error stopped it? My next acceptance exercise is a representative document sample checked against the originals, alongside collaboration cases that show when the guard blocks and when it only warns. Broader input support and visible limitations are progress. They are not yet permission to stop looking.
Historical basis: VALESKA commits 2310a77, August 8; 40e3cc9, August 9; and 6c5b473, d37d040, 1cdc795, August 11, 2026. Dates use America/Los_Angeles.