Published positions on architecture, governance, and systemic risk. Each brief is a position — not an opinion.
The briefs that anchor the doctrine. Each makes a structural argument — read these first.
This text challenges the common conflation of architecture with microservices, arguing that true architectural decisions are context-driven and should precede technical choices. It emphasizes that architecture is about conscious decision-making under constraints, not about adopting fashionable solutions by default.
Read → Architectural RiskMost architectural failures do not announce themselves. They accumulate quietly — in the gap between what the system does and what your technical reports describe. These seven signs do not require technical knowledge to evaluate. They require honesty.
Read → AI Exposure & GovernanceAI projects contain two distinct problems — validating whether to build, and building so the system operates. They look related but require different engineering, different evidence, and different judgment. The persistent confusion of these problems into one is why most AI projects stall at six months.
Read → AI Exposure & GovernanceWhy the practice is structured in two named modes — and why the names matter. Ratio is the work of judgment before building. Vis is the work of operating at scale. Both are complete disciplines; neither is a migration of the other.
Read → AI Exposure & GovernanceEvery AI-native product reaches a point where third-party APIs stop being tools and become single points of failure. This brief examines the migration off vendor inference — what it costs, what it returns, and why owning the critical path is the strategic question, not the cost equation.
Read →When technology fails badly enough to matter, the postmortem almost always points at the wrong layer. The bug is named, the fix shipped, and the same class of failure returns — because the bug was never the cause, only the place the cause surfaced.
View Brief →Complexity got mistaken for competence. A system with more moving parts looks more serious — but complexity is not a sign you are doing something hard. It is a cost you agree to pay every day the system lives, and the accidental kind is almost always self-inflicted.
View Brief →"Best practice" is the phrase people reach for when they want the authority of a decision without the work of making one. Architecture is trade-offs bound to a context — this team, this load, this rate of change. Move the context and the right choice becomes the wrong one without changing a line.
View Brief →"Human in the loop" has become a phrase people say to avoid thinking about where the human is actually standing. AI moves a decision — faster, cheaper, more available. It does not make the decision better unless someone designed the judgment around it.
View Brief →The model is the cheapest, most replaceable part of an AI system — and the one part that gets all the attention. Value is decided in the decision it feeds, the workflow that acts on it, and the cost of being wrong. Most AI roadmaps optimize the variable that matters least.
View Brief →Fluency is not knowledge. A language model produces the most probable continuation of a prompt; it has no internal signal separating "well-supported" from "plausible and invented." The failure mode is not an error message — it is a confident wrong answer identical to a confident right one.
View Brief →"Garbage in, garbage out" is too generous — it implies the garbage is visible on the way out. Bad data produces confident AI that is wrong in the exact shape of your historical mistakes, laundered through a system that looks objective because it is automated.
View Brief →Automated decision systems fail in the gap between the rules a business believes it enforces and the states its architecture actually permits. A limit that isn't an invariant is a suggestion the system is free to ignore — and at scale, it will.
View Brief →Observability is an admission that your system can reach states you don't understand, so you instrument it to find out after the fact. Worth doing — but not the same as being reliable. A dashboard observes; it does not constrain.
View Brief →Downtime rarely arrives from outside. Whether a system survives the spike, the dependency failure, the bad deploy was decided long before, in the boundaries that were or were not drawn. Reliability is structural — or it is luck with good reflexes.
View Brief →Governance gets treated as paperwork bolted on after the system is built. That version protects nothing — it describes intentions while the system does whatever its architecture permits. The gap between the policy and the permission is where regulatory risk lives.
View Brief →Dashboards measure what the system is doing — latency, throughput, error rate. None measures what the system must never do, and that is the failure that ends companies. Correctness has no column on the dashboard.
View Brief →Every system that survives the real world is held up by invariants — conditions that must always hold for it to stay correct. The only choice is whether yours are explicit and enforced, or implicit and discovered the hard way.
View Brief →The most expensive misreadings in a startup's life share one shape: mistaking a signal of momentum for a signal of truth. Users signed up, revenue rose, a round closed. Each feels like the market saying yes — and none of them is.
View Brief →An idea describes something that could exist. A value proposition is a claim about someone else — that a specific person, in a specific situation, has a problem painful enough to choose and pay for your solution. The distance between the two is where most early-stage time is wasted.
View Brief →There are two ways to be known for expertise: be visible, or be the source. The first depends on the algorithm and the hype cycle and evaporates with them. The second is grounded in something that happened — which is why it survives the follow-up question.
View Brief →Most competitive advantages are expensive — capital, technology, talent. Clarity is nearly free, available to anyone, and almost no one takes it. A team that can say in one sentence what it is doing and refusing to do moves faster than a better-resourced team that cannot.
View Brief →Growth is a number going up. Scale is that number going up without a proportional increase in the effort, improvisation, or specific people required to produce it. Most startups that believe they are scaling are amplifying — and amplification breaks exactly when success makes improvisation impossible.
View Brief →PMF gets talked about like a moment you cross and announce. That framing produces a specific failure: teams that "achieve PMF," declare victory, and stop doing the thing that produced it. Fit is a state you are continuously in — or sliding out of.
View Brief →"Minimum viable product" has quietly come to mean "first version you keep." That reading guts the idea. An MVP is an experiment — and an experiment that cannot fail was never an experiment, just a launch with extra steps.
View Brief →The instinctive response to growth is to add people. Often that is the opposite of scaling — adding mass to a system whose real constraint was never the number of hands, and watching new people make the same unscalable decisions faster and in more places.
View Brief →