The reading behind the thinking

The bounded-context idea is foundational to the System-of-Systems approach: sovereign models that interoperate through explicit contracts rather than a shared mush.

A study of how systems that impose legibility from above destroy the local knowledge they depend on. Essential reading for anyone designing governance - a warning against context-flattening.

Brooks on why conceptual integrity is the most important property of a design, and why it almost always requires a single mind or a tightly aligned few. The intellectual root of how I think about the Founding Architect role.

The clearest primer on stocks, flows, and feedback. The chapter on leverage points reframed how I prioritize where to intervene in an architecture - the highest-leverage change is almost never the one that feels urgent.

The transformer paper. Worth re-reading not for the architecture but for what it implies: capability is cheap and context is the constraint. The model was never the moat.

The early formalization of grounding generation in retrieved context. The practical lesson for enterprises: your retrieval and context layer matters more than your model choice.

Foundry's ontology is context-as-infrastructure made concrete - a shared semantic layer that both humans and machines decide against. The closest production analog to what Context Intelligence Infrastructure aims at.

Stripe's enduring lesson is that the interface IS the product. Backwards-compatible evolution, ruthless naming, and idempotency as a first-class concept - an object lesson in designing the durable layer.

Don't remove a constraint until you understand why it exists. In legacy enterprise systems, the 'inefficiency' you want to automate away is often encoded judgment. Find out before you delete it.

Systems mirror the communication structures that build them. If you want a different architecture, you often have to change the organization first - which is why founding architecture is also organizational design.

Ask 'and then what?' The first-order effect of automating a decision is speed; the second-order effect is the slow erosion of the judgment that made the decision good. Most AI strategy stops at first order.

A standing tension I track: the more legible (measurable, auditable) you make a system, the more you risk optimizing for the metric and losing the resilience that lived in the unmeasured parts. Governance has to hold both.

Context has a half-life. The rationale behind a decision is vivid the day it's made and nearly gone within a quarter. Systems that don't capture it at the moment of decision are paying compounding interest on lost judgment.

A staged path: master the system → master the domain → master the decision → master the org. Each stage changes what 'good' means. The map tracks the readings and projects that move you up an altitude.