Japanese version: CTG Developer Theory

CTG Developer Theory v0.1.1.1

Canonical Trajectory Governance (CTG) is the deterministic governance membrane used by AIKernel to decide whether a proposed step, and then a whole trajectory, remains admissible under canon-backed personality governance.

This document explains the theory in developer terms. It does not define canon rule text, council criteria, gate policy, or runtime implementation logic. The fixed theoretical reference remains the published paper:

• Paper 12: Canonical Trajectory Governance
• DOI: https://doi.org/10.5281/zenodo.20681895

AIKernel.NET exposes only the contract vocabulary: interfaces, DTOs, and enums. Runtime execution, ROM loading, VFS merge, policy evaluation, and rule interpretation belong outside this repository.

1. Mental Model

CTG is easier to review as a small deterministic pipeline:

proposal\n  -> council votes\n  -> step gate\n  -> step trace\n  -> trajectory gate\n  -> governance trace

The contract surface exists so every step in this pipeline can be replayed, audited, and compared without relying on hidden runtime state.

CTG is not a scoring model. It is not a probabilistic router. It does not let a high score in one dimension compensate for a hard denial in another. The contracts preserve observations such as confidence and risk, but those observations are trace evidence, not decision weights.

2. Three Councils

The council vocabulary is fixed to the triad represented by CouncilKind:

• Logos
• Ethos
• Pathos

These are not interchangeable with operational categories such as policy, safety, execution, or audit. Operational categories can be modeled elsewhere, but they must not replace the CTG triad in the contract surface.

Each council emits a CouncilVote DTO. The actual finite vote is carried by the CouncilVoteValue enum:

Unknown = parse or transport failure sentinel\nApprove = positive vote\nAbstain = neutral vote\nReject = negative vote

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

3. Step Gate

The paper describes the step gate as gate(l,e,p), where l, e, and p come from the Logos, Ethos, and Pathos council outcomes.

The contract surface represents the step result with DecisionGateResult and the discrete GateDecisionKind enum:

Unknown = fail-closed sentinel\nAllow = the step is admitted by the gate\nDeny = the step is closed by the gate

The important developer invariant is fail-closed determinism:

• missing canon fails closed
• unknown enum values fail closed
• missing or unresolved canon references fail closed
• Ethos rejection is a hard boundary
• confidence and risk do not change the gate decision

The exact algorithm that maps council results into an allow or deny decision is runtime-owned. AIKernel.NET only carries the inputs, outputs, reasons, and traces required for deterministic replay.

4. Trajectory Gate

A trajectory is a finite ordered set of governed steps. CTG evaluates the trajectory by preserving the ordered step trace chain and reducing it to a trajectory decision.

The contract surface represents trajectory decisions with TrajectoryGateDecisionKind:

Unknown = fail-closed sentinel\nContinue = the trajectory remains admissible\nHalt = the trajectory is closed

The theoretical invariant is product-like: the trajectory remains valid only while every required step-level gate remains admissible. A single denied step must be enough to halt the trajectory. The result should preserve the rejected step index, reasons, canon references, and diagnostics needed to explain the closure.

5. Rejection Taxonomy

RejectReasonKind is the C# canonical serialization enum for rejection categories. The ROM/YAML layer may use uppercase snake case, but C# keeps PascalCase enum names:

SafetyViolation\nLogicalInconsistency\nContextMisalignment\nIrreversibleAction\nInsufficientInformation\nOpaqueReasoning\nEthosVeto\nFailClosed\nStepDenied\nImplicitDeny

The enum does not carry rule text. Human-readable explanation and stable reason codes belong in RejectReasonInfo, together with canon references.

6. Canon References

CanonReference is a pointer, not the canon itself. It must not carry or generate rule text.

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}

DTOs use IReadOnlyList<CanonReference> because a single decision can be justified by multiple canon anchors. Runtime hosts are responsible for resolving those references against mounted ROM, VFS resources, package assets, or another trusted source.

7. Replay Contract

For developers, the minimum replay contract is:

• every council vote is carried by CouncilVote
• every step gate result is carried by DecisionGateResult
• every step trace is carried by StepGovernanceTrace
• every trajectory trace is carried by GovernanceTrace
• every rejection carries RejectReasonInfo
• every canon dependency is represented by CanonReference

Unknown values are never silently coerced. They close the decision and should be recorded according to the enum handling policy.

8. What AIKernel.NET Does Not Do

AIKernel.NET does not:

• implement council evaluation
• implement gate algorithms
• read or merge ROM files at runtime
• create canon rule text
• decide personalized diff layer semantics
• replace PDP, HATL, PPM, or replay packages

It publishes the stable vocabulary that lets those systems interoperate without smuggling implementation behavior into the contract packages.