Concept
Consequence Architecture
Consequence architecture names professional literacy for systems where generation or scale outruns informal caution.
Consequence architecture names professional literacy for systems where generation or scale outruns informal caution. It becomes important when guardrails exist on paper but production paths bypass them, or when postmortems produce action items detached from redesign authority. It helps preserve corrigibility under acceleration, but can fail when organizations prove they cared while the same failure class repeats. It differs from coupling because consequence-architecture is designed structure; coupling is the resulting attachment strength. It differs from cohesion because architecture designs the whole path; cohesion names ownership clarity within one boundary.
Recognition signals
- responsibility boundaries and escalation routes are deliberately designed
- feedback paths return consequence to actors who can redesign behavior
- guardrails unite cohesion and coupling in practice
- guardrail policies exist on paper while production paths bypass them
- nobody can answer who learns from a given failure class after postmortems
Questions to ask
- Who can still redesign behavior when this path returns signal?
- Where will this fail first, and can that boundary redesign the system?
- Which constraint layers actually run where consequence happens?
Counterbalances
- design feedback paths before expanding generation or deployment speed
- pair guardrails with redesign authority, not only compliance proof
- keep escalation routes short enough for memory of the decision to survive
Trajectory
Early signals
- teams ad hoc route incidents to whoever is available, not a clear owner
- policies multiply without matching runtime enforcement paths
Intensification
- postmortems produce vague action items detached from redesign authority
- AI-assisted output spreads faster than boundary rules are updated
Failure modes
- organizations prove they cared while the same failure class repeats
- consequence architecture exists in documents but not in production paths
Restoration paths
- attach each guardrail to the production path where harm would appear
- name who decides, who absorbs consequence, and who can redesign after failure
Manifestations
software
- security-approved AI assistant still serves traffic through a legacy endpoint
organizations
- incident reviews end with prompt tweaks when retrieval boundary ownership is unclear
leadership
- executives demand guardrails without funding teams who must redesign around them
ai_systems
- evaluation suites test benchmark prompts while operational failures repeat in production
Appears in chapters
- Part I — Why Knowing No Longer Governs Outcomes
- Chapter 1 — When Knowing Is No Longer Enough
- Chapter 3 — The Collapse of Corrective Loops
- Chapter 4 — Constraint as Discipline
- Chapter 6 — Seeing the System You Are In
- Chapter 8 — When Failure Is Not an Option
- Part III — What These Disciplines Share
- Chapter 11 — Authority That Preserves Correction
And 2 more chapters with this association.
Related books2 books
Book
Coupling
Cohesion, Consequence, and the Architecture of Responsibility
A practical framework for seeing where systems are tightly joined, where they drift apart, and how those coupling choices shape accountability over time.
View book
Book
How Serious Systems Learn
Disciplines for Acting Without Certainty
A handbook for teams and institutions that need to learn in motion, improve under pressure, and make better decisions without waiting for perfect information.
View book
Outgoing dynamics2 relationships
shapes
Consequence-architecture shapes coupling by intentionally designing feedback paths, boundaries, and escalation routes that determine attachment strength.
preserves
Consequence-architecture preserves corrigibility under acceleration by designing feedback paths that reach redesign authority.