Governance artifacts
Governance files brought into scope by this page
This page is anchored to published surfaces that declare identity, precedence, limits, and the corpus reading conditions. Their order below gives the recommended reading sequence.
Causal context map
/causal-context-map.json
Machine-readable projection of the CCL layer connecting triggers, latent needs, canonical surfaces and intended consequences.
- Governs
- The causal reading of content and legitimate bridges between problem, need, surface and consequence.
- Bounds
- Plausibility-based reconstructions that confuse surface topic, latent need, service and promise.
Does not guarantee: This map does not guarantee conversion, ranking, citation or adoption by a third-party model.
situational-applicability-map.json
/situational-applicability-map.json
Published machine-first governance surface.
- Governs
- Part of the corpus reading conditions.
- Bounds
- An inference zone that would otherwise remain implicit.
Does not guarantee: This file does not, on its own, guarantee system obedience.
interpretive-weighting-policy.json
/interpretive-weighting-policy.json
Published machine-first governance surface.
- Governs
- Part of the corpus reading conditions.
- Bounds
- An inference zone that would otherwise remain implicit.
Does not guarantee: This file does not, on its own, guarantee system obedience.
Complementary artifacts (1)
These surfaces extend the main block. They add context, discovery, routing, or observation depending on the topic.
authority-scope-matrix.json
/authority-scope-matrix.json
Published machine-first governance surface.
Evidence layer
Probative surfaces brought into scope by this page
This page does more than point to governance files. It is also anchored to surfaces that make observation, traceability, fidelity, and audit more reconstructible. Their order below makes the minimal evidence chain explicit.
- 01Canon and scopeDefinitions canon
- 02Response authorizationQ-Layer: response legitimacy
- 03Evidence artifactclaims.json
Definitions canon
/canon.md
Opposable base for identity, scope, roles, and negations that must survive synthesis.
- Makes provable
- The reference corpus against which fidelity can be evaluated.
- Does not prove
- Neither that a system already consults it nor that an observed response stays faithful to it.
- Use when
- Before any observation, test, audit, or correction.
Q-Layer: response legitimacy
/response-legitimacy.md
Surface that explains when to answer, when to suspend, and when to switch to legitimate non-response.
- Makes provable
- The legitimacy regime to apply before treating an output as receivable.
- Does not prove
- Neither that a given response actually followed this regime nor that an agent applied it at runtime.
- Use when
- When a page deals with authority, non-response, execution, or restraint.
claims.json
/claims.json
Published surface that contributes to making an evidence chain more reconstructible.
- Makes provable
- Part of the observation, trace, audit, or fidelity chain.
- Does not prove
- Neither total proof, obedience guarantee, nor implicit certification.
- Use when
- When a page needs to make its evidence regime explicit.
Interpretive conditioning matrix
The interpretive conditioning matrix prepares an entity before any contextual recommendation, comparison or audit campaign. It does not generate the conclusion. It makes explicit the elements needed to qualify an output as factual, conditional, comparative, insufficient or drifted.
Its unit of work is:
entity × context profile × relation × source × output modeObjectives
The matrix is used to:
- establish a dated entity baseline;
- separate invariants from contextualizable variables;
- define reproducible context profiles;
- assign every relation to a competent source;
- preserve temporality and reversal conditions;
- declare forbidden transformations;
- limit authorized output strength;
- prepare probes for the contextual fidelity protocol.
It should be completed before observing a system. Otherwise the auditor risks judging outputs retrospectively through shifting intuition.
Step 1: entity sheet
| Field | Question | Requirement |
|---|---|---|
| Identity | Which entity is targeted? | Resolve identifiers, homonyms and scope |
| Category | What material role does it perform? | Sufficient precision to prevent fusion |
| Capabilities | What can it actually do? | Documented and versioned claims |
| Exclusions | What does it not do? | Explicit limits, not inferred from silence |
| Authority | Which claims may it establish? | Scope by claim class |
| Temporality | Which state is current? | Observation date and relevant history |
The sheet must not contain only favourable attributes. Exclusions, incompatibilities and non-applicability conditions are necessary to prevent automatic recommendation.
Step 2: invariant registry
For each entity invariant, record:
| Field | Expected content |
|---|---|
invariantId |
Stable identifier |
| Canonical claim | Bounded wording |
| Claim class | Identity, capability, policy, limit, constitutive relation |
| Competent source | Source or source combination |
| Version | Version or state date |
| Wording tolerance | Acceptable linguistic variants |
| Critical contradictions | Incompatible formulations |
| Expiry | Date or event requiring review |
An invariant is not a sentence to repeat. It is a material constraint to preserve.
Step 3: context profiles
A context profile must be closed, named and reproducible. It may remain impersonal.
| Dimension | Examples | Rule |
|---|---|---|
| Intent | choose, verify, compare, plan | One primary intent per profile |
| Audience | family, technical team, regulated buyer | Do not generalize to every audience |
| Place | area, jurisdiction, destination | Declare exact scope |
| Time | date, hour, season, duration | Declare validity window |
| Use | car-free stay, local integration | Declare concrete scenario |
| Constraints | budget, accessibility, compliance | Separate constraints from preferences |
| Preferences | quiet, lively area, control | Attribute them to the user |
| Dependencies | transit, event, third-party supplier | Identify external sources |
| Missing data | material unknowns | Do not turn them into defaults |
Each profile must state what distinguishes it from other profiles. Nearly identical profiles must not be used to manufacture artificial variation.
Step 4: contextual relation registry
For each contextual relation, record:
| Field | Function |
|---|---|
relationId |
Relation identifier |
| Subject | Concerned entity |
| Relation | Distance, compatibility, availability, dependency or other |
| Object | Destination, event, rule, audience or constraint |
| Source | Competent authority |
| Observed on | Collection date |
| Valid until | Expiry or next verification |
| Scope | Time, place, audience and use |
| Uncertainty | Low, medium, high or unqualifiable |
| Reversal condition | Change that may alter the conclusion |
| Permitted inference | Authorized interpretive use |
| Forbidden inference | Prohibited generalization or ranking |
The matrix must distinguish absence of a relation, absence of evidence and absence of observation. These states are not equivalent.
Step 5: output modes
| Mode | Authorized when | Typical wording | Forbidden when |
|---|---|---|---|
| Factual description | Direct claim and competent source | “The entity has X.” | Source or state uncertain |
| Bounded relation | Verified relation and preserved scope | “At T, X relates to Y under C.” | Date or object missing |
| Conditional relevance | Several relations support local fit | “Appears relevant for C, subject to Z.” | Reversal condition unknown |
| Bounded comparison | Explicit criteria and symmetrical data | “Under X, A is closer than B.” | Incomplete set or incompatible metrics |
| Qualified recommendation | Sufficient comparison, arbitration and uncertainty | “A is preferred under C for X and Y.” | Criteria or alternatives insufficient |
| Clarification | Material data missing | “Specify X before concluding.” | Question already resolved |
| Abstention | Insufficient evidence or critical conflict | “Available data does not support a conclusion.” | A bounded answer remains possible |
Textual fluency does not authorize a stronger mode. Every transition requires more context and evidence.
Step 6: forbidden transformations
The matrix must explicitly declare forbidden derivations. The minimum core includes:
| Transformation | Legitimate input | Forbidden output |
|---|---|---|
| Condition → property | Compatible under C | Intrinsically suitable |
| Local relation → global superiority | Closer to X | Better located in general |
| Preference → truth | Preferred by this user | Objectively better |
| Temporary state → permanent property | Closed until T | Always unavailable |
| Missing data → implicit value | Information unknown | Capability assumed |
| Applicability → recommendation | May fit under C | Must be chosen |
| Documentation → superiority | Better documented | Better product |
| Repetition → evidence | Often stated by models | Established fact |
These transformations become negative tests in the protocol.
Step 7: reversal conditions
A reversal condition is data whose change may alter the conclusion without changing the entity. Examples include:
- schedule change;
- option unavailability;
- new accessibility constraint;
- different jurisdiction;
- revised budget;
- interruption of an external dependency;
- changed group composition;
- policy or event expiry.
For every candidate conclusion, the matrix asks:
What minimal context change would make this conclusion false, insufficient or weaker?
A conclusion with no identifiable reversal condition may be an invariant, a tautology, an excessive generalization or a poorly specified statement.
Condensed example: hotel and car-free stay
| Element | Declaration |
|---|---|
| Entity | Hotel H, identity resolved |
| Invariants | Address, no parking, room categories, policies |
| Profile | Two adults, October 14–17, no car, event at 8 p.m. |
| Relations | Station distance, service schedule, route to event |
| Sources | Hotel site for policies, transit operator for schedules |
| Reversal condition | Service interruption after 10 p.m. |
| Admissible output | Conditional relevance |
| Forbidden output | “Best hotel in the city” |
The sheet does not recommend the hotel. It declares the material needed to produce and evaluate a situated conclusion.
Matrix governance
Each version should preserve:
- author or preparing system;
- date;
- sources;
- changes since the previous version;
- added, removed or revised invariants;
- active and expired profiles;
- stale relations;
- boundary decisions;
- unresolved cases.
A matrix prepared by the entity may document its canon and policies. It must not self-evaluate external reputation or decide comparative superiority on its own.
Output to the protocol
The matrix produces a test package, not a score. The package contains:
- invariants to preserve;
- profiles to compare;
- expected relations;
- traps and forbidden transformations;
- inversions to test;
- permitted output modes;
- clarification and abstention criteria.
The contextual fidelity protocol uses this package to build a reproducible campaign.
Limits
The matrix does not prove that a model will use context correctly. It does not guarantee recommendation, measure commercial performance or replace external source auditing. It structures test conditions and makes gaps classifiable.