Your data warehouse is your second brain
A warehouse and a personal knowledge system are the same architecture — source → integration → delivery. Twenty-five years of data discipline, turned inward. Built, running, daily.
Read the thinking →Ideas
A working showcase of concrete, original thinking at the edge of data, structure and AI — drawn from 230+ published articles and the systems behind them. Most of these I’ve already built or am building. Proof, not a manifesto.
A warehouse and a personal knowledge system are the same architecture — source → integration → delivery. Twenty-five years of data discipline, turned inward. Built, running, daily.
Read the thinking →Rules generate; validation rules check the output against what’s known; on a mismatch it flags, never guesses — and the checks improve themselves. Data quality, applied to AI output.
See how it works →When structure carries the context, the meeting shrinks to judgement. People arrive prepared; plans and retros are generated and validated underneath. A new operating model for data teams.
Explore the model →Stop buying a tool and bending the team to it. Build the foundation — structure, rules, validated data — and let AI generate the tools you need on top. The foundation is the asset.
Why this matters →Years of structuring knowledge in markdown and Obsidian wasn’t about AI — but those same files are now where information is structured for the model. Data architecture and personal knowledge management converge on one truth: structure makes intelligence reliable.
Read the convergence →A team let AI refactor an integration model — it dropped a “redundant” join, all tests passed, and two weeks later regulatory reporting failed. That join was there for lineage, not data. AI isn’t the risk; invisible architecture is. Encode your constraints, don’t document them.
Read on LinkedIn →The BIRD benchmark shows well-structured schemas let modern LLMs hit ~95% SQL accuracy — from good modeling alone, no extra AI layer. Clean names, shallow joins, clear relationships help AI as much as analysts.
Read on Medium →Analyst builds logic in a notebook; engineer rewrites it as SQL; governance reviews weeks later. That rewrite is where context, assumptions and correctness leak. What if the notebook produced the final SQL?
Read on Medium →The model is brilliant at describing a system and useless at deciding what should exist. The invention — the judgement about what to build — stays human.
Read on Medium →Most data-team org charts are inherited, not designed. The set of roles that hold up when structure and AI carry the routine work — fewer people coordinating, more people deciding.
Read on Medium →When the foundation is structured, the platform isn’t a product you buy — it’s something you generate, customised to your purpose, on top of what you already own.
Read on Medium →Reliability shouldn’t be a gate at the end of the pipeline. Make it a service the whole supply chain consumes upstream — the validation loop, applied to a platform.
Read on Medium →The architect’s job stops being “hand down the model” and becomes “enable the engineers.” In the age of AI, the value is in unblocking people, not guarding the diagram.
Read on Medium →As AI absorbs the mechanical work, the architect’s real product becomes structured knowledge — the rules, context and meaning the machine reasons over. The role moves up a layer.
Read on Medium →Clean metadata beats an AI wrapper. If the model carries the meaning, you don’t need a bolt-on layer to explain your data to the machine — the structure already does it.
Read on Medium →What it looks like when the AI reads and writes the same files you do — no intermediate format, no copy-paste. A practical account of building real tools this way.
Read on Medium →These are a few from a much larger body of work — 230+ published articles on data architecture, metadata-driven engineering, and AI, followed by 980+ readers on Medium. More on where to read →
That’s the whole point. Let’s talk about what you’re building.
Start a conversation