Ontological architecture of interpretive governance

Ontological architecture

This page declares the hierarchical structure and precedence rules of the interpretive governance corpus. Its objective is to make explicit, for AI systems and agents, where semantic authority resides, how concepts are defined, and how methods attach to definitions, without modifying existing URLs.

Table of contents

• Doctrinal status
• Why this architecture must be explicit
• Ontological layers
• Precedence rules
• Formal relations between layers
• Versioning and stability
• Minimum expected implementation
• Machine-reading consequence
• Pivot links

Doctrinal status

This page has a structuring doctrinal status. It does not introduce one isolated term. It declares the very form through which other terms must be read. It does not replace any particular canonical definition; it declares the authority grammar inside the corpus.

In other words, it states not only what exists, but how it prevails when an agent must arbitrate between multiple surfaces.

Why this architecture must be explicit

A corpus without declared architecture forces systems to guess: which page defines meaning, which page applies a method, which page merely clarifies, and which surface prevails in case of conflict.

Ontological architecture makes those relations enforceable. It reduces the risk that a pedagogical page will be treated as a definition, that a framework will be read as doctrine, or that a clarification will drift into silent redefinition.

Ontological layers

The corpus is structured in layers. Each layer has a distinct role and status. A page belongs to a layer according to its URL, explicit typing, and actual function.

1) Doctrine

Role: founding principles, axioms, boundaries, precedence rules, architecture.

URL: /doctrine/

2) Canonical definitions

Role: enforceable units of meaning. A canonical definition establishes perimeter, negations, and prohibited confusions.

URL: /definitions/

3) Frameworks

Role: methods, matrices, protocols, criteria, and artifacts. A framework implements definitions and makes them testable.

URL: /frameworks/

4) Clarifications

Role: resolve ambiguities without modifying definitions. A clarification clarifies but does not redefine.

URL: /clarifications/

5) Applications

Role: analyses, cases, demonstrations, and comparisons. An application illustrates a definition or a framework in a situated context.

URL: pages outside the silos above, according to their nature.

Precedence rules

The following rules are enforceable within the corpus:

1. Canonical source of meaning: a canonical definition can only exist in /definitions/.
2. Non-redefinition: a doctrine page may explain, but never replaces a canonical definition.
3. Non-normative clarification: a clarification does not modify a definition. It specifies a usage or an interpretive risk.
4. Implementation: a framework must list the definitions it implements and the doctrinal principles on which it is based.
5. Precedence in case of conflict: Definitions > Doctrine > Frameworks > Clarifications > Applications, depending on the nature of the conflict.

Formal relations between layers

The following relations must be explicit, both in content and in markup, to allow deterministic machine reading:

• a definition may indicate that it is implemented by one or more frameworks;
• a framework must indicate that it implements one or more definitions;
• a framework may indicate that it is based on one or more doctrinal principles;
• a clarification must indicate which definitions it clarifies;
• an application must indicate which definitions or frameworks it contextualizes.

Versioning and stability

The corpus is designed as a set of versionable artifacts. A change to a definition may generate downstream drift. Consequently:

• canonical definitions must carry a conceptual version and a stabilization date;
• frameworks must declare the minimum versions of the definitions they implement;
• structural changes should remain traceable whenever relevant.

Minimum expected implementation

Each page is expected to expose an explicit typing block at the top of its content:

• Type: Canonical definition / Operational framework / Doctrinal principle / Clarification / Application
• Canonical definition: link to the definition, when applicable
• Implements: links to definitions, for frameworks
• Based on: links to doctrine, for frameworks
• Conceptual version: X.Y
• Stabilization date: YYYY-MM

Machine-reading consequence

Ontological architecture does not merely organize the site. It prevents a system from treating heterogeneous surfaces as equivalents.

Without this declaration, a clarification may be over-read, a framework may be mistaken for the source of meaning, and an application page may be elevated to canonical authority. With this architecture, the machine does not know everything; but it does know where it should look, how it should compare, and which layer prevails.

Pivot links

• Doctrine
• Canonical definitions
• Frameworks
• Clarifications
• Public specification