Kernel capabilities implemented. End-to-end platform integration and qualification are progressing.Interactive demonstrationPlatform status
Explore the platformBecome a collaborator

Governance and formal assurance

Chinje

Make the promise explicit before action.

Intent governance, actor identity and authority, obligation tracking, evidence sufficiency, conformance and drift.

Integrated2 lifecycle positionsNon-production evidence
Try the interactive demonstrationDiscuss an evaluation

Responsibility

What Chinje is responsible for

All products

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. In the platform architecture Chinje is the sole evidence-sufficiency and conformance authority; those responsibilities are not delegated to λ-Safe, the Control Plane or the runtime enforcement layer.

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. It also holds the intent and evidence-sufficiency context during degradation, and is the authority that determines whether a reduced mode still conforms.

In depth

The problem, the boundary and the lifecycle role

Each section below is drawn from the product register and states the context this product is built for, in the product's own terms.

01

Intent continuity and conformance during degradation

When operating conditions deteriorate, the intent does not disappear. Chinje keeps the declared intent, actor identity, authority context and provenance requirements available to the degraded transition, so the reduced mode can be assessed against the same obligations as normal operation.

Chinje classifies drift and determines conformance from observed evidence, including whether a degraded mode stayed within the declared contract. Recovery is a governed transition authorised through the same context — not an automatic return to full operation.

Chinje is the sole evidence-sufficiency and conformance authority in the platform architecture. λ-Safe defines and verifies admissible boundaries; the Control Plane and runtime authorise, enforce, observe and reconcile; Chinje decides what the evidence means.

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.

Open the full lifecycle

  1. Intent

    Declare the objective, obligations and scope.

  2. 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 classification, including during degraded operation
  • Authorization of reconciliation and recovery as governed transitions

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

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.

Integrated

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

See the full architecture

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

  1. Can the intent be reviewed and approved by a person distinct from its author?
  2. Are scope, expiry, obligations and denial reasons explicit and machine-readable?
  3. Can a reviewer distinguish an evaluated intent from a completed action?

Related products

Continue through the lifecycle

Product portfolio
  • Governance and formal assuranceIntegrated

    Intent-to-Control Bridge

    Translation of declared intent and obligations into machine-enforceable contract fragments and compiler inputs.

    View Intent-to-Control Bridge
  • Governance and formal assuranceIntegrated

    Gatekeeper

    Independent admission and authorisation, gate evaluation and signed permit issuance bound to the action.

    View Gatekeeper
  • Runtime and execution assuranceIntegrated

    Reconciliation and Audit

    Independent observation, expected-versus-observed reconciliation and linked evidence across the audit ledger.

    View Reconciliation and Audit

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.

Run the interactive demonstrationDiscuss an evaluationDesign-partner programme