The real enemy is complexity
It shows up as scattered change, mental overhead, and hidden consequences. Every principle in the book exists to push complexity back — to keep it local, visible, and manageable.
Articulates the engineering philosophy that underwrites the whole body.
Every other work in The Meridian Model depends on something. The failure mode catalog depends on a team that can act on recognition. The operating method depends on tests, boundaries, and isolable change. The Halocline depends on knowing which components to apply discipline to. None of it holds on poorly structured software. This book is what makes it all possible.
The Discipline of Dependable Software articulates the engineering philosophy that underwrites every other work in the body. It uses Clean Architecture as a foundation, not as doctrine. It defines what "good" looks like in a long-lived system — and names why that definition matters now more than it did before AI entered the development workflow.
Practitioners who care about systems that outlast their original authors.
Practicing software engineers and technical leaders who care about systems that outlast their original authors. Readers who want the deeper "why" behind the rest of The Meridian Model. This is not a beginner's book and not an architecture pattern catalogue — it is the philosophical foundation that makes the patterns worth following.
Engineers who have read Human-Assisted AI and asked "engineering discipline as the passive defense — but what discipline, specifically?" will find the answer here.
The enemy is complexity. It does not announce itself.
Complexity is not dramatic. It accumulates in small decisions — a boundary softened for convenience, a responsibility blurred because the deadline was close, a test that verifies the implementation instead of the requirement. Each decision is defensible. The accumulated result is a system where change is dangerous, new engineers cannot read the flow, and AI-assisted changes cannot be verified against anything real.
If the answer is harder, complexity is winning. From The Discipline of Dependable Software
The test is simple: if understanding what a change will affect requires reading more of the codebase than the change itself, complexity has won that piece of the system. This book gives engineers the vocabulary and the structural patterns to stop complexity before it compounds.
Five ideas the book develops.
Ten core principles
Separation of responsibilities, loose coupling, clear boundaries, swappable implementations, traceable execution, simplicity and consistency, dependency injection, testing, error handling, and documentation. Each principle has a structural reason.
Policy first
Business logic is not application logic. Resolve policy in one intentional place, then coordinate the flow. Systems that scatter policy across layers lose it; systems that center it stay readable.
What good looks like
Thin entry points, explicit orchestration, infrastructure behind boundaries, readable flow, localized change. These are not aspirations — they are observable properties that a team can verify in code review.
Clean Architecture as foundation, not rulebook
Use the structural fit. Reject the ritual. Folder worship and dogmatic layering miss the point. The goal is a system where change is local, flow is traceable, and the codebase survives its authors.
The Principles Sheet.
Ten principles on a single page. Not a summary — a working reference. Each principle is stated concisely with the structural reason behind it. Built to sit above the workstation and be consulted during design review or code review, not just during onboarding.
If the answer is harder, complexity is winning. Keep the sheet in the design review. When a decision feels right but the implementation turns complex, that tension is worth naming before it is committed.
Without the foundation, AI work is built on sand.
Systems built this way do not stop AI from being wrong. They make the wrongness easier to isolate, test, and correct. That is the passive defense Human-Assisted AI names. Without it, AI failures become entangled with application logic, tests become indistinguishable from the code they verify, and localized change stops being possible.
Dependable software is what makes disciplined AI work even possible. The Confluent Method depends on verification against real boundaries. The Halocline test depends on being able to trace which components have human decision points and which do not. Neither discipline can be applied correctly to a system where responsibilities are scattered and flow is unreadable.
Change stays local. Flow stays readable.
Teams stop spending review cycles on accidental complexity. Change stays local. Error handling becomes visible instead of buried. New engineers can read the flow from entry point to result. AI-assisted changes become verifiable against real boundaries instead of smeared logic.
The long-run return is a system that can be maintained, extended, and understood by engineers who were not there when it was written — which is the only engineering standard that actually holds once a team or a codebase grows.
Where to go from here.
Application to AI work
→
Human-Assisted AI
Why engineering discipline is the passive defense against AI mistakes.
The method built on this foundation
→
The Confluent Method
The operating method that depends on the boundaries this book defines.
Classification layer
→
The Halocline
The boundary between CAID and OAID — applies at the component level this foundation enables.
Preview the PDF.
View the first four pages here. Submit your name and email to reveal the full publication PDF.
Cite this work
Russo, P. (2026). The Discipline of Dependable Software: A Practical Philosophy for Long-Lived Systems. Riverbend Consulting Group. https://doi.org/10.5281/zenodo.19597270