CAPABILITIES

Eight control capabilities, organised by the problem they solve.

The public model is capability-first. Internal repositories and programmes appear only as provenance beneath the evidence.

01 / QUALIFIED — bounded software

Authority & Governance

Reasoning or intent must not silently become permission to cause a consequence.

Open capability →
02 / QUALIFIED — bounded software paths

Execution Integrity

Retries, races, stale context and changed material can turn one approved action into the wrong action or a duplicate effect.

Open capability →
03 / QUALIFIED — bounded software; physical safe state remains domain-specific

STOP & Containment

Once consequential execution has started, a normal decision response is too late to serve as the interrupt mechanism.

Open capability →
04 / QUALIFIED in bounded software/composed paths

Recovery & Reconciliation

After crash, partition or ambiguous acknowledgement, the external effect may be unknown and a blind retry may be unsafe.

Open capability →
05 / QUALIFIED at bounded two-domain/shared-fabric scope

State, Context & Federation

Independent systems need enough shared context to cooperate without merging their authority domains.

Open capability →
06 / QUALIFIED — bounded evidence contracts and programme evidence

Evidence & Accountability

A system can say that work completed while still hiding whether it was authorised, attempted, acknowledged, applied or reconciled.

Open capability →
07 / PARTIALLY QUALIFIED — mechanisms stronger than broad legitimacy claims

Human Control & Escalation

Human approval can become stale or over-broad if it is not bound to the exact action and current state released for execution.

Open capability →
08 / MIXED — qualified SIL, real-GPU and simulator results with explicit ceilings

Physical & Infrastructure Control

Software control claims can easily outrun what has actually been tested in simulators, real hardware or operational environments.

Open capability →