AIKernel.NET
version: 0.1.1.1 / status: Active / edition: Draft / published: 2026-06-14 / updated: 2026-06-14

Japanese version: Canonical Trajectory Governance

Canonical Trajectory Governance v0.1.1.1

Canonical Trajectory Governance (CTG) is the contract-level governance model for checking whether an execution trajectory remains aligned with canon, policy, and operator intent. This document is the developer-facing companion to the Zenodo-published CTG paper:

The paper is the fixed theoretical reference. This document maps that theory to the AIKernel.NET contract surface and does not define canon rule bodies.

AIKernel.NET only publishes the contract vocabulary for CTG. Runtime hosts and provider packages can implement the contracts, but the contract packages remain limited to interfaces, DTOs, and enums.

1. Scope

CTG covers three questions:

  • Can a proposed step be accepted by the governance councils?
  • Can a finite gate decision be derived deterministically from those council votes?
  • Can a whole trajectory be accepted when all step-level gates are replayed?

The published contract surface is intentionally narrow:

  • interfaces live in AIKernel.Abstractions.Governance
  • records live in AIKernel.Dtos.Governance
  • enums live in AIKernel.Enums.Governance
  • canon text and rule execution are outside AIKernel.NET
  • runtime implementations are outside AIKernel.NET

2. Triadic Council Model

CTG keeps the council vocabulary as the triad:

  • Logos
  • Ethos
  • Pathos

These values are represented by CouncilKind. The triad is the stable governance vocabulary. It must not be replaced with operational categories such as audit, policy, safety, or execution in this contract surface. If those categories are needed later, they should be introduced as a separate enum rather than changing CouncilKind.

Each council emits a CouncilVote carrier and can preserve:

  • the CouncilVoteValue
  • a reason message
  • one or more CanonReference values
  • optional Confidence
  • optional RiskScore

Confidence and RiskScore are observational carriers. They exist to preserve trace evidence and must not become weights in the gate decision.

The C# enum numeric values are serialization discriminants, not the paper's mathematical vote weights. Runtime implementations map CouncilVoteValue values onto the paper's finite vote table: approve is positive, abstain is neutral, and reject is negative.

Veto is not a fourth vote value. Hard denial conditions are carried as rejection evidence, gate denial, and where applicable RejectReasonKind.EthosVeto.

3. Step Gate

The conceptual step gate is gate(l,e,p), where:

  • l is the Logos council decision
  • e is the Ethos council decision
  • p is the Pathos council decision

The contract model is deterministic and fail-closed:

  1. Missing or unknown inputs are treated as rejection evidence.
  2. An Ethos rejection closes the step gate.
  3. If Ethos does not reject, the step can be accepted only when the

    4. mapped aggregate council vote is strictly positive.

  4. Zero, negative, missing, unknown, or insufficient evidence rejects the step.

The exact runtime algorithm belongs outside AIKernel.NET. The contract package only provides the carriers required to make the decision replayable:

  • DecisionGateRequest
  • GateInput
  • DecisionGateResult
  • RejectReasonInfo
  • StepGovernanceTrace

DecisionGateRequest carries a single vote-only GateInput. It must not carry per-council L / E / P gate envelopes or a CouncilDecision payload; those belong to council evaluation and trace carriers.

The gate decision vocabulary is discrete-only: GateDecisionKind.Allow or GateDecisionKind.Deny, with Unknown reserved as a fail-closed sentinel.

4. Trajectory Gate

The trajectory gate evaluates a sequence of step governance traces. A trajectory is accepted only when every step is accepted and no step contains missing, unknown, or denial governance evidence.

The contract carriers are:

  • TrajectoryGateRequest
  • TrajectoryGateInput
  • TrajectoryGateResult
  • GovernanceTrace

The result must preserve the rejected step index and rejection reasons when the trajectory is denied. This keeps replay deterministic and allows diagnostics to explain which step closed the gate.

The trajectory decision vocabulary is discrete-only: TrajectoryGateDecisionKind.Continue or TrajectoryGateDecisionKind.Halt, with Unknown reserved as a fail-closed sentinel.

This corresponds to the paper's product semantics: a trajectory remains valid only when every step-level gate admits execution. A single denial short-circuits the trajectory.

5. Canon References

CanonReference is a DTO carrier. CTG contracts use IReadOnlyList<CanonReference> instead of a single reference because a single decision can depend on multiple canon anchors.

The normalized DTO shape is:

public sealed record CanonReference\n{\n    public string CanonId { get; init; } = string.Empty;\n    public string Path { get; init; } = string.Empty;\n    public string Section { get; init; } = string.Empty;\n    public string? Anchor { get; init; }\n    public string? ContentHash { get; init; }\n}

AIKernel.NET does not author canon rule text. Runtime hosts can resolve CanonReference values against a ROM, VFS, package resource, or other trusted source. If canon resolution fails, the governance result should fail closed.

The Monolith minimal CTG-ROM is the baseline canon for the AIKernel personality OS. Its effective canon path is resolved through the locale ROM descriptor:

rom/governance/ctg.monolith.canon.md

The repository separates the base canon layer from localized personality ROM descriptors:

  • rom/governance/ contains canon, council, gate, and reject-policy assets.
  • rom/locales/<locale>/ contains localized personality ROM descriptors.
  • runtime VFS implementations merge the base canon layer, the selected locale

    • descriptor, and optional developer diff layers into a mounted Personality-ROM.

Developer diff layers personalize the Monolith base without editing the base canon directly. They must preserve the triadic council model, Ethos veto, fail-closed behavior, default deny, and replayable trace requirements.

The paper describes CTG-ROM as a portable persona contract containing canon, root goals, prohibitions, council criteria, and trace requirements. AIKernel.NET documents the Monolith base-layer layout while keeping runtime VFS merge logic outside the contract packages.

6. Deterministic Replay

CTG is replay-oriented. Every governance decision should be reconstructable from its carriers without hidden state:

  • council inputs and outputs are carried by evaluation DTOs
  • gate inputs and outputs are carried by decision DTOs
  • step traces capture council and gate evidence together
  • trajectory traces aggregate the ordered step trace chain

Replay consumers should treat unknown enum values as fail-closed and record raw values in diagnostics or metadata according to the enum handling policy.

7. Relationship to Existing Governance

CTG complements existing PDP, policy, signed prompt, HATL, PPM, and replay vocabulary. It does not replace them.

  • PDP decides whether an operation is allowed in a policy context.
  • Signed prompt governance verifies trusted prompt artifacts.
  • HATL/HBS contracts preserve signed history and audit evidence.
  • PPM remains a mathematical research line for state-space, interference, and

    • memory-protection analysis; it is not the CTG execution gate.

  • CTG evaluates whether a step or trajectory remains canonically admissible.

These surfaces are additive. Existing v0.1.1 public interfaces remain stable.

The important separation is: CTG governs decision admissibility, HATL protects state and replay integrity, and PPM may inform future state or memory protection research.

Source: architecture/20.CANONICAL_TRAJECTORY_GOVERNANCE-v0.1.1.1.md