Inputs
- Actor-supplied intent declaration and success conditions
- Identity assertions and tenant context
- Obligations, invariants and scope constraints
- Evidence references from runtime and observation components
Intent and authority
Chinje
Make the promise explicit before action.
Intent governance, actor identity and authority, obligation tracking, evidence sufficiency, conformance and drift.
Responsibility
What Chinje is responsible for
Chinje establishes what an actor intends to achieve, which obligations and scope apply, who is authorised to act, and whether the evidence available is sufficient to proceed. It keeps the intent version chain and supports conformance and drift assessment against the original obligations.
An autonomous system is only governable if its intent is inspectable. Chinje turns a declared objective into a versioned, reviewable intent with explicit obligations, scope and authority requirements, so later decisions can be checked against something concrete rather than inferred from a prompt or a log line.
Chinje sits at the start and the end of the governance lifecycle. It provides the authoritative intent that the Intent-to-Control Bridge translates into enforceable requirements, and it supplies the original obligations against which observed outcomes are later assessed for conformance and drift.
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.
Intent
Declare the objective, obligations and scope.
Conformance
Evaluate outcomes against the original obligations.
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.
- Intent authoring, approval and version chain with a distinct approving principal
- Declared obligations, scope and expiry attached to a published intent
- Actor identity and authority requirements carried into admission
- Evidence sufficiency assessment before a decision is treated as complete
- Conformance and drift assessment against the original obligations
Outputs
- Published, versioned intent records
- Machine-readable obligation and scope set
- Authority and evidence-sufficiency findings
- Conformance and drift signals for review
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
Verified in the local demonstration stack: an intent was authored, approved by a distinct principal, published and read back by version. Intent read-by-id was independently probed in the November 2026 capability audit.
Not production-qualified
This label describes verified engineering evidence only. No production deployment, certification, benchmark or customer outcome is claimed.
Evidence recorded
- Intent authored, approved by a distinct principal, published and read back by version in the local demonstration stack (conformance matrix, 2026-10-26).
- Capability audit, 2026-11-03: intent read by id/version returned contract data; intent list returned HTTP 405.
- Intent-to-admission regression record and cross-agent contract register.
Dependencies
- Intent-to-Control Bridge
- λ-Safe compiler and verifier
- Gatekeeper
- 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
- Intent browsing is not implemented: intents are read by id and version, and a list endpoint is absent.
- External OIDC is not configured in the reviewed environment; local development identity is used.
- Conformance and drift are partially integrated; drift assessment is derived from evidence-driven analysis rather than one unified lifecycle artefact.
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
Chinje is the authority for what was intended. It does not execute actions and does not issue permits. Its published intent becomes the input to the Bridge and λ-Safe, and its obligations become the reference point for conformance after reconciliation.
Evaluation questions
- Can the intent be reviewed and approved by a person distinct from its author?
- Are scope, expiry, obligations and denial reasons explicit and machine-readable?
- Can a reviewer distinguish an evaluated intent from a completed action?
Next step
Evaluate Chinje 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.