Commercial use starts where reliance starts
(In)Canon is used in workflows where outputs must be defensible. It provides a deterministic admissibility report upstream of scoring, analytics, legal judgement, or LLM generation.
In production settings, (In)Canon is not a concept. It is a practical artefact generator. The value is that it produces a stable, auditable admissibility output that can be stored, attached to decisions, and reused as a defensible asset over time.
- Asset: a deterministic admissibility record that can travel with reports, tickets, cases, and model outputs
- Control: a documented boundary between stated evidence and supplied reconstruction
- Durability: repeatable behaviour that remains stable across vendor, model, and policy changes
(In)Canon does not establish truth, correctness, quality, compliance, or adequacy. It reports only whether required structural elements are explicitly present or not stated. “Admissible” means structurally permissible only.
If an output can be challenged later, you need an explicit boundary between what was stated and what was supplied. The rationale lives on the Why page. This page shows where it plugs in.
Admissibility record
A deterministic structural permission output that can be stored and referenced later when decisions are challenged.
Audit attachment
A portable artefact for governance and assurance that makes absence explicit without altering downstream judgement.
Regression fixture
A stable output for testing that model, vendor, or pipeline updates do not silently change admissibility behaviour.
Inputs (text / tables / objects)
↓
(In)Canon: admissibility (stated / not stated)
↓
Reconstruction (optional, explicit, logged)
↓
Interpretation (scoring / analytics / legal judgement / generation)
Teams
- LLM product and platform teams
- Governance, risk, and audit functions
- Legal and eDiscovery operations
- Healthcare documentation and assurance teams
- HR and evaluation panels
- Research synthesis and evidence teams
When they reach for it
- When they need a deterministic precondition before automation
- When multiple reviewers disagree due to unlogged “assembly”
- When auditability and traceability are non-negotiable
- When model updates must not change admissibility behaviour
In commercial deployments, the deliverable is not a promise of correctness. It is a dependable upstream control. Organisations buy (In)Canon when they need a deterministic admissibility artefact that can be relied upon, repeated, and audited as a product output.
These are insertion points where a deterministic admissibility layer adds value without changing the organisation’s judgement model.
LLM products and copilots
- Gate inputs before generation.
- Prevent schema-filling by keeping not stated fields explicit.
- Use deterministic outputs as regression fixtures across model changes.
eDiscovery and disclosure operations
- Separate extracted commitments from assembled narrative.
- Log where reconstruction is required before conclusions are formed.
- Support defensible workflows without hidden assumptions.
Governance, audit, and assurance
- Attach an upstream admissibility artefact to reports.
- Make absence explicit without judging downstream interpretation.
- Shift audit visibility earlier in the pipeline.
Healthcare documentation and safety cases
- Surface structural omissions in incident narratives and handovers.
- Prevent implied timeline and agency being treated as stated.
- Produce assurance-friendly outputs in constrained environments.
HR evaluation and job matching
- Expose where claims lack explicit scope, time, or outcome.
- Reduce disputes by separating text-evidence from supplied interpretation.
- Preserve panel judgement while clarifying reliance conditions.
Research synthesis and evidence review
- Detect thin reporting before coding and synthesis.
- Separate interpretive labour from reconstructive labour.
- Record absence as a pre-synthesis artefact.
The commercial effect is simple: downstream teams receive a stable admissibility output that tells them what is stated and what is not stated, so they can act without silently importing assumptions. This reduces disputes, supports audit, and makes change safe.
Typical insertion points:
Pattern A: Hard gate
If inadmissible, do not proceed. Route to clarification or an explicit reconstruction step. Inadmissible is not a judgement on truth. It means required structure is not explicitly present.
- Best for regulated outputs and high-stakes workflows
- Prevents high-confidence automation on low-structure inputs
Pattern B: Constrained continuation
Proceed, but enforce nulls where structure is not stated and require explicit handling. Absence remains explicit and auditable.
- Best for assistive tools where partial output is still useful
- Absence remains explicit and auditable
{
"spec_version": "1.0",
"admissible": false,
"presence": {
"actor": "not_stated",
"action": "stated",
"time": "not_stated",
"outcome": "not_stated"
},
"required_handling": "request_clarification_or_log_reconstruction"
}Integration is designed to be vendor-agnostic. (In)Canon does not replace judgement systems. It produces an upstream admissibility artefact that can be consumed by existing products, pipelines, and operating models.
Deployment options
- API integration for platforms and pipelines
- On-prem or offline constraints where required
- Deterministic logs for assurance and regression testing
- PII constraints and governance boundaries supported
Commercial distinctiveness
- Determinism enables repeatability and stable fixtures
- Absence is a first-class output, not an error to hide
- Works upstream of any model, vendor, or scoring framework
- Prevents implied content being treated as stated evidence
The admissibility record is reusable. It can be stored alongside outputs and re-checked after model upgrades, policy changes, or disputes. This turns a one-off assessment into a durable artefact that strengthens operational defensibility.
This is what is exposed for evaluation and integration. Internal rules are intentionally not disclosed.
- Admissible / not admissible flag (structural permission only)
- Presence map (stated vs not stated)
- Anchored explicit commitments (verbatim where applicable)
- Traceability fields (e.g., offsets, audit labels)
The output is intentionally contract-level. It is designed to be evaluated, integrated, and relied upon as a product artefact without requiring trust in interpretation. This is why it fits commercial environments where defensibility matters.
What it does not do
- No interpretation of meaning
- No inference or gap-filling
- No scoring, weighting, or quality judgement
- No decision-making
What it protects
- Evidence/inference separability
- Honest starting conditions for analysis
- Upstream audit visibility
- Reliability under change
This boundary is what makes (In)Canon deployable. By refusing interpretation and preserving stated versus not stated, the output remains stable, defensible, and safe to rely on in regulated and high-stakes contexts.
(In)Canon identifies structure and reports stated vs not stated. It does not assess meaning, correctness, quality, compliance, or adequacy.