Inputs
- Verified permit
- Action payload and target resource
- Adapter configuration
Runtime and execution assurance
Substrate
Execute only under a verified permit.
Controlled execution and resource adapters that apply an action and support independent read-back.
Responsibility
What Substrate is responsible for
Substrate provides the controlled execution boundary. It verifies a permit before applying an effect through a bounded adapter, then supports read-back so the result can be observed rather than assumed.
Substrate is the component that actually touches the world. Its contract is narrow: verify the permit, apply the effect through an adapter with a defined blast radius, and make the resulting state observable.
It is presented as a reference execution boundary rather than a universal driver layer. The effect is a local file/cgroup worker, and the read-back reads the same local effect store rather than an independent third-party source.
Lifecycle position
Where it sits in the governance lifecycle
Stage numbering is canonical across the site. Open the interactive lifecycle to see every component with responsibilities at each stage.
Execution
Apply the effect through a controlled adapter.
Independent observation
Record what the external state actually is.
Verified capabilities
What is verified today
Capabilities are drawn from the product register. Each one is bounded by the limitations stated further down this page.
- Permit verification before an effect is applied
- Controlled execution through a reference adapter
- Read-back of resulting state from the effect store
- Explicit unavailable/unknown effects instead of assumed success
Outputs
- Applied effect record
- Read-back observation
- Unavailable or unknown effect result
Evidence and maturity
What the evidence supports
Maturity describes verified engineering evidence in a bounded environment. It is not a production-readiness statement.
Maturity note
A reference execution boundary with permit verification, execute and effect read-back was exercised in the recorded local chain. Its own README describes the boundary as parked, and the demonstrated Control Plane path uses it; that discrepancy (D-1) is unresolved.
Not production-qualified
This label describes verified engineering evidence only. No production deployment, certification, benchmark or customer outcome is claimed.
Evidence recorded
- Recorded local chain hop 10: execute plus read-back through the reference adapter.
- Failure/recovery case: unavailable effects reported without claiming success.
- Substrate README (parked boundary) and Control Plane integration record (D-1 discrepancy).
Dependencies
- Gatekeeper
- NARG
- Integrations
Dependencies are stated as the product register records them. A dependency is not automatically production-qualified; see its own product or component page for its maturity and limitations.
Limitations
What this product does not do (yet).
Limitations are stated before the evaluation questions so they cannot be missed, downplayed or treated as future-work footnotes.
Limitations — read before evaluating
- Reference adapter scope only; no production execution adapter or third-party read-back was verified.
- The effect boundary is a local file/cgroup worker in the reviewed implementation.
- Packet-level and device-level enforcement is not implemented.
- Substrate README describes the boundary as parked, while the demonstrated Control Plane path uses it (D-1 unresolved).
No capability on this page should be read as production qualification. If a limitation is material to your use case, it belongs in the evaluation scope — not after it.
Relationship to the platform
How it fits
Substrate executes what NARG dispatches and what Gatekeeper admitted. It is the last enforcement point and the first source of observed state for reconciliation.
Evaluation questions
- Which execution adapters exist and what is their blast radius?
- How is read-back performed independently of the executor's response?
- What does the platform do when an adapter is unavailable?
Next step
Evaluate Substrate against a real control problem.
Bring a system boundary, an action class and a failure mode. The first step is to agree what should be governed and what evidence would count.