Inputs
- Verified permit and action payload
- External system connection configuration
- Adapter contract definition
Runtime and execution assurance
Integrations
One governed external boundary, built carefully.
A permit-gated Kubernetes Deployment scale boundary with receipt, plus connector and adapter libraries. Never live-cluster validated in the reviewed environment.
Responsibility
What Integrations is responsible for
Integrations carries governed action beyond the platform boundary. The reviewed implementation is one permit-gated Kubernetes Deployment scale operation with a receipt, supported by connector and adapter libraries that describe how external targets are reached.
A governance platform is only useful if governed action can reach the systems an organisation already runs. Integrations define those paths: how an external target is described, how an action reaches it, and how results and errors return into reconciliation.
The implemented surface is deliberately narrow: one Kubernetes mutation boundary, with static token configuration and no provider validation. Connector libraries exist but are not a certified integration estate, and no supported-integration count is claimed.
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-gated Kubernetes Deployment scale operation with receipt
- Connector and adapter libraries for external targets
- Connector capability reporting
- Failure and unavailability reporting into reconciliation
Outputs
- External operation result and receipt
- Failure/unavailability reports
- Capability report
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 permit-gated Kubernetes Deployment scale boundary with receipt is implemented, with connector libraries and capability reporting. It is standalone, was not running in the current stack, and has never been validated against a live cluster.
Not production-qualified
This label describes verified engineering evidence only. No production deployment, certification, benchmark or customer outcome is claimed.
Evidence recorded
- Integrations connector capability matrix and repository implementation.
- Local adapter transaction exercised in the nine-stage evidence chain.
- Capability audit: integrations upstream unavailable in the reviewed stack.
Dependencies
- NARG
- Substrate
- Control Plane
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
- One mutation type (Kubernetes Deployment scale), in-process Kubernetes API access and a static token.
- Never validated against a live cluster; the service was not running in the reviewed stack.
- Connectors are not provider-validated or certified.
- No supported-integration count is claimed, and Kubernetes integration is not production-qualified.
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
Integrations extend Substrate's execution reach. They do not make admission decisions and do not carry authority; they consume a permit already granted and report back what happened.
Evaluation questions
- Which external systems are actually connected today versus planned?
- Does a connector path bypass permit verification?
- How are external failures and timeouts represented?
Next step
Evaluate Integrations 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.