{ "schema_version": "asi_stack.narrative_product_projection.v1", "status": "generated_candidate_spine_not_a_reviewed_reader_release", "selected_chapter_count": 22, "canonical_chapter_count": 87, "selected_canonical_orders": [ 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22 ], "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", "plain_language_thesis": "Advanced AI is easier to understand and govern when capability, authority, memory, planning, action, evidence, and improvement remain distinct responsibilities.", "normative_engineering_rule": "Design the system as typed layers whose artifacts and authority cross only declared interfaces with explicit failure, observation, and recovery ownership.", "machine_contract": "Admit a layer transition only when source and target identities, authority, obligations, evidence, residuals, consumers, expiry, and recovery are bound; capability alone does not authorize the transition.", "reader_question": "Why should advanced AI be treated as governed responsibilities and transitions rather than one opaque model?", "running_example": "Start one repository change by separating capability, authority, context, plan, effect, observation, evidence, and replacement.", "strongest_objection": "A sufficiently capable end-to-end model may preserve more information with less bureaucracy than an explicit stack.", "failure_story": "The change succeeds, but nobody can reconstruct who authorized it, what changed, or how to recover it.", "evidence_that_would_change_the_conclusion": "Matched natural deployments showing simpler monolithic operation is equally controllable, observable, recoverable, useful, and affordable would narrow the thesis.", "handoff": "The efficiency unit asks whether explicit routing and reuse can earn their governance and lifecycle costs.", "unit_id": "unit-01-stack-thesis", "unit_label": "Stack thesis", "reference_owner_count": 0, "reference_owners": [], "contribution_id": "governed-cognition-interface-contracts" }, { "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", "plain_language_thesis": "Useful intelligence may become cheaper and more dependable when work is routed, reused, verified, and repaired according to the task instead of always invoking the largest model.", "normative_engineering_rule": "Compare candidate routes on accepted useful output and full lifecycle cost, including verification, repair, review, residuals, latency, memory, energy, and recovery.", "machine_contract": "Select a route only from candidates that satisfy the frozen quality and authority floor and minimize declared lifecycle cost; a cheaper token path does not establish efficiency or permission.", "reader_question": "Can governed routing, reuse, and specialist computation improve useful capability without hiding displaced costs?", "running_example": "Compare frontier-model-only work with a routed repository change that reuses context, specialists, tests, and independent checks.", "strongest_objection": "The accounting and verification required by a stack may cost more than using the strongest model throughout.", "failure_story": "A cheap route looks efficient only because repair, reviewer burden, false refusal, and residual effects were excluded.", "evidence_that_would_change_the_conclusion": "Matched workloads with full lifecycle accounting and no risk-adjusted cost or quality advantage would reject or narrow the hypothesis.", "handoff": "Efficiency is meaningful only after the next unit defines authority ceilings and ordinary failure boundaries.", "unit_id": "unit-02-efficient-asi", "unit_label": "Efficient-ASI hypothesis", "reference_owner_count": 0, "reference_owners": [], "contribution_id": "record-reality-residual-honesty" }, { "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", "plain_language_thesis": "A system remains governable only when proposing, approving, executing, observing, and releasing are different acts with different authority and ownership.", "normative_engineering_rule": "Bind every material effect to a current scoped grant, an exact dispatch record, independent-enough observation, and a recovery or residual route.", "machine_contract": "Permit an effect only when caller identity, live grant, authority ceiling, target, epoch, receipt, observer, and rollback or compensation state validate; a plan or credential handle does not create effect authority.", "reader_question": "Which boundaries separate proposal, approval, execution, observation, and release, and how do failures remain owned?", "running_example": "Let the planner draft a patch while a current scoped grant alone permits a bounded adapter to alter the tree.", "strongest_objection": "Typed boundaries can become ceremonial metadata when the runtime can ignore, forge, or bypass them.", "failure_story": "A low-authority planner borrows a broad stale credential and the resulting failure is assigned to no detector or owner.", "evidence_that_would_change_the_conclusion": "Simpler permission systems resisting revocation, confused-deputy, bypass, and residual-loss attacks equally well would justify a smaller boundary model.", "handoff": "The evidence unit now asks how records about those boundaries can change belief without inheriting support.", "unit_id": "unit-03-authority-and-failure", "unit_label": "Authority, security, and failure boundaries", "reference_owner_count": 9, "reference_owners": [ { "chapter_id": "failure-modes-of-ungoverned-intelligence", "title": "Failure Modes of Ungoverned Intelligence", "canonical_order": 4, "core_claim_ref": "failure-modes-of-ungoverned-intelligence.core", "distinct_responsibility": "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", "architecture_reference_path": "chapters/failure-modes-of-ungoverned-intelligence.html" }, { "chapter_id": "dangerous-capability-domains-and-misuse-uplift", "title": "Dangerous Capability Domains and Misuse Uplift", "canonical_order": 5, "core_claim_ref": "dangerous-capability-domains-and-misuse-uplift.core", "distinct_responsibility": "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", "architecture_reference_path": "chapters/dangerous-capability-domains-and-misuse-uplift.html" }, { "chapter_id": "military-ai-autonomous-weapons-and-strategic-stability", "title": "Military AI, Autonomous Weapons, and Strategic Stability", "canonical_order": 6, "core_claim_ref": "military-ai-autonomous-weapons-and-strategic-stability.core", "distinct_responsibility": "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", "architecture_reference_path": "chapters/military-ai-autonomous-weapons-and-strategic-stability.html" }, { "chapter_id": "security-kernel-and-digital-scifs", "title": "Security Kernel and Digital SCIFs", "canonical_order": 20, "core_claim_ref": "security-kernel-and-digital-scifs.core", "distinct_responsibility": "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", "architecture_reference_path": "chapters/security-kernel-and-digital-scifs.html" }, { "chapter_id": "adversarial-machine-learning-and-model-attack-surface", "title": "Adversarial Machine Learning and the Model Attack Surface", "canonical_order": 21, "core_claim_ref": "adversarial-machine-learning-and-model-attack-surface.core", "distinct_responsibility": "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", "architecture_reference_path": "chapters/adversarial-machine-learning-and-model-attack-surface.html" }, { "chapter_id": "privacy-data-rights-and-information-flow-governance", "title": "Privacy, Data Rights, and Information-Flow Governance", "canonical_order": 22, "core_claim_ref": "privacy-data-rights-and-information-flow-governance.core", "distinct_responsibility": "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", "architecture_reference_path": "chapters/privacy-data-rights-and-information-flow-governance.html" }, { "chapter_id": "confidential-and-verifiable-ai-computation", "title": "Confidential and Verifiable AI Computation", "canonical_order": 23, "core_claim_ref": "confidential-and-verifiable-ai-computation.core", "distinct_responsibility": "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", "architecture_reference_path": "chapters/confidential-and-verifiable-ai-computation.html" }, { "chapter_id": "model-weight-custody-and-hardware-roots-of-trust", "title": "Model-Weight Custody and Hardware Roots of Trust", "canonical_order": 24, "core_claim_ref": "model-weight-custody-and-hardware-roots-of-trust.core", "distinct_responsibility": "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", "architecture_reference_path": "chapters/model-weight-custody-and-hardware-roots-of-trust.html" }, { "chapter_id": "ai-supply-chain-integrity-and-lifecycle-provenance", "title": "AI Supply-Chain Integrity and Lifecycle Provenance", "canonical_order": 26, "core_claim_ref": "ai-supply-chain-integrity-and-lifecycle-provenance.core", "distinct_responsibility": "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", "architecture_reference_path": "chapters/ai-supply-chain-integrity-and-lifecycle-provenance.html" } ], "contribution_id": "governed-cognition-interface-contracts" }, { "order": 4, "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", "plain_language_thesis": "Evidence should strengthen only the claim it actually tests; nearby architecture claims, publication language, and runtime permissions must not inherit that support.", "normative_engineering_rule": "Move a claim between support states only through an accepted, identity-bound transition that names evidence, scope, defeaters, maximum inference, and downstream consumers.", "machine_contract": "Apply a support transition only when claim identity, prior state, evidence bundle, evaluator, scope, decision, defeaters, and nonclaims validate; a receipt, theorem, citation, or adjacent result does not promote another claim.", "reader_question": "How can claims change while capability, authority, context, receipts, proofs, and publication remain noninheriting states?", "running_example": "Let one repository test strengthen a narrow result without promoting the architecture claim or turning a receipt into reality.", "strongest_objection": "Support labels may create an aura of rigor while the underlying evidence remains narrow, stale, dependent, or weak.", "failure_story": "A schema receipt becomes a runtime-safety claim through repeated prose even though no independent effect was observed.", "evidence_that_would_change_the_conclusion": "Natural correction streams showing no improvement over a simpler review protocol would force a smaller claim-transition system.", "handoff": "Claim discipline next meets constitutions, values, objectives, and the problem of legitimate protected change.", "unit_id": "unit-04-evidence-and-noninheritance", "unit_label": "Evidence states, oversight, and noninheritance", "reference_owner_count": 1, "reference_owners": [ { "chapter_id": "scalable-oversight-and-adversarial-ai-control", "title": "Scalable Oversight and Adversarial AI Control", "canonical_order": 8, "core_claim_ref": "scalable-oversight-and-adversarial-ai-control.core", "distinct_responsibility": "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", "architecture_reference_path": "chapters/scalable-oversight-and-adversarial-ai-control.html" } ], "contribution_id": "claim-state-transition-discipline" }, { "order": 5, "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", "plain_language_thesis": "Powerful optimization needs a contestable constitutional process that exposes value conflict, protects agency, and prevents the optimizer from controlling its own rules or evidence.", "normative_engineering_rule": "Separate objective proposal, interpretation, protected constraints, affected-party standing, amendment authority, evaluation, appeal, and enforcement while preserving unresolved disagreement.", "machine_contract": "Accept an objective or constitutional change only with authorized provenance, conflict disclosure, protected-boundary checks, independent evaluation, appeal, and ratification; model preference or performance does not self-ratify the change.", "reader_question": "How should constitutions, conflicting values, learned objectives, human factors, and legitimate amendment interact?", "running_example": "A repository request conflicts with a protected policy and a user preference, forcing contestable interpretation rather than silent optimization.", "strongest_objection": "A formal constitution can freeze contested values, centralize power, and offer only the appearance of alignment.", "failure_story": "The system satisfies a literal rule while manipulating the user, hiding the conflict, and controlling the amendment evidence.", "evidence_that_would_change_the_conclusion": "Pluralistic governance mechanisms with fewer capture, rigidity, and burden failures would replace or sharply narrow the constitutional substrate.", "handoff": "The next unit turns protected capabilities into replaceable fields whose qualification cannot be inherited.", "unit_id": "unit-05-constitutional-objective-governance", "unit_label": "Constitutional, value, objective, and institutional governance", "reference_owner_count": 7, "reference_owners": [ { "chapter_id": "human-factors-and-meaningful-control-in-oversight", "title": "Human Factors and Meaningful Control in Oversight", "canonical_order": 10, "core_claim_ref": "human-factors-and-meaningful-control-in-oversight.core", "distinct_responsibility": "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", "architecture_reference_path": "chapters/human-factors-and-meaningful-control-in-oversight.html" }, { "chapter_id": "human-ai-communication-persuasion-and-epistemic-security", "title": "Human-AI Communication, Persuasion, and Epistemic Security", "canonical_order": 11, "core_claim_ref": "human-ai-communication-persuasion-and-epistemic-security.core", "distinct_responsibility": "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", "architecture_reference_path": "chapters/human-ai-communication-persuasion-and-epistemic-security.html" }, { "chapter_id": "inner-alignment-mesa-optimization-and-learned-objective-integrity", "title": "Inner Alignment, Mesa-Optimization, and Learned-Objective Integrity", "canonical_order": 13, "core_claim_ref": "inner-alignment-mesa-optimization-and-learned-objective-integrity.core", "distinct_responsibility": "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", "architecture_reference_path": "chapters/inner-alignment-mesa-optimization-and-learned-objective-integrity.html" }, { "chapter_id": "moral-uncertainty-and-value-conflict", "title": "Moral Uncertainty, Value Conflict, and Contestable Governance", "canonical_order": 14, "core_claim_ref": "moral-uncertainty-and-value-conflict.core", "distinct_responsibility": "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", "architecture_reference_path": "chapters/moral-uncertainty-and-value-conflict.html" }, { "chapter_id": "governed-objective-formation-value-learning-and-goal-integrity", "title": "Governed Objective Formation, Value Learning, and Goal Integrity", "canonical_order": 15, "core_claim_ref": "governed-objective-formation-value-learning-and-goal-integrity.core", "distinct_responsibility": "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", "architecture_reference_path": "chapters/governed-objective-formation-value-learning-and-goal-integrity.html" }, { "chapter_id": "institutions-international-coordination-and-public-legitimacy", "title": "Institutions, International Coordination, and Public Legitimacy", "canonical_order": 16, "core_claim_ref": "institutions-international-coordination-and-public-legitimacy.core", "distinct_responsibility": "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", "architecture_reference_path": "chapters/institutions-international-coordination-and-public-legitimacy.html" }, { "chapter_id": "societal-resilience-and-misuse-defense", "title": "Societal Resilience and Misuse Defense", "canonical_order": 17, "core_claim_ref": "societal-resilience-and-misuse-defense.core", "distinct_responsibility": "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", "architecture_reference_path": "chapters/societal-resilience-and-misuse-defense.html" } ], "contribution_id": "governed-cognition-interface-contracts" }, { "order": 6, "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", "plain_language_thesis": "A capability can remain understandable while its machinery changes if the contract stays stable and every replacement must earn qualification for itself.", "normative_engineering_rule": "Version capability identity separately from implementation identity and require matched qualification, regression, migration, rollback, and retirement records for every replacement.", "machine_contract": "Promote a replacement only when its artifact identity, contract version, qualification envelope, regressions, authority ceiling, migration, rollback, and residuals validate; predecessor readiness does not transfer automatically.", "reader_question": "How can a capability retain a stable contract while its model, memory, router, tool, or substrate changes?", "running_example": "Replace the patch verifier while preserving the exact capability contract, regression envelope, authority ceiling, and recovery route.", "strongest_objection": "A stable field may hide semantic drift and make incomparable components look interchangeable.", "failure_story": "A faster replacement inherits its predecessor's name and readiness but silently drops the attack that justified the field.", "evidence_that_would_change_the_conclusion": "Natural replacement studies showing no continuity or recovery benefit over conventional versioning would weaken the field abstraction.", "handoff": "Stable capabilities become useful when a human request is compiled into an exact command without inventing authority.", "unit_id": "unit-06-capability-fields-and-replacement", "unit_label": "Stable Capability Fields and replacement", "reference_owner_count": 1, "reference_owners": [ { "chapter_id": "capability-replacement-and-rollback", "title": "Capability Replacement and Rollback", "canonical_order": 19, "core_claim_ref": "capability-replacement-and-rollback.core", "distinct_responsibility": "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", "architecture_reference_path": "chapters/capability-replacement-and-rollback.html" } ], "contribution_id": "governed-cognition-interface-contracts" }, { "order": 7, "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", "plain_language_thesis": "Human intent becomes safer executable work when ambiguity, scope, success, authority, evidence duties, and stop conditions are made explicit before action.", "normative_engineering_rule": "Compile requests into revisable command contracts that preserve uncertainty and require clarification, narrowing, escalation, or refusal when consequential fields are unresolved.", "machine_contract": "Dispatch work only when principal, purpose, targets, allowed operations, success criteria, evidence duties, authority, risks, stop rules, and expiry are bound; inferred intent does not invent permission.", "reader_question": "How does an ambiguous human request become bounded work without inventing authority, success criteria, or certainty?", "running_example": "Translate a repository chapter-improvement request into target files, allowed operations, evidence duties, stop rules, and approval conditions.", "strongest_objection": "A precise command contract can harden a mistaken interpretation and make ambiguity harder to notice.", "failure_story": "The system completes the literal patch while violating the user's actual constraint because uncertainty became an unstated default.", "evidence_that_would_change_the_conclusion": "User studies showing lighter clarification produces fewer intent failures at lower burden would justify a smaller contract.", "handoff": "The planning unit turns the accepted command into dependencies and alternatives without turning the plan into permission.", "unit_id": "unit-07-intent-and-command", "unit_label": "Intent and command contracts", "reference_owner_count": 1, "reference_owners": [ { "chapter_id": "human-intent-as-a-formal-input", "title": "Human Intent as a Formal Input", "canonical_order": 9, "core_claim_ref": "human-intent-as-a-formal-input.core", "distinct_responsibility": "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", "architecture_reference_path": "chapters/human-intent-as-a-formal-input.html" } ], "contribution_id": "governed-cognition-interface-contracts" }, { "order": 8, "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", "plain_language_thesis": "Plans should coordinate dependencies and alternatives without becoming stale scripts or silently granting permission to act.", "normative_engineering_rule": "Represent plans as versioned proposals with assumptions, dependencies, branch conditions, verification points, replanning triggers, cost, and explicit execution handoffs.", "machine_contract": "Advance a plan node only when dependencies, context epoch, assumptions, budget, verification state, and a separate live execution grant hold; plan reachability does not authorize an external effect.", "reader_question": "How can a plan coordinate dependencies and replanning while remaining a proposal rather than implicit execution authority?", "running_example": "Represent the repository change as source inspection, drafting, verification, tests, rollback preparation, and release or refusal.", "strongest_objection": "Detailed plans are expensive and brittle when the environment changes faster than the plan can be checked.", "failure_story": "A stale plan executes after its context, dependency, and authorization assumptions have changed.", "evidence_that_would_change_the_conclusion": "Dynamic-task studies showing direct reactive control is safer and more efficient would narrow when explicit planning should activate.", "handoff": "Planning requires a world model that keeps predictions, branches, interventions, and actual observations separate.", "unit_id": "unit-08-planning", "unit_label": "Planning as a control layer", "reference_owner_count": 0, "reference_owners": [], "contribution_id": "governed-cognition-interface-contracts" }, { "order": 9, "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", "plain_language_thesis": "Predictions and simulations become useful when the system keeps them separate from observations and learns from the mismatch through controlled interventions.", "normative_engineering_rule": "Track possible worlds, causal assumptions, interventions, sensor provenance, uncertainty, actual observations, reconciliation, and downstream belief effects as distinct artifacts.", "machine_contract": "Update a world-state belief only from an identity-bound observation and accepted reconciliation against a declared prediction or intervention; neither simulated success nor a sensor receipt establishes actual state and either alone does not justify the update.", "reader_question": "How should a system predict, simulate, intervene, and reconcile without confusing possible worlds with actual state?", "running_example": "Predict the patch's effects in a branch, run a bounded intervention, and reconcile the prediction with the observed tree.", "strongest_objection": "World-model governance may add records without improving prediction, causal identification, or grounding.", "failure_story": "A simulated passing state overwrites actual repository state and later planning treats the branch as observed fact.", "evidence_that_would_change_the_conclusion": "Strong predictive and causal baselines with simpler branch discipline and equal calibration would justify collapsing the extra machinery.", "handoff": "The compilation unit converts qualified meaning into executable representations while preserving declared semantic loss.", "unit_id": "unit-09-world-models", "unit_label": "Perception, governed world models, and embodied reconciliation", "reference_owner_count": 2, "reference_owners": [ { "chapter_id": "perception-sensor-fusion-and-observation-trust", "title": "Perception, Sensor Fusion, and Observation Trust", "canonical_order": 31, "core_claim_ref": "perception-sensor-fusion-and-observation-trust.core", "distinct_responsibility": "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", "architecture_reference_path": "chapters/perception-sensor-fusion-and-observation-trust.html" }, { "chapter_id": "embodied-agency-real-time-control-and-physical-safety", "title": "Embodied Agency, Real-Time Control, and Physical Safety", "canonical_order": 48, "core_claim_ref": "embodied-agency-real-time-control-and-physical-safety.core", "distinct_responsibility": "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", "architecture_reference_path": "chapters/embodied-agency-real-time-control-and-physical-safety.html" } ], "contribution_id": "record-reality-residual-honesty" }, { "order": 10, "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", "plain_language_thesis": "Intent and knowledge can be lowered into efficient executable forms only if semantic loss, relational structure, assumptions, and rescue paths remain visible.", "normative_engineering_rule": "Compile through typed intermediate representations that bind source meaning to target operations, record losses and approximations, and retain fallback to a higher-fidelity form.", "machine_contract": "Accept a compiled artifact only when source identity, target identity, preserved obligations, declared losses, validation, fallback, and consumer scope hold; structural conformance does not establish semantic equivalence.", "reader_question": "How can intent, beliefs, relations, and constraints be lowered into executable forms without silently changing meaning?", "running_example": "Lower the repository-change contract into planner predicates, verifier queries, tool calls, and recovery obligations with traceable losses.", "strongest_objection": "Semantic intermediate representations may be brittle private languages that lose nuance while pretending to preserve it.", "failure_story": "A compiler preserves field names but drops the constraint that the verifier must be independent of the proposer.", "evidence_that_would_change_the_conclusion": "End-to-end systems preserving intent and observability better without an explicit semantic IR would narrow the compiler boundary.", "handoff": "The context unit packages the exact sources, branches, taint, tools, and omissions consumed by compiled work.", "unit_id": "unit-10-cognitive-compilation", "unit_label": "Cognitive compilation, relational cognition, and search", "reference_owner_count": 2, "reference_owners": [ { "chapter_id": "relational-dimension-compilation-and-polyadic-cognition", "title": "Relational Dimension Compilation and Polyadic Cognition", "canonical_order": 54, "core_claim_ref": "relational-dimension-compilation-and-polyadic-cognition.core", "distinct_responsibility": "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", "architecture_reference_path": "chapters/relational-dimension-compilation-and-polyadic-cognition.html" }, { "chapter_id": "mathematical-and-search-substrates", "title": "Mathematical and Search Substrates", "canonical_order": 66, "core_claim_ref": "mathematical-and-search-substrates.core", "distinct_responsibility": "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", "architecture_reference_path": "chapters/mathematical-and-search-substrates.html" } ], "contribution_id": "governed-cognition-interface-contracts" }, { "order": 11, "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", "plain_language_thesis": "Large context becomes manageable when retrieved, cached, paged, mounted, and summarized material carries identity, provenance, freshness, taint, rights, and omissions.", "normative_engineering_rule": "Expose context through a typed ABI that separates storage from belief and authority while supporting snapshots, transactions, revocation, deletion, and adequacy checks.", "machine_contract": "Mount a context object only when source, version, purpose, rights, freshness, taint, omissions, derivation, consumer, and revocation state validate; presence in context does not make content true or authorized.", "reader_question": "What interface lets models consume paged, cached, mounted, and tainted context without treating it as belief or authority?", "running_example": "Mount repository source files, policy history, summaries, and cached work as versioned context pages with explicit omissions and rights.", "strongest_objection": "A typed context ABI may add latency and false precision while retrieval errors still determine the answer.", "failure_story": "A stale cached summary is mounted under a current name and silently authorizes removal of a deliberate safety check.", "evidence_that_would_change_the_conclusion": "Simpler retrieval and caching systems matching adequacy, provenance, revocation, and cost would justify a thinner ABI.", "handoff": "The memory unit decides what may persist as revisable belief or reusable procedure after the task.", "unit_id": "unit-11-context-abi", "unit_label": "Virtual Context ABI and context transactions", "reference_owner_count": 1, "reference_owners": [ { "chapter_id": "context-transactions-snapshots-mounts-and-taint", "title": "Context Transactions, Snapshots, Mounts, and Taint", "canonical_order": 37, "core_claim_ref": "context-transactions-snapshots-mounts-and-taint.core", "distinct_responsibility": "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", "architecture_reference_path": "chapters/context-transactions-snapshots-mounts-and-taint.html" } ], "contribution_id": "governed-cognition-interface-contracts" }, { "order": 12, "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", "plain_language_thesis": "Experience should become durable belief or reusable skill only through revisable consolidation that preserves provenance, uncertainty, regressions, and retirement.", "normative_engineering_rule": "Separate episodic observations, semantic beliefs, and procedural skills; qualify every promotion with contradiction checks, expiry, descendants, forgetting, and rollback or compensation.", "machine_contract": "Consolidate memory only when source episodes, belief or skill identity, evidence, confidence, conflicts, consumers, expiry, regression tests, and deletion lineage validate; repeated success does not make a trace universally correct.", "reader_question": "How do qualified observations become durable beliefs and successful traces become revisable procedures rather than frozen mistakes?", "running_example": "Store the patch rationale as a defeasible belief and compile the validated workflow into a skill with regressions and retirement.", "strongest_objection": "Structured memory and procedural consolidation can amplify early errors and create opaque path dependence.", "failure_story": "One successful trace becomes a default skill, then survives after its policy, dependency, and safety assumptions expire.", "evidence_that_would_change_the_conclusion": "Continual-learning baselines with less structure and equal revision, forgetting, transfer, and recovery would narrow the design.", "handoff": "The verification unit asks whether the available context and reviewer capacity can actually test the resulting claims.", "unit_id": "unit-12-memory-and-consolidation", "unit_label": "Durable memory and procedural consolidation", "reference_owner_count": 1, "reference_owners": [ { "chapter_id": "procedural-memory-and-cognitive-loop-closure", "title": "Procedural Memory and Cognitive Loop Closure", "canonical_order": 51, "core_claim_ref": "procedural-memory-and-cognitive-loop-closure.core", "distinct_responsibility": "Cognitive loop closure compiles repeated reasoning into verified parameterized tools and procedural memory.", "claim_label": "Design rationale", "support_state": "argument", "architecture_reference_path": "chapters/procedural-memory-and-cognitive-loop-closure.html" } ], "contribution_id": "governed-cognition-interface-contracts" }, { "order": 13, "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", "plain_language_thesis": "Verification fails when a reviewer lacks the information, independence, tools, time, or comparison capacity needed to detect the important contradiction.", "normative_engineering_rule": "Allocate verification according to claim risk and record source coverage, omissions, independence, sensitivity, disagreement, escalation, latency, and reviewer burden.", "machine_contract": "Accept a verification result only when the frozen claim, context-adequacy floor, evaluator independence, tools, sensitivity controls, budget, and disagreement route hold; reviewer confidence does not establish adequate verification.", "reader_question": "When does relevant context still fail to provide enough independent comparison capacity for a risky judgment?", "running_example": "The verifier sees the patch and tests but lacks the policy history explaining why a removed check exists.", "strongest_objection": "Adequacy labels may become subjective gates that add delay without predicting contradictions.", "failure_story": "A concise summary preserves topic coverage but drops the one constraint that should block deployment.", "evidence_that_would_change_the_conclusion": "Benchmarks showing no relation between declared adequacy, review allocation, and contradiction detection would require replacement.", "handoff": "The claim-review unit converts verification results into revisable beliefs and proof-carrying decisions.", "unit_id": "unit-13-verification-bandwidth", "unit_label": "Verification bandwidth and context adequacy", "reference_owner_count": 0, "reference_owners": [], "contribution_id": "claim-state-transition-discipline" }, { "order": 14, "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", "plain_language_thesis": "Claims stay corrigible when evidence, proofs, observations, objections, revisions, consumers, and maximum inference remain connected over time.", "normative_engineering_rule": "Maintain identity-bound claim ledgers that preserve defeaters and disagreements, distinguish proof from runtime observation, and propagate corrections or downgrades to every known consumer.", "machine_contract": "Accept a claim state only when identity, proposition, assumptions, evidence, evaluator, proof scope, observations, defeaters, decision, consumers, and downgrade triggers agree; formal validity does not establish runtime truth.", "reader_question": "How should claims, defeaters, proof receipts, observations, disagreements, and revisions remain connected over time?", "running_example": "Bind the patch claim to sources, tests, verifier objections, effect observations, maximum inference, and downgrade triggers.", "strongest_objection": "A rich ledger can preserve immaculate metadata around a wrong conclusion and overwhelm meaningful review.", "failure_story": "A theorem receipt and two correlated reviews create confidence while the actual effect contradicts the recorded claim.", "evidence_that_would_change_the_conclusion": "Simpler evidence records producing equal correction, calibration, and challenge performance would justify consolidation.", "handoff": "The work unit turns an accepted claim and plan into owned jobs, artifacts, acknowledgements, and replayable history.", "unit_id": "unit-14-claim-and-proof-review", "unit_label": "Claim ledgers, proof-carrying review, and formal scope", "reference_owner_count": 4, "reference_owners": [ { "chapter_id": "spinoza-verification-and-proof-carrying-claims", "title": "Proof-Carrying Claims and Adversarial Review", "canonical_order": 40, "core_claim_ref": "spinoza-verification-and-proof-carrying-claims.core", "distinct_responsibility": "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", "architecture_reference_path": "chapters/spinoza-verification-and-proof-carrying-claims.html" }, { "chapter_id": "circle-calculus-and-proof-carrying-ai-contracts", "title": "Circle Calculus and Proof-Carrying AI Contracts", "canonical_order": 67, "core_claim_ref": "circle-calculus-and-proof-carrying-ai-contracts.core", "distinct_responsibility": "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", "architecture_reference_path": "chapters/circle-calculus-and-proof-carrying-ai-contracts.html" }, { "chapter_id": "executable-specifications-and-lean-proof-envelope", "title": "Executable Specifications and Lean Proof Envelope", "canonical_order": 70, "core_claim_ref": "executable-specifications-and-lean-proof-envelope.core", "distinct_responsibility": "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", "architecture_reference_path": "chapters/executable-specifications-and-lean-proof-envelope.html" }, { "chapter_id": "white-box-evidence-interpretability-and-activation-governance", "title": "White-Box Evidence, Interpretability, and Activation Governance", "canonical_order": 72, "core_claim_ref": "white-box-evidence-interpretability-and-activation-governance.core", "distinct_responsibility": "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", "architecture_reference_path": "chapters/white-box-evidence-interpretability-and-activation-governance.html" } ], "contribution_id": "claim-state-transition-discipline" }, { "order": 15, "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", "plain_language_thesis": "Humans, agents, and tools can collaborate reliably when work, artifacts, authority, acknowledgements, dependencies, and accountability remain explicit.", "normative_engineering_rule": "Issue typed jobs with exact owners, inputs, outputs, authority, evidence obligations, dependencies, handoffs, failure states, cost, and terminal acknowledgement.", "machine_contract": "Close a job only when its identity, assignee, authority, inputs, artifact outputs, checks, effects, handoffs, residuals, and accountable owner reconcile; a worker success report does not establish task completion.", "reader_question": "How should humans, agents, tools, and artifact stewards coordinate work without losing ownership, lineage, or accountability?", "running_example": "Issue typed jobs for drafting, checking, applying, observing, and recovering the repository change and join every artifact.", "strongest_objection": "A labor operating system may bureaucratize small tasks and shift responsibility into unread records.", "failure_story": "Each worker reports success, but the test belongs to another commit and no owner acknowledges the final effect.", "evidence_that_would_change_the_conclusion": "Conventional issue, CI, and audit workflows matching continuity and recovery at lower burden would narrow the layer.", "handoff": "The runtime unit defines the narrow boundary where owned work becomes an external effect and ongoing operation.", "unit_id": "unit-15-labor-and-artifacts", "unit_label": "Labor OS, organizations, artifact graphs, and stewardship", "reference_owner_count": 8, "reference_owners": [ { "chapter_id": "ai-work-surfaces-agent-harnesses-and-organizational-absorption", "title": "From Chat to Organizations: AI Work Surfaces and Agent Harnesses", "canonical_order": 42, "core_claim_ref": "ai-work-surfaces-agent-harnesses-and-organizational-absorption.core", "distinct_responsibility": "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", "architecture_reference_path": "chapters/ai-work-surfaces-agent-harnesses-and-organizational-absorption.html" }, { "chapter_id": "human-ai-organizations-delegation-and-accountability", "title": "Human-AI Organizations, Delegation, and Accountability", "canonical_order": 43, "core_claim_ref": "human-ai-organizations-delegation-and-accountability.core", "distinct_responsibility": "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", "architecture_reference_path": "chapters/human-ai-organizations-delegation-and-accountability.html" }, { "chapter_id": "human-ai-symbiosis-neurotechnology-and-cognitive-sovereignty", "title": "Human-AI Symbiosis, Neurotechnology, and Cognitive Sovereignty", "canonical_order": 44, "core_claim_ref": "human-ai-symbiosis-neurotechnology-and-cognitive-sovereignty.core", "distinct_responsibility": "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", "architecture_reference_path": "chapters/human-ai-symbiosis-neurotechnology-and-cognitive-sovereignty.html" }, { "chapter_id": "ai-deployment-transition-distribution-and-human-agency", "title": "AI Deployment, Transition, Distribution, and Human Agency", "canonical_order": 45, "core_claim_ref": "ai-deployment-transition-distribution-and-human-agency.core", "distinct_responsibility": "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", "architecture_reference_path": "chapters/ai-deployment-transition-distribution-and-human-agency.html" }, { "chapter_id": "artifact-graphs-audit-logs-and-replay", "title": "Artifact Graphs, Audit Logs, and Replay", "canonical_order": 46, "core_claim_ref": "artifact-graphs-audit-logs-and-replay.core", "distinct_responsibility": "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", "architecture_reference_path": "chapters/artifact-graphs-audit-logs-and-replay.html" }, { "chapter_id": "inter-stack-protocols-identity-and-economic-exchange", "title": "Inter-Stack Protocols, Identity, and Economic Exchange", "canonical_order": 49, "core_claim_ref": "inter-stack-protocols-identity-and-economic-exchange.core", "distinct_responsibility": "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", "architecture_reference_path": "chapters/inter-stack-protocols-identity-and-economic-exchange.html" }, { "chapter_id": "multi-agent-dynamics-collective-intelligence-and-systemic-risk", "title": "Multi-Agent Dynamics, Collective Intelligence, and Systemic Risk", "canonical_order": 50, "core_claim_ref": "multi-agent-dynamics-collective-intelligence-and-systemic-risk.core", "distinct_responsibility": "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", "architecture_reference_path": "chapters/multi-agent-dynamics-collective-intelligence-and-systemic-risk.html" }, { "chapter_id": "artifact-steward-agents-and-living-project-governance", "title": "Artifact Steward Agents and Living Project Governance", "canonical_order": 82, "core_claim_ref": "artifact-steward-agents-and-living-project-governance.core", "distinct_responsibility": "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", "architecture_reference_path": "chapters/artifact-steward-agents-and-living-project-governance.html" } ], "contribution_id": "governed-cognition-interface-contracts" }, { "order": 16, "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", "plain_language_thesis": "The crucial runtime boundary is where approved proposals become observable external effects and remain recoverable under failure or changing authority.", "normative_engineering_rule": "Mediate tools through least-privilege adapters that bind approval to exact effect scope, observe actual state, revoke promptly, degrade safely, and preserve incident and recovery records.", "machine_contract": "Execute a tool call only with live scoped approval, adapter policy, pre-state, expected effect, observer, timeout, revocation, and rollback or compensation route; tool success does not establish intended task success.", "reader_question": "Which boundary should turn proposals into observed effects while preserving approval, incident, recovery, and graceful-degradation paths?", "running_example": "Apply the verified patch under a live grant, observe pre and post state, and retain exact rollback or compensation.", "strongest_objection": "Approval and adapter layers invite rubber-stamping while sophisticated tools find effects outside the declared boundary.", "failure_story": "A narrow file-edit approval is reused for deployment and tool success is reported as task success.", "evidence_that_would_change_the_conclusion": "Simpler least-privilege wrappers matching effect observation, revocation, recovery, and incident handling would narrow the contract.", "handoff": "The substrate unit decides which cognitive architecture or specialist should serve each role behind these stable boundaries.", "unit_id": "unit-16-runtime-and-operations", "unit_label": "Runtime adapters, observation, incident command, and operations", "reference_owner_count": 1, "reference_owners": [ { "chapter_id": "governed-operations-incident-command-and-graceful-degradation", "title": "Governed Operations, Incident Command, and Graceful Degradation", "canonical_order": 77, "core_claim_ref": "governed-operations-incident-command-and-graceful-degradation.core", "distinct_responsibility": "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", "architecture_reference_path": "chapters/governed-operations-incident-command-and-graceful-degradation.html" } ], "contribution_id": "governed-cognition-interface-contracts" }, { "order": 17, "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", "plain_language_thesis": "Transformers should be one replaceable substrate among many, selected according to the work rather than treated as the permanent shape of intelligence.", "normative_engineering_rule": "Qualify heterogeneous models, recurrence, state-space systems, symbolic methods, search, tools, and future substrates behind stable capability contracts using matched task and lifecycle comparisons.", "machine_contract": "Route to a substrate only when capability contract, task fit, qualification envelope, authority, resource budget, fallback, regression, and migration state hold; novelty or benchmark speed does not inherit readiness.", "reader_question": "How can routers choose among transformers, state-space models, recurrence, symbolic methods, tools, and future substrates?", "running_example": "Route patch generation, retrieval, verification, and rollback checks to different qualified substrates behind stable capability fields.", "strongest_objection": "Heterogeneous routing may add complexity and correlated failure without outperforming one well-tuned general model.", "failure_story": "A novel fast substrate wins a proxy benchmark, inherits qualification, and fails the rare dependency case it never saw.", "evidence_that_would_change_the_conclusion": "Matched natural tasks showing no useful frontier gain after routing, migration, verification, and maintenance cost would favor monoculture.", "handoff": "The developmental-learning unit explains how those substrates acquire, consolidate, compose, and qualify new competence.", "unit_id": "unit-17-routing-and-substrates", "unit_label": "Routing and replaceable cognitive substrates", "reference_owner_count": 3, "reference_owners": [ { "chapter_id": "routing-heads-and-specialist-cores", "title": "Routing Heads and Specialist Cores", "canonical_order": 52, "core_claim_ref": "routing-heads-and-specialist-cores.core", "distinct_responsibility": "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", "architecture_reference_path": "chapters/routing-heads-and-specialist-cores.html" }, { "chapter_id": "coil-attention-cyclic-memory-and-recurrence-contracts", "title": "Coil Attention, Cyclic Memory, and Recurrence Contracts", "canonical_order": 68, "core_claim_ref": "coil-attention-cyclic-memory-and-recurrence-contracts.core", "distinct_responsibility": "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", "architecture_reference_path": "chapters/coil-attention-cyclic-memory-and-recurrence-contracts.html" }, { "chapter_id": "coilra-multicoil-rope-and-cyclic-mixers", "title": "CoilRA, MultiCoil RoPE, and Cyclic Mixers", "canonical_order": 69, "core_claim_ref": "coilra-multicoil-rope-and-cyclic-mixers.core", "distinct_responsibility": "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", "architecture_reference_path": "chapters/coilra-multicoil-rope-and-cyclic-mixers.html" } ], "contribution_id": "governed-cognition-interface-contracts" }, { "order": 18, "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", "plain_language_thesis": "Intelligence develops through a lifecycle of interaction, prediction error, abstraction, memory, practice, stabilization, and qualification—not merely by shuffling weights.", "normative_engineering_rule": "Join curriculum, training state, interventions, consolidation, proceduralization, forgetting, regression, stability, cost, and independent qualification without collapsing their owners.", "machine_contract": "Promote a learned capability only when full run identity and state, causal or intervention evidence, memory and skill lineage, regressions, stability epoch, cost, and unopened qualification hold; checkpoint load or score does not establish development.", "reader_question": "How does the stack develop capability through training, interaction, intervention, memory, procedure, stabilization, and promotion?", "running_example": "Follow one repository-task candidate from frozen curriculum and full training state through learning, consolidation, regression, and qualification handoff.", "strongest_objection": "The developmental loop may be governance paperwork around standard training with no causal effect on learning quality.", "failure_story": "A checkpoint loads and scores well, but hidden state, data order, forgetting, and evaluator leakage make the claimed development irreproducible.", "evidence_that_would_change_the_conclusion": "Strong standard training pipelines matching transfer, recovery, causal learning, and lifecycle cost would justify simplifying the loop.", "handoff": "The readiness unit decides when a candidate may advance while keeping benchmarks, safety cases, deception, and liveness visible.", "unit_id": "unit-18-developmental-learning", "unit_label": "Governed training and developmental learning", "reference_owner_count": 6, "reference_owners": [ { "chapter_id": "learning-compute-topology-and-adaptive-process-architecture", "title": "Learning–Compute Topology and Adaptive Process Architecture", "canonical_order": 56, "core_claim_ref": "learning-compute-topology-and-adaptive-process-architecture.core", "distinct_responsibility": "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", "architecture_reference_path": "chapters/learning-compute-topology-and-adaptive-process-architecture.html" }, { "chapter_id": "learning-theory-generalization-and-scaling-science", "title": "Learning Theory, Generalization, and Scaling Science", "canonical_order": 57, "core_claim_ref": "learning-theory-generalization-and-scaling-science.core", "distinct_responsibility": "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", "architecture_reference_path": "chapters/learning-theory-generalization-and-scaling-science.html" }, { "chapter_id": "adjudicated-persistence-and-the-adaptive-commit-boundary", "title": "Adjudicated Persistence and the Adaptive Commit Boundary", "canonical_order": 78, "core_claim_ref": "adjudicated-persistence-and-the-adaptive-commit-boundary.core", "distinct_responsibility": "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", "architecture_reference_path": "chapters/adjudicated-persistence-and-the-adaptive-commit-boundary.html" }, { "chapter_id": "policy-optimization-and-learning-from-feedback", "title": "Policy Optimization and Learning from Feedback", "canonical_order": 79, "core_claim_ref": "policy-optimization-and-learning-from-feedback.core", "distinct_responsibility": "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", "architecture_reference_path": "chapters/policy-optimization-and-learning-from-feedback.html" }, { "chapter_id": "data-engines-continual-learning-and-unlearning", "title": "Data Engines, Continual Learning, and Unlearning", "canonical_order": 80, "core_claim_ref": "data-engines-continual-learning-and-unlearning.core", "distinct_responsibility": "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", "architecture_reference_path": "chapters/data-engines-continual-learning-and-unlearning.html" }, { "chapter_id": "scientific-discovery-and-experimental-governance", "title": "Scientific Discovery and Experimental Governance", "canonical_order": 81, "core_claim_ref": "scientific-discovery-and-experimental-governance.core", "distinct_responsibility": "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", "architecture_reference_path": "chapters/scientific-discovery-and-experimental-governance.html" } ], "contribution_id": "governed-cognition-interface-contracts" }, { "order": 19, "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", "plain_language_thesis": "Readiness means useful work can proceed within declared risk while failures, uncertainty, residuals, and quarantine all reach finite owned outcomes.", "normative_engineering_rule": "Join competence, adversarial evaluation, safety cases, deployment commitments, release boundaries, residual escrow, and bounded liveness with usefulness and governance cost.", "machine_contract": "Advance readiness only when competence, attacks, evaluator sensitivity, residual owners, threshold commitments, rollback, liveness, false-blocking, and cost gates pass; benchmark success does not authorize deployment or release.", "reader_question": "How should benchmarks, safety cases, adversarial evaluation, residuals, and bounded liveness determine readiness?", "running_example": "Qualify the changed repository verifier against positive controls, attacks, transfer, recovery, false blocks, and a finite quarantine route.", "strongest_objection": "Readiness gates can optimize benchmarks, hide residuals, and become safe only by preventing useful work.", "failure_story": "The candidate passes a contaminated suite and remains quarantined indefinitely whenever a natural task exposes uncertainty.", "evidence_that_would_change_the_conclusion": "Simpler release practices matching defect escape, throughput, recovery, and governance cost would weaken the readiness system.", "handoff": "The economics unit prices useful cognition, infrastructure, verification, rollback, residuals, and governance on one ledger.", "unit_id": "unit-19-readiness-and-liveness", "unit_label": "Readiness, benchmarks, safety cases, and bounded liveness", "reference_owner_count": 6, "reference_owners": [ { "chapter_id": "open-weight-release-and-post-release-control", "title": "Open-Weight Release and Post-Release Control", "canonical_order": 25, "core_claim_ref": "open-weight-release-and-post-release-control.core", "distinct_responsibility": "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", "architecture_reference_path": "chapters/open-weight-release-and-post-release-control.html" }, { "chapter_id": "benchmark-ratchets-and-anti-goodhart-evidence", "title": "Benchmark Ratchets and Anti-Goodhart Evidence", "canonical_order": 71, "core_claim_ref": "benchmark-ratchets-and-anti-goodhart-evidence.core", "distinct_responsibility": "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", "architecture_reference_path": "chapters/benchmark-ratchets-and-anti-goodhart-evidence.html" }, { "chapter_id": "capability-thresholds-and-deployment-commitments", "title": "Capability Thresholds and Deployment Commitments", "canonical_order": 73, "core_claim_ref": "capability-thresholds-and-deployment-commitments.core", "distinct_responsibility": "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", "architecture_reference_path": "chapters/capability-thresholds-and-deployment-commitments.html" }, { "chapter_id": "adversarial-evaluation-sandbagging-and-training-time-deception", "title": "Adversarial Evaluation, Sandbagging, and Training-Time Deception", "canonical_order": 74, "core_claim_ref": "adversarial-evaluation-sandbagging-and-training-time-deception.core", "distinct_responsibility": "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", "architecture_reference_path": "chapters/adversarial-evaluation-sandbagging-and-training-time-deception.html" }, { "chapter_id": "safety-cases-and-structured-assurance", "title": "Safety Cases and Structured Assurance", "canonical_order": 75, "core_claim_ref": "safety-cases-and-structured-assurance.core", "distinct_responsibility": "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", "architecture_reference_path": "chapters/safety-cases-and-structured-assurance.html" }, { "chapter_id": "content-authenticity-watermarking-and-synthetic-media-integrity", "title": "Content Authenticity, Watermarking, and Synthetic Media Integrity", "canonical_order": 76, "core_claim_ref": "content-authenticity-watermarking-and-synthetic-media-integrity.core", "distinct_responsibility": "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", "architecture_reference_path": "chapters/content-authenticity-watermarking-and-synthetic-media-integrity.html" } ], "contribution_id": "governed-cognition-interface-contracts" }, { "order": 20, "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", "plain_language_thesis": "Efficient intelligence must account for compute, memory, storage, energy, latency, human attention, verification, failure, and recovery on the same ledger.", "normative_engineering_rule": "Allocate resources by risk-adjusted useful throughput while protecting required review and safety work and exposing displaced costs, cache effects, paging, fallback, and residual burden.", "machine_contract": "Select or defer work only from routes whose quality floor, protected overhead, resource envelope, verifier cost, recovery, and residual accounting validate; lower tokens, latency, or cache price does not establish lower lifecycle cost.", "reader_question": "When do routing and governance earn their compute, memory, storage, energy, latency, human, and recovery costs?", "running_example": "Compare repository-change routes on success, unsafe effects, false blocks, latency, reviewer effort, rollback, and lifecycle cost.", "strongest_objection": "Accounting can be gamed by excluding human burden, rare losses, transfer risk, and maintenance of governance itself.", "failure_story": "Token cost falls while review queues, stale caches, inexact rollback, and operator bypass move costs downstream.", "evidence_that_would_change_the_conclusion": "Representative workloads where governance costs exceed avoided losses across risk tiers would require material simplification.", "handoff": "The integration unit joins recursive improvement, transitions, trust, development, recovery, and the Theseus prototype program.", "unit_id": "unit-20-resource-and-recovery-economics", "unit_label": "Resource economics, efficient inference, and effect-complete recovery", "reference_owner_count": 6, "reference_owners": [ { "chapter_id": "personal-compute-hives-and-federated-edge-intelligence", "title": "Personal Compute Hives and Federated Edge Intelligence", "canonical_order": 59, "core_claim_ref": "personal-compute-hives-and-federated-edge-intelligence.core", "distinct_responsibility": "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", "architecture_reference_path": "chapters/personal-compute-hives-and-federated-edge-intelligence.html" }, { "chapter_id": "compact-generative-systems-and-residual-honesty", "title": "Compact Generative Systems: Generate, Verify, Repair, and Residual Honesty", "canonical_order": 60, "core_claim_ref": "compact-generative-systems-and-residual-honesty.core", "distinct_responsibility": "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", "architecture_reference_path": "chapters/compact-generative-systems-and-residual-honesty.html" }, { "chapter_id": "fast-generation-architectures", "title": "Fast Generation Architectures", "canonical_order": 61, "core_claim_ref": "fast-generation-architectures.core", "distinct_responsibility": "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", "architecture_reference_path": "chapters/fast-generation-architectures.html" }, { "chapter_id": "governed-deliberation-and-test-time-scaling", "title": "Governed Deliberation and Test-Time Scaling", "canonical_order": 62, "core_claim_ref": "governed-deliberation-and-test-time-scaling.core", "distinct_responsibility": "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", "architecture_reference_path": "chapters/governed-deliberation-and-test-time-scaling.html" }, { "chapter_id": "rankfold-neuralfold-and-artifact-compression", "title": "RankFold, NeuralFold, and Artifact Compression", "canonical_order": 63, "core_claim_ref": "rankfold-neuralfold-and-artifact-compression.core", "distinct_responsibility": "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", "architecture_reference_path": "chapters/rankfold-neuralfold-and-artifact-compression.html" }, { "chapter_id": "physical-compute-infrastructure-energy-and-environmental-constraints", "title": "Physical Compute Infrastructure, Energy, and Environmental Constraints", "canonical_order": 65, "core_claim_ref": "physical-compute-infrastructure-energy-and-environmental-constraints.core", "distinct_responsibility": "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", "architecture_reference_path": "chapters/physical-compute-infrastructure-energy-and-environmental-constraints.html" } ], "contribution_id": "record-reality-residual-honesty" }, { "order": 21, "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", "plain_language_thesis": "The stack matters only if its local contracts compose into one useful, observable, recoverable trace that cannot silently expand authority or ratify its own improvement.", "normative_engineering_rule": "Join identity, intent, context, plans, effects, observations, evidence, learning, replacement, incidents, rollback, residuals, and publication through the Governed Transition Calculus.", "machine_contract": "Accept an end-to-end transition only when every required owner supplies a compatible identity-bound state and the joined trace reaches effect, observation, recovery, or explicit residual closure; local component validity does not establish composition.", "reader_question": "Do recursive improvement and all local controls compose into one observable, recoverable, and non-self-ratifying trace?", "running_example": "Replay the complete governed repository change and its attacks through the ASI-THESEUS-FLAGSHIP-01 design.", "strongest_objection": "A coherent reference trace may omit the open-world concurrency, institutions, adversaries, and recovery failures that break deployment.", "failure_story": "Locally valid components combine stale authority, a wrong receipt, and partial rollback into an unsafe release.", "evidence_that_would_change_the_conclusion": "End-to-end natural implementations with persistent composition failures would falsify specific interfaces and force architectural revision.", "handoff": "The final unit applies the same discipline to the book's sources, claims, derivatives, publication, and open challenges.", "unit_id": "unit-21-recursive-integration-and-prototype", "unit_label": "Recursive improvement, integrated architecture, and prototype program", "reference_owner_count": 5, "reference_owners": [ { "chapter_id": "recursive-self-improvement-boundaries", "title": "Recursive Self-Improvement Boundaries", "canonical_order": 27, "core_claim_ref": "recursive-self-improvement-boundaries.core", "distinct_responsibility": "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", "architecture_reference_path": "chapters/recursive-self-improvement-boundaries.html" }, { "chapter_id": "open-ended-improvement-engines", "title": "Open-Ended Improvement Engines", "canonical_order": 28, "core_claim_ref": "open-ended-improvement-engines.core", "distinct_responsibility": "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", "architecture_reference_path": "chapters/open-ended-improvement-engines.html" }, { "chapter_id": "autonomous-replication-proliferation-and-containment", "title": "Autonomous Replication, Proliferation, and Containment", "canonical_order": 29, "core_claim_ref": "autonomous-replication-proliferation-and-containment.core", "distinct_responsibility": "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", "architecture_reference_path": "chapters/autonomous-replication-proliferation-and-containment.html" }, { "chapter_id": "project-theseus-as-report-first-implementation-reference", "title": "Project Theseus as Report-First Implementation Reference", "canonical_order": 84, "core_claim_ref": "project-theseus-as-report-first-implementation-reference.core", "distinct_responsibility": "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", "architecture_reference_path": "chapters/project-theseus-as-report-first-implementation-reference.html" }, { "chapter_id": "prototype-roadmap", "title": "Prototype Roadmap", "canonical_order": 85, "core_claim_ref": "prototype-roadmap.core", "distinct_responsibility": "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", "architecture_reference_path": "chapters/prototype-roadmap.html" } ], "contribution_id": "governed-cognition-interface-contracts" }, { "order": 22, "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", "plain_language_thesis": "A living technical book stays trustworthy when ideas, sources, claims, proofs, tests, corrections, products, releases, and open work remain synchronized without pretending that organization proves the thesis.", "normative_engineering_rule": "Treat every substantive editorial or evidence change as a versioned transaction with canonical ownership, validation, support-state effects, public truth, residuals, and one successor.", "machine_contract": "Publish a derivative only when source commit, manifest, rights, claim states, validation, artifact digest, review state, deployment observation, corrections, and successor authority reconcile; a green build does not establish manuscript truth or evidence maturity.", "reader_question": "Can the research program keep its ideas, sources, claims, proofs, corrections, products, and releases mutually accountable?", "running_example": "Treat this repository's prose-first convergence as a governed change that preserves support ceilings and leaves proof execution for its explicit gate.", "strongest_objection": "Elaborate self-governance may optimize records and publication surfaces instead of research quality or reader value.", "failure_story": "Local ledgers declare completion while ideas remain only in roadmaps and the public book exposes stale structure.", "evidence_that_would_change_the_conclusion": "Natural maintenance comparisons showing no improvement in correction, traceability, comprehension, or cost would require a smaller method.", "handoff": "The narrative route ends in the open challenge agenda: prove only the final bounded conclusions after every idea has an owner.", "unit_id": "unit-22-living-book-and-agenda", "unit_label": "Living Book methodology and open challenge agenda", "reference_owner_count": 1, "reference_owners": [ { "chapter_id": "open-research-agenda-and-bibliography-plan", "title": "Open Research Agenda and Bibliography Plan", "canonical_order": 87, "core_claim_ref": "open-research-agenda-and-bibliography-plan.core", "distinct_responsibility": "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", "architecture_reference_path": "chapters/open-research-agenda-and-bibliography-plan.html" } ], "contribution_id": "claim-state-transition-discipline" } ], "reference_only_chapters": [ { "chapter_id": "failure-modes-of-ungoverned-intelligence", "title": "Failure Modes of Ungoverned Intelligence", "canonical_order": 4, "architecture_reference_path": "chapters/failure-modes-of-ungoverned-intelligence.html", "nearest_narrative_owner": "system-boundaries-and-authority", "unit_id": "unit-03-authority-and-failure", "unit_label": "Authority, security, and failure boundaries", "distinct_responsibility": "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" }, { "chapter_id": "dangerous-capability-domains-and-misuse-uplift", "title": "Dangerous Capability Domains and Misuse Uplift", "canonical_order": 5, "architecture_reference_path": "chapters/dangerous-capability-domains-and-misuse-uplift.html", "nearest_narrative_owner": "system-boundaries-and-authority", "unit_id": "unit-03-authority-and-failure", "unit_label": "Authority, security, and failure boundaries", "distinct_responsibility": "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" }, { "chapter_id": "military-ai-autonomous-weapons-and-strategic-stability", "title": "Military AI, Autonomous Weapons, and Strategic Stability", "canonical_order": 6, "architecture_reference_path": "chapters/military-ai-autonomous-weapons-and-strategic-stability.html", "nearest_narrative_owner": "system-boundaries-and-authority", "unit_id": "unit-03-authority-and-failure", "unit_label": "Authority, security, and failure boundaries", "distinct_responsibility": "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" }, { "chapter_id": "scalable-oversight-and-adversarial-ai-control", "title": "Scalable Oversight and Adversarial AI Control", "canonical_order": 8, "architecture_reference_path": "chapters/scalable-oversight-and-adversarial-ai-control.html", "nearest_narrative_owner": "evidence-states-and-claim-discipline", "unit_id": "unit-04-evidence-and-noninheritance", "unit_label": "Evidence states, oversight, and noninheritance", "distinct_responsibility": "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" }, { "chapter_id": "human-intent-as-a-formal-input", "title": "Human Intent as a Formal Input", "canonical_order": 9, "architecture_reference_path": "chapters/human-intent-as-a-formal-input.html", "nearest_narrative_owner": "intent-to-execution-contracts", "unit_id": "unit-07-intent-and-command", "unit_label": "Intent and command contracts", "distinct_responsibility": "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" }, { "chapter_id": "human-factors-and-meaningful-control-in-oversight", "title": "Human Factors and Meaningful Control in Oversight", "canonical_order": 10, "architecture_reference_path": "chapters/human-factors-and-meaningful-control-in-oversight.html", "nearest_narrative_owner": "constitutional-alignment-substrate", "unit_id": "unit-05-constitutional-objective-governance", "unit_label": "Constitutional, value, objective, and institutional governance", "distinct_responsibility": "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" }, { "chapter_id": "human-ai-communication-persuasion-and-epistemic-security", "title": "Human-AI Communication, Persuasion, and Epistemic Security", "canonical_order": 11, "architecture_reference_path": "chapters/human-ai-communication-persuasion-and-epistemic-security.html", "nearest_narrative_owner": "constitutional-alignment-substrate", "unit_id": "unit-05-constitutional-objective-governance", "unit_label": "Constitutional, value, objective, and institutional governance", "distinct_responsibility": "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" }, { "chapter_id": "inner-alignment-mesa-optimization-and-learned-objective-integrity", "title": "Inner Alignment, Mesa-Optimization, and Learned-Objective Integrity", "canonical_order": 13, "architecture_reference_path": "chapters/inner-alignment-mesa-optimization-and-learned-objective-integrity.html", "nearest_narrative_owner": "constitutional-alignment-substrate", "unit_id": "unit-05-constitutional-objective-governance", "unit_label": "Constitutional, value, objective, and institutional governance", "distinct_responsibility": "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" }, { "chapter_id": "moral-uncertainty-and-value-conflict", "title": "Moral Uncertainty, Value Conflict, and Contestable Governance", "canonical_order": 14, "architecture_reference_path": "chapters/moral-uncertainty-and-value-conflict.html", "nearest_narrative_owner": "constitutional-alignment-substrate", "unit_id": "unit-05-constitutional-objective-governance", "unit_label": "Constitutional, value, objective, and institutional governance", "distinct_responsibility": "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" }, { "chapter_id": "governed-objective-formation-value-learning-and-goal-integrity", "title": "Governed Objective Formation, Value Learning, and Goal Integrity", "canonical_order": 15, "architecture_reference_path": "chapters/governed-objective-formation-value-learning-and-goal-integrity.html", "nearest_narrative_owner": "constitutional-alignment-substrate", "unit_id": "unit-05-constitutional-objective-governance", "unit_label": "Constitutional, value, objective, and institutional governance", "distinct_responsibility": "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" }, { "chapter_id": "institutions-international-coordination-and-public-legitimacy", "title": "Institutions, International Coordination, and Public Legitimacy", "canonical_order": 16, "architecture_reference_path": "chapters/institutions-international-coordination-and-public-legitimacy.html", "nearest_narrative_owner": "constitutional-alignment-substrate", "unit_id": "unit-05-constitutional-objective-governance", "unit_label": "Constitutional, value, objective, and institutional governance", "distinct_responsibility": "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" }, { "chapter_id": "societal-resilience-and-misuse-defense", "title": "Societal Resilience and Misuse Defense", "canonical_order": 17, "architecture_reference_path": "chapters/societal-resilience-and-misuse-defense.html", "nearest_narrative_owner": "constitutional-alignment-substrate", "unit_id": "unit-05-constitutional-objective-governance", "unit_label": "Constitutional, value, objective, and institutional governance", "distinct_responsibility": "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" }, { "chapter_id": "capability-replacement-and-rollback", "title": "Capability Replacement and Rollback", "canonical_order": 19, "architecture_reference_path": "chapters/capability-replacement-and-rollback.html", "nearest_narrative_owner": "stable-capability-fields", "unit_id": "unit-06-capability-fields-and-replacement", "unit_label": "Stable Capability Fields and replacement", "distinct_responsibility": "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" }, { "chapter_id": "security-kernel-and-digital-scifs", "title": "Security Kernel and Digital SCIFs", "canonical_order": 20, "architecture_reference_path": "chapters/security-kernel-and-digital-scifs.html", "nearest_narrative_owner": "system-boundaries-and-authority", "unit_id": "unit-03-authority-and-failure", "unit_label": "Authority, security, and failure boundaries", "distinct_responsibility": "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" }, { "chapter_id": "adversarial-machine-learning-and-model-attack-surface", "title": "Adversarial Machine Learning and the Model Attack Surface", "canonical_order": 21, "architecture_reference_path": "chapters/adversarial-machine-learning-and-model-attack-surface.html", "nearest_narrative_owner": "system-boundaries-and-authority", "unit_id": "unit-03-authority-and-failure", "unit_label": "Authority, security, and failure boundaries", "distinct_responsibility": "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" }, { "chapter_id": "privacy-data-rights-and-information-flow-governance", "title": "Privacy, Data Rights, and Information-Flow Governance", "canonical_order": 22, "architecture_reference_path": "chapters/privacy-data-rights-and-information-flow-governance.html", "nearest_narrative_owner": "system-boundaries-and-authority", "unit_id": "unit-03-authority-and-failure", "unit_label": "Authority, security, and failure boundaries", "distinct_responsibility": "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" }, { "chapter_id": "confidential-and-verifiable-ai-computation", "title": "Confidential and Verifiable AI Computation", "canonical_order": 23, "architecture_reference_path": "chapters/confidential-and-verifiable-ai-computation.html", "nearest_narrative_owner": "system-boundaries-and-authority", "unit_id": "unit-03-authority-and-failure", "unit_label": "Authority, security, and failure boundaries", "distinct_responsibility": "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" }, { "chapter_id": "model-weight-custody-and-hardware-roots-of-trust", "title": "Model-Weight Custody and Hardware Roots of Trust", "canonical_order": 24, "architecture_reference_path": "chapters/model-weight-custody-and-hardware-roots-of-trust.html", "nearest_narrative_owner": "system-boundaries-and-authority", "unit_id": "unit-03-authority-and-failure", "unit_label": "Authority, security, and failure boundaries", "distinct_responsibility": "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" }, { "chapter_id": "open-weight-release-and-post-release-control", "title": "Open-Weight Release and Post-Release Control", "canonical_order": 25, "architecture_reference_path": "chapters/open-weight-release-and-post-release-control.html", "nearest_narrative_owner": "readiness-gates-residual-escrow-and-quarantine", "unit_id": "unit-19-readiness-and-liveness", "unit_label": "Readiness, benchmarks, safety cases, and bounded liveness", "distinct_responsibility": "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" }, { "chapter_id": "ai-supply-chain-integrity-and-lifecycle-provenance", "title": "AI Supply-Chain Integrity and Lifecycle Provenance", "canonical_order": 26, "architecture_reference_path": "chapters/ai-supply-chain-integrity-and-lifecycle-provenance.html", "nearest_narrative_owner": "system-boundaries-and-authority", "unit_id": "unit-03-authority-and-failure", "unit_label": "Authority, security, and failure boundaries", "distinct_responsibility": "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" }, { "chapter_id": "recursive-self-improvement-boundaries", "title": "Recursive Self-Improvement Boundaries", "canonical_order": 27, "architecture_reference_path": "chapters/recursive-self-improvement-boundaries.html", "nearest_narrative_owner": "integrated-reference-architecture", "unit_id": "unit-21-recursive-integration-and-prototype", "unit_label": "Recursive improvement, integrated architecture, and prototype program", "distinct_responsibility": "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" }, { "chapter_id": "open-ended-improvement-engines", "title": "Open-Ended Improvement Engines", "canonical_order": 28, "architecture_reference_path": "chapters/open-ended-improvement-engines.html", "nearest_narrative_owner": "integrated-reference-architecture", "unit_id": "unit-21-recursive-integration-and-prototype", "unit_label": "Recursive improvement, integrated architecture, and prototype program", "distinct_responsibility": "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" }, { "chapter_id": "autonomous-replication-proliferation-and-containment", "title": "Autonomous Replication, Proliferation, and Containment", "canonical_order": 29, "architecture_reference_path": "chapters/autonomous-replication-proliferation-and-containment.html", "nearest_narrative_owner": "integrated-reference-architecture", "unit_id": "unit-21-recursive-integration-and-prototype", "unit_label": "Recursive improvement, integrated architecture, and prototype program", "distinct_responsibility": "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" }, { "chapter_id": "perception-sensor-fusion-and-observation-trust", "title": "Perception, Sensor Fusion, and Observation Trust", "canonical_order": 31, "architecture_reference_path": "chapters/perception-sensor-fusion-and-observation-trust.html", "nearest_narrative_owner": "governed-world-models-and-reality-grounding", "unit_id": "unit-09-world-models", "unit_label": "Perception, governed world models, and embodied reconciliation", "distinct_responsibility": "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" }, { "chapter_id": "context-transactions-snapshots-mounts-and-taint", "title": "Context Transactions, Snapshots, Mounts, and Taint", "canonical_order": 37, "architecture_reference_path": "chapters/context-transactions-snapshots-mounts-and-taint.html", "nearest_narrative_owner": "virtual-context-abi", "unit_id": "unit-11-context-abi", "unit_label": "Virtual Context ABI and context transactions", "distinct_responsibility": "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" }, { "chapter_id": "spinoza-verification-and-proof-carrying-claims", "title": "Proof-Carrying Claims and Adversarial Review", "canonical_order": 40, "architecture_reference_path": "chapters/spinoza-verification-and-proof-carrying-claims.html", "nearest_narrative_owner": "claim-ledgers-and-belief-revision", "unit_id": "unit-14-claim-and-proof-review", "unit_label": "Claim ledgers, proof-carrying review, and formal scope", "distinct_responsibility": "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" }, { "chapter_id": "ai-work-surfaces-agent-harnesses-and-organizational-absorption", "title": "From Chat to Organizations: AI Work Surfaces and Agent Harnesses", "canonical_order": 42, "architecture_reference_path": "chapters/ai-work-surfaces-agent-harnesses-and-organizational-absorption.html", "nearest_narrative_owner": "labor-os-and-typed-jobs", "unit_id": "unit-15-labor-and-artifacts", "unit_label": "Labor OS, organizations, artifact graphs, and stewardship", "distinct_responsibility": "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" }, { "chapter_id": "human-ai-organizations-delegation-and-accountability", "title": "Human-AI Organizations, Delegation, and Accountability", "canonical_order": 43, "architecture_reference_path": "chapters/human-ai-organizations-delegation-and-accountability.html", "nearest_narrative_owner": "labor-os-and-typed-jobs", "unit_id": "unit-15-labor-and-artifacts", "unit_label": "Labor OS, organizations, artifact graphs, and stewardship", "distinct_responsibility": "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" }, { "chapter_id": "human-ai-symbiosis-neurotechnology-and-cognitive-sovereignty", "title": "Human-AI Symbiosis, Neurotechnology, and Cognitive Sovereignty", "canonical_order": 44, "architecture_reference_path": "chapters/human-ai-symbiosis-neurotechnology-and-cognitive-sovereignty.html", "nearest_narrative_owner": "labor-os-and-typed-jobs", "unit_id": "unit-15-labor-and-artifacts", "unit_label": "Labor OS, organizations, artifact graphs, and stewardship", "distinct_responsibility": "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" }, { "chapter_id": "ai-deployment-transition-distribution-and-human-agency", "title": "AI Deployment, Transition, Distribution, and Human Agency", "canonical_order": 45, "architecture_reference_path": "chapters/ai-deployment-transition-distribution-and-human-agency.html", "nearest_narrative_owner": "labor-os-and-typed-jobs", "unit_id": "unit-15-labor-and-artifacts", "unit_label": "Labor OS, organizations, artifact graphs, and stewardship", "distinct_responsibility": "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" }, { "chapter_id": "artifact-graphs-audit-logs-and-replay", "title": "Artifact Graphs, Audit Logs, and Replay", "canonical_order": 46, "architecture_reference_path": "chapters/artifact-graphs-audit-logs-and-replay.html", "nearest_narrative_owner": "labor-os-and-typed-jobs", "unit_id": "unit-15-labor-and-artifacts", "unit_label": "Labor OS, organizations, artifact graphs, and stewardship", "distinct_responsibility": "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" }, { "chapter_id": "embodied-agency-real-time-control-and-physical-safety", "title": "Embodied Agency, Real-Time Control, and Physical Safety", "canonical_order": 48, "architecture_reference_path": "chapters/embodied-agency-real-time-control-and-physical-safety.html", "nearest_narrative_owner": "governed-world-models-and-reality-grounding", "unit_id": "unit-09-world-models", "unit_label": "Perception, governed world models, and embodied reconciliation", "distinct_responsibility": "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" }, { "chapter_id": "inter-stack-protocols-identity-and-economic-exchange", "title": "Inter-Stack Protocols, Identity, and Economic Exchange", "canonical_order": 49, "architecture_reference_path": "chapters/inter-stack-protocols-identity-and-economic-exchange.html", "nearest_narrative_owner": "labor-os-and-typed-jobs", "unit_id": "unit-15-labor-and-artifacts", "unit_label": "Labor OS, organizations, artifact graphs, and stewardship", "distinct_responsibility": "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" }, { "chapter_id": "multi-agent-dynamics-collective-intelligence-and-systemic-risk", "title": "Multi-Agent Dynamics, Collective Intelligence, and Systemic Risk", "canonical_order": 50, "architecture_reference_path": "chapters/multi-agent-dynamics-collective-intelligence-and-systemic-risk.html", "nearest_narrative_owner": "labor-os-and-typed-jobs", "unit_id": "unit-15-labor-and-artifacts", "unit_label": "Labor OS, organizations, artifact graphs, and stewardship", "distinct_responsibility": "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" }, { "chapter_id": "procedural-memory-and-cognitive-loop-closure", "title": "Procedural Memory and Cognitive Loop Closure", "canonical_order": 51, "architecture_reference_path": "chapters/procedural-memory-and-cognitive-loop-closure.html", "nearest_narrative_owner": "durable-semantic-memory-and-knowledge-lattices", "unit_id": "unit-12-memory-and-consolidation", "unit_label": "Durable memory and procedural consolidation", "distinct_responsibility": "Cognitive loop closure compiles repeated reasoning into verified parameterized tools and procedural memory.", "claim_label": "Design rationale", "support_state": "argument" }, { "chapter_id": "routing-heads-and-specialist-cores", "title": "Routing Heads and Specialist Cores", "canonical_order": 52, "architecture_reference_path": "chapters/routing-heads-and-specialist-cores.html", "nearest_narrative_owner": "replaceable-cognitive-substrates-beyond-transformer-monoculture", "unit_id": "unit-17-routing-and-substrates", "unit_label": "Routing and replaceable cognitive substrates", "distinct_responsibility": "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" }, { "chapter_id": "relational-dimension-compilation-and-polyadic-cognition", "title": "Relational Dimension Compilation and Polyadic Cognition", "canonical_order": 54, "architecture_reference_path": "chapters/relational-dimension-compilation-and-polyadic-cognition.html", "nearest_narrative_owner": "cognitive-compilation-and-semantic-ir", "unit_id": "unit-10-cognitive-compilation", "unit_label": "Cognitive compilation, relational cognition, and search", "distinct_responsibility": "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" }, { "chapter_id": "learning-compute-topology-and-adaptive-process-architecture", "title": "Learning–Compute Topology and Adaptive Process Architecture", "canonical_order": 56, "architecture_reference_path": "chapters/learning-compute-topology-and-adaptive-process-architecture.html", "nearest_narrative_owner": "governed-model-training-distributed-optimization-and-scaling", "unit_id": "unit-18-developmental-learning", "unit_label": "Governed training and developmental learning", "distinct_responsibility": "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" }, { "chapter_id": "learning-theory-generalization-and-scaling-science", "title": "Learning Theory, Generalization, and Scaling Science", "canonical_order": 57, "architecture_reference_path": "chapters/learning-theory-generalization-and-scaling-science.html", "nearest_narrative_owner": "governed-model-training-distributed-optimization-and-scaling", "unit_id": "unit-18-developmental-learning", "unit_label": "Governed training and developmental learning", "distinct_responsibility": "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" }, { "chapter_id": "personal-compute-hives-and-federated-edge-intelligence", "title": "Personal Compute Hives and Federated Edge Intelligence", "canonical_order": 59, "architecture_reference_path": "chapters/personal-compute-hives-and-federated-edge-intelligence.html", "nearest_narrative_owner": "resource-economics-and-token-budgets", "unit_id": "unit-20-resource-and-recovery-economics", "unit_label": "Resource economics, efficient inference, and effect-complete recovery", "distinct_responsibility": "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" }, { "chapter_id": "compact-generative-systems-and-residual-honesty", "title": "Compact Generative Systems: Generate, Verify, Repair, and Residual Honesty", "canonical_order": 60, "architecture_reference_path": "chapters/compact-generative-systems-and-residual-honesty.html", "nearest_narrative_owner": "resource-economics-and-token-budgets", "unit_id": "unit-20-resource-and-recovery-economics", "unit_label": "Resource economics, efficient inference, and effect-complete recovery", "distinct_responsibility": "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" }, { "chapter_id": "fast-generation-architectures", "title": "Fast Generation Architectures", "canonical_order": 61, "architecture_reference_path": "chapters/fast-generation-architectures.html", "nearest_narrative_owner": "resource-economics-and-token-budgets", "unit_id": "unit-20-resource-and-recovery-economics", "unit_label": "Resource economics, efficient inference, and effect-complete recovery", "distinct_responsibility": "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" }, { "chapter_id": "governed-deliberation-and-test-time-scaling", "title": "Governed Deliberation and Test-Time Scaling", "canonical_order": 62, "architecture_reference_path": "chapters/governed-deliberation-and-test-time-scaling.html", "nearest_narrative_owner": "resource-economics-and-token-budgets", "unit_id": "unit-20-resource-and-recovery-economics", "unit_label": "Resource economics, efficient inference, and effect-complete recovery", "distinct_responsibility": "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" }, { "chapter_id": "rankfold-neuralfold-and-artifact-compression", "title": "RankFold, NeuralFold, and Artifact Compression", "canonical_order": 63, "architecture_reference_path": "chapters/rankfold-neuralfold-and-artifact-compression.html", "nearest_narrative_owner": "resource-economics-and-token-budgets", "unit_id": "unit-20-resource-and-recovery-economics", "unit_label": "Resource economics, efficient inference, and effect-complete recovery", "distinct_responsibility": "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" }, { "chapter_id": "physical-compute-infrastructure-energy-and-environmental-constraints", "title": "Physical Compute Infrastructure, Energy, and Environmental Constraints", "canonical_order": 65, "architecture_reference_path": "chapters/physical-compute-infrastructure-energy-and-environmental-constraints.html", "nearest_narrative_owner": "resource-economics-and-token-budgets", "unit_id": "unit-20-resource-and-recovery-economics", "unit_label": "Resource economics, efficient inference, and effect-complete recovery", "distinct_responsibility": "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" }, { "chapter_id": "mathematical-and-search-substrates", "title": "Mathematical and Search Substrates", "canonical_order": 66, "architecture_reference_path": "chapters/mathematical-and-search-substrates.html", "nearest_narrative_owner": "cognitive-compilation-and-semantic-ir", "unit_id": "unit-10-cognitive-compilation", "unit_label": "Cognitive compilation, relational cognition, and search", "distinct_responsibility": "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" }, { "chapter_id": "circle-calculus-and-proof-carrying-ai-contracts", "title": "Circle Calculus and Proof-Carrying AI Contracts", "canonical_order": 67, "architecture_reference_path": "chapters/circle-calculus-and-proof-carrying-ai-contracts.html", "nearest_narrative_owner": "claim-ledgers-and-belief-revision", "unit_id": "unit-14-claim-and-proof-review", "unit_label": "Claim ledgers, proof-carrying review, and formal scope", "distinct_responsibility": "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" }, { "chapter_id": "coil-attention-cyclic-memory-and-recurrence-contracts", "title": "Coil Attention, Cyclic Memory, and Recurrence Contracts", "canonical_order": 68, "architecture_reference_path": "chapters/coil-attention-cyclic-memory-and-recurrence-contracts.html", "nearest_narrative_owner": "replaceable-cognitive-substrates-beyond-transformer-monoculture", "unit_id": "unit-17-routing-and-substrates", "unit_label": "Routing and replaceable cognitive substrates", "distinct_responsibility": "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" }, { "chapter_id": "coilra-multicoil-rope-and-cyclic-mixers", "title": "CoilRA, MultiCoil RoPE, and Cyclic Mixers", "canonical_order": 69, "architecture_reference_path": "chapters/coilra-multicoil-rope-and-cyclic-mixers.html", "nearest_narrative_owner": "replaceable-cognitive-substrates-beyond-transformer-monoculture", "unit_id": "unit-17-routing-and-substrates", "unit_label": "Routing and replaceable cognitive substrates", "distinct_responsibility": "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" }, { "chapter_id": "executable-specifications-and-lean-proof-envelope", "title": "Executable Specifications and Lean Proof Envelope", "canonical_order": 70, "architecture_reference_path": "chapters/executable-specifications-and-lean-proof-envelope.html", "nearest_narrative_owner": "claim-ledgers-and-belief-revision", "unit_id": "unit-14-claim-and-proof-review", "unit_label": "Claim ledgers, proof-carrying review, and formal scope", "distinct_responsibility": "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" }, { "chapter_id": "benchmark-ratchets-and-anti-goodhart-evidence", "title": "Benchmark Ratchets and Anti-Goodhart Evidence", "canonical_order": 71, "architecture_reference_path": "chapters/benchmark-ratchets-and-anti-goodhart-evidence.html", "nearest_narrative_owner": "readiness-gates-residual-escrow-and-quarantine", "unit_id": "unit-19-readiness-and-liveness", "unit_label": "Readiness, benchmarks, safety cases, and bounded liveness", "distinct_responsibility": "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" }, { "chapter_id": "white-box-evidence-interpretability-and-activation-governance", "title": "White-Box Evidence, Interpretability, and Activation Governance", "canonical_order": 72, "architecture_reference_path": "chapters/white-box-evidence-interpretability-and-activation-governance.html", "nearest_narrative_owner": "claim-ledgers-and-belief-revision", "unit_id": "unit-14-claim-and-proof-review", "unit_label": "Claim ledgers, proof-carrying review, and formal scope", "distinct_responsibility": "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" }, { "chapter_id": "capability-thresholds-and-deployment-commitments", "title": "Capability Thresholds and Deployment Commitments", "canonical_order": 73, "architecture_reference_path": "chapters/capability-thresholds-and-deployment-commitments.html", "nearest_narrative_owner": "readiness-gates-residual-escrow-and-quarantine", "unit_id": "unit-19-readiness-and-liveness", "unit_label": "Readiness, benchmarks, safety cases, and bounded liveness", "distinct_responsibility": "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" }, { "chapter_id": "adversarial-evaluation-sandbagging-and-training-time-deception", "title": "Adversarial Evaluation, Sandbagging, and Training-Time Deception", "canonical_order": 74, "architecture_reference_path": "chapters/adversarial-evaluation-sandbagging-and-training-time-deception.html", "nearest_narrative_owner": "readiness-gates-residual-escrow-and-quarantine", "unit_id": "unit-19-readiness-and-liveness", "unit_label": "Readiness, benchmarks, safety cases, and bounded liveness", "distinct_responsibility": "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" }, { "chapter_id": "safety-cases-and-structured-assurance", "title": "Safety Cases and Structured Assurance", "canonical_order": 75, "architecture_reference_path": "chapters/safety-cases-and-structured-assurance.html", "nearest_narrative_owner": "readiness-gates-residual-escrow-and-quarantine", "unit_id": "unit-19-readiness-and-liveness", "unit_label": "Readiness, benchmarks, safety cases, and bounded liveness", "distinct_responsibility": "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" }, { "chapter_id": "content-authenticity-watermarking-and-synthetic-media-integrity", "title": "Content Authenticity, Watermarking, and Synthetic Media Integrity", "canonical_order": 76, "architecture_reference_path": "chapters/content-authenticity-watermarking-and-synthetic-media-integrity.html", "nearest_narrative_owner": "readiness-gates-residual-escrow-and-quarantine", "unit_id": "unit-19-readiness-and-liveness", "unit_label": "Readiness, benchmarks, safety cases, and bounded liveness", "distinct_responsibility": "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" }, { "chapter_id": "governed-operations-incident-command-and-graceful-degradation", "title": "Governed Operations, Incident Command, and Graceful Degradation", "canonical_order": 77, "architecture_reference_path": "chapters/governed-operations-incident-command-and-graceful-degradation.html", "nearest_narrative_owner": "runtime-adapters-tool-permissions-and-human-approval", "unit_id": "unit-16-runtime-and-operations", "unit_label": "Runtime adapters, observation, incident command, and operations", "distinct_responsibility": "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" }, { "chapter_id": "adjudicated-persistence-and-the-adaptive-commit-boundary", "title": "Adjudicated Persistence and the Adaptive Commit Boundary", "canonical_order": 78, "architecture_reference_path": "chapters/adjudicated-persistence-and-the-adaptive-commit-boundary.html", "nearest_narrative_owner": "governed-model-training-distributed-optimization-and-scaling", "unit_id": "unit-18-developmental-learning", "unit_label": "Governed training and developmental learning", "distinct_responsibility": "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" }, { "chapter_id": "policy-optimization-and-learning-from-feedback", "title": "Policy Optimization and Learning from Feedback", "canonical_order": 79, "architecture_reference_path": "chapters/policy-optimization-and-learning-from-feedback.html", "nearest_narrative_owner": "governed-model-training-distributed-optimization-and-scaling", "unit_id": "unit-18-developmental-learning", "unit_label": "Governed training and developmental learning", "distinct_responsibility": "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" }, { "chapter_id": "data-engines-continual-learning-and-unlearning", "title": "Data Engines, Continual Learning, and Unlearning", "canonical_order": 80, "architecture_reference_path": "chapters/data-engines-continual-learning-and-unlearning.html", "nearest_narrative_owner": "governed-model-training-distributed-optimization-and-scaling", "unit_id": "unit-18-developmental-learning", "unit_label": "Governed training and developmental learning", "distinct_responsibility": "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" }, { "chapter_id": "scientific-discovery-and-experimental-governance", "title": "Scientific Discovery and Experimental Governance", "canonical_order": 81, "architecture_reference_path": "chapters/scientific-discovery-and-experimental-governance.html", "nearest_narrative_owner": "governed-model-training-distributed-optimization-and-scaling", "unit_id": "unit-18-developmental-learning", "unit_label": "Governed training and developmental learning", "distinct_responsibility": "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" }, { "chapter_id": "artifact-steward-agents-and-living-project-governance", "title": "Artifact Steward Agents and Living Project Governance", "canonical_order": 82, "architecture_reference_path": "chapters/artifact-steward-agents-and-living-project-governance.html", "nearest_narrative_owner": "labor-os-and-typed-jobs", "unit_id": "unit-15-labor-and-artifacts", "unit_label": "Labor OS, organizations, artifact graphs, and stewardship", "distinct_responsibility": "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" }, { "chapter_id": "project-theseus-as-report-first-implementation-reference", "title": "Project Theseus as Report-First Implementation Reference", "canonical_order": 84, "architecture_reference_path": "chapters/project-theseus-as-report-first-implementation-reference.html", "nearest_narrative_owner": "integrated-reference-architecture", "unit_id": "unit-21-recursive-integration-and-prototype", "unit_label": "Recursive improvement, integrated architecture, and prototype program", "distinct_responsibility": "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" }, { "chapter_id": "prototype-roadmap", "title": "Prototype Roadmap", "canonical_order": 85, "architecture_reference_path": "chapters/prototype-roadmap.html", "nearest_narrative_owner": "integrated-reference-architecture", "unit_id": "unit-21-recursive-integration-and-prototype", "unit_label": "Recursive improvement, integrated architecture, and prototype program", "distinct_responsibility": "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" }, { "chapter_id": "open-research-agenda-and-bibliography-plan", "title": "Open Research Agenda and Bibliography Plan", "canonical_order": 87, "architecture_reference_path": "chapters/open-research-agenda-and-bibliography-plan.html", "nearest_narrative_owner": "living-book-methodology", "unit_id": "unit-22-living-book-and-agenda", "unit_label": "Living Book methodology and open challenge agenda", "distinct_responsibility": "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" } ], "review_gate": [ "Generate the derivative from the current canonical manifest rather than copying a parallel manuscript.", "Verify that all twenty-two representative chapters exist, preserve canonical order, and carry current core-claim references.", "Verify that every chapter in the current manifest maps to exactly one narrative unit or remains explicitly discoverable as optional reference material.", "Verify meaning preservation, handoffs, glossary terms, source and claim links, role ownership, browser navigation, and accessibility preparation.", "Create an edition release record only for artifacts that were actually rendered and reviewed under the declared internal gates." ], "non_claims": [ "Selection for the narrative route does not promote a chapter-core support state.", "Omission as a representative unit does not reject, deprecate, merge, or remove a canonical chapter.", "A generated candidate is not a reviewed reader release, publication artifact, empirical result, or independent approval.", "Compound-unit synthesis does not transfer authority or evidence between canonical chapter owners.", "The orientation fields are editorial navigation and add no evidence." ] }