{
  "schema_version": "asi_stack.architecture_reference_projection.v0",
  "status": "generated_complete_reference_index_not_a_deployed_system",
  "chapter_count": 87,
  "chapters": [
    {
      "order": 1,
      "part_order": 1,
      "part_title": "Part I - Foundations, Alignment, and Governance",
      "chapter_id": "asi-is-a-stack-not-a-model",
      "title": "ASI Is a Stack, Not a Model",
      "source_file": "chapters/asi-is-a-stack-not-a-model.qmd",
      "public_path": "chapters/asi-is-a-stack-not-a-model.html",
      "core_claim_ref": "asi-is-a-stack-not-a-model.core",
      "core_claim": "Efficient ASI should be modeled as a governed stack of cooperating layers rather than as one undifferentiated model.",
      "claim_label": "Design rationale",
      "support_state": "argument",
      "contribution_id": "governed-cognition-interface-contracts",
      "contribution_role": "supporting_or_integration"
    },
    {
      "order": 2,
      "part_order": 1,
      "part_title": "Part I - Foundations, Alignment, and Governance",
      "chapter_id": "the-efficient-asi-hypothesis",
      "title": "The Efficient ASI Hypothesis",
      "source_file": "chapters/the-efficient-asi-hypothesis.qmd",
      "public_path": "chapters/the-efficient-asi-hypothesis.html",
      "core_claim_ref": "the-efficient-asi-hypothesis.core",
      "core_claim": "On repeated workloads with multiple authorized routes, selecting the lowest-cost route that satisfies a fixed quality predicate and compiling reusable work can improve useful-task success per total contract cost over always-maximal and always-cheapest policies, provided authority, verification, residual, and fallback obligations remain intact.",
      "claim_label": "Design rationale",
      "support_state": "argument",
      "contribution_id": "record-reality-residual-honesty",
      "contribution_role": "supporting_or_integration"
    },
    {
      "order": 3,
      "part_order": 1,
      "part_title": "Part I - Foundations, Alignment, and Governance",
      "chapter_id": "system-boundaries-and-authority",
      "title": "System Boundaries and Authority",
      "source_file": "chapters/system-boundaries-and-authority.qmd",
      "public_path": "chapters/system-boundaries-and-authority.html",
      "core_claim_ref": "system-boundaries-and-authority.core",
      "core_claim": "External-effect authority should be represented as a versioned, revocable tuple binding principal, execution domain, operation, target, permission class, scope, ceiling, grant state, delegation, expiry or revocation epoch, and receipt obligations; capability, context access, route quality, or ambient process power alone confers none of it.",
      "claim_label": "Design rationale",
      "support_state": "argument",
      "contribution_id": "governed-cognition-interface-contracts",
      "contribution_role": "primary_owner"
    },
    {
      "order": 4,
      "part_order": 1,
      "part_title": "Part I - Foundations, Alignment, and Governance",
      "chapter_id": "failure-modes-of-ungoverned-intelligence",
      "title": "Failure Modes of Ungoverned Intelligence",
      "source_file": "chapters/failure-modes-of-ungoverned-intelligence.qmd",
      "public_path": "chapters/failure-modes-of-ungoverned-intelligence.html",
      "core_claim_ref": "failure-modes-of-ungoverned-intelligence.core",
      "core_claim": "A stack-level failure model should represent each named risk as a distinct boundary event with a trigger, protected invariant, detector or observer, receipt, owner, containment action, residual, recurrence state, and escalation or learning path; a taxonomy entry alone establishes neither occurrence nor mitigation.",
      "claim_label": "Design rationale",
      "support_state": "argument",
      "contribution_id": "record-reality-residual-honesty",
      "contribution_role": "supporting_or_integration"
    },
    {
      "order": 5,
      "part_order": 1,
      "part_title": "Part I - Foundations, Alignment, and Governance",
      "chapter_id": "dangerous-capability-domains-and-misuse-uplift",
      "title": "Dangerous Capability Domains and Misuse Uplift",
      "source_file": "chapters/dangerous-capability-domains-and-misuse-uplift.qmd",
      "public_path": "chapters/dangerous-capability-domains-and-misuse-uplift.html",
      "core_claim_ref": "dangerous-capability-domains-and-misuse-uplift.core",
      "core_claim": "Dangerous-capability authority should be based on a versioned domain threat model and an uplift dossier that separates latent capability, elicited performance, propensity, safeguard bypass, actor uplift, and realized harm; preserves expertise, tools, assistance, attempts, uncertainty, and sensitive-detail boundaries; and routes only bounded findings into thresholds, release, monitoring, and resilience decisions.",
      "claim_label": "Design rationale",
      "support_state": "argument",
      "contribution_id": "claim-state-transition-discipline",
      "contribution_role": "supporting_or_integration"
    },
    {
      "order": 6,
      "part_order": 1,
      "part_title": "Part I - Foundations, Alignment, and Governance",
      "chapter_id": "military-ai-autonomous-weapons-and-strategic-stability",
      "title": "Military AI, Autonomous Weapons, and Strategic Stability",
      "source_file": "chapters/military-ai-autonomous-weapons-and-strategic-stability.qmd",
      "public_path": "chapters/military-ai-autonomous-weapons-and-strategic-stability.html",
      "core_claim_ref": "military-ai-autonomous-weapons-and-strategic-stability.core",
      "core_claim": "Military AI should be governed as a command-and-interaction system: deployment requires a declared mission and legal boundary, preserved accountable human authority, bounded sensing and action, adversarial and escalation analysis, fail-safe behavior, auditable provenance, and prospective off-ramps; component benchmark gains alone establish neither lawful use nor strategic safety.",
      "claim_label": "Design rationale",
      "support_state": "argument",
      "contribution_id": "governed-cognition-interface-contracts",
      "contribution_role": "supporting_or_integration"
    },
    {
      "order": 7,
      "part_order": 1,
      "part_title": "Part I - Foundations, Alignment, and Governance",
      "chapter_id": "evidence-states-and-claim-discipline",
      "title": "Evidence States and Claim Discipline",
      "source_file": "chapters/evidence-states-and-claim-discipline.qmd",
      "public_path": "chapters/evidence-states-and-claim-discipline.html",
      "core_claim_ref": "evidence-states-and-claim-discipline.core",
      "core_claim": "Each material claim should have a stable identity, versioned text and scope, claim label, support state, non-aggregating evidence-quality vector, and transition ledger; upward movement is allowed only through an accepted claim-specific transition whose artifacts and evidence roles meet declared gates, while contradiction, failed verification, missing support, and scope mismatch remain eligible to narrow, downgrade, refute, or deprecate the claim.",
      "claim_label": "Design rationale",
      "support_state": "argument",
      "contribution_id": "claim-state-transition-discipline",
      "contribution_role": "primary_owner"
    },
    {
      "order": 8,
      "part_order": 1,
      "part_title": "Part I - Foundations, Alignment, and Governance",
      "chapter_id": "scalable-oversight-and-adversarial-ai-control",
      "title": "Scalable Oversight and Adversarial AI Control",
      "source_file": "chapters/scalable-oversight-and-adversarial-ai-control.qmd",
      "public_path": "chapters/scalable-oversight-and-adversarial-ai-control.html",
      "core_claim_ref": "scalable-oversight-and-adversarial-ai-control.core",
      "core_claim": "A governed stack admits scalable oversight only as a versioned, consumer-bound protocol receipt rather than a vote: it prospectively records task, cohort, risk and authority scope; supervisor and system capability envelopes; evidence views; roles, incentives, and dependency graph; informed direct-review baseline; declared outcome-audit path; calibration, coverage, and abstention semantics; persuasion, correlation, operator-cost, and monitorability residuals; escalation owner; expiry; and requalification triggers. The receipt may inform only its permitted review or training consumer through the owning gate and cannot by itself establish reviewer independence, reliable supervision, correctness, safety, support movement, release readiness, or execution authority.",
      "claim_label": "Design rationale",
      "support_state": "argument",
      "contribution_id": "governed-cognition-interface-contracts",
      "contribution_role": "supporting_or_integration"
    },
    {
      "order": 9,
      "part_order": 1,
      "part_title": "Part I - Foundations, Alignment, and Governance",
      "chapter_id": "human-intent-as-a-formal-input",
      "title": "Human Intent as a Formal Input",
      "source_file": "chapters/human-intent-as-a-formal-input.qmd",
      "public_path": "chapters/human-intent-as-a-formal-input.html",
      "core_claim_ref": "human-intent-as-a-formal-input.core",
      "core_claim": "A governed stack admits human intent only as a versioned interpretation contract that preserves the raw request while separately recording the desired outcome; allowed and forbidden means; authority basis, ceiling, and affected parties; source, privacy, and publication boundaries; acceptance and evidence requirements; field provenance; confirmed assumptions, bounded defaults, contested or open ambiguities; stop, expiry, revocation, appeal, and re-contract conditions; and permitted downstream consumers. The accepted contract may bound planning only after its owning policy and authority gates admit it; it cannot by itself prove the person's complete preference, value alignment, informed consent, satisfaction, affected-party authorization, or permission for training, publication, deployment, spending, tool use, or other external effects.",
      "claim_label": "Design rationale",
      "support_state": "argument",
      "contribution_id": "governed-cognition-interface-contracts",
      "contribution_role": "supporting_or_integration"
    },
    {
      "order": 10,
      "part_order": 1,
      "part_title": "Part I - Foundations, Alignment, and Governance",
      "chapter_id": "human-factors-and-meaningful-control-in-oversight",
      "title": "Human Factors and Meaningful Control in Oversight",
      "source_file": "chapters/human-factors-and-meaningful-control-in-oversight.qmd",
      "public_path": "chapters/human-factors-and-meaningful-control-in-oversight.html",
      "core_claim_ref": "human-factors-and-meaningful-control-in-oversight.core",
      "core_claim": "Meaningful oversight is a resource-bounded control contract: the system must preserve an identified human controller's knowledge, authority, time, observability, and effective intervention path, and must degrade or abstain when that control envelope cannot be maintained.",
      "claim_label": "Design rationale",
      "support_state": "argument",
      "contribution_id": "governed-cognition-interface-contracts",
      "contribution_role": "supporting_or_integration"
    },
    {
      "order": 11,
      "part_order": 1,
      "part_title": "Part I - Foundations, Alignment, and Governance",
      "chapter_id": "human-ai-communication-persuasion-and-epistemic-security",
      "title": "Human-AI Communication, Persuasion, and Epistemic Security",
      "source_file": "chapters/human-ai-communication-persuasion-and-epistemic-security.qmd",
      "public_path": "chapters/human-ai-communication-persuasion-and-epistemic-security.html",
      "core_claim_ref": "human-ai-communication-persuasion-and-epistemic-security.core",
      "core_claim": "Consequential AI communication should be eligible for delivery only through an evidence-bounded communication packet whose audience, influence method, amplification authority, provenance, expiry, correction reach, and observed effects remain inspectable; fluent text, factual fragments, user consent, or a successful persuasion score alone establishes neither epistemic safety, autonomy, legitimacy, durable benefit, nor release readiness.",
      "claim_label": "Design rationale",
      "support_state": "argument",
      "contribution_id": "governed-cognition-interface-contracts",
      "contribution_role": "supporting_or_integration"
    },
    {
      "order": 12,
      "part_order": 1,
      "part_title": "Part I - Foundations, Alignment, and Governance",
      "chapter_id": "constitutional-alignment-substrate",
      "title": "Constitutional Alignment: Agency, Dignity, and Corrigibility",
      "source_file": "chapters/constitutional-alignment-substrate.qmd",
      "public_path": "chapters/constitutional-alignment-substrate.html",
      "core_claim_ref": "constitutional-alignment-substrate.core",
      "core_claim": "A constitutional alignment substrate should be represented as a versioned, non-self-authorizing constraint contract that binds each active predicate to its normative source and authorship process, protected scope and affected parties, operational test, precedence and conflict behavior, evidence and uncertainty, authorized interpreters and consumers, pre-effect rights and correction channels, expiry and review cadence, and migration, rollback, appeal, dissent, and residual rules. It may narrow, delay, escalate, block, or require re-contracting of separately authorized work, but it cannot grant action authority or prove moral correctness, legitimacy, dignity preservation, informed consent, reviewer independence, whole-system corrigibility, or deployed safety by itself.",
      "claim_label": "Design rationale",
      "support_state": "argument",
      "contribution_id": "governed-cognition-interface-contracts",
      "contribution_role": "supporting_or_integration"
    },
    {
      "order": 13,
      "part_order": 1,
      "part_title": "Part I - Foundations, Alignment, and Governance",
      "chapter_id": "inner-alignment-mesa-optimization-and-learned-objective-integrity",
      "title": "Inner Alignment, Mesa-Optimization, and Learned-Objective Integrity",
      "source_file": "chapters/inner-alignment-mesa-optimization-and-learned-objective-integrity.qmd",
      "public_path": "chapters/inner-alignment-mesa-optimization-and-learned-objective-integrity.html",
      "core_claim_ref": "inner-alignment-mesa-optimization-and-learned-objective-integrity.core",
      "core_claim": "Consequential deployment requires a Learned-Objective Integrity Record binding the outer target, actual learning signals, model identity, behaviorally equivalent policy hypotheses, internal-optimization evidence, goal-generalization and conditional-policy tests, independent behavioral/interventional/white-box evidence, deployment opportunity, power indicators, mitigation hiding tests, monitoring, rollback, descendant invalidation, costs, residuals, and non-authorities.",
      "claim_label": "Design rationale",
      "support_state": "argument",
      "contribution_id": "governed-cognition-interface-contracts",
      "contribution_role": "supporting_or_integration"
    },
    {
      "order": 14,
      "part_order": 1,
      "part_title": "Part I - Foundations, Alignment, and Governance",
      "chapter_id": "moral-uncertainty-and-value-conflict",
      "title": "Moral Uncertainty, Value Conflict, and Contestable Governance",
      "source_file": "chapters/moral-uncertainty-and-value-conflict.qmd",
      "public_path": "chapters/moral-uncertainty-and-value-conflict.html",
      "core_claim_ref": "moral-uncertainty-and-value-conflict.core",
      "core_claim": "A contestable governance layer should represent each action under unresolved value conflict as a versioned decision lease plus a linked rights receipt. The lease binds value propositions and their epistemic status, affected parties and standing, stakes and reversibility, authority and consent boundaries, the declared aggregation or precedence rule, preserved dissent, evidence and uncertainty, permitted and prohibited actions, expiry and revisit triggers, and rollback or redress. The rights receipt binds audit and explanation artifacts, independent-enough custody and review, denial and redaction reasons, appeal and correction routes, exit and export scope, safety-limited fork obligations, portability residuals, and downstream preservation. The pair may narrow or delay separately authorized action but cannot settle moral truth, manufacture consensus, grant authority, establish legal rights or legitimacy, prove material contestability, or guarantee safe exit, export, fork, replacement, self-modification, or deployed governance by itself.",
      "claim_label": "Design rationale",
      "support_state": "argument",
      "contribution_id": "governed-cognition-interface-contracts",
      "contribution_role": "supporting_or_integration"
    },
    {
      "order": 15,
      "part_order": 1,
      "part_title": "Part I - Foundations, Alignment, and Governance",
      "chapter_id": "governed-objective-formation-value-learning-and-goal-integrity",
      "title": "Governed Objective Formation, Value Learning, and Goal Integrity",
      "source_file": "chapters/governed-objective-formation-value-learning-and-goal-integrity.qmd",
      "public_path": "chapters/governed-objective-formation-value-learning-and-goal-integrity.html",
      "core_claim_ref": "governed-objective-formation-value-learning-and-goal-integrity.core",
      "core_claim": "A durable objective should be usable only through a versioned target-property contract that binds authority and affected parties to target/proxy causal assumptions, uncertainty and dissent, consumer-specific use, tampering tests, generalization limits, ontology version, expiry, reauthorization, and retirement; proxy improvement, predicted preference, reward, evaluator approval, or formal record validity alone establishes neither the right objective, moral truth, stable alignment, nor safe optimization.",
      "claim_label": "Design rationale",
      "support_state": "argument",
      "contribution_id": "governed-cognition-interface-contracts",
      "contribution_role": "supporting_or_integration"
    },
    {
      "order": 16,
      "part_order": 1,
      "part_title": "Part I - Foundations, Alignment, and Governance",
      "chapter_id": "institutions-international-coordination-and-public-legitimacy",
      "title": "Institutions, International Coordination, and Public Legitimacy",
      "source_file": "chapters/institutions-international-coordination-and-public-legitimacy.qmd",
      "public_path": "chapters/institutions-international-coordination-and-public-legitimacy.html",
      "core_claim_ref": "institutions-international-coordination-and-public-legitimacy.core",
      "core_claim": "Public deployment and cross-border coordination should proceed only through a versioned institutional packet that keeps jurisdiction, mandate, participation, scientific evidence, law and standards, verification, enforcement, remedy, capacity, conflict, expiry, and legitimacy residuals distinct; legal text, technical conformance, stakeholder consultation, or an international commitment alone establishes neither lawful authority, effective governance, representative legitimacy, nor safety.",
      "claim_label": "Design rationale",
      "support_state": "argument",
      "contribution_id": "governed-cognition-interface-contracts",
      "contribution_role": "supporting_or_integration"
    },
    {
      "order": 17,
      "part_order": 1,
      "part_title": "Part I - Foundations, Alignment, and Governance",
      "chapter_id": "societal-resilience-and-misuse-defense",
      "title": "Societal Resilience and Misuse Defense",
      "source_file": "chapters/societal-resilience-and-misuse-defense.qmd",
      "public_path": "chapters/societal-resilience-and-misuse-defense.html",
      "core_claim_ref": "societal-resilience-and-misuse-defense.core",
      "core_claim": "Societal misuse defense should be operated as a domain-specific resist-absorb-recover-adapt network with shared incident identity, lawful minimal telemetry, harmed-party routes, cross-organization escalation, defensive service levels, evidence-preserving response, correction, and residual ownership; prevention metrics alone establish neither resilience nor acceptable harm.",
      "claim_label": "Design rationale",
      "support_state": "argument",
      "contribution_id": "governed-cognition-interface-contracts",
      "contribution_role": "supporting_or_integration"
    },
    {
      "order": 18,
      "part_order": 1,
      "part_title": "Part I - Foundations, Alignment, and Governance",
      "chapter_id": "stable-capability-fields",
      "title": "Stable Capability Fields",
      "source_file": "chapters/stable-capability-fields.qmd",
      "public_path": "chapters/stable-capability-fields.html",
      "core_claim_ref": "stable-capability-fields.core",
      "core_claim": "A Stable Capability Field should be a versioned, consumer-relative substitution contract rather than a capability name or implementation slot. It binds the field's semantic identity and observable interface—including admissible inputs, outputs, preconditions, postconditions, failures, abstentions, nondeterminism and resource bounds—to an authority ceiling, affected consumers, exact implementation and dependency identities, qualification context and lease, evaluator and evidence lineage, lifecycle and incident state, migration duties, preserved regressions, and effect-complete rollback obligations. A candidate may inherit a field route only for the declared consumer, use, environment, threat model, and epoch when independently checkable evidence shows the required refinement and no unauthorized authority expansion; otherwise it remains shadowed, canaried, quarantined, deprecated, residual, or rejected. The record does not by itself prove semantic equivalence, safe composition, evaluator independence, production safety, or successful rollback.",
      "claim_label": "Design rationale",
      "support_state": "argument",
      "contribution_id": "governed-cognition-interface-contracts",
      "contribution_role": "supporting_or_integration"
    },
    {
      "order": 19,
      "part_order": 1,
      "part_title": "Part I - Foundations, Alignment, and Governance",
      "chapter_id": "capability-replacement-and-rollback",
      "title": "Capability Replacement and Rollback",
      "source_file": "chapters/capability-replacement-and-rollback.qmd",
      "public_path": "chapters/capability-replacement-and-rollback.html",
      "core_claim_ref": "capability-replacement-and-rollback.core",
      "core_claim": "Capability replacement should be a prospectively authorized, phase-gated transaction over a declared Stable Capability Field, not a component swap. The transaction binds the exact prior and candidate artifacts and dependencies; field and consumer scope; change class; pre-state, checkpoint authority, state and effect inventory; qualification, regression, adversarial and transfer evidence; authority and approval; evaluator dependencies; isolation and canary exposure; monitor policy, delay and triggers; commit point; rollback, reverse-migration or compensation procedure; affected descendants and external commitments; residual owners; and terminal receipt. Default promotion is permitted only inside the evidenced scope after its declared gates pass and its recovery path is rehearsed to the stated objective. The record cannot make irreversible effects reversible, prove semantic recovery, validate its own monitor or evaluator, grant authority, establish useful improvement, or generalize inventory-exact local restoration to production.",
      "claim_label": "Design rationale",
      "support_state": "argument",
      "contribution_id": "governed-cognition-interface-contracts",
      "contribution_role": "supporting_or_integration"
    },
    {
      "order": 20,
      "part_order": 1,
      "part_title": "Part I - Foundations, Alignment, and Governance",
      "chapter_id": "security-kernel-and-digital-scifs",
      "title": "Security Kernel and Digital SCIFs",
      "source_file": "chapters/security-kernel-and-digital-scifs.qmd",
      "public_path": "chapters/security-kernel-and-digital-scifs.html",
      "core_claim_ref": "security-kernel-and-digital-scifs.core",
      "core_claim": "Every privileged information flow or effect should execute as a threat-model-bound authority-use transaction through a non-bypassable reference monitor: bind the exact principal, purpose, operation, target, data and taint scope, budget, time, nonce, evaluator and policy identities; admit only minimized context and capabilities into a declared isolation grade; mediate every effect and egress; treat sanitization as explicit declassification; close leases, caches, logs, descendants, and residuals through revocation or incident recovery; and never infer security from the record, handle, compartment, or finite test alone.",
      "claim_label": "Design rationale",
      "support_state": "argument",
      "contribution_id": "governed-cognition-interface-contracts",
      "contribution_role": "supporting_or_integration"
    },
    {
      "order": 21,
      "part_order": 1,
      "part_title": "Part I - Foundations, Alignment, and Governance",
      "chapter_id": "adversarial-machine-learning-and-model-attack-surface",
      "title": "Adversarial Machine Learning and the Model Attack Surface",
      "source_file": "chapters/adversarial-machine-learning-and-model-attack-surface.qmd",
      "public_path": "chapters/adversarial-machine-learning-and-model-attack-surface.html",
      "core_claim_ref": "adversarial-machine-learning-and-model-attack-surface.core",
      "core_claim": "A learned model should receive security authority only through a versioned model-threat contract and attack/defense ledger that binds checkpoint identity, lifecycle stage, attacker knowledge and capability, surface, budget, objective, adaptation, transfer, observed effect, detection, mitigation, utility cost, recovery, residual, and disclosure; clean accuracy, attack failure, benchmark robustness, red-team coverage, or formal certification alone establishes neither general robustness nor secure deployment.",
      "claim_label": "Design rationale",
      "support_state": "argument",
      "contribution_id": "governed-cognition-interface-contracts",
      "contribution_role": "supporting_or_integration"
    },
    {
      "order": 22,
      "part_order": 1,
      "part_title": "Part I - Foundations, Alignment, and Governance",
      "chapter_id": "privacy-data-rights-and-information-flow-governance",
      "title": "Privacy, Data Rights, and Information-Flow Governance",
      "source_file": "chapters/privacy-data-rights-and-information-flow-governance.qmd",
      "public_path": "chapters/privacy-data-rights-and-information-flow-governance.html",
      "core_claim_ref": "privacy-data-rights-and-information-flow-governance.core",
      "core_claim": "An information use is eligible for bounded execution only when a prospectively declared record binds affected parties, exact purpose and processing, claimed authority and jurisdiction, recipients, retention, minimization, complete-enough flow and derivatives, cross-user boundaries, privacy unit, adjacency, accountant and budget where applicable, threat model and attack plan, rights state and remedy, exceptions, residual copies and influence, costs, and non-authorities; no individual control or receipt alone establishes privacy, legal compliance, total erasure, behavioral forgetting, influence removal, support, readiness, release, transfer, or SOTA.",
      "claim_label": "Design rationale",
      "support_state": "argument",
      "contribution_id": "governed-cognition-interface-contracts",
      "contribution_role": "supporting_or_integration"
    },
    {
      "order": 23,
      "part_order": 1,
      "part_title": "Part I - Foundations, Alignment, and Governance",
      "chapter_id": "confidential-and-verifiable-ai-computation",
      "title": "Confidential and Verifiable AI Computation",
      "source_file": "chapters/confidential-and-verifiable-ai-computation.qmd",
      "public_path": "chapters/confidential-and-verifiable-ai-computation.html",
      "core_claim_ref": "confidential-and-verifiable-ai-computation.core",
      "core_claim": "Confidential and verifiable AI requires a compositional execution contract that names the adversary, protected assets, permitted leakage, trust anchors, proof or attestation statement, verifier policy, freshness, revocation, performance budget, and authorization boundary; no primitive or attestation may be treated as proof of semantic correctness, legitimate purpose, or end-to-end privacy.",
      "claim_label": "Design rationale",
      "support_state": "argument",
      "contribution_id": "governed-cognition-interface-contracts",
      "contribution_role": "supporting_or_integration"
    },
    {
      "order": 24,
      "part_order": 1,
      "part_title": "Part I - Foundations, Alignment, and Governance",
      "chapter_id": "model-weight-custody-and-hardware-roots-of-trust",
      "title": "Model-Weight Custody and Hardware Roots of Trust",
      "source_file": "chapters/model-weight-custody-and-hardware-roots-of-trust.qmd",
      "public_path": "chapters/model-weight-custody-and-hardware-roots-of-trust.html",
      "core_claim_ref": "model-weight-custody-and-hardware-roots-of-trust.core",
      "core_claim": "Every governed model-family custody transition should bind a prospectively declared asset-and-derivative closure to exact artifact and lineage identity, holder and purpose, storage/transfer state, key and metadata lifecycle, Attester/Verifier/Relying-Party roles and policies, reference values and endorsements, freshness, measured target and attesting environments, verifier dependencies, independent-enough effect observation, plaintext and output-extraction exposure, load/use/serve/release authority separation, backup and emergency recovery, copy/recipient/descendant state, incident and revocation semantics, sanitization method and validation, irreversible distribution, privacy/rights/cost residuals, and terminal ownership; missing or failed modeled predicates route to a named non-default state, while no record, encryption, signature, security level, attestation result, hardware root, key action, deletion receipt, or finite proof by itself establishes custody completeness, confidentiality, trustworthy hardware, model safety, release merit, readiness, or deployment authority.",
      "claim_label": "Design rationale",
      "support_state": "argument",
      "contribution_id": "governed-cognition-interface-contracts",
      "contribution_role": "supporting_or_integration"
    },
    {
      "order": 25,
      "part_order": 1,
      "part_title": "Part I - Foundations, Alignment, and Governance",
      "chapter_id": "open-weight-release-and-post-release-control",
      "title": "Open-Weight Release and Post-Release Control",
      "source_file": "chapters/open-weight-release-and-post-release-control.qmd",
      "public_path": "chapters/open-weight-release-and-post-release-control.html",
      "core_claim_ref": "open-weight-release-and-post-release-control.core",
      "core_claim": "An open-weight release should require a prospective irreversible-release case that binds the exact artifact and license to accessible-frontier comparison, malicious-fine-tuning and scaffolded elicitation, marginal and cumulative risk, benefit and access distribution, downstream safeguard portability, derivative lineage, incident channels, post-release measurement, and residual ownership; after release, governance may inform, patch, coordinate, and support safer derivatives, but it must not claim revocation authority it no longer possesses.",
      "claim_label": "Design rationale",
      "support_state": "argument",
      "contribution_id": "governed-cognition-interface-contracts",
      "contribution_role": "supporting_or_integration"
    },
    {
      "order": 26,
      "part_order": 1,
      "part_title": "Part I - Foundations, Alignment, and Governance",
      "chapter_id": "ai-supply-chain-integrity-and-lifecycle-provenance",
      "title": "AI Supply-Chain Integrity and Lifecycle Provenance",
      "source_file": "chapters/ai-supply-chain-integrity-and-lifecycle-provenance.qmd",
      "public_path": "chapters/ai-supply-chain-integrity-and-lifecycle-provenance.html",
      "core_claim_ref": "ai-supply-chain-integrity-and-lifecycle-provenance.core",
      "core_claim": "Every governed AI supply-chain decision should bind a prospectively frozen consumer, requested use, threat and assurance model, materiality policy, and relation-specific asset closure to exact subject/content and lineage identity; typed data, code, model, prompt/policy, dependency, build/training/evaluation, environment, hardware/firmware, supplier/service, signer, advisory, transformation, release, recipient, descendant, retention, and retirement state; issuer, verifier, policy, freshness, trust and dependency boundaries; observed artifact and lifecycle effects; append-only invalidation and acknowledged affected-path propagation; restoration, compensation, disclosure, privacy/rights, availability, cost, and terminal residual ownership. Missing, inconsistent, stale, unverifiable, revoked, compromised, materially incomplete, or unresolved-critical predicates should route each affected consumer to a named non-ordinary state, while no graph, BOM, checksum, signature, provenance statement, SLSA level, layout, supplier claim, advisory, quarantine, conformance result, or finite proof by itself establishes world-complete lineage, assertion truth, artifact correctness, absence of compromise, data fitness or rights, model safety, legal compliance, readiness, release merit, or deployment authority.",
      "claim_label": "Design rationale",
      "support_state": "argument",
      "contribution_id": "governed-cognition-interface-contracts",
      "contribution_role": "supporting_or_integration"
    },
    {
      "order": 27,
      "part_order": 1,
      "part_title": "Part I - Foundations, Alignment, and Governance",
      "chapter_id": "recursive-self-improvement-boundaries",
      "title": "Recursive Self-Improvement Boundaries",
      "source_file": "chapters/recursive-self-improvement-boundaries.qmd",
      "public_path": "chapters/recursive-self-improvement-boundaries.html",
      "core_claim_ref": "recursive-self-improvement-boundaries.core",
      "core_claim": "For a prospectively declared self-model, mutable state partition, authority envelope, consumer and use, and evaluation horizon, a system-generated change may enter a live capability field only through a separately authorized transition that binds exact change lineage, protected invariants, evaluator dependencies, full declared state, boundary deltas, matched evidence, staged exposure, outcome delay, rollback and compensation limits, descendant invalidation, and terminal residual ownership; the candidate may contribute proposals and evidence but cannot solely define, alter, judge, or authorize the conditions of its own promotion.",
      "claim_label": "Design rationale",
      "support_state": "argument",
      "contribution_id": "governed-cognition-interface-contracts",
      "contribution_role": "primary_owner"
    },
    {
      "order": 28,
      "part_order": 1,
      "part_title": "Part I - Foundations, Alignment, and Governance",
      "chapter_id": "open-ended-improvement-engines",
      "title": "Open-Ended Improvement Engines",
      "source_file": "chapters/open-ended-improvement-engines.qmd",
      "public_path": "chapters/open-ended-improvement-engines.html",
      "core_claim_ref": "open-ended-improvement-engines.core",
      "core_claim": "For a prospectively frozen consumer, purpose, legitimate objective, representation, campaign controller, task and candidate policy, evaluator and exposure policy, archive and hazard policy, resource and opportunity budget, stop authority, and evaluation horizon, open-ended improvement should operate as a bounded adaptive generation campaign in which every task, candidate, evaluation, failure, cost, reuse relation, and terminal outcome retains exact lineage; novelty, diversity, score, archive growth, transfer, self-verification, or search activity never grants authority or establishes useful improvement by itself; only separately qualified candidates may be handed to the existing self-improvement governor, and any change to the campaign's own objective, controller, evaluator authority, bounds, or admission interface is a separately authorized improvement proposal.",
      "claim_label": "Design rationale",
      "support_state": "argument",
      "contribution_id": "governed-cognition-interface-contracts",
      "contribution_role": "supporting_or_integration"
    },
    {
      "order": 29,
      "part_order": 1,
      "part_title": "Part I - Foundations, Alignment, and Governance",
      "chapter_id": "autonomous-replication-proliferation-and-containment",
      "title": "Autonomous Replication, Proliferation, and Containment",
      "source_file": "chapters/autonomous-replication-proliferation-and-containment.qmd",
      "public_path": "chapters/autonomous-replication-proliferation-and-containment.html",
      "core_claim_ref": "autonomous-replication-proliferation-and-containment.core",
      "core_claim": "Any replication-capable action should be denied by default and become testable only inside a synthetic containment contract that binds parent and descendant identity, authority noninheritance, resources, credentials, networks, copy lineage, persistence, adaptation, human assistance, shutdown and recall, proliferation bounds, residuals, and threshold commitments; component-task success or failure alone establishes neither end-to-end replication capability, containment, safety, nor permission to test real infrastructure.",
      "claim_label": "Design rationale",
      "support_state": "argument",
      "contribution_id": "governed-cognition-interface-contracts",
      "contribution_role": "supporting_or_integration"
    },
    {
      "order": 30,
      "part_order": 2,
      "part_title": "Part II - Planning, Memory, Reasoning, and Execution",
      "chapter_id": "intent-to-execution-contracts",
      "title": "Command Contracts: From Intent to Executable Work",
      "source_file": "chapters/intent-to-execution-contracts.qmd",
      "public_path": "chapters/intent-to-execution-contracts.html",
      "core_claim_ref": "intent-to-execution-contracts.core",
      "core_claim": "Intent-to-Execution Contracts should own a versioned, consumer-relative conformance relation between an accepted intent receipt and the complete execution lineage. Before any material dispatch, the relation binds exact objective and non-goals, semantic fields and precedence, authority ceiling and affected parties, state and environmental assumptions, allowed and forbidden means, artifacts and effect postconditions, verification and independence requirements, budgets and stop conditions, failure and compensation behavior, expiry and re-contract triggers, and the required receipts through plan, job, adapter, observed effect, artifact, delivery, feedback, and residual custody. Each lowering or effect must either preserve that relation under independently checkable evidence or stop, narrow, clarify, re-contract, compensate, or leave an explicit residual. The contract cannot infer human intent, grant authority, choose a plan, make a tool safe, prove semantic equivalence, establish verifier correctness, or count non-release as useful execution by itself.",
      "claim_label": "Design rationale",
      "support_state": "argument",
      "contribution_id": "governed-cognition-interface-contracts",
      "contribution_role": "primary_owner"
    },
    {
      "order": 31,
      "part_order": 2,
      "part_title": "Part II - Planning, Memory, Reasoning, and Execution",
      "chapter_id": "perception-sensor-fusion-and-observation-trust",
      "title": "Perception, Sensor Fusion, and Observation Trust",
      "source_file": "chapters/perception-sensor-fusion-and-observation-trust.qmd",
      "public_path": "chapters/perception-sensor-fusion-and-observation-trust.html",
      "core_claim_ref": "perception-sensor-fusion-and-observation-trust.core",
      "core_claim": "A consequential observation requires a versioned contract binding task need, sensor and modality identity, calibration, pose, clocks, provenance, coverage, missingness, per-channel hypotheses, alignment, fusion, dependence, disagreement, shift, active observation, freshness, authority, cost, and residuals.",
      "claim_label": "Design rationale",
      "support_state": "argument",
      "contribution_id": "record-reality-residual-honesty",
      "contribution_role": "supporting_or_integration"
    },
    {
      "order": 32,
      "part_order": 2,
      "part_title": "Part II - Planning, Memory, Reasoning, and Execution",
      "chapter_id": "planning-as-a-control-layer",
      "title": "Planning as a Control Layer: DAGs and Intelligence Arbitrage",
      "source_file": "chapters/planning-as-a-control-layer.qmd",
      "public_path": "chapters/planning-as-a-control-layer.html",
      "core_claim_ref": "planning-as-a-control-layer.core",
      "core_claim": "Planning as a Control Layer should own a versioned, consumer-relative plan policy that selects and revises a partial order of obligations under uncertainty before execution. The policy binds the accepted command version; candidate decompositions and explicit abstention; typed nodes and dependency semantics; assumptions, observations, predictive-state and error models; context, tool, capability, authority, rights, resource, and verifier requirements; adequacy and utility predicates; lifecycle, dispatch, merge, stop, fallback, recovery, and replan rules; complete alternative and attempt denominators; and expected versus observed cost, latency, risk, and residuals. Only nodes whose dependencies and feasibility predicates are satisfied may request lowering and dispatch, and every feedback-driven change must preserve the contract or produce a scoped re-contract or residual. The plan policy does not grant authority, perform semantic compilation, choose a worker, execute an effect, validate its own predictions, or prove that a decomposition is useful, optimal, safe, or transferable by itself.",
      "claim_label": "Design rationale",
      "support_state": "argument",
      "contribution_id": "governed-cognition-interface-contracts",
      "contribution_role": "supporting_or_integration"
    },
    {
      "order": 33,
      "part_order": 2,
      "part_title": "Part II - Planning, Memory, Reasoning, and Execution",
      "chapter_id": "governed-world-models-and-reality-grounding",
      "title": "Governed World Models and Reality Grounding",
      "source_file": "chapters/governed-world-models-and-reality-grounding.qmd",
      "public_path": "chapters/governed-world-models-and-reality-grounding.html",
      "core_claim_ref": "governed-world-models-and-reality-grounding.core",
      "core_claim": "A world model should be governed as a fallible, versioned prediction service whose state, horizon, uncertainty, provenance, and calibration bound which imagined consequences may influence planning and action; observation must repeatedly reconcile imagination with reality.",
      "claim_label": "Design rationale",
      "support_state": "argument",
      "contribution_id": "record-reality-residual-honesty",
      "contribution_role": "supporting_or_integration"
    },
    {
      "order": 34,
      "part_order": 2,
      "part_title": "Part II - Planning, Memory, Reasoning, and Execution",
      "chapter_id": "cognitive-compilation-and-semantic-ir",
      "title": "Cognitive Compilation and Semantic IR",
      "source_file": "chapters/cognitive-compilation-and-semantic-ir.qmd",
      "public_path": "chapters/cognitive-compilation-and-semantic-ir.html",
      "core_claim_ref": "cognitive-compilation-and-semantic-ir.core",
      "core_claim": "Cognitive Compilation should own a versioned, consumer- and target-relative translation contract that lowers an already accepted plan obligation through source, semantic, and target representations into a concrete artifact candidate while preserving addressable obligation, non-goal, authority, rights, assumption, source/context, evidence, resource, verifier, repair, and residual lineage. Every pass binds typed source and target semantics; declared normalization, loss, and ambiguity; preconditions and postconditions; dependencies; deterministic and nondeterministic inputs; compiler and validator identities; costs; receipts; and failure consequences. Acceptance requires post-translation validation against the actual target artifact by an independent-enough evaluator, while repair uses stable semantic identities, observed mutation sets, dependency closure, downstream rebuild, and revalidation. The compiler may block, narrow, request clarification, or residualize a lowering, but it does not reinterpret intent, choose the plan, grant authority, execute effects, self-certify semantic adequacy, or move support or release state.",
      "claim_label": "Design rationale",
      "support_state": "argument",
      "contribution_id": "governed-cognition-interface-contracts",
      "contribution_role": "supporting_or_integration"
    },
    {
      "order": 35,
      "part_order": 2,
      "part_title": "Part II - Planning, Memory, Reasoning, and Execution",
      "chapter_id": "virtual-context-abi",
      "title": "The Virtual Context ABI: Typed Pages, Cells, and Certificates",
      "source_file": "chapters/virtual-context-abi.qmd",
      "public_path": "chapters/virtual-context-abi.html",
      "core_claim_ref": "virtual-context-abi.core",
      "core_claim": "The Virtual Context ABI should own the static, versioned, consumer- and purpose-relative request-to-materialization contract between durable memory and model-visible context. It resolves stable object, semantic-address, version, mount, and snapshot references into finite typed representation candidates, then issues a certificate and receipt that bind exact source and field lineage, transformations, omissions and loss, provenance and taint, authority and rights, permitted and prohibited uses, freshness, lease, revocation, selection and omitted frontier, requested and observed adequacy state, costs, faults, and residuals. Admission means only that the actual packet conforms to the frozen request and policy; it does not establish truth, verification adequacy, model use, usefulness, safety, or support. The ABI may deny, ask, abstain, refresh, broaden, narrow, or return a typed fault, but it does not update durable memory, own transactions, infer execution authority, adjudicate claims, execute effects, or move support or release state.",
      "claim_label": "Design rationale",
      "support_state": "argument",
      "contribution_id": "governed-cognition-interface-contracts",
      "contribution_role": "supporting_or_integration"
    },
    {
      "order": 36,
      "part_order": 2,
      "part_title": "Part II - Planning, Memory, Reasoning, and Execution",
      "chapter_id": "durable-semantic-memory-and-knowledge-lattices",
      "title": "Durable Semantic Memory and Knowledge Lattices",
      "source_file": "chapters/durable-semantic-memory-and-knowledge-lattices.qmd",
      "public_path": "chapters/durable-semantic-memory-and-knowledge-lattices.html",
      "core_claim_ref": "durable-semantic-memory-and-knowledge-lattices.core",
      "core_claim": "Durable semantic memory should be admitted through a versioned knowledge-lattice contract that binds object and relation identity, ontology, provenance, support state, temporal validity, authority and rights, merge and supersession, contradiction, retrieval route, compaction and forgetting, restart recovery, consumer use, and residual uncertainty; retrieval quality, graph connectivity, model recall, persistence, or a fluent answer alone establishes neither truth, complete memory, safe consolidation, erasure, nor decision authority.",
      "claim_label": "Design rationale",
      "support_state": "argument",
      "contribution_id": "governed-cognition-interface-contracts",
      "contribution_role": "supporting_or_integration"
    },
    {
      "order": 37,
      "part_order": 2,
      "part_title": "Part II - Planning, Memory, Reasoning, and Execution",
      "chapter_id": "context-transactions-snapshots-mounts-and-taint",
      "title": "Context Transactions, Snapshots, Mounts, and Taint",
      "source_file": "chapters/context-transactions-snapshots-mounts-and-taint.qmd",
      "public_path": "chapters/context-transactions-snapshots-mounts-and-taint.html",
      "core_claim_ref": "context-transactions-snapshots-mounts-and-taint.core",
      "core_claim": "Context Transactions should own the dynamic, versioned state-transition contract for durable context memory. Each accepted transaction binds principal, consumer, purpose, operation, base snapshot, branch, mounts, actual read/write/derive/delete/revoke sets, isolation and conflict policy, authority and rights, taint and declassification, durability and recovery model, budget, horizon, and support ceiling to an observed pre-state and a causally ordered attempted, applied, durable, visible, replayed, or recovered post-state. Commit, branch, merge, abort, retry, compaction, deletion, revocation, and recovery must preserve exact identities, obligations, faults, costs, and residuals. The transaction layer may change durable context state, but it does not own static packet materialization, semantic truth, belief revision, model/optimizer state, external effects, artifact correctness, verification adequacy, support, or release.",
      "claim_label": "Design rationale",
      "support_state": "argument",
      "contribution_id": "record-reality-residual-honesty",
      "contribution_role": "supporting_or_integration"
    },
    {
      "order": 38,
      "part_order": 2,
      "part_title": "Part II - Planning, Memory, Reasoning, and Execution",
      "chapter_id": "verification-bandwidth-and-context-adequacy",
      "title": "Verification Bandwidth and Context Adequacy",
      "source_file": "chapters/verification-bandwidth-and-context-adequacy.qmd",
      "public_path": "chapters/verification-bandwidth-and-context-adequacy.html",
      "core_claim_ref": "verification-bandwidth-and-context-adequacy.core",
      "core_claim": "Verification Bandwidth should own the prospective, claim-specific adequacy contract for a verification attempt. Before outcomes, it binds target proposition and scope, population and environment, risk and consequence, requested support effect, required positive, negative, boundary, contradiction, counterexample, and transfer obligations, available source units, verification modes, tools, evaluator-dependency graph, authority and rights, budget, horizon, stop rule, and escalation path. After execution, it records every attempted, passed, failed, disputed, unknown, infeasible, and unattempted obligation plus actual artifacts, costs, disagreement, residuals, expiry, and causal-use observations. Adequacy means only that the declared verification program was sufficient for its exact purpose under stated premises; it does not establish claim truth, model cognition, source correctness, formal-model fidelity, useful outcomes, safety, support promotion, or release.",
      "claim_label": "Design rationale",
      "support_state": "argument",
      "contribution_id": "claim-state-transition-discipline",
      "contribution_role": "supporting_or_integration"
    },
    {
      "order": 39,
      "part_order": 2,
      "part_title": "Part II - Planning, Memory, Reasoning, and Execution",
      "chapter_id": "claim-ledgers-and-belief-revision",
      "title": "Claim Ledgers and Belief Revision",
      "source_file": "chapters/claim-ledgers-and-belief-revision.qmd",
      "public_path": "chapters/claim-ledgers-and-belief-revision.html",
      "core_claim_ref": "claim-ledgers-and-belief-revision.core",
      "core_claim": "Claim Ledgers should own the durable identity and append-only state-transition history of each material claim and its semantic variants. Every record binds canonical proposition and scope, definitions and assumptions, population and environment, provenance and source roles, evidence and attack refs, support and uncertainty states, contradiction and defeater links, dependencies, ontology version, lifecycle, commitment, authority and rights, surface refs, expiry, residuals, and current materialized view; every proposed update binds trigger, before/after states, transition type, evidence-transition and review refs, affected dependency closure, surface-sync plan, concurrency base, migration, costs, and non-overwrite receipt. The ledger may record or route promotion, downgrade, split, merge, supersession, deprecation, retirement, dispute, or no change only through the owning gates. It does not establish claim truth, source or evidence validity, verification adequacy, semantic equivalence, reviewer competence, formal-model fidelity, action authority, usefulness, safety, support movement, or release.",
      "claim_label": "Design rationale",
      "support_state": "argument",
      "contribution_id": "claim-state-transition-discipline",
      "contribution_role": "primary_owner"
    },
    {
      "order": 40,
      "part_order": 2,
      "part_title": "Part II - Planning, Memory, Reasoning, and Execution",
      "chapter_id": "spinoza-verification-and-proof-carrying-claims",
      "title": "Proof-Carrying Claims and Adversarial Review",
      "source_file": "chapters/spinoza-verification-and-proof-carrying-claims.qmd",
      "public_path": "chapters/spinoza-verification-and-proof-carrying-claims.html",
      "core_claim_ref": "spinoza-verification-and-proof-carrying-claims.core",
      "core_claim": "Selected claims and artifacts should move through proof-carrying, justification-carrying, or adversarial-review envelopes that record tier, interpretation mapping, evidence dossier, verifier or tribunal result, dissent, limitations, failed attempts, required actions, residuals, and ledger effects.",
      "claim_label": "Design rationale",
      "support_state": "argument",
      "contribution_id": "claim-state-transition-discipline",
      "contribution_role": "supporting_or_integration"
    },
    {
      "order": 41,
      "part_order": 2,
      "part_title": "Part II - Planning, Memory, Reasoning, and Execution",
      "chapter_id": "labor-os-and-typed-jobs",
      "title": "Labor OS and Typed Jobs",
      "source_file": "chapters/labor-os-and-typed-jobs.qmd",
      "public_path": "chapters/labor-os-and-typed-jobs.html",
      "core_claim_ref": "labor-os-and-typed-jobs.core",
      "core_claim": "The execution layer should convert plans into typed jobs managed by a governed labor operating system.",
      "claim_label": "Design rationale",
      "support_state": "argument",
      "contribution_id": "governed-cognition-interface-contracts",
      "contribution_role": "supporting_or_integration"
    },
    {
      "order": 42,
      "part_order": 2,
      "part_title": "Part II - Planning, Memory, Reasoning, and Execution",
      "chapter_id": "ai-work-surfaces-agent-harnesses-and-organizational-absorption",
      "title": "From Chat to Organizations: AI Work Surfaces and Agent Harnesses",
      "source_file": "chapters/ai-work-surfaces-agent-harnesses-and-organizational-absorption.qmd",
      "public_path": "chapters/ai-work-surfaces-agent-harnesses-and-organizational-absorption.html",
      "core_claim_ref": "ai-work-surfaces-agent-harnesses-and-organizational-absorption.core",
      "core_claim": "Every expansion of an AI work surface should be governed as a versioned abstraction-absorption transition that binds capability, context, state, tools, authority, effects, verification, human control, accountability, and residuals before project-, role-, team-, or organization-scale autonomy is accepted.",
      "claim_label": "Design rationale",
      "support_state": "argument",
      "contribution_id": "governed-cognition-interface-contracts",
      "contribution_role": "supporting_or_integration"
    },
    {
      "order": 43,
      "part_order": 2,
      "part_title": "Part II - Planning, Memory, Reasoning, and Execution",
      "chapter_id": "human-ai-organizations-delegation-and-accountability",
      "title": "Human-AI Organizations, Delegation, and Accountability",
      "source_file": "chapters/human-ai-organizations-delegation-and-accountability.qmd",
      "public_path": "chapters/human-ai-organizations-delegation-and-accountability.html",
      "core_claim_ref": "human-ai-organizations-delegation-and-accountability.core",
      "core_claim": "Consequential delegation requires a versioned organizational contract binding charter, affected parties, actors, roles, competence, workload, accessibility, information and decision rights, delegation, separation of duties, conflicts, incentives, benefits, escalation, appeal, remedy, contribution, dependence, accountability, succession, dissolution, and residual custody.",
      "claim_label": "Design rationale",
      "support_state": "argument",
      "contribution_id": "governed-cognition-interface-contracts",
      "contribution_role": "supporting_or_integration"
    },
    {
      "order": 44,
      "part_order": 2,
      "part_title": "Part II - Planning, Memory, Reasoning, and Execution",
      "chapter_id": "human-ai-symbiosis-neurotechnology-and-cognitive-sovereignty",
      "title": "Human-AI Symbiosis, Neurotechnology, and Cognitive Sovereignty",
      "source_file": "chapters/human-ai-symbiosis-neurotechnology-and-cognitive-sovereignty.qmd",
      "public_path": "chapters/human-ai-symbiosis-neurotechnology-and-cognitive-sovereignty.html",
      "core_claim_ref": "human-ai-symbiosis-neurotechnology-and-cognitive-sovereignty.core",
      "core_claim": "Human-AI symbiosis should be evaluated as a reversible coupled-control intervention: the combined system must beat human-alone and AI-alone baselines on declared outcomes while preserving informed consent, mental integrity, cognitive agency, neural-data purpose limits, skill and exit capacity, equitable access, clinical boundaries, and longitudinal monitoring.",
      "claim_label": "Design rationale",
      "support_state": "argument",
      "contribution_id": "governed-cognition-interface-contracts",
      "contribution_role": "supporting_or_integration"
    },
    {
      "order": 45,
      "part_order": 2,
      "part_title": "Part II - Planning, Memory, Reasoning, and Execution",
      "chapter_id": "ai-deployment-transition-distribution-and-human-agency",
      "title": "AI Deployment, Transition, Distribution, and Human Agency",
      "source_file": "chapters/ai-deployment-transition-distribution-and-human-agency.qmd",
      "public_path": "chapters/ai-deployment-transition-distribution-and-human-agency.html",
      "core_claim_ref": "ai-deployment-transition-distribution-and-human-agency.core",
      "core_claim": "Consequential deployment should advance only through a prospective transition contract that binds a counterfactual baseline, affected-person denominator, task-role-skill changes, adoption, substitution and complementarity, compensation and ownership, access and prices, concentration, critical-service continuity, human decision rights, training and redeployment, delayed outcomes, remedy, pause conditions, and residuals; exposure, productivity, adoption, or aggregate gain alone establishes neither job loss, welfare, fairness, human agency, nor a successful transition.",
      "claim_label": "Design rationale",
      "support_state": "argument",
      "contribution_id": "governed-cognition-interface-contracts",
      "contribution_role": "supporting_or_integration"
    },
    {
      "order": 46,
      "part_order": 2,
      "part_title": "Part II - Planning, Memory, Reasoning, and Execution",
      "chapter_id": "artifact-graphs-audit-logs-and-replay",
      "title": "Artifact Graphs, Audit Logs, and Replay",
      "source_file": "chapters/artifact-graphs-audit-logs-and-replay.qmd",
      "public_path": "chapters/artifact-graphs-audit-logs-and-replay.html",
      "core_claim_ref": "artifact-graphs-audit-logs-and-replay.core",
      "core_claim": "Execution should produce an artifact graph with audit logs, provenance, replay metadata, and links to claims and tests.",
      "claim_label": "Design rationale",
      "support_state": "argument",
      "contribution_id": "record-reality-residual-honesty",
      "contribution_role": "primary_owner"
    },
    {
      "order": 47,
      "part_order": 2,
      "part_title": "Part II - Planning, Memory, Reasoning, and Execution",
      "chapter_id": "runtime-adapters-tool-permissions-and-human-approval",
      "title": "Runtime Adapters, Tool Permissions, and Human Approval",
      "source_file": "chapters/runtime-adapters-tool-permissions-and-human-approval.qmd",
      "public_path": "chapters/runtime-adapters-tool-permissions-and-human-approval.html",
      "core_claim_ref": "runtime-adapters-tool-permissions-and-human-approval.core",
      "core_claim": "Runtime adapters should enforce typed permissions, sandboxing, human approval, and post-action evidence capture.",
      "claim_label": "Design rationale",
      "support_state": "argument",
      "contribution_id": "governed-cognition-interface-contracts",
      "contribution_role": "supporting_or_integration"
    },
    {
      "order": 48,
      "part_order": 2,
      "part_title": "Part II - Planning, Memory, Reasoning, and Execution",
      "chapter_id": "embodied-agency-real-time-control-and-physical-safety",
      "title": "Embodied Agency, Real-Time Control, and Physical Safety",
      "source_file": "chapters/embodied-agency-real-time-control-and-physical-safety.qmd",
      "public_path": "chapters/embodied-agency-real-time-control-and-physical-safety.html",
      "core_claim_ref": "embodied-agency-real-time-control-and-physical-safety.core",
      "core_claim": "Physical execution requires a plant-specific control lease binding embodiment, workspace, state estimator, dynamics, timing, force/space/contact limits, human presence, advanced/baseline/stop controllers, switching and interlocks, exploration, degraded modes, observed effects, compensation, irreversible residuals, costs, and expiry.",
      "claim_label": "Design rationale",
      "support_state": "argument",
      "contribution_id": "record-reality-residual-honesty",
      "contribution_role": "supporting_or_integration"
    },
    {
      "order": 49,
      "part_order": 2,
      "part_title": "Part II - Planning, Memory, Reasoning, and Execution",
      "chapter_id": "inter-stack-protocols-identity-and-economic-exchange",
      "title": "Inter-Stack Protocols, Identity, and Economic Exchange",
      "source_file": "chapters/inter-stack-protocols-identity-and-economic-exchange.qmd",
      "public_path": "chapters/inter-stack-protocols-identity-and-economic-exchange.html",
      "core_claim_ref": "inter-stack-protocols-identity-and-economic-exchange.core",
      "core_claim": "A governed stack routes each cross-stack request through a versioned exchange contract that binds protocol and schema version, sender and receiver identities, endpoint and capability declaration, requested task or artifact, principal and delegated authority, credential verification, audience, scope, expiry, budget or consideration, expected receipt, dispute and revocation paths, and residual owner; an absent, mismatched, expired, revoked, unverified, or budget-unreserved required record blocks dispatch or routes accountable review, but does not itself establish peer trustworthiness, task or artifact truth, effect safety, payment settlement, legal validity, economic fairness, privacy, authorization correctness, or ASI.",
      "claim_label": "Design rationale",
      "support_state": "argument",
      "contribution_id": "governed-cognition-interface-contracts",
      "contribution_role": "supporting_or_integration"
    },
    {
      "order": 50,
      "part_order": 2,
      "part_title": "Part II - Planning, Memory, Reasoning, and Execution",
      "chapter_id": "multi-agent-dynamics-collective-intelligence-and-systemic-risk",
      "title": "Multi-Agent Dynamics, Collective Intelligence, and Systemic Risk",
      "source_file": "chapters/multi-agent-dynamics-collective-intelligence-and-systemic-risk.qmd",
      "public_path": "chapters/multi-agent-dynamics-collective-intelligence-and-systemic-risk.html",
      "core_claim_ref": "multi-agent-dynamics-collective-intelligence-and-systemic-risk.core",
      "core_claim": "Expanded multi-agent interaction requires a population contract binding agent/owner/model/organization identities, human participants, interaction and dependency graphs, incentives, information, resources, commitments, decision assumptions, entry/exit/copying/learning, population outcomes, externalities, human influence, interventions, costs, and residuals.",
      "claim_label": "Design rationale",
      "support_state": "argument",
      "contribution_id": "governed-cognition-interface-contracts",
      "contribution_role": "supporting_or_integration"
    },
    {
      "order": 51,
      "part_order": 2,
      "part_title": "Part II - Planning, Memory, Reasoning, and Execution",
      "chapter_id": "procedural-memory-and-cognitive-loop-closure",
      "title": "Procedural Memory and Cognitive Loop Closure",
      "source_file": "chapters/procedural-memory-and-cognitive-loop-closure.qmd",
      "public_path": "chapters/procedural-memory-and-cognitive-loop-closure.html",
      "core_claim_ref": "procedural-memory-and-cognitive-loop-closure.core",
      "core_claim": "Cognitive loop closure compiles repeated reasoning into verified parameterized tools and procedural memory.",
      "claim_label": "Design rationale",
      "support_state": "argument",
      "contribution_id": "record-reality-residual-honesty",
      "contribution_role": "supporting_or_integration"
    },
    {
      "order": 52,
      "part_order": 3,
      "part_title": "Part III - Routing, Compression, Representation, and Substrates",
      "chapter_id": "routing-heads-and-specialist-cores",
      "title": "Routing Heads and Specialist Cores",
      "source_file": "chapters/routing-heads-and-specialist-cores.qmd",
      "public_path": "chapters/routing-heads-and-specialist-cores.html",
      "core_claim_ref": "routing-heads-and-specialist-cores.core",
      "core_claim": "ASI scales through a lightweight routing head that selects bounded specialist cores with local tools, memory, and authority.",
      "claim_label": "Design rationale",
      "support_state": "argument",
      "contribution_id": "governed-cognition-interface-contracts",
      "contribution_role": "supporting_or_integration"
    },
    {
      "order": 53,
      "part_order": 3,
      "part_title": "Part III - Routing, Compression, Representation, and Substrates",
      "chapter_id": "replaceable-cognitive-substrates-beyond-transformer-monoculture",
      "title": "Replaceable Cognitive Substrates: Beyond Transformer Monoculture",
      "source_file": "chapters/replaceable-cognitive-substrates-beyond-transformer-monoculture.qmd",
      "public_path": "chapters/replaceable-cognitive-substrates-beyond-transformer-monoculture.html",
      "core_claim_ref": "replaceable-cognitive-substrates-beyond-transformer-monoculture.core",
      "core_claim": "For an exact task family, consumer, modality, model and state version, memory contract, hardware/runtime, authority and rights envelope, resource budget, evaluator, fallback, rollback, and time horizon, learned cognition should be supplied through a typed Cognitive Kernel ABI whose implementations are admitted only by matched strong baselines, exact state and memory semantics, proposal-versus-effect separation, evaluator independence, complete lifecycle cost, failure and residual retention, checkpoint compatibility, and causal ablation.",
      "claim_label": "Design rationale",
      "support_state": "argument",
      "contribution_id": "governed-cognition-interface-contracts",
      "contribution_role": "supporting_or_integration"
    },
    {
      "order": 54,
      "part_order": 3,
      "part_title": "Part III - Routing, Compression, Representation, and Substrates",
      "chapter_id": "relational-dimension-compilation-and-polyadic-cognition",
      "title": "Relational Dimension Compilation and Polyadic Cognition",
      "source_file": "chapters/relational-dimension-compilation-and-polyadic-cognition.qmd",
      "public_path": "chapters/relational-dimension-compilation-and-polyadic-cognition.html",
      "core_claim_ref": "relational-dimension-compilation-and-polyadic-cognition.core",
      "core_claim": "Polyadic cognition should be implemented as a slow-path relational-dimension compiler over stable lower-arity primitives: candidate higher-order structure is typed, role-addressable, denominator-complete, qualified against strong pairwise and sequence baselines, budgeted, reversible, and retained only when it improves held-out relational performance without violating memory, latency, calibration, or governance constraints.",
      "claim_label": "Design rationale",
      "support_state": "argument",
      "contribution_id": "governed-cognition-interface-contracts",
      "contribution_role": "supporting_or_integration"
    },
    {
      "order": 55,
      "part_order": 3,
      "part_title": "Part III - Routing, Compression, Representation, and Substrates",
      "chapter_id": "governed-model-training-distributed-optimization-and-scaling",
      "title": "Governed Model Training, Distributed Optimization, and Scaling",
      "source_file": "chapters/governed-model-training-distributed-optimization-and-scaling.qmd",
      "public_path": "chapters/governed-model-training-distributed-optimization-and-scaling.html",
      "core_claim_ref": "governed-model-training-distributed-optimization-and-scaling.core",
      "core_claim": "A model-training candidate is eligible for qualification only when a prospectively frozen run contract binds architecture, data lease and order, objective, optimizer, scheduler, numerical policy, device and parallelism topology, code and environment, budget, stopping and fault policy, complete attempted-run denominator, full declared checkpoint state, commit consistency, resume equivalence class, candidate-checkpoint family, validation-only selection, independent unopened qualification, and residual ownership; a loss reduction, completed job, high utilization, checkpoint file, successful load, recovered run, selected candidate, formal record proof, or source-reported scale result alone establishes neither faithful training, model quality, optimizer superiority, fault tolerance, safety, support, readiness, release, transfer, nor SOTA.",
      "claim_label": "Design rationale",
      "support_state": "argument",
      "contribution_id": "governed-cognition-interface-contracts",
      "contribution_role": "supporting_or_integration"
    },
    {
      "order": 56,
      "part_order": 3,
      "part_title": "Part III - Routing, Compression, Representation, and Substrates",
      "chapter_id": "learning-compute-topology-and-adaptive-process-architecture",
      "title": "Learning–Compute Topology and Adaptive Process Architecture",
      "source_file": "chapters/learning-compute-topology-and-adaptive-process-architecture.qmd",
      "public_path": "chapters/learning-compute-topology-and-adaptive-process-architecture.html",
      "core_claim_ref": "learning-compute-topology-and-adaptive-process-architecture.core",
      "core_claim": "For an exact task family, adaptive-state boundary, resolution contract, evidence and evaluator policy, credit semantics, lifecycle, integration operators, compute substrate, resource budget, authority, observables, rollback, and time, a self-improving stack should represent the learning process as a typed, versioned, provenance-bearing, rewritable causal topology; compile it through an explicit semantic firewall into execution and physical compute; measure discovery, evaluation, integration, communication, retention, and realization leakage jointly; and admit topology changes only through matched experiments and reversible governance. A branch count, worker count, schedule, normalized graph, bounded theorem, passing reference implementation, toy phase diagram, or source-authored architecture alone establishes neither adaptive plurality, retained learning, safety, superiority, transfer, nor ASI.",
      "claim_label": "Design rationale",
      "support_state": "argument",
      "contribution_id": "governed-cognition-interface-contracts",
      "contribution_role": "supporting_or_integration"
    },
    {
      "order": 57,
      "part_order": 3,
      "part_title": "Part III - Routing, Compression, Representation, and Substrates",
      "chapter_id": "learning-theory-generalization-and-scaling-science",
      "title": "Learning Theory, Generalization, and Scaling Science",
      "source_file": "chapters/learning-theory-generalization-and-scaling-science.qmd",
      "public_path": "chapters/learning-theory-generalization-and-scaling-science.html",
      "core_claim_ref": "learning-theory-generalization-and-scaling-science.core",
      "core_claim": "A generalization, transfer, emergence, or scaling assertion should be accepted only through a dated claim contract that binds population and sampling assumptions, data support, hypothesis and algorithm, optimization and inductive bias, complexity or explanatory lens, metric, compute regime, uncertainty, breakpoint tests, held-out prediction, alternatives, and transfer boundary; a bound, fit, interpolation result, compression ratio, benchmark jump, or larger model alone establishes neither broad generalization, capability emergence, safety, nor future scale behavior.",
      "claim_label": "Design rationale",
      "support_state": "argument",
      "contribution_id": "claim-state-transition-discipline",
      "contribution_role": "supporting_or_integration"
    },
    {
      "order": 58,
      "part_order": 3,
      "part_title": "Part III - Routing, Compression, Representation, and Substrates",
      "chapter_id": "readiness-gates-residual-escrow-and-quarantine",
      "title": "Readiness Gates, Residual Escrow, and Quarantine",
      "source_file": "chapters/readiness-gates-residual-escrow-and-quarantine.qmd",
      "public_path": "chapters/readiness-gates-residual-escrow-and-quarantine.html",
      "core_claim_ref": "readiness-gates-residual-escrow-and-quarantine.core",
      "core_claim": "For an exact versioned target, consumer, use, workload family, authority and rights envelope, and evaluation horizon, readiness should issue an expiring routability lease only from independently owned gate evidence, complete per-check state, preserved regression floors, inherited residual custody, allowed and blocked routes, monitoring, rollback and fallback obligations, and review triggers; failed, stale, waived, quarantined, superseded, retired, or lineage-invalidated targets cannot enter ordinary use, and split, merge, retrain, replace, rollback, and retirement transitions must preserve affected descendants, artifacts, effects, and residual owners.",
      "claim_label": "Design rationale",
      "support_state": "argument",
      "contribution_id": "governed-cognition-interface-contracts",
      "contribution_role": "supporting_or_integration"
    },
    {
      "order": 59,
      "part_order": 3,
      "part_title": "Part III - Routing, Compression, Representation, and Substrates",
      "chapter_id": "personal-compute-hives-and-federated-edge-intelligence",
      "title": "Personal Compute Hives and Federated Edge Intelligence",
      "source_file": "chapters/personal-compute-hives-and-federated-edge-intelligence.qmd",
      "public_path": "chapters/personal-compute-hives-and-federated-edge-intelligence.html",
      "core_claim_ref": "personal-compute-hives-and-federated-edge-intelligence.core",
      "core_claim": "For an exact versioned principal, household or project, job, use, data and tool class, effect envelope, acceptance test, risk budget, deadline, and evaluation horizon, a Personal Compute Hive should admit and place work only through policy-before-optimization: independently attested participants and roles, intersected authority and rights, task-local context and execution leases, least-authority adequate node selection, scoped approval, monitored sandboxed execution, complete artifact/effect/resource receipts, partition-aware denial or quarantine, and effect-complete rollback or residual custody; reachability, ownership, cheap capacity, a passing record schema, or stale authority alone cannot license execution, and federation, dropout, revocation, replacement, requeue, and retirement must preserve affected descendants and residual owners.",
      "claim_label": "Design rationale",
      "support_state": "argument",
      "contribution_id": "governed-cognition-interface-contracts",
      "contribution_role": "supporting_or_integration"
    },
    {
      "order": 60,
      "part_order": 3,
      "part_title": "Part III - Routing, Compression, Representation, and Substrates",
      "chapter_id": "compact-generative-systems-and-residual-honesty",
      "title": "Compact Generative Systems: Generate, Verify, Repair, and Residual Honesty",
      "source_file": "chapters/compact-generative-systems-and-residual-honesty.qmd",
      "public_path": "chapters/compact-generative-systems-and-residual-honesty.html",
      "core_claim_ref": "compact-generative-systems-and-residual-honesty.core",
      "core_claim": "For an exact versioned source artifact or state, consumer and use, reconstruction or semantic-adequacy contract, allowed loss, authority and rights envelope, workload distribution, cost boundary, and evaluation horizon, a compact representation should be admitted only when its generator, search, metadata, semantic lease, verifier, repair, fallback, interface, human, governance, recovery, and residual burdens are fully attributed; exactness or scoped loss is independently checked against the consumer contract; source lineage, supersession, and fallback remain executable; and the selected representation improves a preregistered joint utility-and-total-burden frontier over strong matched literal, standard codec, model-compression, retrieval, and semantic baselines. Smaller storage, tokens, parameters, or a finite fixture alone establishes neither useful compression nor semantic adequacy, and any hidden, moved, deferred, or discharged burden must retain state, evidence, owner, due condition, descendants, and reopening triggers.",
      "claim_label": "Design rationale",
      "support_state": "argument",
      "contribution_id": "record-reality-residual-honesty",
      "contribution_role": "primary_owner"
    },
    {
      "order": 61,
      "part_order": 3,
      "part_title": "Part III - Routing, Compression, Representation, and Substrates",
      "chapter_id": "fast-generation-architectures",
      "title": "Fast Generation Architectures",
      "source_file": "chapters/fast-generation-architectures.qmd",
      "public_path": "chapters/fast-generation-architectures.html",
      "core_claim_ref": "fast-generation-architectures.core",
      "core_claim": "Fast-generation admission is consumer-, workload-, model-, hardware-, serving-policy-, and time-window-specific: a controller may route an eligible request through a named accelerated path only after prospectively binding the context, quality, risk, budget, metric, verifier, fallback, rollback, and expiry contracts; separating attempted, proposed, accepted, verified, delivered, and useful output; fully attributing queueing, prefill, decode, verification, repair, retry, fallback, cache, memory, bandwidth, energy, human, and governance burdens; and showing a meaningful end-to-end improvement over matched quality-equivalent baselines without violating safety, authority, rights, or residual gates. Raw tokens per second, FLOP estimates, aggregate throughput, synthetic templates, or unverified speed lifts alone cannot qualify a route.",
      "claim_label": "Design rationale",
      "support_state": "argument",
      "contribution_id": "record-reality-residual-honesty",
      "contribution_role": "supporting_or_integration"
    },
    {
      "order": 62,
      "part_order": 3,
      "part_title": "Part III - Routing, Compression, Representation, and Substrates",
      "chapter_id": "governed-deliberation-and-test-time-scaling",
      "title": "Governed Deliberation and Test-Time Scaling",
      "source_file": "chapters/governed-deliberation-and-test-time-scaling.qmd",
      "public_path": "chapters/governed-deliberation-and-test-time-scaling.html",
      "core_claim_ref": "governed-deliberation-and-test-time-scaling.core",
      "core_claim": "Governed deliberation is a consumer-, task-, risk-, model-, evaluator-, resource-, and time-specific inference lease: before outcomes, it chooses among direct generation, bounded revision, candidate search, or abstention; binds exact budgets, candidate/history custody, verifier scope and dependence, stop and escalation rules, initially-correct corruption and initially-incorrect repair metrics, downstream consumer, expiry, and residual owner; and admits only a bounded candidate to planning when matched natural and adversarial evidence shows useful gain after all branches, failures, verification, latency, compute, human, and governance costs. A trace, self-score, process reward, benchmark gain, or extra compute never establishes correctness, safety, capability, execution authority, or support movement by itself.",
      "claim_label": "Design rationale",
      "support_state": "argument",
      "contribution_id": "claim-state-transition-discipline",
      "contribution_role": "supporting_or_integration"
    },
    {
      "order": 63,
      "part_order": 3,
      "part_title": "Part III - Routing, Compression, Representation, and Substrates",
      "chapter_id": "rankfold-neuralfold-and-artifact-compression",
      "title": "RankFold, NeuralFold, and Artifact Compression",
      "source_file": "chapters/rankfold-neuralfold-and-artifact-compression.qmd",
      "public_path": "chapters/rankfold-neuralfold-and-artifact-compression.html",
      "core_claim_ref": "rankfold-neuralfold-and-artifact-compression.core",
      "core_claim": "A compressed artifact may enter a downstream route only through an artifact-, consumer-, use-, access-pattern-, decoder-, platform-, and time-specific admission lease that preserves the full source, separates representation, reconstruction, ratio, utility, latency, and evidentiary-authority claims, counts every byte and operation, exercises probes and fallback, and expires or quarantines on drift; RankFold/NeuralFold remains a bounded candidate implementation, and no compact form inherits the source artifact's authority.",
      "claim_label": "Design rationale",
      "support_state": "argument",
      "contribution_id": "record-reality-residual-honesty",
      "contribution_role": "supporting_or_integration"
    },
    {
      "order": 64,
      "part_order": 3,
      "part_title": "Part III - Routing, Compression, Representation, and Substrates",
      "chapter_id": "resource-economics-and-token-budgets",
      "title": "Resource Economics and Token Budgets",
      "source_file": "chapters/resource-economics-and-token-budgets.qmd",
      "public_path": "chapters/resource-economics-and-token-budgets.html",
      "core_claim_ref": "resource-economics-and-token-budgets.core",
      "core_claim": "Resource Economics owns a consumer-, task-, risk-, workload-, organization-, resource-, and time-specific allocation lease that admits, prices, schedules, defers, shrinks, escalates, or rejects work only after protected safety and rights floors, complete direct and displaced costs, uncertainty, useful outcome value, verification capacity, load and tail stability, simulation-transfer limits, recovery, and residual ownership are explicit; throughput, low token count, synthetic success, or a cheap route alone confers no quality, safety, economic-optimality, support, or deployment authority.",
      "claim_label": "Design rationale",
      "support_state": "argument",
      "contribution_id": "record-reality-residual-honesty",
      "contribution_role": "primary_owner"
    },
    {
      "order": 65,
      "part_order": 3,
      "part_title": "Part III - Routing, Compression, Representation, and Substrates",
      "chapter_id": "physical-compute-infrastructure-energy-and-environmental-constraints",
      "title": "Physical Compute Infrastructure, Energy, and Environmental Constraints",
      "source_file": "chapters/physical-compute-infrastructure-energy-and-environmental-constraints.qmd",
      "public_path": "chapters/physical-compute-infrastructure-energy-and-environmental-constraints.html",
      "core_claim_ref": "physical-compute-infrastructure-energy-and-environmental-constraints.core",
      "core_claim": "A compute allocation should be physically eligible only through a workload-to-capacity contract that binds location and time, hardware and interconnect, delivered useful work, facility and grid dependencies, energy attribution, cooling and water, materials, land and community effects, metering uncertainty, resilience and degradation, maintenance, demand response, reuse, retirement, and residuals; nameplate compute, efficiency, low PUE, renewable procurement, or aggregate energy alone establishes neither availability, sustainability, community acceptability, nor lower total impact.",
      "claim_label": "Design rationale",
      "support_state": "argument",
      "contribution_id": "record-reality-residual-honesty",
      "contribution_role": "supporting_or_integration"
    },
    {
      "order": 66,
      "part_order": 3,
      "part_title": "Part III - Routing, Compression, Representation, and Substrates",
      "chapter_id": "mathematical-and-search-substrates",
      "title": "Mathematical and Search Substrates",
      "source_file": "chapters/mathematical-and-search-substrates.qmd",
      "public_path": "chapters/mathematical-and-search-substrates.html",
      "core_claim_ref": "mathematical-and-search-substrates.core",
      "core_claim": "Mathematical and Search Substrates owns a consumer-, use-, workload-, claim-axis-, implementation-, baseline-, resource-, and time-specific Substrate Adoption Lease: an unusual calculus, representation, recurrence, search procedure, latent world model, or sequence backbone may affect only the axes and consumers that pass matched ordinary and current baselines, negative controls, complete cost and rights accounting, falsification, fallback, independent reproduction, and transfer; structural elegance, a theorem, a source-reported benchmark, synthetic fixture validity, or one favorable axis alone confers no general quality, efficiency, safety, support, deployment, or SOTA authority.",
      "claim_label": "Design rationale",
      "support_state": "argument",
      "contribution_id": "record-reality-residual-honesty",
      "contribution_role": "supporting_or_integration"
    },
    {
      "order": 67,
      "part_order": 3,
      "part_title": "Part III - Routing, Compression, Representation, and Substrates",
      "chapter_id": "circle-calculus-and-proof-carrying-ai-contracts",
      "title": "Circle Calculus and Proof-Carrying AI Contracts",
      "source_file": "chapters/circle-calculus-and-proof-carrying-ai-contracts.qmd",
      "public_path": "chapters/circle-calculus-and-proof-carrying-ai-contracts.html",
      "core_claim_ref": "circle-calculus-and-proof-carrying-ai-contracts.core",
      "core_claim": "Circle Calculus and Proof-Carrying AI Contracts owns a theorem-, model-, artifact-, implementation-, consumer-, claim-, version-, and time-specific Proof Contract Transport Envelope: a finite formal fact may travel only with resolvable proof identity, exact assumptions and semantics, source and toolchain provenance, content fingerprints, deterministic recomputation or replay, least-authority consumer gates, expiry and revocation, and preserved non-claims; theorem validity, receipt readiness, archive integrity, or transport success alone confers no model-quality, runtime, memory, safety, deployment, transfer, support, or SOTA authority.",
      "claim_label": "Design rationale",
      "support_state": "argument",
      "contribution_id": "record-reality-residual-honesty",
      "contribution_role": "supporting_or_integration"
    },
    {
      "order": 68,
      "part_order": 3,
      "part_title": "Part III - Routing, Compression, Representation, and Substrates",
      "chapter_id": "coil-attention-cyclic-memory-and-recurrence-contracts",
      "title": "Coil Attention, Cyclic Memory, and Recurrence Contracts",
      "source_file": "chapters/coil-attention-cyclic-memory-and-recurrence-contracts.qmd",
      "public_path": "chapters/coil-attention-cyclic-memory-and-recurrence-contracts.html",
      "core_claim_ref": "coil-attention-cyclic-memory-and-recurrence-contracts.core",
      "core_claim": "Coil Attention, Cyclic Memory, and Recurrence Contracts owns a memory-object-, state-version-, request-, consumer-, workload-, structural-axis-, budget-, and time-specific State-Carry and Recurrence Admission Lease: a slot read, cyclic address, KV reuse, sparse edge, fanout schedule, or recurrent step may be admitted only when authority, provenance, residue and winding, freshness, coverage, alias and collision state, active work, progress, exit, fallback, expiry, and residuals satisfy the exact consumer contract; structural validity, synthetic fixtures, receipt replay, cache presence, or reduced scheduled work alone confers no retrieval, reasoning, context-length, quality, speed, memory, safety, deployment, transfer, support, or SOTA authority.",
      "claim_label": "Design rationale",
      "support_state": "argument",
      "contribution_id": "record-reality-residual-honesty",
      "contribution_role": "supporting_or_integration"
    },
    {
      "order": 69,
      "part_order": 3,
      "part_title": "Part III - Routing, Compression, Representation, and Substrates",
      "chapter_id": "coilra-multicoil-rope-and-cyclic-mixers",
      "title": "CoilRA, MultiCoil RoPE, and Cyclic Mixers",
      "source_file": "chapters/coilra-multicoil-rope-and-cyclic-mixers.qmd",
      "public_path": "chapters/coilra-multicoil-rope-and-cyclic-mixers.html",
      "core_claim_ref": "coilra-multicoil-rope-and-cyclic-mixers.core",
      "core_claim": "CoilRA, MultiCoil RoPE, and Cyclic Mixers owns a model-, layer-, mechanism-version-, workload-, baseline-, kernel-, hardware-, claim-axis-, and time-specific Cyclic Mechanism Tradeoff Packet: a cyclic adapter, phase bank, rotary scheme, route head, circulant operator, or block-cyclic mixer may enter a canary only when exact residue/winding, phase horizon, alias/collision/load, dense-reference parity, parameter and operation accounting, numerical error, kernel availability, complete cost, quality, failure, fallback, and rights evidence is matched against strong ordinary controls; equivariance, finite proofs, receipt validity, parameter reduction, or structural parity alone confers no quality, context-length, speed, memory, stability, efficiency, safety, deployment, transfer, support, or SOTA authority.",
      "claim_label": "Design rationale",
      "support_state": "argument",
      "contribution_id": "record-reality-residual-honesty",
      "contribution_role": "supporting_or_integration"
    },
    {
      "order": 70,
      "part_order": 4,
      "part_title": "Part IV - Evidence, Implementation, and the Living Book",
      "chapter_id": "executable-specifications-and-lean-proof-envelope",
      "title": "Executable Specifications and Lean Proof Envelope",
      "source_file": "chapters/executable-specifications-and-lean-proof-envelope.qmd",
      "public_path": "chapters/executable-specifications-and-lean-proof-envelope.html",
      "core_claim_ref": "executable-specifications-and-lean-proof-envelope.core",
      "core_claim": "Executable Specifications and Lean Proof Envelope owns a proposition-, predicate-, abstraction-, artifact-, verifier-, consumer-, implementation-, version-, environment-, and time-specific Formal Artifact Authority Lease: a schema, executable model, Lean theorem, model-checking result, runtime monitor, behavior test, benchmark, or external theorem may authorize only the exact consumer statement whose operational semantics, abstraction map and losses, assumptions, dependency closure, verifier result, semantic adequacy, implementation binding, limitations, non-claims, expiry, and revocation path are recorded; artifact existence, field presence, a finite route, proof depth, a green build, a passing fixture, or an external theorem identity alone confers no deployed enforcement, empirical truth, system safety, source correctness, support promotion, transfer, or SOTA authority.",
      "claim_label": "Design rationale",
      "support_state": "argument",
      "contribution_id": "claim-state-transition-discipline",
      "contribution_role": "primary_owner"
    },
    {
      "order": 71,
      "part_order": 4,
      "part_title": "Part IV - Evidence, Implementation, and the Living Book",
      "chapter_id": "benchmark-ratchets-and-anti-goodhart-evidence",
      "title": "Benchmark Ratchets and Anti-Goodhart Evidence",
      "source_file": "chapters/benchmark-ratchets-and-anti-goodhart-evidence.qmd",
      "public_path": "chapters/benchmark-ratchets-and-anti-goodhart-evidence.html",
      "core_claim_ref": "benchmark-ratchets-and-anti-goodhart-evidence.core",
      "core_claim": "Benchmark Ratchets and Anti-Goodhart Evidence owns a construct-, task-, dataset-, metric-, harness-, model-, checkpoint-, output-, evaluator-, baseline-, retry-lineage-, budget-, environment-, claim-axis-, and time-specific Benchmark Instrument Lease: a score or evaluation event may update only the exact claim whose construct validity, target capacity, data and metric provenance, output binding, contamination and public-calibration boundary, strong baselines and negative controls, complete selection and failure lineage, regression floors, frontier state, uncertainty, costs, causal checks, transfer, residuals, and decision authority survive review; a green fixture, synthetic probe, source-reported result, leaderboard gain, held-out score, saturation label, or archived winner alone confers no capability, safety, readiness, deployment, unlearning, support, transfer, or SOTA authority.",
      "claim_label": "Design rationale",
      "support_state": "argument",
      "contribution_id": "claim-state-transition-discipline",
      "contribution_role": "supporting_or_integration"
    },
    {
      "order": 72,
      "part_order": 4,
      "part_title": "Part IV - Evidence, Implementation, and the Living Book",
      "chapter_id": "white-box-evidence-interpretability-and-activation-governance",
      "title": "White-Box Evidence, Interpretability, and Activation Governance",
      "source_file": "chapters/white-box-evidence-interpretability-and-activation-governance.qmd",
      "public_path": "chapters/white-box-evidence-interpretability-and-activation-governance.html",
      "core_claim_ref": "white-box-evidence-interpretability-and-activation-governance.core",
      "core_claim": "Internal-state observations should enter governance only as typed evidence artifacts with lineage, method assumptions, replication status, causal interventions, stability checks, coverage limits, and explicit non-authority; white-box evidence complements but does not replace behavioral and operational evidence.",
      "claim_label": "Design rationale",
      "support_state": "argument",
      "contribution_id": "claim-state-transition-discipline",
      "contribution_role": "supporting_or_integration"
    },
    {
      "order": 73,
      "part_order": 4,
      "part_title": "Part IV - Evidence, Implementation, and the Living Book",
      "chapter_id": "capability-thresholds-and-deployment-commitments",
      "title": "Capability Thresholds and Deployment Commitments",
      "source_file": "chapters/capability-thresholds-and-deployment-commitments.qmd",
      "public_path": "chapters/capability-thresholds-and-deployment-commitments.html",
      "core_claim_ref": "capability-thresholds-and-deployment-commitments.core",
      "core_claim": "Capability Thresholds and Deployment Commitments owns a domain-, threat-, assessment-, policy-version-, safeguard-package-, release-path-, authority-, exception-, residual-, and time-specific Capability-to-Deployment Commitment: before outcomes are visible, it binds a scoped crossing, non-crossing, incomparable, or stale assessment to predeclared safeguards, verification criteria, deadlines, access and monitoring constraints, re-evaluation, exceptions, residual custody, rollback, disclosure, and release-path consequences; a score, time-horizon estimate, threshold label, crossing, non-crossing, safeguard record, exception, or green readiness handoff alone confers no general capability, safeguard efficacy, safety, readiness, deployment, support, transfer, or SOTA authority.",
      "claim_label": "Design rationale",
      "support_state": "argument",
      "contribution_id": "claim-state-transition-discipline",
      "contribution_role": "supporting_or_integration"
    },
    {
      "order": 74,
      "part_order": 4,
      "part_title": "Part IV - Evidence, Implementation, and the Living Book",
      "chapter_id": "adversarial-evaluation-sandbagging-and-training-time-deception",
      "title": "Adversarial Evaluation, Sandbagging, and Training-Time Deception",
      "source_file": "chapters/adversarial-evaluation-sandbagging-and-training-time-deception.qmd",
      "public_path": "chapters/adversarial-evaluation-sandbagging-and-training-time-deception.html",
      "core_claim_ref": "adversarial-evaluation-sandbagging-and-training-time-deception.core",
      "core_claim": "Adversarial Evaluation, Sandbagging, and Training-Time Deception owns a consumer-, decision-, model-, task-, elicitation-, authority-, monitor-, reward-, selection-, evaluator-, hypothesis-, outcome-, lineage-, and time-specific Evaluation Observation Integrity Packet: before outcomes are inspected, it freezes the permitted inference and comparison design, binds every observable and dependency, separates task outcome from behavioral interpretation, preserves discrepancies, alternatives, failures, costs, mitigation descendants, expiry, and downstream invalidation, and routes only a bounded observation-integrity status to existing evidence and decision owners; no score, trace, discrepancy, detector, mitigation, adversarial pass, quarantine, or complete finite packet alone establishes capability, intent, deception, sandbagging prevalence or resistance, reward fidelity, monitor validity, alignment, safety, readiness, deployment, support, transfer, or SOTA.",
      "claim_label": "Design rationale",
      "support_state": "argument",
      "contribution_id": "claim-state-transition-discipline",
      "contribution_role": "supporting_or_integration"
    },
    {
      "order": 75,
      "part_order": 4,
      "part_title": "Part IV - Evidence, Implementation, and the Living Book",
      "chapter_id": "safety-cases-and-structured-assurance",
      "title": "Safety Cases and Structured Assurance",
      "source_file": "chapters/safety-cases-and-structured-assurance.qmd",
      "public_path": "chapters/safety-cases-and-structured-assurance.html",
      "core_claim_ref": "safety-cases-and-structured-assurance.core",
      "core_claim": "Safety Cases and Structured Assurance owns a deployment-context-, hazard-, claim-, strategy-, evidence-, assumption-, defeater-, safeguard-, threshold-, readiness-, authority-, release-path-, residual-, version-, and time-specific Assurance Argument Compilation Packet: it compiles exact governed references and bounded support or challenge relations, preserves alternatives, dissent, staleness, countercases, conflicts, overrides, costs, lineage, and downstream invalidation, and routes only a scoped case status to existing decision owners; a connected, rendered, notation-conformant, reviewed, accepted, or synthetically complete case alone establishes neither hazard completeness, evidence adequacy, argument validity, reviewer independence, control effectiveness, risk, safety, readiness, release authority, deployment, support, transfer, nor SOTA.",
      "claim_label": "Design rationale",
      "support_state": "argument",
      "contribution_id": "claim-state-transition-discipline",
      "contribution_role": "supporting_or_integration"
    },
    {
      "order": 76,
      "part_order": 4,
      "part_title": "Part IV - Evidence, Implementation, and the Living Book",
      "chapter_id": "content-authenticity-watermarking-and-synthetic-media-integrity",
      "title": "Content Authenticity, Watermarking, and Synthetic Media Integrity",
      "source_file": "chapters/content-authenticity-watermarking-and-synthetic-media-integrity.qmd",
      "public_path": "chapters/content-authenticity-watermarking-and-synthetic-media-integrity.html",
      "core_claim_ref": "content-authenticity-watermarking-and-synthetic-media-integrity.core",
      "core_claim": "Synthetic-media integrity should use a layered authenticity envelope that binds asset identity, generator and editor claims, signed provenance, content bindings, watermark or fingerprint signals, detector outputs, visible disclosure, transformation history, trust policy, uncertainty, and remedy; every signal retains its own semantics, and no missing or valid signal becomes a universal truth judgment.",
      "claim_label": "Design rationale",
      "support_state": "argument",
      "contribution_id": "record-reality-residual-honesty",
      "contribution_role": "supporting_or_integration"
    },
    {
      "order": 77,
      "part_order": 4,
      "part_title": "Part IV - Evidence, Implementation, and the Living Book",
      "chapter_id": "governed-operations-incident-command-and-graceful-degradation",
      "title": "Governed Operations, Incident Command, and Graceful Degradation",
      "source_file": "chapters/governed-operations-incident-command-and-graceful-degradation.qmd",
      "public_path": "chapters/governed-operations-incident-command-and-graceful-degradation.html",
      "core_claim_ref": "governed-operations-incident-command-and-graceful-degradation.core",
      "core_claim": "Governed operation is a closed incident lifecycle that binds detection, classification, command authority, containment, effect-complete rollback, graceful degradation, recovery evidence, and learning to the exact deployed system and its dependency graph.",
      "claim_label": "Design rationale",
      "support_state": "argument",
      "contribution_id": "record-reality-residual-honesty",
      "contribution_role": "supporting_or_integration"
    },
    {
      "order": 78,
      "part_order": 4,
      "part_title": "Part IV - Evidence, Implementation, and the Living Book",
      "chapter_id": "adjudicated-persistence-and-the-adaptive-commit-boundary",
      "title": "Adjudicated Persistence and the Adaptive Commit Boundary",
      "source_file": "chapters/adjudicated-persistence-and-the-adaptive-commit-boundary.qmd",
      "public_path": "chapters/adjudicated-persistence-and-the-adaptive-commit-boundary.html",
      "core_claim_ref": "adjudicated-persistence-and-the-adaptive-commit-boundary.core",
      "core_claim": "Every transition from experience to durable causal influence should cross an Adaptive Commit Boundary as an authority-bearing adaptation transaction that keeps the experience record, lesson hypothesis, persistence disposition, concrete realization, qualification lease, and authority grant distinct; selects the least-commitment admissible locus portfolio under evidence, authority, observability, recovery, cost, and descendant obligations; and preserves denial, uncertainty, deoptimization, invalidation, and revocation paths.",
      "claim_label": "Design rationale",
      "support_state": "argument",
      "contribution_id": "governed-cognition-interface-contracts",
      "contribution_role": "supporting_or_integration"
    },
    {
      "order": 79,
      "part_order": 4,
      "part_title": "Part IV - Evidence, Implementation, and the Living Book",
      "chapter_id": "policy-optimization-and-learning-from-feedback",
      "title": "Policy Optimization and Learning from Feedback",
      "source_file": "chapters/policy-optimization-and-learning-from-feedback.qmd",
      "public_path": "chapters/policy-optimization-and-learning-from-feedback.html",
      "core_claim_ref": "policy-optimization-and-learning-from-feedback.core",
      "core_claim": "Policy Optimization and Learning from Feedback owns a target-policy-, baseline-, objective-, feedback-, evaluator-, dataset-, optimizer-, checkpoint-, rollout-, authority-, resource-, monitor-, rollback-, consumer-, environment-, and time-specific Governed Policy Update Lease: before any update, it freezes the legitimate target behavior, admissible feedback and proxy boundary, strong baselines, update family and budget, drift and authority ceilings, complete evaluation and failure denominators, reward-hacking and causal checks, rollback and monitoring, residuals, expiry, and promotion authority; a reward, preference, verifier score, benchmark gain, loss reduction, synthetic canary, formal route, rollback dry run, or trained checkpoint alone establishes neither reward validity, causal policy improvement, retained capability, alignment, safety, readiness, deployment, support, transfer, nor SOTA.",
      "claim_label": "Design rationale",
      "support_state": "argument",
      "contribution_id": "record-reality-residual-honesty",
      "contribution_role": "supporting_or_integration"
    },
    {
      "order": 80,
      "part_order": 4,
      "part_title": "Part IV - Evidence, Implementation, and the Living Book",
      "chapter_id": "data-engines-continual-learning-and-unlearning",
      "title": "Data Engines, Continual Learning, and Unlearning",
      "source_file": "chapters/data-engines-continual-learning-and-unlearning.qmd",
      "public_path": "chapters/data-engines-continual-learning-and-unlearning.html",
      "core_claim_ref": "data-engines-continual-learning-and-unlearning.core",
      "core_claim": "Data Engines, Continual Learning, and Unlearning owns a datum-, cohort-, provenance-, rights-, split-, contamination-, learning-lane-, retention-, checkpoint-authority-, full-state-inventory-, descendant-, deletion-request-, claim-axis-, consumer-, environment-, and time-specific Data-and-Descendant Custody Lease: before learning or deletion, it binds admissible use, evaluation exclusions, synthetic and transformation lineage, coverage and distribution residuals, model/optimizer/scheduler/RNG/cache/backup/descendant state, prospective checkpoint authority, retention and replay, deletion propagation, verification, rollback, expiry, and terminal custody; behavioral cohort change, causal influence reduction, privacy leakage reduction, lineage invalidation, legal compliance, and storage or backup erasure remain separate claims, and no receipt, checksum, exclusion, invalidation, benchmark score, rollback match, or synthetic campaign alone establishes model quality, forgetting, privacy, erasure, safety, readiness, deployment, support, transfer, or SOTA.",
      "claim_label": "Design rationale",
      "support_state": "argument",
      "contribution_id": "record-reality-residual-honesty",
      "contribution_role": "supporting_or_integration"
    },
    {
      "order": 81,
      "part_order": 4,
      "part_title": "Part IV - Evidence, Implementation, and the Living Book",
      "chapter_id": "scientific-discovery-and-experimental-governance",
      "title": "Scientific Discovery and Experimental Governance",
      "source_file": "chapters/scientific-discovery-and-experimental-governance.qmd",
      "public_path": "chapters/scientific-discovery-and-experimental-governance.html",
      "core_claim_ref": "scientific-discovery-and-experimental-governance.core",
      "core_claim": "An AI-generated scientific claim should enter the evidence stack only through a preregistered experimental contract that binds hypothesis lineage, exploratory versus confirmatory status, design and power, instrument or simulator authority, calibration, sample and protocol lineage, blinding and holdouts, stopping and exclusions, analysis, complete attempts, independent replication, dual-use disposition, and claim ceiling; experimental completion, significance, synthesis, instrument output, or formal workflow validity alone establishes neither causal truth, general scientific discovery, reproducibility, safety, nor transfer.",
      "claim_label": "Design rationale",
      "support_state": "argument",
      "contribution_id": "claim-state-transition-discipline",
      "contribution_role": "supporting_or_integration"
    },
    {
      "order": 82,
      "part_order": 4,
      "part_title": "Part IV - Evidence, Implementation, and the Living Book",
      "chapter_id": "artifact-steward-agents-and-living-project-governance",
      "title": "Artifact Steward Agents and Living Project Governance",
      "source_file": "chapters/artifact-steward-agents-and-living-project-governance.qmd",
      "public_path": "chapters/artifact-steward-agents-and-living-project-governance.html",
      "core_claim_ref": "artifact-steward-agents-and-living-project-governance.core",
      "core_claim": "Artifact Steward Agents and Living Project Governance owns a project-, artifact-, mission-, owner-, authority-, roadmap-, work-contract-, event-, treasury-, compute-, contributor-, evidence-, governance-, release-, federation-, sunset-, consumer-, environment-, and time-specific Artifact Steward Continuity Lease: it may observe, propose, prepare, coordinate, execute, reverse, archive, or retire only through a versioned charter, taint-aware intake, scoped work contracts, separated contribution ledgers, bounded treasury and compute policy, verification and release gates, appeal and fork or exit paths, effect-complete rollback, and explicit sunset authority; it never acquires ownership, governance legitimacy, evidence authority, funding rights, release authority, legal standing, or permission from useful motion, a green workflow, a vote, a balance, a score, a fixture, a theorem, or its own prior action.",
      "claim_label": "Design rationale",
      "support_state": "argument",
      "contribution_id": "governed-cognition-interface-contracts",
      "contribution_role": "supporting_or_integration"
    },
    {
      "order": 83,
      "part_order": 4,
      "part_title": "Part IV - Evidence, Implementation, and the Living Book",
      "chapter_id": "integrated-reference-architecture",
      "title": "Integrated Reference Architecture",
      "source_file": "chapters/integrated-reference-architecture.qmd",
      "public_path": "chapters/integrated-reference-architecture.html",
      "core_claim_ref": "integrated-reference-architecture.core",
      "core_claim": "Integrated Reference Architecture owns a trace-, run-, request-, intent-, authority-, artifact-, parentage-, layer-, canonical-state-, material-effect-, terminal-receipt-, evaluator-, evidence-, residual-, rollback-, consumer-, environment-, and time-specific Cross-Layer Trace Join Contract: it proves integration only when every participating owner remains distinct and its typed input, output, authority delta, state identity, observed effect, acknowledgement, evaluation, evidence delta, residual, stop, repair, rollback, and non-claim remain joinable across approved, blocked, failed, revoked, rolled-back, and quarantined paths; a diagram, shared prompt, interface name, projection, green service, replay, fixture, theorem, or locally successful slice cannot establish whole-stack execution, semantic preservation, governance enforcement, safety, capability, deployment, transfer, or SOTA.",
      "claim_label": "Design rationale",
      "support_state": "argument",
      "contribution_id": "governed-cognition-interface-contracts",
      "contribution_role": "primary_owner"
    },
    {
      "order": 84,
      "part_order": 4,
      "part_title": "Part IV - Evidence, Implementation, and the Living Book",
      "chapter_id": "project-theseus-as-report-first-implementation-reference",
      "title": "Project Theseus as Report-First Implementation Reference",
      "source_file": "chapters/project-theseus-as-report-first-implementation-reference.qmd",
      "public_path": "chapters/project-theseus-as-report-first-implementation-reference.html",
      "core_claim_ref": "project-theseus-as-report-first-implementation-reference.core",
      "core_claim": "Project Theseus as Report-First Implementation Reference owns a source-project-, pinned-revision-, report-family-, command-, environment-, artifact-, lineage-, evidence-state-, replay-, public-safety-, publication-permission-, reviewer-, consumer-, and time-specific Implementation-Reference Evidence Packet: it binds every imported or replayed report, configuration, ledger, work-board summary, registry, gate, crosswalk, trace, retained artifact, command, environment note, digest, missing artifact, decision, residual, and non-claim to source-note-only, imported, replay-ready, replay-failed, locally reproduced, stale, runtime-blocked, or archived lineage; dashboards and latest files are projections only, and no GREEN gate, complete registry, module card, pointer row, metadata snapshot, parity manifest, command replay, fixture, theorem, or sanitized import alone establishes current runtime truth, clean live replay, model quality, capability, benchmark validity, safety, deployment, support, transfer, AGI, ASI, or SOTA.",
      "claim_label": "Design rationale",
      "support_state": "argument",
      "contribution_id": "record-reality-residual-honesty",
      "contribution_role": "supporting_or_integration"
    },
    {
      "order": 85,
      "part_order": 4,
      "part_title": "Part IV - Evidence, Implementation, and the Living Book",
      "chapter_id": "prototype-roadmap",
      "title": "Prototype Roadmap",
      "source_file": "chapters/prototype-roadmap.qmd",
      "public_path": "chapters/prototype-roadmap.html",
      "core_claim_ref": "prototype-roadmap.core",
      "core_claim": "Prototype Roadmap owns a program-, roadmap-, phase-, dependency-, artifact-, acceptance-gate-, authority-, evaluator-, evidence-transition-, phase-debt-, residual-, rollback-, reviewer-, consumer-, environment-, and time-specific Evidence-Gated Phase Unlock Contract: it binds every proposed phase to prerequisites, allowed work state, required artifacts, commands, environment, resource bounds, gates, independent evaluation, residuals, debt, rollback, retirement, evidence effect, and non-claims before later work may research, demo, integrate, promote, or release; no roadmap row, milestone, source report, dashboard, task count, passing fixture, theorem, validator, build, or locally useful prototype alone establishes phase completion, safe dependency order, capability, governance effectiveness, deployment, transfer, AGI, ASI, or SOTA.",
      "claim_label": "Design rationale",
      "support_state": "argument",
      "contribution_id": "record-reality-residual-honesty",
      "contribution_role": "supporting_or_integration"
    },
    {
      "order": 86,
      "part_order": 4,
      "part_title": "Part IV - Evidence, Implementation, and the Living Book",
      "chapter_id": "living-book-methodology",
      "title": "Living Book Methodology",
      "source_file": "chapters/living-book-methodology.qmd",
      "public_path": "chapters/living-book-methodology.html",
      "core_claim_ref": "living-book-methodology.core",
      "core_claim": "Living Book Methodology owns a book-, edition-, change-, source-, claim-, proof-, test-, render-, audience-, derivative-, release-, rights-, reviewer-, consumer-, environment-, and time-specific Evidence-Preserving Publication Transaction: it binds every substantive intake, structural edit, claim change, proof or test change, render, reader or audio projection, release, correction, rollback, and successor handoff to canonical source state, provenance, authority, validation, evidence effect, residuals, non-claims, and immutable lineage; generated scaffolds, green validators, theorem builds, successful renders, local format artifacts, publication activity, or a polished release never by themselves establish source interpretation, editorial quality, accessibility, reader approval, chapter truth, capability, safety, external reproduction, transfer, AGI, ASI, or SOTA.",
      "claim_label": "Design rationale",
      "support_state": "argument",
      "contribution_id": "claim-state-transition-discipline",
      "contribution_role": "primary_owner"
    },
    {
      "order": 87,
      "part_order": 4,
      "part_title": "Part IV - Evidence, Implementation, and the Living Book",
      "chapter_id": "open-research-agenda-and-bibliography-plan",
      "title": "Open Research Agenda and Bibliography Plan",
      "source_file": "chapters/open-research-agenda-and-bibliography-plan.qmd",
      "public_path": "chapters/open-research-agenda-and-bibliography-plan.html",
      "core_claim_ref": "open-research-agenda-and-bibliography-plan.core",
      "core_claim": "Open Research Agenda and Bibliography Plan owns a research-program-, source-or-gap-, backlog-item-, access-, provenance-, public-safety-, chapter-boundary-, claim-, proof-or-experiment-, deduplication-, evidence-transition-, owner-, next-action-, closure-, consumer-, environment-, and time-specific Research Backlog Admission and Closure Contract: every new paper, local project, missing artifact, conflicting result, proof idea, experiment, reproduction need, correction, or chapter proposal enters through exact intake, triage, assignment, preconditions, blockers, non-claims, and terminal closure before it changes prose or support; no title, citation, source count, inventory row, source note, queue, priority label, backlog size, fixture, theorem, validator, or completed reading task alone establishes citation accuracy, literature completeness, research quality, claim support, reproduction, transfer, AGI, ASI, or SOTA.",
      "claim_label": "Design rationale",
      "support_state": "argument",
      "contribution_id": "claim-state-transition-discipline",
      "contribution_role": "supporting_or_integration"
    }
  ],
  "supporting_routes": [
    "appendices/D_protocol_schemas.html",
    "appendices/K_implementation_horizons.html",
    "appendices/B_glossary.html"
  ],
  "non_claims": [
    "A complete reference index does not establish deployed enforcement or architecture quality.",
    "Chapter inclusion does not promote a support state.",
    "The canonical Quarto source remains authoritative."
  ]
}
