An external framework does not govern the canon

Status of this position

This page is a public projection of a proposed architectural position. It explains a boundary intended for specification in the normative doctrinal repository; it does not replace that specification or claim that an external-integration mechanism is already active in production.

The position is:

An external framework may qualify a risk, mitigation, obligation or mapping. It does not directly govern the internal canon and cannot widen the permissions derived from it.

The rule applies to risk taxonomies, standards, regulatory frameworks, mitigation databases, Codebooks, brand manuals and other imported formalisms.

1. Three authorities that must no longer be conflated

A governed architecture must distinguish at least three planes.

1.1 External reference authority

It originates from an external institution, standard, author or organization. It is authoritative over its own document: vocabulary, categories, versions, licence and declared scope.

It may be used to:

• name a recognized risk type;
• compare frameworks;
• identify a control family;
• document an obligation or practice;
• establish shared vocabulary with auditors or partners.

That authority does not automatically extend to another organization’s internal claims.

1.2 Internal canonical authority

It determines which sources govern the organization’s identity, claims, terms, constraints and precedence rules.

It answers different questions:

• which entity is concerned;
• which Claim is admitted;
• which source has authority over that class;
• which limits or exclusions apply;
• which rule adjudicates a conflict;
• which information may be projected in a given situation.

An official source may be canonical for identity, published doctrine or a declared limitation. It does not thereby become the absolute arbiter of reputation, external criticism or objective truth.

1.3 Operational decision authority

It belongs to the mechanism applying compiled rules to a concrete interaction. It does not invent permissions. It selects only from what higher layers already authorized.

This authority may decide to:

• admit information;
• bound it;
• attach a constraint;
• request clarification;
• produce a legitimate non-response;
• record the event in the evidence chain.

The runtime must not become the judge of its own policy. It executes a deterministic projection produced from previously compiled authorities and rules.

2. The Core remains closed to five objects

The v0.1 proposal contains only five objects:

1. Entity;
2. Claim;
3. Term;
4. Constraint;
5. Precedence.

Their small number is a control property, not an accidental limitation.

An external framework does not create an additional Risk, Control, Framework, Codebook or Profile object in the Core. Those concepts may exist in an external registry, mapping matrix or projection, but they do not change the canonical model.

This closure prevents every new integration from imposing:

• its ontology;
• its states;
• its lifecycle;
• its priority rules;
• its ambiguities;
• its technical dependencies.

The five objects must be sufficient to express the internal effects of a mapping.

Example: an external risk may justify a candidate Constraint requiring a certification date before delivery. The external risk is not the Constraint. It is the referenced justification. The Constraint enters the Core only after an authority decision and admission under internal rules.

3. Core states must not be contaminated

Canonical states remain:

• allowed;
• conditional;
• forbidden;
• deprecated.

An external mapping may have its own workflow state, such as proposed, reviewed, accepted, rejected or superseded. That status belongs to the mapping registry, not the Core.

The distinction matters.

A condition that is not satisfied or cannot be evaluated makes the Claim non-admissible in the situation. It does not automatically turn the Claim into forbidden. The forbidden state must remain reserved for an explicit prohibition issued by the competent authority.

Similarly, a high-risk category does not automatically make every connected Claim forbidden. It may require stronger evidence, qualification, escalation or non-response. The decision depends on context and internal rules.

4. A mapping is a derived projection

The relation between an external framework and the Core must be represented as a versioned, reversible mapping.

It may declare:

• the external namespace;
• the risk or control identifier;
• snapshot version or date;
• source and licence;
• targeted internal failure mode;
• affected Core objects;
• authority approving the mapping;
• applicability conditions;
• expected evidence;
• residual limitations.

It must also declare:

canonical: false

This field does not imply that the external framework is unreliable. It states that the framework does not hold authority to define the internal canon.

An accepted mapping may influence governance policy or projection construction. It remains removable or replaceable without rewriting the Core objects it references.

5. Non-widening rule

The non-widening axiom applies throughout the chain:

A lower layer must never widen permissions granted by a higher layer.

Consequently:

• an external framework cannot authorize a Claim the canon does not authorize;
• a mapping matrix cannot neutralize a Constraint;
• a projection cannot add meaning absent from admitted objects;
• the runtime cannot complete an unsatisfied condition;
• fluent restitution cannot be reclassified as a legitimate answer after the fact;
• an aggregate metric cannot erase an unsatisfied necessary condition.

Exceptions must be explicit, local and authorized by a higher-level rule. An implicit exception is ungoverned widening.

6. Relationship with a Codebook

A Codebook may play two valid roles, but not simultaneously.

6.1 Bootstrap source

The Codebook is analyzed and normalized into the five Core objects. Each imported element receives provenance, authority, status and, where required, human review.

After that step, the Codebook does not remain the runtime’s operational dependency. Later changes follow the Core authority process.

6.2 Regenerated view

The Codebook becomes a readable representation produced from the Core. It may support human consultation, bounded editing or exchange, but it must not automatically re-inject its own output as new truth.

An unarbitrated bidirectional loop is forbidden because it makes it impossible to determine which surface governs the other.

The same rule applies to a risk registry: controlled import into an external namespace, followed by approved mappings. Never a live synchronization capable of mutating the Core without a decision.

7. Epistemic status accompanies every transformation

An architecture able to import frameworks and use model-based classification must preserve the nature of each item of knowledge.

At minimum, it distinguishes:

• source-declared: explicitly published by the cited authority;
• deterministically derived: produced by a reproducible rule;
• model-classified: a probabilistic output;
• human-reviewed: examined by an identified person;
• interaction-observed: describing an event or restitution within a defined window.

An item may carry several successive statuses, but their chain must be preserved.

A model classification must at least record:

• provider and model;
• available version;
• protocol or instructions;
• date;
• corpus used;
• score or relevance level;
• human-review status;
• known disagreements.

No confidence score automatically converts a classification into canonical fact.

8. The framework is captured, never queried live by the runtime

A serious integration uses a local, versioned snapshot.

The minimum flow is:

selected external source
        ↓
dated snapshot
        ↓
hash
        ↓
licence and attribution
        ↓
external normalization
        ↓
mapping review
        ↓
compilation
        ↓
authorized projection

The runtime must not query an external database directly when delivering an answer. Such a dependency would allow uncontrolled mutation, prevent state reproduction and create ambiguity about the version actually applied.

A new framework release triggers comparison. It never automatically replaces the active version.

9. Governance and evidence cycle

The external framework participates in a broader loop:

Authority
    → admissibility
    → projection
    → delivery
    → restitution
    → deviation
    → conformance
    → ledger

Projection may be represented as:

P = f(A, G, I, C)

where:

• A is authority and admitted canonical objects;
• G is the applicable governance policy;
• I is intent or request class;
• C is context, including audience, channel, jurisdiction and time;
• P is the authorized projection.

The external framework may inform G. It does not replace A.

Restitution R is then compared with P:

Δ = g(P, R)

Conformance Q qualifies the deviation under governance:

Q = h(Δ, G)

A ledger observation may trigger review of policy or a mapping. It does not directly change the five objects.

10. Contradictions and compilation failures

When an external framework conflicts with internal authority, the system must not resolve the issue through textual proximity or averaging.

Minimum rules are:

• an external authority remains bounded to its own object;
• a mapping identifies the relevant Claim class;
• an explicit Precedence rule adjudicates comparable authorities;
• two contradictory rules at the same authority level cause compilation failure;
• a mapping whose applicability cannot be evaluated remains inactive;
• non-response is preferable to an invented permission.

Compilation failure is a safety mechanism. It prevents contradiction from becoming an arbitrary runtime decision.

11. What this position prohibits

This position prohibits the following derivations:

1. treating an external taxonomy as internal authority by default;
2. creating a new Core object for every imported framework;
3. promoting a model classification to canonical fact without review;
4. connecting the runtime to a live external source;
5. letting an observation mutate the canon directly;
6. using a declared mitigation as evidence of effectiveness;
7. claiming global compliance from a partial mapping;
8. allowing a lower layer to widen a higher-layer permission.

12. Architectural consequence

An interoperable system is not one that absorbs every framework into its core. It is one that can:

• capture its version;
• preserve attribution;
• keep it in an external namespace;
• make a mapping explicit;
• submit that mapping to internal authority;
• compile a control without widening permissions;
• measure a result without confusing observation and attestation;
• remove or replace the mapping without destabilizing the Core.

The value of the external framework is preserved, while its jurisdiction remains bounded.

Final rule

The canon declares what the organization is authorized to assert and under which constraints. The external framework explains why certain failures matter or which control families exist. The matrix connects the two. The runtime executes the compiled decision. The audit measures restitution. The ledger preserves bounded evidence.

None of these planes should absorb the others.