Skip to main content
Created Jan 22, 2026Last updated Jul 6, 2026Version v0.2.0

Enterprise Outer Constraints

This section captures enterprise-level constraints that bound all architectural work at AMI.

Constraints are rings​

Outer constraints are rings around the entire hierarchy beneath them. Every subset and every level of nesting — aspects, capabilities, components, technology architectures, and their own nested 00_outer-constraints — is bound by every ring above it. They bound all thought within them.

  1. Binding is transitive. A technology component obeys the enterprise rings; a view inside that component obeys both the component's constraints and the enterprise rings. There is no depth at which an outer ring stops applying.
  2. Inner constraints may only tighten. A nested 00_outer-constraints may narrow an outer ring for its scope (e.g. a stricter latency bound). It may never loosen, contradict, or silently ignore one.
  3. Rings state rules, not designs. They read as prohibitions and obligations ("raw data must always be retained", "no irreversible cloud lock-in") — never as implementation choices.
  4. Escape requires enterprise-level justification. Where a ring permits deviation, the deviation is decided and documented at the level that owns the ring — never inside the bounded scope.
  5. Conformance is checked, not assumed. Drift between a ring and observed reality is recorded in RISKS.md; invalidated premises are recorded in ASSUMPTIONS.md and force revisiting of every functional, NFR, and architecture that referenced them.

The rings at this level are defined in:

The exercise for nested constraint documents​

Every nested 00_outer-constraints/README.md (each technology component has one) fills in this template:

  1. State the constraints imposed on the node from outside it
  2. Cite which enterprise rings each constraint tightens (by non-negotiable number) — a nested constraint that traces to no ring is a design choice in disguise; move it to 01_aspects
  3. Reference assumptions by stable ID from the Global Assumption Register
  4. Declare scope boundaries: what is in, what is explicitly out
  5. Record the agreement date — constraints bind from agreement, not from authorship