Charter Protocol
A domain-charter architecture for making structural inevitability executable before inference.
Charter Protocol is Citium's public design document for turning raw tasks into bounded, auditable, verifier-facing specifications before a model answers. The protocol treats source ambiguity as the primary object of control: domain boundary, source authority, semantic equivalence, admissible methods, invariants, verifier channels, routing, and escalation are fixed before generation so the intended semantic class can become structurally favored.
This page is a public design-document surface. It explains the computable charter layer referenced by the PSI/SI preprints without exposing implementation machinery.
Problem Specification
A model can fail even when its output is coherent, locally plausible, and compatible with visible evidence. In those cases, the fault often sits upstream: the source problem did not disambiguate the intended semantic class from coherent rivals. A post-hoc verifier may still be useful, but only when its observation channel separates those classes after generation. When the verifier sees the same evidence for true and false completions, decision rules over that channel cannot recover the missing distinction.
Charter Protocol moves the control surface before inference. It asks what a task family must specify so that valid completions are well-formed, invalid completions are rejectable, and unresolved cases produce an inadequacy signal rather than a fluent answer.
The design problem is therefore: compile a raw problem into a chartered problem whose domain boundary, admissible response space, invariants, verifier, and escalation behavior are explicit enough for bounded execution.
Charter Object
A charter is a domain-scoped specification object. It is not merely a long prompt and not a style guide. It is the executable boundary between a family of problems and the response classes that may count as completions of those problems.
| Field | Function |
|---|---|
| Domain boundary | States which task family is covered and which requests are outside scope. |
| Authority sources | Fixes the documents, policies, formal systems, corpora, or source hierarchy that controls interpretation. |
| Semantic equivalence | Defines when two surface responses represent the same task-relevant response class. |
| Admissible set | Declares which response classes can count as completions of the same problem. |
| Invariants | Records the properties every valid completion must preserve. |
| Method boundaries | Specifies required, permitted, and prohibited methods, including evidence requirements. |
| Verifier | Names the checks available for rejecting unsupported or invalid candidates. |
| Escalation rule | Defines the inadequacy behavior when margin, coverage, or verifier adequacy is unresolved. |
Execution Pipeline
A chartered execution run proceeds through six public stages. Implementations may vary, but any implementation that drops one of these stages loses the discipline the protocol is meant to enforce.
- Normalize. Convert the raw request into a stable problem representation with explicit terms, source authority, temporal scope, and output contract.
- Constrain. Apply hard constraints, invariants, method boundaries, and invalid-method exclusions before candidate generation.
- Generate. Search only within the admissible response space exposed by the chartered problem.
- Score. Use a declared computable surrogate for structural cost and require the apparent margin to survive proxy error.
- Verify. Apply available checks: tests, proof checkers, retrieval checks, invariant checks, external measurements, or human review where those channels exist.
- Route. Return the response only when adequacy conditions hold; otherwise return an inadequacy signal or escalate.
Adequacy Conditions
Detail is not adequacy. A charter is adequate only relative to a covered task family, a declared semantic equivalence relation, a declared verifier, and a declared structural surrogate. The intended class must remain valid after normalization; invalid classes must be rejectable; and the surrogate must preserve the relevant ideal ordering across the intended class and margin-relevant rivals.
If verifier-passing proxy minimizers fall into more than one semantic class inside the declared error band, the correct behavior is unresolved adequacy unless those minimizers are equivalent under the problem's semantic relation. Silent arbitrary tie-breaking defeats the purpose of chartering.
Failure Modes
- Boundary failure. The request falls outside the covered task family.
- Authority failure. The source hierarchy is missing, stale, conflicting, or underspecified.
- Invariant failure. A required property is omitted, mistranslated, weakly enforced, or invalidated by context drift.
- Proxy failure. The computable score does not preserve the structural ordering needed for the claimed margin.
- Verifier failure. Invalid candidates can pass the available checks.
- Coverage failure. No verified charter covers the problem; the system must route to inadequacy rather than answer as if the problem were covered.
Relation to the PSI/SI Papers
The verification preprint identifies the oracle-limited regime where true and coherent false completions induce the same verifier observation vector. Charter Protocol is the practical source-side response: it specifies which fields must be fixed before generation so the intended semantic class can become structurally favored.
The companion preprint uses Charter Protocol as the computable approximation layer for response-level AGI evaluation. Exact Kolmogorov complexity remains an ideal object; charters supply a bounded, inspectable architecture for approximating that ideal in domains with declared coverage and adequacy.