Implementation: SHADOW · Exposure: INTERNAL. See status labels. The decision runtime answers questions where every legal answer is known in advance: which of these files, is this safe, is this criterion met, how do these rank. It is the S1 level of the Cognitive Machine.

​
Architecture contract

​
Operations

​
Request and result

A DecisionRequestV1 carries the envelope, the operation, a state projection, instructions, the candidates or scale, constraints, an optional calibration domain and a latency limit. A DecisionResultV1 returns the typed answer, the probabilities, a confidence, the calibration reference, evidence references, the component identity as evidence, and a threshold action: AUTO, REVIEW, ESCALATE or REJECT.

​
Rules

  • The caller supplies the candidates. A decision backend never invents options. Every candidate set has an unknown or fallback path.
  • Illegal candidates are removed before cognition, by policy.
  • Thresholds are policy, never model output.
  • No threshold acts without valid calibration. A missing calibration artifact means fallback, never a made-up confidence.
  • An uncalibrated margin is never shown as a probability.
  • Decision backends are interchangeable behind the contract: rules, schema encoders, contrastive rankers, decoder readouts, specialists or remote services.
Why a separate runtime: a scored choice over known answers is cheaper, faster and more checkable than generating text and parsing it. Putting it behind one contract lets any backend serve it and lets the system measure each one.

​
Current implementation

On main there is one canonical decision server. It speaks the frozen Kernel ABI 1.0.0 decision contracts on a local, loopback-only endpoint. Its local readout provider serves BELIEF, GATE, VERIFY, CHOICE, SCORE, ESTIMATE, RANK, SUBSET and PAIR_SCORE by reading label probabilities from a local model over a constrained label set; it does not parse probabilities out of free text. Its router runs in shadow mode by default. Without a bound calibration manifest that has passed the go-live gate, every result is marked uncalibrated and abstains; it is never AUTO. AUTO needs live mode, a passing manifest for that primitive, the caller attesting the decision is reversible, and a confidence inside the calibrated region. For a manifest from the Q26 gate, live mode also needs the primitive to be in a canary with budget left. Today only judge.first_pass.tool qualifies. See Calibration.

​
Typed decisions endpoint (E1)

allternit-api’s Agency Kernel serves POST /v1/decisions (alias /v1/systemone): one choice over up to 255 caller options, for computer-use steps and any other bounded question. A backend chain answers it: the owned local scorer (one-pass option scoring on MLX or llama.cpp, Qwen3.5-4B by default), live flywheel heads first, optional vendor adapters (off by default, enabled per project), and the planner model through gizzi as the oracle. Under a per-kind confidence threshold the router escalates to the next backend, within the caller’s latency budget, and abstains when the caller allows it. Every decision is stored with its outcome. Its probabilities are relative to the option set and marked uncalibrated. See the API reference. Flywheel (E5). Registered heads run in shadow on every decision of their kind, off the latency path; their choices are stored next to the served choice and the outcome. A head is promoted to live when its accuracy against outcomes clears the kind’s bar (default 97% over 200 labelled answers, not overconfident) and demoted when live accuracy drops under 93%; each state is re-earned from scratch, and every change is audited. The first head, head.lookup, is an exact-match lookup over the account’s past successful choices that answers in well under 10 ms; trained heads from the decision-model track register through the same interface. See The flywheel. Vendor backends (E6). Adapters for a hosted vendor decisions API and for TypeSafe Jev follow the vendors’ published request formats. Both are off by default, need the key on the server and the project enabled, and are metered by the vendor. domains/decision-runtime/bench/compare_backends.py compares backends on the same decisions (latency and accuracy). Computer use runs on it through run_subtask (E2): the planner sets a bounded goal once and each UI step is an element, field or verify decision on the fast tiers, with every outcome written back. See How computer use decides. A pre-tool safety hook uses the server in log-only mode: deterministic hard rules decide first and last, and the decision server can only add friction, never allow.

​
Availability

​
Developer relevance

To add a decision backend, implement the request and result contract and report your probability semantics honestly (calibrated, relative to the set, or uncalibrated). Your backend will run in shadow until a calibration manifest for each primitive passes.