COMMAND
The governance architecture the other four capabilities are designed to operate under.
Command is designed as the control plane — the part of the architecture that holds the gates, the authority model and the enforcement rules that bound what every other capability may and may not do.
Governance architecture.
The human gate model
Command is designed to be the architectural home of every gate — planning, sampling, finding, report, close-out. The gate points, their definitions and their dispositions are held here, not distributed across the capabilities that pass through them.
The authority model — default-deny
The platform's authority model is specified as default-deny. Command is designed to hold the authority roster — a record of what each person is permitted to do — and to enforce it structurally rather than by convention.
Capability boundary enforcement
The boundaries between what the platform may and may not do are not expressed as policy documents — they are designed to be enforced by Command at the architecture level. A capability cannot exceed its boundary because the enforcement sits outside it.
An immutable governance log
Command is designed so that every governed act — gate decisions, authority changes, enforcement events — is appended to an immutable log. The design intent is that nothing in this record is editable after the fact.
Why the control plane sits outside the other capabilities.
Governance that sits inside the capability it governs is governance that the capability can, in principle, influence or circumvent. The boundary between what the platform may do and what a person must do would then be a boundary defined by the thing it is supposed to constrain.
Command is designed to be architecturally separate from the capabilities it governs. Blueprint, TRACE, Resolve and Insights are designed to operate within the rules Command holds — and the enforcement is designed to be structural, not a matter of each capability behaving correctly.
What the architecture is designed to make possible.
The platform boundary — what it may and may not do — is designed to be enforced architecturally, not described in a policy document.
Every person in the platform is designed to hold exactly the authority the programme has granted — the default is denial, and authority must be explicit.
The complete governance log is designed to be available and uneditable — accessible to anyone the programme authorises, and readable long after the engagement is over.
Where it sits in the chain.
The designed authority model provides the governance architecture for programme and portfolio assurance.
Request a briefing
A working conversation about how any of these applies to your programme.