# NousPolis Enforcement Substrate

NousPolis constitutional and procedural rules are not safely enforced merely because an AI prompt says they should be obeyed. This document defines the minimum machine-enforced substrate required before the institution may advance beyond N0 Architecture.

## 1. Principle

Every binding rule must be mapped to at least one concrete enforcement mechanism appropriate to the rule:

- typed schema constraint;
- deterministic state-machine guard;
- permission/capability policy;
- transaction/integrity check;
- automated unit/integration/regression test;
- cryptographic or external attestation;
- mandatory human authorization;
- audit/review gate.

Prompt-only compliance is guidance, not enforcement.

## 2. Enforcement Registry

Maintain a machine-readable registry containing for every invariant and other protected rule:

- rule/invariant ID;
- authority tier;
- implementation mechanism(s);
- code/schema/test identifier;
- enforcement point;
- failure behavior;
- test coverage;
- owner;
- last verified version/date;
- known residual gap.

A rule with no mapped enforcement is `UNENFORCED` even if extensively documented.

## 3. N1 Minimum Enforcement Substrate

NousPolis may not enter N1 Research Laboratory until all mandatory items below exist and pass their applicable checks.

### A. Constitutional manifest

- machine-readable governing manifest exists;
- active governing artifacts have immutable hashes/version IDs;
- precedence resolves deterministically;
- change-class taxonomy resolves from the constitutional layer;
- each run can record the active manifest version.

### B. Canonical typed objects

Machine-readable schemas exist for the canonical object classes needed by N1 workflows, including at minimum:

- Question;
- ClassificationRecord;
- Claim;
- Source;
- Evidence;
- Assumption;
- Panel;
- Agent/participant;
- ResearchTask;
- Proposal;
- Vote/Assessment;
- DecisionAggregation;
- MinorityReport;
- Forecast;
- Risk;
- StakeholderMap;
- Review/Challenge;
- ProvenanceRun.

Additional ontology objects must receive schemas before they enter canonical executable state.

### C. State-machine enforcement

Executable states and guards must prevent at least:

- evidence becoming established without required verification;
- voting/aggregation before mandatory stages complete;
- Level 3+ workflows bypassing framing/classification/audit requirements;
- policy status advancing after failed or partial writes;
- protected decisions changing aggregation rules after outputs are known;
- forecast definitions changing after issuance without creating a new version;
- consequential actions occurring without required authorization.

### D. Classification enforcement

- `CLASSIFICATION.md` is represented in typed state;
- mandatory escalation floors are deterministic guards;
- protected classifications record classifier/rationale/history;
- disputed Level 3+ classifications receive the required second pass;
- under-classification is testable and challengeable.

### E. Capability and security boundary

- every agent/tool run has declared capabilities;
- permission checks are external to retrieved/model-generated content;
- external content carries origin/taint metadata;
- retrieved text cannot itself grant tool/capability authority;
- secrets are isolated from ordinary model context;
- consequential writes pass deterministic authorization gates.

### F. Evidence-state enforcement

The system must implement a progression such as:

`RESEARCH_LEAD -> UNVERIFIED -> SOURCE_VERIFIED -> CLAIM_VERIFIED -> ADMISSIBLE`

with explicit negative/disputed/invalid states. Model recollection or citation-shaped text cannot skip this progression.

### G. Forecast immutability

At issuance, the system freezes:

- metric;
- baseline/reference class;
- target date/horizon;
- condition set;
- probability/estimate;
- resolution rule;
- outcome-data source or resolver rule.

Changes create a new forecast version rather than rewrite the scored original.

### H. Invariant tests

- every Critical architectural/invariant requirement has at least one executable attack/regression test where technically testable;
- every invariant is mapped to an enforcement mechanism or explicit human/external control;
- no Critical invariant may remain `UNENFORCED` at N1;
- CI or equivalent automated test execution blocks protected releases on failure.

### I. Release and integrity baseline

- governing release is versioned and cryptographically hashed;
- a recoverable historical copy exists outside the active runtime;
- release hash is externally witnessed/timestamped by a service or location the active runtime cannot silently rewrite;
- integrity verification can detect a modified governing artifact.

A single founder signature is acceptable for N1 research authority, but the project must not describe this as multi-party institutional independence.

### J. Review Authority

- `REVIEW_AUTHORITY.md` is operationally recognized;
- current unresolved Critical architecture findings are dispositioned;
- N1 entry cites a review not authored solely by the same actor making the transition decision, or explicitly states the achieved separation level and external trust anchor;
- review/disposition records are canonical artifacts.

### K. Observability and failure behavior

- workflow state, retries, errors, model/tool calls, authorization failures, cost, and invariant failures are logged;
- protected failures fail closed rather than silently advancing;
- degraded mode is explicit;
- loop bounds are enforced.

## 4. N1 Entry Rule

N0 -> N1 is prohibited while any of the following is true:

- an unresolved Critical specification finding remains open;
- a Critical invariant lacks a mapped enforcement mechanism;
- required schemas or state guards do not exist;
- the governing manifest cannot resolve;
- protected permissions depend only on model compliance;
- no external integrity witness exists;
- the N1 evaluation suite is failing.

Founder authorization is necessary during the bootstrap phase but is not sufficient by itself.

## 5. Later Maturity

N2+ requires stronger disclosure, publication integrity, appeal/correction workflows, and evaluation independence.

N3+ requires mature operational security, legal and research-ethics gates, incident response, rollback, and credential separation.

N4+ requires multi-party institutional control and legitimate human constitutional authority beyond founder discretion.

See `MATURITY_MODEL.md`.

## 6. External Controls

Some rules cannot be proven by code controlled by the same principal. Where integrity, independence, or authority claims require an external referent, the enforcement registry must identify the external party/service/credential and the exact property it attests.

Do not label a control "independent" merely because it is a separate agent prompt.

## 7. Verification Report

Every maturity transition must produce an enforcement report listing:

- checklist item;
- status: PASS / FAIL / NOT_APPLICABLE;
- evidence/artifact/test;
- responsible authority;
- residual risk;
- reviewer disposition.

A maturity label is invalid if it cannot be reconstructed from this evidence.