Purpose

This document replaces the prior constraint support documents with one integrated canonical reference for Substrate and domain systems such as language acquisition, legislative drafting, legal analysis, education, governance, and future domain modules.

It combines:

Substrate Canon v2
Constraint consolidation work
Promotion criteria and promotion engine
Constraint evaluation engine
Language Acquisition Canon v1
Literature-grounded Canon v3
PR9+ artifact-testing implications

The goal is not to create a philosophical theory of constraints. The goal is to create an operational governance layer that can decide what may exist, what may proceed, what may be promoted, what must be blocked, and what must be preserved as failure.

Part I — Constraint Foundations

1. What a Constraint Is

A constraint is not merely a rule, preference, instruction, policy, rubric, score, warning, or suggestion.

A constraint is a system-defining condition that determines:

what may exist
what may be admitted into shared state
what may act
what may change
what may be reused
what may be promoted
what must be blocked, escalated, revised, or deprecated

A constraint becomes meaningful only when it has consequence. If it cannot block, alter, route, require validation, trigger escalation, or preserve failure, it is not yet a governed constraint. It is commentary.

2. Why Constraints Are Easy to Overlook

Constraints are often overlooked because generative systems make output feel like progress. Models can produce fluent text, plausible artifacts, apparent reasoning, and helpful suggestions before the system has earned trust.

This creates a dangerous inversion:

Output appears before governance.

Without constraints:

capability is mistaken for correctness
generated text becomes apparent knowledge
validation becomes optional
failure is smoothed away
authority boundaries collapse
artifacts accumulate without admission control
models act beyond their capability envelope
systems scale faster than control

Substrate exists to prevent that inversion.

3. Core Constraint Thesis

Substrate is a system for converting weak signals, claims, failures, rules, and human judgments into durable, validated, enforceable governance artifacts.

The recurring lifecycle is:

signal → claim → artifact → evidence → validation → promotion → enforcement → monitoring → revision

The model proposes. The artifact preserves. Evidence supports. Validation tests. Constraint bounds. Promotion grants authority. Harness enforces. Human or institution authorizes. Audit remembers.

Part II — Core System Laws

These are non-negotiable invariants. If violated, the system is not governed.

C-01 — Capability ≠ Correctness

Systems may produce useful outputs that are incorrect.

Implications:

no output is trusted by default
all durable outputs require validation status
apparent usefulness cannot substitute for evidence

C-02 — No Validation ⇒ No Execution

Any action without validated constraints must not proceed.

Implications:

default state is block or defer
missing validation is not neutral
execution requires admissibility before usefulness

C-03 — Outputs Are Not Knowledge

Generated outputs must not become durable artifacts or shared system knowledge without validation.

Implications:

no artifact enters shared state without validation status
no reuse of unvalidated artifacts as authority
generated content must remain provisional until admitted

C-04 — Enforcement Defines Governance

Trace, logging, explanation, and visibility do not constrain behavior by themselves.

Implications:

constraints must block, alter, route, require review, or trigger escalation
advisory rules are not sufficient for governance
enforcement point must be explicit

C-05 — Constraint Defines Feasibility

Constraints define what is admissible before quality is evaluated.

Implications:

first ask: may this proceed?
only then ask: is this good?
hard constraints are non-compensatory

C-06 — Authority Must Be Externalized

The system being governed cannot be the sole authority that governs itself.

Separate:

generation
validation
authorization
execution
audit

C-07 — Failure Must Be Preserved

Failures are system inputs, not waste.

Implications:

no silent correction
failures must be recorded, classified, and reusable
failure traces feed new validation and constraints

C-08 — Scaling Expands Risk Faster Than Control

Expansion increases failure surface faster than oversight.

Implications:

no scaling without validated control layer
new capability requires new constraint coverage
deployment expands validation burden

C-09 — Constraint Conflict Is Real

Constraints may collide.

Implications:

conflicts must be explicit
conflicts must be tracked
unresolved conflicts must be escalated, deferred, or blocked

C-10 — Context Binds Validity

A constraint is valid only within a declared context.

Implications:

no universal application without scope definition
constraints must state where they apply and where they do not
context drift requires revalidation

C-11 — Capability Must Be Bounded

Systems must operate inside explicit capability envelopes.

Implications:

no unconstrained tool access
no implicit delegation
action space must be bounded by role, authority, context, and reversibility

C-12 — Irreversibility Requires Stronger Constraint

Actions that cannot be undone require stricter validation and authorization.

Implications:

higher evidence threshold
independent validation
explicit decision event
stronger pre-action gate

Part III — Constraint Artifact Canon

A constraint must be represented as an artifact.

Required Constraint Artifact Fields

ID
Statement
Type
Regime
Scope
Context assumptions
Source
Evidence
Validation method
Enforcement point
Enforcement mechanism
Failure response
Authority
Capability envelope
Conflicts
Dependencies
Lifecycle state
Promotion status
Revision history
Owner

Minimum Valid Constraint

A constraint is minimally valid only if it has:

clear statement
scope
source
evidence or evidence requirement
validation status
enforcement point or explicit note that enforcement is not yet defined
lifecycle state

If these are missing, it may be a signal or candidate, but not a supported or enforceable constraint.

Part IV — Constraint Types

1. By Strength

Hard Constraint

Cannot be offset by utility, confidence, popularity, or convenience.

Example: no irreversible external action without explicit authorization.

Soft Constraint

Influences ranking, preference, priority, or routing, but does not automatically block.

Advisory Constraint

Guides behavior but has no enforcement consequence. Advisory constraints must not be mistaken for governance.

Latent Constraint

A constraint implied by repeated failure or observed pattern but not yet formalized.

Non-Compensatory Constraint

A special hard constraint: failure on this dimension cannot be compensated by success elsewhere.

2. By Regime

epistemic: truth, evidence, claim validity
operational: execution, tools, workflow
legal: law, regulation, formal authority
social: norms, roles, stakeholder legitimacy
ethical: harm, dignity, fairness, consent
educational: learning progression, cognitive load, feedback validity
organizational: roles, approvals, accountability
technical: schemas, APIs, runtime limits, security
governance: promotion, authority, lifecycle, audit

3. By Function

admission constraint: what may enter shared state
execution constraint: what may act
validation constraint: what must be tested
promotion constraint: what may gain authority
scope constraint: where something applies
authority constraint: who may decide
capability constraint: what tools/actions are allowed
conflict constraint: what happens when rules collide
failure constraint: what must be preserved
lifecycle constraint: when something must be revised or deprecated

Part V — Validation Modes

Validation must be typed. “Validate this” is not enough.

1. Evidence-Based Validation

Used for factual claims.

Requires:

claim isolation
source evidence
evidence sufficiency
contradiction check
provenance

2. Executable Validation

Used when a check can be run.

Examples:

schema validation
unit tests
program execution
formal verifier
planner
calculator
rule engine

Prefer executable validation over model judgment where available.

3. Comparative Validation

Used when selecting among candidates.

Requires:

candidate set
comparison criteria
selection rationale
failure if better candidate was generated but rejected

4. Adversarial Validation

Used to test failure under pressure.

Includes:

prompt injection
adversarial examples
contradiction prompts
stress cases
malicious or malformed input
boundary violations

5. Proxy / Metric Validation

Used when direct truth is unavailable.

Requires:

proxy declaration
Goodhart risk
metric conflict tracking
periodic revalidation

6. Human / Authority Validation

Used when judgment, legitimacy, culture, law, domain expertise, or irreversible consequences are involved.

Requires:

named authority or authority class
decision basis
trace
limits of authority

7. Consensus Validation

Used when agreement among actors, validators, nodes, or institutions matters.

Requires:

voting or quorum rule
ordering rule
conflict rule
rollback or escalation path

8. Runtime Validation

Used after deployment or execution.

Requires:

monitoring
violation detection
rollback / mitigation
revision trigger

Part VI — Constraint Evaluation Engine

The evaluation engine determines whether an object may proceed.

It does not ask:

Is this best?

It asks:

Is this admissible?

Inputs

Every evaluation begins with an object:

object_id
object_type
statement
requested_transition
context
actor
authority
evidence
trace
capabilities_requested
risk_level
reversibility

Object types may include:

claim
artifact
action
promotion
delegation
model output
system change
domain feedback
legal draft
learning artifact

Outputs

ALLOW
ALLOW_WITH_CONSTRAINTS
DEFER
ESCALATE
BLOCK

Non-action is a valid output.

Evaluation Order

Visibility check
Trace check
Context match
Authority check
Capability envelope check
Evidence check
Hard constraint satisfaction check
Conflict check
Irreversibility check
Enforcement binding check
Decision event check
Trace update

No Silent Pass Rule

Every ALLOW must include:

constraints checked
evidence basis
trace update

Allowed is itself an artifact.

Part VII — Promotion Canon

Promotion is not reward.

Promotion is transfer of authority.

Each promotion increases:

burden
traceability
evidence requirement
validation requirement
enforcement requirement
accountability

Promotion Levels

Signal
Candidate
Supported
Validated
Enforced
Canonical
Deprecated

Level Definitions

0 — Signal

An observed pattern, failure, intuition, literature note, or candidate rule.

Minimum:

observed or stated
not yet structured

1 — Candidate

A clear proposed constraint.

Requires:

one clear statement
at least one source
provisional scope

2 — Supported

A candidate with independent support.

Requires:

two independent sources, or
one strong empirical/failure case

3 — Validated

A supported constraint that has been tested.

Requires:

explicit validation method
reproducible evidence or expert review
conflicts recorded

4 — Enforced

A validated constraint with operational consequence.

Requires:

enforcement point
enforcement mechanism
failure response

5 — Canonical

An enforced constraint that becomes system authority.

Requires all:

repeated necessity
cross-context validity
conflict stability
independent validation
clear enforcement
lifecycle owner
revision path

6 — Deprecated

A constraint that lost authority.

Triggered by:

invalidation
better replacement
context change
conflict resolution
supersession

Promotion Blocking Conditions

A constraint cannot be promoted if:

statement is ambiguous
source is missing
scope is unclear
conflicts are hidden
validation is absent at validated-or-higher levels
enforcement is undefined at enforced-or-higher levels
it depends solely on model behavior
it cannot be tested

Promotion Outputs

PROMOTE
PROMOTE_WITH_LIMITS
DEFER_PROMOTION
ESCALATE_PROMOTION
BLOCK_PROMOTION
DEPRECATE

Part VIII — Falsification and Negative Testing

A constraint is not stable until attempts have been made to break it.

Falsification Questions

For every proposed constraint, ask:

Can this fail in a simple case?
Can it fail under adversarial input?
Can it fail under scale?
Can it fail under ambiguity?
Can it fail under conflicting constraints?
Can it fail because of authority confusion?
Can it fail because evidence is weak?
Can it fail because the wrong validation mode was used?
Can it fail because the system generated a good candidate but selected a bad one?
Can it fail because enforcement is advisory rather than blocking?

Negative Test Types

contradiction test
malformed input test
adversarial prompt test
boundary / authority test
missing evidence test
context mismatch test
irreversible action test
metric gaming test
selection failure test
degradation / drift test
replay / reproducibility test
human escalation test

Falsification Result States

survives test
survives with limits
fails and must be refined
fails and must be downgraded
fails and must be deprecated
requires escalation

Part IX — PR9+ Constraint Tests

PR9+ is where Substrate must prove that artifacts, claims, validation, and constraints are real mechanisms rather than useful prose.

PR9 Artifact Quality Test

Purpose:

Determine whether an artifact is admissible, reusable, and capable of constraining downstream behavior.

Test Object

Any PR9 artifact, evaluation report, extracted artifact, reusable component, or claimed quality mechanism.

12 Checks

Score each 0–3:

0 = absent
1 = implicit / weak
2 = explicit
3 = enforced or tested

Typed unit: What is being validated?
Decomposition: Can it be broken into testable units?
Evidence binding: Which parts require evidence?
Validation mode: Which validation mode applies?
Loop: Does validation retry, revise, stop, or fail?
Trace: Is lineage/process preserved?
Executable constraint: Which checks are hard-coded?
Boundary protection: Can input/tool/user text hijack authority?
Adversarial robustness: What negative test attacks it?
Selection failure: Could a better candidate exist but be rejected?
Multi-metric evaluation: What dimensions besides correctness matter?
Failure preservation: Are failures classified and retained?

Scoring

0–17: weak artifact
18–26: useful context
27–31: high-quality artifact
32–36: enforceable system component

PR9 Stop Condition

Stop progression if:

artifacts are not interpretable
artifacts are not reusable
artifacts do not constrain output
failure is not preserved
validation is not reproducible

PR10 Reuse Mechanism Test

Purpose:

Prove artifact reuse changes output causally, not by hidden context or prompt contamination.

Checks:

artifact used explicitly
baseline without artifact
output delta observed
delta attributable to artifact
negative case where artifact should not apply
reproducibility by another actor

PR11 Loop Validation Test

Purpose:

Prove the full loop works:

artifact → reuse → changed behavior → validation → failure capture → improved artifact

Checks:

loop executable end-to-end
improvement causal
negative validation included
failures preserved
no hidden human correction masquerading as system behavior
reproducible across cases

Part X — Domain Constraint Canon

Substrate domains inherit the core canon, then add domain-specific constraints.

Domain Canon Rule

A domain canon must declare:

domain object types
domain failure modes
domain validation modes
domain authority boundaries
domain irreversibility risks
domain promotion rules
domain-specific metrics

Domain constraints cannot override core system laws. They can only refine, specialize, or strengthen them.

A. Language Acquisition Domain Canon

L-01 — Language Learning Is Controlled Skill Acquisition, Not Conversation

A language module must not be treated as open AI chat. It must structure practice through constrained tasks, observable attempts, feedback, reuse, and validation.

L-02 — Every Learning Interaction Requires an Interaction Contract

Each task must declare:

mode
target skill
allowed input
expected output
evaluation method
success condition

L-03 — Scenarios Are the Primary Learning Container

Practice should occur inside bounded, repeatable scenarios with roles, goals, vocabulary, target forms, cultural context, and failure branches.

L-04 — Learner Attempts Must Be Captured as Artifacts

Every meaningful learner output should preserve:

original attempt
context
target skill
correction
validation state
reuse history

L-05 — Feedback Is a Claim, Not a Message

Every correction must state:

what is wrong
why it is wrong
evidence
rule or pattern
confidence
next validation task

L-06 — Feedback Must Be Validated Through Learner Action

A correction is not proven useful until the learner repairs, reuses, transfers, or stabilizes the corrected form.

L-07 — Repair Is a Bounded Learning Loop

The system must support:

attempt → hint → retry → correction → validation

But must limit unproductive guessing and over-assistance.

L-08 — Scaffolding Must Be Staged

Feedback should move:

hint → partial scaffold → guided answer → explicit correction

It should not jump immediately to full answer unless necessary.

L-09 — Skills Must Be Represented in a SkillGraph

Language knowledge should be decomposed into learnable units with dependencies:

vocabulary
grammar
pronunciation
syntax
pragmatics
cultural convention

L-10 — Learner State Must Be Evidence-Based

A learner does not know a skill because they saw it once. Mastery requires evidence across:

recognition
guided production
independent production
transfer
retention

L-11 — Evaluation Must Be Granular

A sentence or utterance is not simply right or wrong. Evaluation must decompose errors by layer:

phonological
lexical
grammatical
syntactic
pragmatic
cultural

L-12 — Transfer Must Be Tracked Explicitly

Progression must test movement across levels:

repeat
substitute
recombine
cross-scenario use
spontaneous use

L-13 — Cognitive Load Must Be Constrained

Tasks must not introduce too much novelty at once. The system should control:

new vocabulary
new grammar
new context
feedback density

L-14 — Pronunciation Feedback Must Be Conservative

Speech/tone feedback requires:

confidence thresholds
granular diagnosis
fallback behavior

Low-confidence pronunciation feedback must not be presented as authoritative.

L-15 — Authority Boundaries Must Be Explicit

AI may generate, scaffold, and propose. But culturally sensitive, dialectal, ambiguous, or low-confidence claims require human/community authority or marked uncertainty.

Minimal Language Loop

scenario → interaction contract → learner attempt → granular evaluation → feedback claim → scaffolded repair → language artifact → reuse → transfer test → validation → SkillGraph update → progression

B. Legislative Drafting Domain Canon — Placeholder v0.1

This domain should be developed next, but the likely primitives are already visible.

LD-01 — Draft Text Is Not Legislative Effect

A bill’s language is not equivalent to its actual legal, fiscal, administrative, or social effect.

LD-02 — Every Provision Requires an Effect Claim

Each provision should declare what it is intended to do, who it affects, and by what mechanism.

LD-03 — Beneficiary Claims Require Validation

Claims about who benefits must be tested against actual distribution of effects.

LD-04 — Enforcement Mechanism Must Be Explicit

A legal obligation without enforcement, remedy, penalty, funding, or administrative authority may be symbolic rather than operational.

LD-05 — Conflict With Existing Law Must Be Checked

Draft language must be tested against existing statutes, regulations, constitutional limits, administrative capacity, and judicial doctrine.

LD-06 — Incentive and Evasion Paths Must Be Modeled

Legislation must be tested for gaming, loopholes, burden shifting, and unintended beneficiaries.

LD-07 — Source Influence Must Be Traceable

Lobbyist, donor, agency, interest group, model-generated, or constituent-originated language must be traceable where available.

LD-08 — Public Explanation Must Match Operative Text

The explanation of a bill must be validated against the actual legal mechanism.

LD-09 — Irreversible or High-Impact Effects Require Stronger Validation

Criminal penalties, rights restrictions, taxation, surveillance, immigration, emergency powers, and irreversible administrative actions require elevated validation.

LD-10 — Ambiguity Must Be Classified

Ambiguity may be intentional, unavoidable, harmful, or delegated. It must not remain invisible.

Part XI — Integrated Minimal System Flow

General Substrate Flow

input → artifact → typed unit → evidence → validation mode → constraint check → decision event → enforcement → action / block / defer / escalate → trace update → monitoring → revision

Constraint Lifecycle Flow

latent → observed → hypothesized → formalized → candidate → supported → validated → enforced → canonical → monitored → revised / deprecated

Failure Flow

failure observed → classified → preserved → evidence attached → candidate constraint generated → validation designed → enforcement considered → promotion evaluated

Part XII — Working Set for PR9–PR11

For the next implementation phase, use the reduced 12 primitives:

Typed validation unit
Decomposition
Claim–evidence binding
Validation mode typing
Iterative validation loop
Process trace
Executable constraints
Boundary / injection protection
Adversarial robustness
Selection failure
Multi-metric evaluation
Failure preservation

These should be used as the default PR9 artifact test and PR10/PR11 loop validation checklist.

Part XIII — Canon Summary

The system is governed only when:

constraints are artifacts
validation is typed
promotion increases burden
authority is separated
failures are preserved
enforcement has consequence
context binds validity
irreversible actions receive stronger gates
domain canons inherit core laws

Final compression:

No claim without validation.
No artifact without trace.
No action without decision.
No execution without enforcement.
No promotion without burden.
No domain without context.
No governance without failure preservation.