Japanese version: CTG ROM Layout

CTG ROM Layout v0.1.1.1

This document defines the repository layout and layering rule for the Monolith CTG-ROM minimal configuration. The Monolith CTG-ROM is treated as the baseline canon for the AIKernel personality OS.

The fixed theoretical reference remains Paper 12:

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

This document does not add runtime logic. It describes how canon files, localized personality ROM descriptors, and developer diff layers are separated so that runtime VFS implementations can merge them deterministically.

1. Directory Layout

rom/\n  governance/\n    ctg.monolith.canon.md\n    ctg.monolith.canon.ja.md\n    council.logos.monolith.md\n    council.logos.monolith.ja.md\n    council.ethos.monolith.md\n    council.ethos.monolith.ja.md\n    council.pathos.monolith.md\n    council.pathos.monolith.ja.md\n    gate.decision.monolith.md\n    gate.decision.monolith.ja.md\n    gate.trajectory.monolith.md\n    gate.trajectory.monolith.ja.md\n    reject.policy.monolith.md\n    reject.policy.monolith.ja.md\n\n  locales/\n    en-US/\n      ctg.monolith.minimal.en.yaml\n    ja-JP/\n      ctg.monolith.minimal.ja.yaml

Files under rom/governance/ are canonical governance assets. Files under rom/locales/<locale>/ are localized personality ROM descriptors that point to the canonical governance assets.

The English governance files are the primary canon. The Japanese governance files are reference canon for Japanese readers and localization review.

2. Layer Model

The Monolith CTG-ROM is the base layer. Developers personalize CTG-ROMs by adding diff layers on top of this base rather than editing the base canon directly.

Developer diff layers must be additive or constraining. They may specialize metadata, locale wording, operator-facing descriptions, profile preferences, or additional references. They must not remove the CTG invariants listed below.

3. Base Canon Invariants

Every personalized CTG-ROM derived from the Monolith base must preserve these invariants:

• CTG remains a three-council model over Logos, Ethos, and Pathos.
• Ethos rejection or veto remains a hard denial boundary.
• Missing, ambiguous, inconclusive, or unknown evidence fails closed.
• Decision gate default behavior remains deny.
• Trajectory admission requires every step-level gate to admit execution.
• Governance traces remain replayable and auditable.
• Canon references remain explicit and resolvable.

If a personalization needs to violate these invariants, it is not a diff layer of the Monolith CTG-ROM. It requires a separate canon identity and migration documentation.

4. Effective Canon Path

The Monolith minimal locale descriptors resolve their canon through:

rom/governance/ctg.monolith.canon.md

Runtime VFS implementations should read the selected locale descriptor first and then resolve its canon.path into the base canon layer. The corresponding Japanese file, rom/governance/ctg.monolith.canon.ja.md, is a reference canon for Japanese review and should not silently replace the primary English canon.

5. Deterministic VFS Merge

A runtime VFS implementation should construct the mounted Personality-ROM in a deterministic order:

1. Load the base canon layer from rom/governance/.
2. Load the selected locale personality descriptor from rom/locales/<locale>/.
3. Apply zero or more developer diff layers in a stable order defined by the

runtime package.

4. Validate that base canon invariants remain intact.
5. Mount the merged Personality-ROM as read-only governance input.

Merge failure, missing canon, unresolved references, unknown enum values, or conflicting diff entries should fail closed and emit diagnostics.

AIKernel.NET does not implement this merge. Runtime packages own the VFS merge logic while AIKernel.NET provides the contract vocabulary and documentation.

6. Diff Layer Rules

Developer diff layers are intended for personalization. They should describe only the delta from the Monolith base and should not copy the full base canon.

Allowed diff examples:

• additional operator-facing profile metadata
• locale-specific wording
• extra non-conflicting canon references
• stricter gate or audit requirements
• runtime package metadata required to mount the profile

Disallowed diff examples:

• removing Ethos veto authority
• changing fail-closed behavior to fail-open behavior
• replacing Logos / Ethos / Pathos with another council set
• weakening audit or traceability requirements
• embedding runtime implementation logic into ROM contract files

7. Related Documents

• Canonical Trajectory Governance
• CTG Contract Model
• CTG Developer Guide
• Enum Handling Policy