Defining What Must Exist Before Anything Is Built
The i5 Design Reference exists to help enterprises move from recognition to definition.
Once coordination, authority, and governance are understood as structural constraints, the next challenge is practical but upstream: defining what must exist so that any system can coordinate decisions, adapt under uncertainty, and remain governable as autonomy grows.
This layer does not provide solutions, implementations, or instructions. It provides shared reference structures that make specific classes of design failure difficult to repeat—regardless of how, or by whom, a system is built.
Why a Design Reference Is Necessary
Most enterprises approach system design indirectly.
They select platforms, assemble tools, and configure workflows, assuming coordination will emerge through integration and governance processes. In stable environments, this can work well enough. In environments shaped by continuous change and autonomous decision-making, it does not.
When core assumptions about coordination remain implicit, they are still encoded—through default system behaviors, vendor abstractions, or organizational habit. Over time, these hidden assumptions accumulate, harden, and become expensive to unwind.
A design reference makes those assumptions explicit before they are operationalized. It creates leverage upstream of software selection, agent design, and execution planning.
Coordination Modes for Distributed Decision-Making
What the Design Reference Contains
The design reference is a curated set of models, invariants, and system design constraints derived from years of design work, operational experience, and failure analysis.
In structured form, it includes:
- System State Models that prevent coordination breakdowns by making operational reality explicit across time and domains.
- Decision Authority Models that prevent ambiguity by defining who—or what—can decide, under which conditions, and with what scope.
- Coordination Patterns that prevent tradeoffs from being resolved implicitly by separating negotiation from execution.
- Governance-as-Runtime Structures that prevent after-the-fact control by embedding oversight, intervention, and explainability into system behavior.
- Failure Modes and Anti‑Patterns that reliably emerge when orchestration is deferred, fragmented, or treated implicitly.
These artifacts are intentionally abstracted from specific technologies. Their role is to shape intent and constrain design space, not to prescribe tools.
What the Design Reference Enables
Used correctly, the design reference enables work that is otherwise difficult—or impossible—to do reliably.
It allows teams to:
- define orchestration-native requirements before engaging vendors or partners,
- evaluate platforms and proposed designs against structural criteria rather than feature lists,
- identify where existing systems will fail as autonomy and tempo increase,
- align stakeholders around constraints that cannot be negotiated away,
- prevent legacy operating logic from being reproduced under new technical labels.
The result is not faster implementation. It is fewer irreversible mistakes.
MORE: i5 Design Reference: Overview
What the Design Reference Deliberately Avoids
The design reference is not a methodology, playbook, or certification program.
It does not provide:
- step-by-step implementation guidance,
- deployable code or configurations,
- vendor-specific architectures,
- maturity scores or benchmarking results.
These omissions are intentional. The purpose of the design reference is not to accelerate execution, but to ensure that execution—however it is carried out—rests on a coherent foundation.
Why the Design Reference Is Standard, Not Bespoke
All organizations accessing the design reference work from the same material.
This is not because enterprises are identical, but because coordination failures are repeatable. They are governed by a small number of non-negotiable structural realities, even when context differs.
Context enters later, during design and execution. The design reference exists to stabilize the thinking that must precede both.
Relationship to Execution
The design reference does not replace internal system designers, engineering teams, or delivery partners. It sits upstream of them.
Some organizations use it to inform bespoke system design. Others use it to interrogate vendor claims or to reframe stalled transformation efforts. In all cases, the design reference remains independent of how work is executed.
This separation is deliberate. Enterprises that must remain governable cannot outsource authorship of their operating logic.
Access to the Design Reference
Access to the design reference is gated, not to create scarcity, but to preserve focus.
It is intended for leaders, system designers, and operators who are actively confronting coordination limits and are prepared to work at the level of definition rather than tooling.
Access provides entry to the shared reference material and establishes a common foundation for deeper design work, should that be required.
What Comes After
For organizations that need to translate reference definitions into a concrete, enterprise-specific plan, a deeper layer of Design Intelligence may be appropriate.
That layer increases prescriptiveness and resolution while keeping authorship and execution squarely within the enterprise.
The design reference is where the problem becomes tractable—without yet becoming constrained by a solution.