Inputs
- Published intent version and obligations from Chinje
- Authority and policy context
- Compiler target capabilities from λ-Safe
Governance and formal assurance
Translate intent into enforceable requirements.
Translation of declared intent and obligations into machine-enforceable contract fragments and compiler inputs.
Responsibility
The Intent-to-Control Bridge resolves a published intent against authority and compilation inputs, then produces a translation package and target fragments that λ-Safe can compile. It preserves the declared scope and refuses when the intent cannot be represented faithfully.
Intent is written for people and policy; a compiler needs contract fragments. The Bridge is the controlled translation step in between, and it is where silent semantic loss would otherwise happen. The translation package records what was resolved, what was mapped and what was refused.
It is also a dependency boundary: the Bridge must resolve authority and compiler inputs before λ-Safe can compile anything. When the window-preservation case cannot be represented faithfully, the design position is refusal rather than an approximate translation.
Lifecycle position
Stage numbering is canonical across the site. Open the interactive lifecycle to see every component with responsibilities at each stage.
Declare the objective, obligations and scope.
Translate intent into machine-enforceable requirements.
Verified capabilities
Capabilities are drawn from the product register. Each one is bounded by the limitations stated further down this page.
Evidence and maturity
Maturity describes verified engineering evidence in a bounded environment. It is not a production-readiness statement.
Adapters and translation packages were implemented and exercised in the local adapter chain (READY_FOR_COMPILATION, then compiled and verified). The Bridge is a CLI component rather than an HTTP service, and the D1 window-preservation case is currently a refusal path only.
This label describes verified engineering evidence only. No production deployment, certification, benchmark or customer outcome is claimed.
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
Limitations are stated before the evaluation questions so they cannot be missed, downplayed or treated as future-work footnotes.
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
The Bridge is deliberately narrow: it neither authorises nor executes. It exists so that the authority decision can be made against a faithful, inspectable translation rather than against raw natural-language intent.
Next step
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.