Three things a PDF cannot do
Put a scanned document into a text-based vault and it lands like a stone. It's stored, it's safe, and it's inert.
It can't be searched — the words are pixels, not text. It can't be queried — there's no "all invoices over €500 from this supplier in Q2," because there are no fields, just a picture of a page. And the one almost nobody names: it can't be linked. You cannot put [[wikilinks]] inside a PDF. It has no way to point at anything else in your system, and nothing about it points back.
The first two are inconveniences. The third is what makes the document an island. A vault's value comes from things being connected; a file that structurally cannot connect is outside the system even while sitting inside the folder.
The sidecar pattern solves all three with one move, and it's almost embarrassingly simple: put a markdown note next to the binary. The PDF stays the untouchable original. The markdown becomes the thing the vault actually works with.
What one actually looks like
Not hypothetically. This is a real note from my vault — the RDW clearance certificate for a caravan my company sold in July:
---
title: Vrijwaringsbewijs caravan WE-56-00 (RDW)
date: 2026-07-02
type: scan
domain: business
entity: Consilium Information Systems B.V.
kenteken: WE-56-00
document: vrijwaringsbewijs
issuer: RDW
visibility: private
related: "[[transaction_caravan-verkoop-daniel-wouters]]"
---Below the frontmatter: the key data pulled out as a small table (registration, transaction code, timestamp, issuer), the operative sentence from the document quoted in full, and links to the sale transaction and the purchase agreement.
Now look at what that gives me that the PDF alone never could.
It's searchable — the text lives in the markdown, so ordinary search finds it. No PDF indexer required.
It's queryable — kenteken, issuer, document, entity are fields. "Every RDW document for this company" is a query, not a rummage.
It's connected — related: points at the sale transaction. The chain from sold the caravan to here's the proof of transfer is walkable in both directions.
It's governed — visibility: private is the same gate every other note uses. The document became a first-class citizen of the system the moment it had a sidecar.
None of that lives in the PDF. All of it lives beside it.
This is not a proposal
Worth being plain: I'm describing what's already running, not sketching an idea. There are 14,774 scanned PDFs in my vault, about 23 GB, and the wrapper-beside-the-scan convention has been the filing rule for years. Every receipt, contract, and official letter that matters arrives, gets OCR'd, gets a wrapper, and gets filed in the day-folder it belongs to.
The pattern earned its name late. It ran for a long time as "that's just how I file scans" before it was worth calling anything.
Where the real upgrade is
The searchability is nice. The structured query is the categorical change, and it's easy to undersell.
Full-text search over documents — even good search — only ever answers "which documents contain these words." That's a fundamentally different question from "which documents have these properties." Google Drive could search my receipts; it could never tell me total spend per category per quarter, because it had text and no fields.
Sidecar frontmatter turns a pile of documents into a dataset. And the fields aren't decoration — they're a small type system. A receipt carries amount, VAT, category, supplier, date. A contract carries party, start date, term. A scan of an official letter carries issuer and document type. Consistency per type is what makes queries trustworthy; inconsistent fields produce silent gaps, which are worse than missing data because they look like answers.
That's data modelling, applied to your own paperwork. For anyone who models data professionally, it's home ground — the same discipline, minus the stakeholders.
One source, two kinds of sidecar
A source doesn't get exactly one companion, and the distinction between the kinds is worth keeping sharp.
A representation stands for the source: derived, regenerable, mechanical, one-to-one. OCR text plus extracted fields. If you lost it you could remake it from the original.
A distillate is your thought about the source: a summary in your own words, an argument you extracted, a note that stands on its own. Not regenerable — nobody can reconstruct your thinking from the PDF.
Keep them typed differently and, ideally, filed separately. The moment "what the document says" blurs into "what I concluded," you've lost the ability to trust either one. A scanned book might carry one bibliographic representation and twenty idea-notes; those twenty are a different species and belong in the part of the system that handles your own thinking.
Frontmatter is a latent table
Every sidecar of the same type shares the same fields. Same fields across many notes is a table: each field a column, each note a row.
Which means the sidecars can be exported to a database — and the export doesn't impose structure, it surfaces structure that was already there. The markdown was a table all along; the database just makes it queryable in a form markdown handles badly.
One rule keeps this honest: the direction of truth is markdown → database, one-way. The files are the source. The database is a derived, regenerable view you rebuild when you want to ask something, and never edit back. Break that rule and you now have two sources of truth and no way to tell which one is lying.
The naming detail that decides whether it survives
Two ways to bind a sidecar to its source: convention (receipt-2026-03.pdf ↔ receipt-2026-03.md) or an explicit source: field in the frontmatter.
Use the field. Convention breaks the first time someone renames a file, and it breaks silently. An explicit pointer survives renaming and — more usefully — makes the relationship queryable: you can ask which sources lack sidecars, which is exactly the audit you'll want once you have a few thousand of these.
And a caveat that costs nothing to state and a lot to discover: the sidecar is only as good as the extraction that filled it. Clean digital PDFs are trivial. Photographed receipts at an angle in bad light are the weak link. A low-confidence extraction is a low-confidence search result, and it will fail you quietly rather than loudly.
A note on the word
If you've used a photo DAM, you've met sidecars already — XMP files carrying ratings and tags beside a RAW image. Same instinct, narrower mechanism: XMP is a fixed metadata standard for image tools.
What's described here is the general case. Any binary, any document type, arbitrary fields you define, plus the two things XMP was never for: extracted body text, and links into the rest of your knowledge.
Why this is the same move as a folder note
A folder can't describe itself. A PDF can't link to anything. In both cases the answer is identical — put a markdown file beside the thing that can't speak, and let it speak on the thing's behalf.
That's the whole pattern, and it generalizes further than documents. Anything in your system that can't carry structure, can't carry links, or can't carry text gets a small markdown companion that can. The heavy original stays exactly as it is, authoritative and untouched. The lightweight note beside it does all the work of being part of a system.
The PDF is still the record. The sidecar is what makes it yours.
Part of the Structure Beats Magic series. Pairs with Everything Is a Folder on self-contained units, and Your Database Is a View on why the files stay the source of truth.