(In)Canon: deterministic admissibility contract
This specification defines (In)Canon as a deterministic, non-inferential admissibility layer. It documents normative terms, interface requirements, canonical output structure, and downstream obligations. It does not disclose internal rules or implementation detail.
(In)Canon does not establish truth, correctness, quality, compliance, or adequacy. It reports only whether information required for downstream judgement is explicitly present or not stated. “Admissible” means structurally permissible only.
(In)Canon reports whether evaluation can proceed without silently inserting missing structure. It records explicit commitments (verbatim, anchored) and reports presence / absence for a declared schema.
How to read this document
The following words are used as normative requirement levels.
What (In)Canon is not
(In)Canon is not an evaluation engine. It is a precondition check on whether evaluation is structurally permissible. It does not claim correctness, sufficiency, or validity of the underlying content.
Prohibited behaviours
- Interpretation of meaning
- Inference or gap filling
- Scoring, weighting, or quality judgement
Out of scope
- Coaching, rewriting, or “improving” narratives
- Criteria mapping or decisioning
- Resolving contradictions (reporting only)
This document specifies only the externally observable contract: required fields, determinism expectations, and the absence/presence semantics. Internal rule sets are intentionally undisclosed.
Input and output requirements
Input type
A single input artefact (textual or structured representation) plus a declared schema configuration.
Input assumptions
No hidden context is assumed. Only explicit content in the input is eligible for commitments.
Output type
A deterministic report containing: admissibility decision, presence/absence map, and commitment anchors.
“Admissibility” is structural permission only.
Determinism
Same input + same configuration MUST produce identical outputs (field values and ordering rules).
Input MUST include
- The source content (text or structured representation)
- A declared schema for presence checks (e.g., actor/action/time/outcome)
- A configuration identifier (or versioned profile)
Output MUST include
- An admissibility flag
- A presence map for the declared schema
- A commitment list anchored to the source (verbatim, offsets where applicable)
- A spec version identifier
Stable object shape (trade-secret-safe)
This is the recommended canonical shape. Field names SHOULD be treated as a stable interface.
Implementations MAY add fields, but MUST NOT change semantics of the required fields.
{
"spec_version": "1.0",
"config_id": "profile-01",
"admissible": false,
"reason": "Missing prerequisites for evaluation without inference",
"presence": {
"actor": "not_stated",
"action": "stated",
"time": "not_stated",
"outcome": "not_stated",
"mitigation": "not_stated"
},
"commitments": [
{
"rc_id": "RC-001",
"span": [128, 162],
"text": "procedures were followed",
"form": "assertion",
"actor_present": false,
"time_present": false
}
],
"contradictions": [],
"notes": "No scoring. No interpretation. Presence/absence and anchored commitments only."
}The commitments list MUST contain verbatim text from the input. Where offsets are used, the substring referenced by span MUST match text exactly.
How other systems MUST behave when consuming Canon outputs
Canon’s value is lost if downstream systems quietly “repair” missing structure. These obligations make the boundary enforceable.
Evidence (explicit commitments) and inference (anything added) MUST remain separable. Canon reports evidence and absence only. Any enrichment belongs in a different, explicitly labelled layer.
Where (In)Canon sits in typical systems
Before generation
- Hard gate: do not generate unless admissible (structurally permissible).
- Or: generate only from stated commitments; preserve not_stated fields as null.
Before evaluation
- Prevent scoring/judgement when prerequisites are missing.
- Expose where a human would otherwise “smooth” a narrative.
Between retrieval and generation
- Canon can be used as a precondition check on retrieved material: if the evidence does not explicitly bind actor/action/time/outcome (per schema), downstream synthesis must remain bounded or explicitly marked as inference.
INPUT -> CANON(admissibility) -> [admissible?]
yes -> downstream evaluation / extraction (bounded to commitments; structural permission only)
no -> block OR continue as explicitly-labelled inference (separate channel)
Determinism requirements (what you can test)
Canon is designed to produce repeatable outputs suitable for fixtures and regression tests.
This section specifies testable properties without exposing internal rules.
Store the input artefact, config_id, spec_version, and the full output JSON as a golden fixture. This enables deterministic regression testing even as downstream model components evolve.
Audit and defensibility framing (non-technical)
What Canon provides
- A documented boundary between evidence and inference
- Explicit absence reporting (where assumptions would be inserted)
- Deterministic artefacts suitable for audit trails
What Canon does not claim
- Truth, correctness, or completeness of the underlying facts
- Quality, competence, or acceptability judgements
- Decision-making authority
Why this matters
Many failures in governance workflows occur before “analysis” begins: the input itself cannot support evaluation without reconstructive guesswork. Canon surfaces that failure mode early and makes it loggable.
Spec evolution and compatibility
Spec versions describe the external contract only. Internal mechanisms may evolve without disclosure, provided the contract remains stable.
(In)Canon identifies structure and reports stated vs not stated. It does not assess meaning, correctness, quality, compliance, or adequacy.