Thinking
How I think.
The frameworks behind the work.
These frameworks came out of real work in real organizations: watching well-designed projects fail because the structure was wrong, and working out why the ones that succeeded actually did.
Original Methodology · Copyright and Patent in Progress
Stateless Content Architecture (SCA)
SCA is a proprietary modular information design methodology for structuring organizational knowledge as typed, role-addressable fragments. The core insight: every domain holder (engineers, product teams, operations leaders) possesses some types of information and is structurally missing others. Engineers have procedure and sequence but not policy. Product has policy and process but not procedure. Leaders have intent but not mechanics.
Traditional documentation blends these together into monolithic documents that serve no audience well. SCA treats information as modular, typed, independently governed units. Policy lives separately from procedure. Procedure lives separately from process. Each unit is complete in itself. The same underlying content can be delivered to an operations user, a developer, an executive, or an AI retrieval system, and each one gets exactly what they need in the form they can use.
This is also the architecture enterprise AI systems require to retrieve information cleanly. Most RAG implementations underperform not because of the model, but because the knowledge layer feeding them was never structured this way. SCA solves that problem at the source.
Original framework developed 2016 to present. The full technical reference (28 sections covering content typing, taxonomy design, metadata schema, governance architecture, AI readiness, and lifecycle management) is available as a complete whitepaper.
How I Think About AI
AI is infrastructure. It has real capabilities, real limits, and it is not a shortcut to competence you don’t have. Like all infrastructure, it performs exactly as well as the layer underneath it.
Organizations failing at AI adoption rarely have a model problem. The knowledge layer feeding those models was never designed for machine retrieval. The people using the tools have no mental model for how to get useful outputs. And someone deployed the technology before designing the system around it.
I do not hype AI. I do not dismiss it. I treat it like any other infrastructure decision: find out what it actually does and what it actually requires, then design the system so it holds up long after demo day.
Knowledge Architecture
Most organizations treat knowledge as a writing problem. They hire people to write documentation, produce content, and maintain repositories, and then wonder why the knowledge doesn't stick, why AI tools retrieve the wrong answers, and why every organizational change forces a content rebuild.
The problem is almost never the writing. It is the absence of architecture: no content model, no taxonomy, no governance layer, no structure that tells the organization how knowledge should be created, maintained, connected, and retired.
Architecture is what makes knowledge compound. Without it, every content effort starts from zero. With it, new content builds on what exists, contradictions surface instead of hiding, and the knowledge base gets more reliable as it grows.
I developed the Stateless Content Architecture (SCA) framework to formalize this philosophy into a working design system: 28 sections covering content typing, taxonomy design, metadata schema, governance architecture, AI readiness, and lifecycle management.
Human-in-the-Loop Systems
The most useful AI systems put human judgment exactly where it belongs and remove it from the decisions that don’t need it.
Most organizations get this backwards. They try to automate everything they can and keep humans in the loop everywhere the automation fails. That produces systems that are unpredictable and hard to trust.
The better approach starts with the question: where does human judgment genuinely add value in this workflow? Where does it introduce error, inconsistency, or delay that it doesn't need to? Then you build accordingly.
This is the operating philosophy behind Human Layer Systems, and the name is deliberate. The decisions that require human judgment are the ones that determine whether everything else can be trusted.
Content as Infrastructure
Content is a layer, not a deliverable: persistent, structured, governed, and either supporting the organization or failing it whether or not anyone is watching.
Organizations that treat content as a series of deliverables produce documents. Organizations that treat content as infrastructure produce systems. The difference becomes visible when the organization changes, scales, or tries to make AI work reliably.
Infrastructure thinking means designing for reuse from the start: content independent enough to survive a system migration, structured enough to be assembled for different audiences without a rewrite, and planned across its whole lifecycle, creation through retirement.
This is why I start with architecture before anyone writes a word. The content that follows is better, faster to produce, more durable, and more useful to the machines that will eventually read it, because the structure was right before the writing began.
Operational Clarity
Documentation is operational truth: the difference between an organization that runs on shared understanding and one that runs on individual memory.
When documentation is inconsistent, employees don't trust it and revert to asking colleagues. When it is incomplete, decisions get made with incomplete information. When it is outdated, compliance risk accumulates invisibly until it surfaces at the worst possible moment.
Operational clarity is what you get when the documentation actually reflects how things work: when the policy document and the actual practice are the same document, when the process guide is written for the person doing the work under pressure, not for the auditor reviewing it after the fact.
Getting there requires structure: start with what people need to know, design content types that match how the information is really used, and build governance that keeps the documentation honest instead of merely complete.
Selected Essays & Long-Form Writing
Extended writing on knowledge systems, AI readiness, and organizational change. These pieces expand on the frameworks above with specifics, examples, and arguments.
Stateless Content Architecture: Full Framework
A 28-section technical reference for designing enterprise knowledge systems as composable, typed, independently governed content fragments. Published as a professional resource for knowledge architects and enterprise AI teams.
Stateless Content Architecture Overview
The case for modular, context-independent content fragments: what they are, why they outperform page-based authoring, and how dynamic assembly works across multiple user experiences without duplication.
What AI-Ready Data Means
A layered explanation designed so a technical architect and a non-technical stakeholder can read the same document and leave with what they actually need.
More Writing →
Browse the full writing samples collection for additional technical writing, process documentation, executive communication, and content architecture samples.