Constraint Visibility
Every consequential constraint within the platform shall be explicit.
Invisible constraints inevitably produce invisible failures.
What must remain true
Every consequential constraint within the platform shall be explicit.
The conditions governing behavior, execution, authority, and adaptation shall be observable.
Invisible constraints inevitably produce invisible failures.
Why the principle matters
Every coordination system operates within constraints.
Some constraints are imposed by the business. Some by architecture. Some by regulation. Some by technology.
The quality of a coordination system depends upon participants understanding the constraints within which they operate.
When constraints become implicit, hidden, or contradictory, people and software begin making decisions based upon assumptions rather than reality.
Constraint Visibility preserves confidence by ensuring that the platform's operating boundaries remain explicit and observable.
Observing Constraint Visibility
Constraint Visibility can be evaluated by examining the observable condition of the coordination system.
Healthy Signals
- Business rules are explicitly defined.
- Diagnostic Definitions clearly express their assumptions.
- Version requirements are explicit.
- Runtime boundaries are well defined.
- Failure conditions are predictable.
- Engineers understand the constraints governing every consequential execution.
Degrading Signals
- Behavior depends upon undocumented assumptions.
- Business rules emerge from implementation rather than declarative knowledge.
- Runtime behavior changes based upon hidden conditions.
- Engineers rely upon tribal knowledge to understand platform behavior.
- Constraints are discovered only after failures occur.
- Multiple components enforce the same constraint differently.
Degrading signals do not necessarily indicate failure.
They indicate that this dimension should be examined before confidence in the platform begins to erode.
Engineering Guidance
When designing or extending the platform:
- Make governing constraints explicit.
- Prefer declarative constraints over procedural enforcement.
- Preserve visible boundaries between runtime responsibilities.
- Avoid hidden assumptions within implementation.
- Express business policy through Diagnostic Definitions whenever possible.
- Make exceptional behavior intentional rather than incidental.
Architectural Review Questions
Before approving an implementation, ask:
- What constraints govern this behavior?
- Are those constraints explicit?
- Could another engineer discover them without prior knowledge?
- Does this implementation introduce hidden assumptions?
- Are the operating boundaries observable?
- Would this implementation improve or weaken Constraint Visibility?