Skip to main content
Jira progress: loading…

CTRL

Control & Governance Engines

1. Identity​

AttributeValue
Type codeCTRL
Canonical nameControl & Governance Engines
Parent type—
Type statusreview
Tier scopetier-0
Invocationpolicy-invoked
Payload effectnone
Lineage roleemits-meta-signal

CTRL is a category boundary, not an identity. Members are identified by MEID, versioned through ZAR as CMIs, and carry mice.category: CTRL. The type itself has no MEID, no CMI and no runtime presence.

2. Purpose and boundary​

Control & Governance Engines (CTRL) are the Tier-0 engines that run the control plane of signal admission and platform trust. They decide where a signal goes (routing, quarantine, escalation), under which policy and configuration it is processed, and they produce the governed control artifacts that make those decisions verifiable: attestation bundles, ledger anchors, replay manifests, audit records, observability telemetry and scheduled runs.

A CTRL engine never produces a sustainability value and never judges the content of a signal. The judgement comes from VALI (contract conformance) and AME (trust and admissibility from evidence); CTRL consumes those outcomes together with registered policy and acts on them.

Most current members are stages of the TrustGate pipeline (see TG-MICE). The type is defined by the operation, not by the pipeline: an engine that resolves policy bundles or anchors artifacts to the ledger is CTRL wherever it runs.

3. Membership criteria​

3.1 Inclusion tests​

A micro engine is a member of CTRL when its specification satisfies the following:

  • Its output is a decision, a control artifact or a telemetry record about a signal or a run — never a value of the signal itself.
  • It consumes outcomes produced by VALI, AME or ALERT (validation results, trust scores, alerts) and policy or configuration context, and acts on them.
  • It is invoked by policy, by the pipeline controller or on a schedule; ZSSR does not select it as a computation step.
  • Each output CSI declares exactly one governed replay mode (EXACT, BANDED or RECORDED), with an optional engine default. Decisions bind registered policy, ruleset and configuration versions; observational records and human rationales retain creation-time evidence rather than claiming deterministic recomputation.
  • Its MEID capability is ATTEST, ANCHOR, REPLAY, ROUTE, ORCHESTRATE, MONITOR, RESOLVE or EXPORT, in the domain TRUST, GOVERNANCE, POLICY, AUDIT or REPLAY.

3.2 Exclusions​

A micro engine is not a member of CTRL when any of the following is its responsibility; each belongs to the type named:

  • ❌ validate a payload against a contract (VALI)
  • ❌ evaluate trust, confidence or admissibility from evidence (AME)
  • ❌ detect threshold violations and recommend escalation (ALERT)
  • ❌ compute, transform or aggregate values (CALC, TRFM, AGGR)
  • ❌ exchange artifacts with external parties (CONN)

3.3 Boundary cases​

  • CTRL versus AME: both may attest. AME derives an assurance statement from evidence about a signal; CTRL produces the governed control artifact (attestation bundle, ledger anchor, replay manifest) and never judges the signal's content.
  • CTRL versus ALERT: ALERT recommends (MANUAL_REVIEW, BLOCK_DISCLOSURE); the TrustGate CTRL decision engine owns the TrustGate routing decision; the authorized controller executes it.
  • CTRL versus CONN: moving attestation bundles across ECO entities is exchange with an external party — CONN (TG-FEDERATION-EXCHANGE). Deciding what may leave is CTRL.
  • CTRL versus ZSSR: ZSSR is the platform router and not a micro engine. A CTRL engine implements one governed control operation that ZSSR or the TrustGate controller invokes.

4. Design rules​

RULE-CTRL-001 — Deterministic decisions

Given the same retained inputs, policy bundle version, configuration version and ruleset version, a CTRL engine SHALL reproduce its governed decision according to the replay mode declared for that output CSI. External receipts and timestamps SHALL be retained evidence; replay SHALL NOT repeat external side effects to recreate them.

RULE-CTRL-002 — Replay binding

Every decision and control artifact SHALL record the policy, configuration and ruleset versions it was produced under, and SHALL be reproducible under the replay semantics declared for it (EXACT, BANDED or RECORDED) by the Replay Constitution and TG-RP.

RULE-CTRL-003 — Non-judgement

A CTRL engine SHALL NOT compute, alter or assess the content of a signal. It SHALL act only on outcomes produced by VALI, AME and ALERT and on registered policy.

RULE-CTRL-004 — Recommendation and execution are separate

Escalation recommendations from ALERT and trust assessments from AME SHALL be inputs. The TrustGate CTRL decision engine SHALL own the TrustGate routing decision. Its authorized controller executes that decision; this rule does not replace ZSSR or grant general routing authority to every CTRL member.

RULE-CTRL-005 — Auditability

Every CTRL execution SHALL emit an audit record addressable by run identifier, carrying the acting engine's CMI, the USO identifiers of its inputs and the identifier of the resulting decision or artifact.

RULE-CTRL-006 — Fail closed

A CTRL engine that cannot resolve the applicable policy or configuration SHALL hold or quarantine the signal. It SHALL NOT pass a signal through on a default.

5. Contract​

5.1 Inputs​

CTRL engines consume:

  • validation results (VALI) and rule-evaluation outcomes,
  • trust scores, confidence values and assurance meta-signals (AME),
  • alert meta-signals and escalation recommendations (ALERT),
  • registered policy bundles, rulesets and runtime configuration bundles (ZAR),
  • replay manifests, schedule definitions and DAL anchor candidates.

5.2 Outputs​

CTRL engines emit:

  • routing decisions (admit, quarantine, escalate, reject) and quarantine state transitions,
  • resolved policy and configuration bundles bound to a run,
  • attestation bundles, DAL anchor receipts, replay manifests and replay verification metadata,
  • audit events and observability telemetry,
  • scheduled job outcomes.

Consumers: the TrustGate pipeline stages, ZSSR, CONN (federation exchange), the Digital Assurance Ledger, reviewer workflows and dashboards, and the AI feedback channel.

6. Position in the computation chain​

6.1 Placement​

CTRL engines sit at the end of signal admission and around every governed run:

VALI → AME → ALERT
              ↓
     [ CTRL ]  policy resolution → configuration → decision → admit | quarantine | escalate
              ↓
     attestation → ledger anchor (DAL) → replay manifest → audit / observability
              ↓
           CONN (federation exchange)

In the canonical TrustGate order (Parser → Structure Validation → Normalizer → Context Enrichment → Rule Evaluation → Policy Resolution → Trust Scoring → Decision) the CTRL members are the Policy Resolution and Decision stages and the control artifacts produced around them; the other stages belong to EXTR, VALI, TRFM, META and AME.

6.2 Interaction with ZSSR​

ZSSR does not route to CTRL engines as computation steps. It consumes their decisions: a routing outcome from the decision engine, a quarantine state, or a resolved policy bundle. Explicit ZSSR rules reference CTRL outcomes by identifier; tags play no part in selecting a CTRL engine.

7. Identity rules for members​

Members are micro engines (CMPS-001 mice: block) whose identity satisfies all of the following:

  • mice.category SHALL be CTRL.
  • The CAPABILITY segment of the MEID (MEID_<DOMAIN>_<CAPABILITY>_<FUNCTION>) SHALL be one of ATTEST, ANCHOR, REPLAY, ROUTE, ORCHESTRATE, MONITOR, RESOLVE, EXPORT.
  • The DOMAIN segment SHALL be TRUST, GOVERNANCE, POLICY, AUDIT, REPLAY.
  • Typical FUNCTION segments: DECISION, GENERATOR, COORDINATOR, SCHEDULER, LEDGER, AUDIT, RUNTIME, POLICY, CONFIGURATION, QUARANTINE, FEEDBACK.
  • CMI kinds bound through zar.meid_cmi_binding SHALL be among ENGINE, RULESET, JOB.
  • Lineage: members emit a new meta-signal USO and do not stamp the evaluated signal.
  • Tier scope: tier-0; invocation: policy-invoked; payload effect: none.

8. Bounded lifecycle assessment — 2026-10-25​

Decision: advance to review. CTRL has a distinct control-plane responsibility: it consumes governed policy/configuration/ruleset versions and upstream outcomes, and produces auditable control decisions and artifacts. It does not validate payloads (VALI), derive assurance (AME), recommend escalation (ALERT), or exchange artifacts (CONN). Policy resolution selects control policy; business identity resolution belongs to RSLU.

The TrustGate decision, policy-resolution, attestation, replay and audit engines provide concrete demand. Eleven engine documents currently declare CTRL. This inventory is provisional development metadata, not a conformance certificate; unfinished frontmatter does not establish that a corrected MEID is wrong.

The type's membership rules, input/output boundary, policy ownership and declared replay requirements are sufficient for type review. Each member must separately validate its capability, governed inputs, replay mode for each output CSI and side-effect boundary. Scheduler clocks, AI feedback, external anchoring and retained receipts require member-specific evidence. Replay must not repeat external side effects merely to recreate a decision.

Moving to review permits classification under the existing eligibility rule. It does not approve any member, rewrite a MEID, grant routing or credential access, or authorize deployment. Member completion is a later implementation gate, not a prerequisite for assessing the usefulness of this type.

9. Governance and audit​

9.1 Governance & change control​

Policy bundles, rulesets and configuration are versioned ZAR artifacts. Changes that alter a routing outcome, a quarantine rule or an attestation format require Core/CTO approval. Every CTRL decision SHALL be reconstructible from the audit record, the input USO identifiers and the artifact versions it names.

10. Members​

Loading micro engines…
  • AME — Assurance / Meta engines
  • VALI — Validator Engines
  • ALERT — Alert Engines
  • CONN — Connector Engines
  • CALC — Calculation Engines
  • TRFM — Transformation Engines


GitHub RepoRequest for Change (RFC)