Attached file we could not open
A disclosure that the PDF carries an attached file whose bytes this engine could not analyse, so its contents were not examined.
How the text is hidden
A PDF can carry whole other files. /Names /EmbeddedFiles is a name tree of file specifications, and a FileAttachment annotation points at one from a page; the attachment is invisible in the page view unless the reader opens the attachments pane. Where the bytes are a format this engine parses, the attachment is analysed and its findings are reported with the attachment named in the location. Where they are not, this disclosure is what says so.
Why a model still reads it
Reported as presence, never as suspicion — PDF/A-3 hybrid invoices embed a payload in every file by design. And it is a coverage statement rather than a live injection route: the code records that pdftotext, pdf.js and the common loaders ignore attachments, while pypdf can enumerate but does not read them during text extraction. What it is, is bytes inside the document nobody read and nobody mentioned.
What we do about it
pdfAttachments resolves both carriers — the document-level name tree and FileAttachment annotations — de-duplicating by filename, then decodes each /EF stream. Anything whose bytes could not be decoded, whose decoded bytes this engine could not parse as a document (the common case, and correctly so — a print-settings file is not a document), or that hit the nesting limit is collected; pdfEmbeddedFindings emits one disclosure finding at informational, action disclosed, chars: 0, naming each unopened file and the reason.
How often it fires
Not measured. We publish a rate only where one has been measured against a named corpus of the right format, and no figure exists for this technique yet. Absence means unknown — never low.
Check your own file
Three commands: a key, credit, a verdict.
Start with the API