For twenty-odd years my job has been data modelling: deciding what the entities are, how they relate, at what grain the facts live, which dimensions you slice them by. It sounds abstract until it isn't — until a wrong entity quietly corrupts a decade of reporting and everyone wonders why the numbers never quite reconcile.
This month I've been doing something that looks nothing like that job. I've been feeding my own photos and scanned receipts into a calendar — tens of thousands of images, years of paper. And somewhere around the third evening I realised I wasn't tidying. I was building an information architecture, making exactly the decisions I make for a living, on the most familiar dataset I'll ever own.
The calendar is a star schema
Look at what the structure actually is, once you stop calling it "folders."
The calendar spine — year, quarter, month, week, day — is a date dimension. Every serious warehouse has one; here it's the backbone of the whole thing. A photo has a timestamp and a location, so it's a fact: a measured event, dropped onto the date dimension at day grain. The activity folders that cluster a day's photos by place — "the market," "the restaurant," "the overlook" — are a location dimension, resolved from GPS the way you'd conform a dimension from a messy source. And the little YAML file beside each photo, holding its metadata and its meaning, is the fact row made durable and queryable.
I didn't set out to build a star schema for my holidays. But attention keeps converging on the same shape, because the shape is what the problem is. When you have events with a time, a place, and some measures, and you want to ask questions across them, you get a fact table on conformed dimensions — whether the events are sales orders or Sunday afternoons.
The structures that run enterprises aren't enterprise structures. They're the structures that fit the problem. Your life has the same problem, so it wants the same structures.
Every hard call was a modelling call
The moments where I got stuck were never about software. They were the classic modelling questions, in disguise.
When a scanned receipt refused to sit still — dinner bill or phone invoice? — that was an entity question: same shape, different meaning, so different tables. When a purchase invoice wanted to live next to the day I bought the thing, that was grain: a moment belongs to a day, a standing agreement belongs to a year. When photos from a place with no GPS still needed a name, that was conformance: reach for a second source — the location timeline — and reconcile. Every one of these has a boardroom equivalent that costs six figures when you get it wrong.
And the failure modes rhymed too. A file dropped into the wrong folder is a row loaded against the wrong key. A receipt smeared across twelve billing dates is a slowly-changing dimension nobody designed. The archive rots for exactly the reasons a data platform rots: not too little data, but meaning filed against the wrong structure, compounding quietly until no query can find the truth.
Why doing it on your own life is the unfair advantage
Here's what the enterprise version never gives you: ground truth you can feel. When I model a client's domain, I'm modelling their understanding of their business — I'm one interview removed from the thing itself. When I model my own life, I am the domain expert. I know the purchase was a purchase and the subscription was a subscription, because I was there. The sample landscape isn't a sanitised extract; it's the messiest, most honest dataset I have access to, and I can check every modelling decision against a memory instead of a stakeholder.
That's why I keep saying the personal work isn't a hobby beside the profession. It's the profession with the training wheels off — a place to feel, at human scale and with instant feedback, the same judgement calls that are invisible and expensive at enterprise scale. The stakes are a shoebox instead of a company, but the discipline is identical, and the feedback loop is a hundred times tighter.
The move you can steal
You don't have to be a modeller to use this. You have to notice that you're already doing it, and start doing it on purpose.
- Name your entities. Before you decide where something goes, decide what it is. A photo, a receipt, an agreement, a purchase — different things, different homes. Most filing mistakes are entity mistakes.
- Pick the grain honestly. Does this belong to a day, a month, a year, or a relationship? Filing at the wrong grain is the quietest, most expensive error there is.
- Conform your dimensions. "Rotterdam" and "Rotterdam, Netherlands" are the same place; make them the same value once, and everything downstream lines up.
- Then, and only then, worry about tools. The database, the app, the AI — those are downstream of the model. Get the entities and the grain right and the plumbing is easy. Get them wrong and no tool will save you.
Structure was always the work
The magic people chase — the AI that finds anything, the system that runs itself — is all downstream of one unglamorous act: deciding what things are and where they belong. That's data modelling. It's what builds an information architecture worth pointing an AI at, and it's what turns a pile of images into something you can actually ask questions of.
You've been doing it every time you moved a file with a small nagging sense that it mattered where it went. That instinct was right. It's not tidying. It's modelling — and your own life is the best classroom the craft will ever hand you.