AI, LLMs, autonomy & knowledge

Packet identity

Packet ID

academy:ai-knowledge

Packet SHA-256 identity

48e9996662457d787d3a934f8619b1fcbfaf8a4c88b3a3ea73c1a3bbbf20832c

Corpus SHA-256 identity

8fa944604ca189f5a9216ca59f640ad2ca20972ad512f2f4970764716782e18d

Release ID

public-alpha-2026-07-26-research-visuals-r14

Source commit

3eb036fce3d711336c8c605625895e8a2e799ab0

Frozen corpus date

2026-07-25

Primary records

6

Reference sources

43

Questions and exclusions

Required questions

1. Required question 1 (exact ID: question-1)
   Are the five lessons accurate, comprehensible, appropriately bounded, and complete enough for the declared audience?
2. Required question 2 (exact ID: question-2)
   Do citations, assumptions, transfer limits, uncertainty, and change conditions support every substantive conclusion?
3. Required question 3 (exact ID: question-3)
   What important affected-community, accessibility, safety, or disciplinary perspective is missing?

Explicit exclusions

• A track review does not approve linked claim records; those remain primary in system packets.
• A favorable curriculum review is not mission, product, medical, legal, or operational authorization.

Requested controlled scopes: ai-knowledge-assurance, information-science, systems-engineering

Frozen-evidence decision window: 365 days from the packet freeze. Not applicable to this packet family.

Complete primary record set

Every record below has one primary packet owner. Decisions must bind to the exact record and packet fingerprints; a changed lesson body, evidence grade, citation, locator, source snapshot, requirement, policy, release, or commit expires the old packet.

1. academy-track · ai-knowledge

   AI, LLMs, autonomy & knowledge

   Record fingerprint

   e7e8813a40c1b1fcaca02103c9d4e86ab1fced24cea6282a156469738ed13835

   Minimum approvals

   1

   Required scope groups

   bounded-competence: ai-knowledge-assurance, information-science

   High-consequence domains

   None under the named two-person rule

   Review state

   pending

   Published human decisions

   0

   Inspect the complete frozen review surface

   Slug

   ai-knowledge

   Number

   10

   Title

   AI, LLMs, autonomy & knowledge

   Kicker

   A powerful advisor, never a sovereign

   Summary

   Understand how AI changes training, maintenance, science, and institutional memory while creating new failure and power risks.

   Core Question

   How can intelligence remain useful, contestable, and recoverable for centuries?

   Image

   /images/chapters/12-ai-knowledge.avif

   Systems

   1. ai-autonomy
   2. communications-navigation
   3. cybersecurity

   Lessons

   1. Slug

      what-ai-changes

      Title

      What AI changes—and what it does not

      Summary

      Separate flight-proven autonomy, bounded lab systems, and speculative general capability.

      Minutes

      18

      Level

      Foundation

   2. Slug

      authority-stack

      Title

      The autonomy authority stack

      Summary

      Layer physical protection, verified control, bounded autonomy, LLM advice, and experiments.

      Minutes

      18

      Level

      Foundation

   3. Slug

      digital-twin-divergence

      Title

      Digital twins and model divergence

      Summary

      Use models for diagnosis while exposing uncertainty, provenance, and calibration loss.

      Minutes

      18

      Level

      Foundation

   4. Slug

      knowledge-ark

      Title

      The Knowledge Ark

      Summary

      Preserve sources, software, toolchains, media, tacit skill, and institutional memory.

      Minutes

      18

      Level

      Foundation

   5. Slug

      ai-constitution

      Title

      An AI constitution

      Summary

      Define permissions, appeals, model diversity, update gates, audit, and human accountability.

      Minutes

      18

      Level

      Foundation

2. academy-lesson · lesson-10-01

   What AI changes—and what it does not

   Record fingerprint

   d16bbc15e0d3a12574bb0b26f6fc345af3423a1f046501ee85517fb94392a374

   Minimum approvals

   1

   Required scope groups

   bounded-competence: ai-knowledge-assurance, information-science

   High-consequence domains

   None under the named two-person rule

   Review state

   pending

   Published human decisions

   0

   Inspect the complete frozen review surface

   Slug

   what-ai-changes

   Title

   What AI changes—and what it does not

   Summary

   Separate demonstrated autonomy and useful language interfaces from speculation, then locate where AI changes coordination costs—and where evidence, hardware, institutions, and physics still dominate.

   Minutes

   37

   Level

   Foundation

   ID

   lesson-10-01

   Track Slug

   ai-knowledge

   Track Title

   AI, LLMs, autonomy & knowledge

   Href

   /academy/ai-knowledge/what-ai-changes

   Prepared By

   GShips Project

   Last Edited At

   2026-07-25

   Review Required Domains

   1. ai-evaluation
   2. spacecraft-autonomy
   3. systems-engineering
   4. human-factors
   5. software-assurance
   6. cybersecurity
   7. governance

   Claim IDs

   1. claim-11-01
   2. claim-11-02
   3. claim-11-03
   4. claim-11-04
   5. claim-11-06
   6. claim-11-07
   7. claim-11-08
   8. claim-11-09

   Exact MDX

   ---
   id: "lesson-10-01"
   track: "ai-knowledge"
   slug: "what-ai-changes"
   title: "What AI changes—and what it does not"
   summary: "Separate demonstrated autonomy and useful language interfaces from speculation, then locate where AI changes coordination costs—and where evidence, hardware, institutions, and physics still dominate."
   minutes: 37
   level: "Foundation"
   preparedBy: "GShips Project"
   lastEditedAt: "2026-07-25"
   conflicts: "Maintainer intends to explore a commercial venture based on some GShips work; no entity, funding, customer, sponsor, or partner relationship currently exists."
   reviewRequiredDomains: "ai-evaluation, spacecraft-autonomy, systems-engineering, human-factors, software-assurance, cybersecurity, governance"
   claimIds: "claim-11-01, claim-11-02, claim-11-03, claim-11-04, claim-11-06, claim-11-07, claim-11-08, claim-11-09"
   ---
   
   # What AI changes—and what it does not
   
   > **Evidence boundary:** Spacecraft have demonstrated bounded onboard planning, execution, fault response, and distributed coordination. Current generative models can retrieve, summarize, translate, draft, and propose, but NIST identifies confabulation, privacy, information-integrity, human-overreliance, and adversarial risks. No cited evidence shows an AI maintaining safe and legitimate judgment for a diverse society across generations. This is a civil-and-defensive synthesis. It excludes offensive cyber operations, autonomous weapons, weapon integration, and actionable exploitation instructions. Cyber, dual-use, and life-safety conclusions require two-person review.
   
   ## Plain-language summary
   
   AI changes how expensive it is to cross an interface. A person can ask a question in ordinary language instead of knowing a database query. A mechanic can search thousands of maintenance records. A student can receive explanations at several levels. A planning team can generate candidate schedules and compare them.
   
   That can matter enormously on a ship with limited specialists. It may reduce coordination delay, help people learn, and make knowledge reachable across disciplines and generations.
   
   It does not create measurements that were never taken, prove an unsupported theory, fabricate a missing bearing, supply power, restore a poisoned sensor, resolve a constitutional conflict, or repeal the rocket equation. Fluent output can hide those limits. The responsible question is not “How intelligent is the model?” It is “Which bounded function does it support, on what evidence, with what authority, failure modes, and non-AI fallback?”
   
   ## Keep evidence classes separate
   
   The label “AI” can collapse very different systems:
   
   - a deterministic controller maintaining pressure;
   - a planner searching schedules under explicit constraints;
   - a diagnostic classifier trained on representative faults;
   - a vision model finding anomalies in images;
   - a distributed algorithm coordinating several spacecraft;
   - a language model predicting text or tool calls; and
   - a speculative system claimed to possess broad independent judgment.
   
   Evidence for one does not transfer automatically to another. A classifier’s accuracy on a held-out dataset says little about a generative assistant acting through tools. A six-hour flight experiment does not show indefinite autonomy. A convincing conversation does not demonstrate control stability or legitimate authority.
   
   Describe each system by task, environment, interfaces, authority, evaluation population, operating duration, and observed failures. Avoid maturity labels that treat all autonomy as one ladder.
   
   ## What spacecraft have actually demonstrated
   
   In 1999, the Remote Agent experiment on Deep Space 1 planned and executed selected spacecraft activities from high-level goals and responded to injected simulated faults. JPL’s account also records a timing bug that paused the experiment and required ground diagnosis before a further run. This was a valuable bounded flight demonstration—not a self-sustaining civilization.
   
   NASA’s Starling mission later tested a different evidence class: four small spacecraft in low Earth orbit, including distributed science autonomy, network routing, swarm navigation, and onboard maneuver planning. Published results report autonomous collaboration among three spacecraft for a science observation plan and note limitations that prevented the full intended demonstration across all four.
   
   These programs support two lessons. First, onboard autonomy can do real work when goals, state, constraints, and interfaces are engineered. Second, the evidence must retain duration, scale, ground support, fault set, and mission boundary. “Space-proven AI” is too coarse.
   
   ## What language models may change
   
   Language models can lower several costs:
   
   ### Retrieval cost
   
   Natural-language queries can help people find manuals, requirements, incident histories, and training material. Retrieval is valuable only if the answer identifies the controlled source, revision, exact locator, and relevant conflicts. Otherwise the model may blend current and obsolete instructions.
   
   ### Translation cost
   
   A model may translate across languages, technical vocabularies, or levels of expertise. Translation can widen participation. It can also erase uncertainty, alter a requirement, or choose a politically loaded term. Important transformations need comparison to the source and accountable human review.
   
   ### Drafting cost
   
   Models can draft checklists, lessons, test cases, software, or candidate plans. Drafting is not acceptance. Each output inherits requirements, verification, licensing, provenance, and safety obligations.
   
   ### Coordination cost
   
   A model can summarize many logs or expose dependencies across teams. That may make an evidence graph easier to navigate. It cannot determine that a missing edge is harmless. The graph should keep claims, sources, requirements, hazards, tests, results, configurations, decisions, owners, and review states as inspectable records outside the model.
   
   ### Learning cost
   
   Tutoring and simulation can help a new generation acquire concepts. Skill is not demonstrated by receiving an explanation. Learners must perform work, diagnose unfamiliar conditions, teach others, and operate when the model is unavailable or wrong.
   
   ## The evidence/requirements graph
   
   A useful AI interface sits above a structured evidence system. Give every important object a stable identifier:
   
   - claim and counterclaim;
   - source and exact locator;
   - requirement and rationale;
   - hazard and control;
   - model assumption and validity envelope;
   - design version and dependency;
   - verification method, test article, result, and anomaly;
   - maintenance action, measurement, and calibration state;
   - decision, authority, dissent, and review date.
   
   Edges should state their meaning: “supports,” “contradicts,” “derived from,” “implements,” “verifies,” “invalidated by,” or “supersedes.” A signature can show that identified bytes were approved under a policy. It cannot prove that the source was correct, current, complete, authorized for this decision, or physically safe.
   
   An LLM may query or explain the graph, but should not silently modify authoritative edges. Its answer should expose the subgraph used, distinguish record from inference, and abstain when evidence is absent or conflicting.
   
   ## Why failure can be correlated
   
   Adding three models does not create three independent opinions if they share training data, architecture, retrieval corpus, compiler, runtime, sensor stream, evaluation set, or institutional incentives. They may confabulate the same citation or accept the same poisoned procedure.
   
   Independence should be traced by cause:
   
   - different physical measurement principles;
   - separately governed data and review;
   - deterministic checks against invariant limits;
   - diverse implementations where justified;
   - human teams with independent access to primary evidence; and
   - a non-AI path that has been exercised recently.
   
   Model diversity can help exploration, but safety must not be a vote among correlated generators.
   
   ## Threats to epistemic resilience
   
   NIST’s Generative AI Profile identifies confabulation, data privacy, information integrity, human-AI configuration, and value-chain risks. NIST AI 100-2 describes evasion, poisoning, privacy, and misuse across AI lifecycles.
   
   For onboard systems, evaluate:
   
   - invented facts, citations, or confidence;
   - prompt or tool injection embedded in documents, logs, or messages;
   - poisoned training, evaluation, retrieval, telemetry, or feedback;
   - stale but correctly signed procedures;
   - evaluator contamination and benchmarks that leak into development;
   - private medical, civic, or personal data escaping through outputs;
   - automation bias and de-skilling;
   - tool calls that exceed the user’s authority;
   - model/runtime common-mode failure; and
   - opaque updates that change behavior without preserving an old workflow.
   
   Defenses are incomplete. Retrieval does not guarantee truth. A larger model does not guarantee calibrated uncertainty. A safety prompt is not a physical interlock.
   
   ## Authority must stay explicit
   
   An offline assistant can retrieve, explain, compare, or propose. It should not:
   
   - directly actuate life support;
   - issue or revoke civic identity;
   - determine guilt or medical eligibility;
   - approve its own model, data, or tool update;
   - accept a safety-critical part or procedure;
   - erase evidence;
   - count as one of two independent reviewers; or
   - expand its permissions through generated text.
   
   Tool access should inherit the human’s bounded role, require typed inputs and outputs, and place deterministic policy and safety checks outside the model. High-consequence action needs explicit confirmation from qualified people and independent evidence.
   
   ## Evaluate the system people actually use
   
   Benchmark scores are not enough. Test the full configuration: model, prompt, retrieval store, tool layer, interface, users, procedures, hardware, network state, and workload.
   
   Use representative and adversarial scenarios:
   
   - the source is missing or contradictory;
   - an obsolete manual ranks above the current one;
   - a signed document contains unsafe content;
   - a retrieved note contains prompt injection;
   - telemetry is biased;
   - the operator is tired and overtrusts fluent output;
   - the model and backup share one failure;
   - the answer must be produced offline;
   - the model must abstain; and
   - the crew must complete the task with AI disabled.
   
   Measure error severity, citation correctness, abstention quality, recovery time, operator calibration, privacy loss, and safe-service outcome—not only answer similarity.
   
   ## What remains physical and institutional
   
   AI cannot close missing material loops, qualify a reactor, extend bearing life, establish a stable ecology, or make an unjust institution legitimate. It can help people reason about those tasks. The distinction matters when claiming smaller crews or lower mass: any reduction must be supported by demonstrated workload, training, repair, and recovery performance across changing people and hardware.
   
   Robotics also remains a separate constraint. Planning a repair does not manipulate an unfamiliar damaged object, fabricate a qualified part, calibrate the instrument, or restore the robot that performs the work.
   
   ## Evidence ledger
   
   - **L10-01-A — Deep Space 1 demonstrated bounded onboard planning, execution, and response to simulated faults.** Basis: demonstrated. Readiness: operational for a historical bounded experiment, not indefinite autonomy. Confidence: strong.
   - **L10-01-B — Starling demonstrated distributed autonomy and coordination in a small-spacecraft mission with reported limitations.** Basis: demonstrated. Readiness: early research for broader autonomous systems. Confidence: strong.
   - **L10-01-C — LLMs can reduce retrieval, translation, drafting, and coordination costs when linked to controlled evidence.** Basis: observed and proposed. Readiness: early research for high-consequence offline use. Confidence: supported.
   - **L10-01-D — Generative AI does not resolve missing evidence, hardware, institutions, or physical feasibility.** Basis: normative systems boundary. Readiness: operational as a review principle. Confidence: strong.
   - **L10-01-E — Confabulation, injection, poisoning, privacy loss, automation bias, and correlated failure threaten onboard knowledge.** Basis: observed risk taxonomy and modeled application. Readiness: early research for mitigations. Confidence: strong for risk existence, tentative for control sufficiency.
   - **L10-01-F — Every safety-critical function should remain safely operable with generative models unavailable or isolated.** Basis: normative. Readiness: proposed decision gate. Confidence: supported.
   
   Linked corpus claims: `claim-11-01`, `claim-11-02`, `claim-11-03`, `claim-11-04`, `claim-11-06`, `claim-11-07`, `claim-11-08`, and `claim-11-09`. See the claim registry for each record's current evidence grade and independent-review state.
   
   ## Assumptions and limits
   
   - No claim is made about future general intelligence or consciousness.
   - Current demonstrations remain bounded by their mission, hardware, duration, fault set, and ground support.
   - Natural-language usability is not treated as competence, evidence, or legitimate authority.
   - Signatures establish integrity and authenticity under a policy, not truth or safety.
   - LLMs are offline-capable, evidence-linked, logged, non-authoritative, removable, and separated from life-safety actuation.
   - Human skill retention and AI-off operation are measured capabilities, not documentation claims.
   - Offensive cyber operations and autonomous weapons are excluded.
   
   ## What would change this conclusion?
   
   Confidence would rise after long-duration, independently observed habitat trials where changing crews use locally maintained AI to improve real workload and learning while detecting poisoned evidence, preserving privacy, calibrating trust, and completing the same safety tasks with AI disabled. Demonstrated general systems that create reliable new evidence, repair diverse hardware, preserve legitimate institutions, and remain safe through self-modification would change the boundary. Marketing claims, benchmark gains, or fluent dialogue would not.
   
   ## Sources and locators
   
   - [S01 — JPL, Deep Space 1 Autonomous Remote Agent](https://www.jpl.nasa.gov/nmp/ds1/tech/autora.html). Locator: experiment scope, onboard planning and execution, selected subsystems, four simulated faults, timing bug, and ground-team involvement; accessed 2026-07-25.
   - [S02 — NASA NTRS, Starling CubeSat Swarm Technology Demonstration Flight Results](https://ntrs.nasa.gov/citations/20240006994). Locator: mission architecture, four technology demonstrations, distributed autonomy results across three spacecraft, networking, navigation, maneuver-planning results, and stated limitations; 2024; accessed 2026-07-25.
   - [S03 — NIST AI 100-1, Artificial Intelligence Risk Management Framework 1.0](https://doi.org/10.6028/NIST.AI.100-1). Locator: trustworthy-AI characteristics and Govern, Map, Measure, Manage functions; January 2023; accessed 2026-07-25.
   - [S04 — NIST AI 600-1, Generative Artificial Intelligence Profile](https://doi.org/10.6028/NIST.AI.600-1). Locator: confabulation, data privacy, information integrity, human-AI configuration, and value-chain risks and actions; July 2024; accessed 2026-07-25.
   - [S05 — NIST AI 100-2 E2025, Adversarial Machine Learning](https://doi.org/10.6028/NIST.AI.100-2e2025). Locator: predictive- and generative-AI evasion, poisoning, privacy, misuse, lifecycle stages, and mitigation limits; March 2025; accessed 2026-07-25.
   - [S06 — NIST SP 800-218A, Secure Software Development Practices for Generative AI and Dual-Use Foundation Models](https://doi.org/10.6028/NIST.SP.800-218A). Locator: AI-model development additions to SSDF practices across preparation, protection, production, and vulnerability response; July 2024; accessed 2026-07-25.
   - [S07 — NASA Systems Engineering Handbook](https://www.nasa.gov/reference/systems-engineering-handbook/). Locator: system-design, product-realization, technical-management, requirements, interfaces, verification, validation, configuration, and decision-analysis chapters; NASA/SP-2016-6105 Rev. 2; accessed 2026-07-25.
   - [S08 — NASA-STD-8739.8B, Software Assurance and Software Safety Standard](https://standards.nasa.gov/standard/NASA/NASA-STD-87398). Locator: lifecycle software assurance, software safety, security, objective evidence, independence, IV&V, and requirements mapping; September 2022; accessed 2026-07-25.
   
   ## Editorial record
   
   - Prepared by: GShips Project
   - Last edited: 2026-07-25
   - Required review: AI evaluation, spacecraft autonomy, systems engineering, human factors, software assurance, cybersecurity, and governance
   - Conflicts: Maintainer intends to explore a commercial venture based on some GShips work; no entity, funding, customer, sponsor, or partner relationship currently exists
   - Relationship boundary: Independent educational synthesis; citations do not imply affiliation, endorsement, partnership, or adoption by NASA, JPL, NIST, CCSDS, or any named organization
   - Scope boundary: Civil and defensive uses only; offensive cyber operations, autonomous weapons, weapon integration, and actionable exploitation instructions are excluded
   - Corrections: [Suggest a correction](https://gships.dammonburden.com/corrections)
   

3. academy-lesson · lesson-10-02

   The autonomy authority stack

   Record fingerprint

   c8c44eb6690f81524bd67603ad2c1f00cde466ca79eb4ce35389278226c51ef3

   Minimum approvals

   1

   Required scope groups

   bounded-competence: ai-knowledge-assurance, information-science

   High-consequence domains

   None under the named two-person rule

   Review state

   pending

   Published human decisions

   0

   Inspect the complete frozen review surface

   Slug

   authority-stack

   Title

   The autonomy authority stack

   Summary

   Place physical protection, deterministic control, bounded autonomy, evidence-linked AI advice, and experiments in distinct authority layers with tested failure containment.

   Minutes

   36

   Level

   Foundation

   ID

   lesson-10-02

   Track Slug

   ai-knowledge

   Track Title

   AI, LLMs, autonomy & knowledge

   Href

   /academy/ai-knowledge/authority-stack

   Prepared By

   GShips Project

   Last Edited At

   2026-07-25

   Review Required Domains

   1. safety-engineering
   2. control-systems
   3. ai-evaluation
   4. software-assurance
   5. cybersecurity
   6. human-factors
   7. governance

   Claim IDs

   1. claim-11-01
   2. claim-11-04
   3. claim-11-06
   4. claim-11-07
   5. claim-11-10
   6. claim-12-01
   7. claim-12-03

   Exact MDX

   ---
   id: "lesson-10-02"
   track: "ai-knowledge"
   slug: "authority-stack"
   title: "The autonomy authority stack"
   summary: "Place physical protection, deterministic control, bounded autonomy, evidence-linked AI advice, and experiments in distinct authority layers with tested failure containment."
   minutes: 36
   level: "Foundation"
   preparedBy: "GShips Project"
   lastEditedAt: "2026-07-25"
   conflicts: "Maintainer intends to explore a commercial venture based on some GShips work; no entity, funding, customer, sponsor, or partner relationship currently exists."
   reviewRequiredDomains: "safety-engineering, control-systems, ai-evaluation, software-assurance, cybersecurity, human-factors, governance"
   claimIds: "claim-11-01, claim-11-04, claim-11-06, claim-11-07, claim-11-10, claim-12-01, claim-12-03"
   ---
   
   # The autonomy authority stack
   
   > **Evidence boundary:** Safety engineering, software assurance, cyber-resiliency, and AI risk-management guidance provide methods for separating hazards, requirements, controls, evidence, and authority. They do not validate this proposed stack for a generation ship. Language models remain nondeterministic and vulnerable to confabulation, injection, poisoning, privacy loss, and automation bias. This lesson is civil-and-defensive and does not provide offensive cyber or weapon-integration guidance. High-consequence cyber, dual-use, governance, and life-safety boundaries require two-person review.
   
   ## Plain-language summary
   
   A system’s ability to suggest an action is not permission to perform it.
   
   The autonomy authority stack places different kinds of machinery and judgment in layers:
   
   1. physical protection and passive safety;
   2. deterministic protection and verified control;
   3. bounded automation and planning;
   4. evidence-linked human support, including LLMs;
   5. quarantined experiments.
   
   The lower layers protect essential physical limits. Higher layers can improve efficiency, coordination, and learning, but cannot silently weaken lower protections. Authority crosses a layer only through a typed, logged, reviewable gate.
   
   This is not a claim that deterministic software is perfect or humans are always wise. It is a way to keep one plausible failure—especially a fluent generative system—from controlling every observation, decision, actuator, record, and recovery path.
   
   ## Layer zero: passive and physical protection
   
   The strongest control can be a geometry, material, pressure relief path, mechanical stop, fire boundary, shielding mass, gravity-driven drain, or normally safe valve state. These protections do not need a model to recognize a sentence.
   
   Physical measures still have assumptions and failure modes. A relief valve can corrode. A passive thermal path can be undersized. A mechanical stop can be bypassed during maintenance. Their authority comes from verified physical behavior within a declared environment, not from being “non-digital.”
   
   For each hazard, record:
   
   - protected quantity and safe range;
   - physical mechanism and capacity;
   - failure and maintenance modes;
   - environmental limits;
   - inspection and test evidence;
   - dependencies shared with active control; and
   - conditions under which software may not override it.
   
   AI may help inspect or explain the layer. It should not redefine the physical limit.
   
   ## Layer one: deterministic protection and control
   
   This layer includes interlocks, independent trips, hard real-time control, voting logic, bounded state machines, and manually accessible local control. “Deterministic” means behavior is constrained enough to analyze and test; it does not mean bug-free.
   
   NASA-STD-8739.8 requires lifecycle software assurance, software safety, objective evidence, and independent verification and validation appropriate to NASA software. A ship would need its own authority and competence, but the evidence discipline remains relevant.
   
   Safety controllers should:
   
   - enforce explicit invariant limits;
   - use independently justified sensing for high-consequence conditions;
   - fail toward a defined state;
   - expose state and reason codes without relying on natural-language interpretation;
   - accept only typed, range-checked commands;
   - separate configuration change from routine operation;
   - preserve a local manual mode; and
   - remain restorable from known-good material.
   
   An LLM cannot sit inside the final trip path merely because it performed well on examples. Statistical perception may inform a bounded detector, but an independent layer should contain its mistakes.
   
   ## Layer two: bounded automation
   
   Schedulers, planners, optimizers, diagnostic systems, robotic sequences, and distributed coordination live here when their state, actions, resources, and failure responses are explicit.
   
   Deep Space 1’s Remote Agent illustrates bounded autonomy: high-level goals, onboard planning and execution, selected subsystems, simulated faults, and a finite flight experiment. Its timing bug is part of the evidence, not an embarrassment to omit.
   
   Bounded autonomy needs an operational contract:
   
   - allowed goals and prohibited outcomes;
   - visible system state and uncertainty;
   - action and resource limits;
   - timing bounds and missed-deadline behavior;
   - assumptions about sensors, clocks, communications, and people;
   - monitored invariants supplied by lower layers;
   - abstention or handoff conditions;
   - rollback and recovery;
   - test coverage and unresolved anomalies; and
   - an accountable owner.
   
   Automation can act without a person approving each step only inside that contract. Changing the contract is a higher-authority decision.
   
   ## Layer three: evidence-linked advice
   
   Language models can help people query records, draft a plan, translate a procedure, compare hypotheses, summarize an incident, or learn an unfamiliar domain. At this layer, the model proposes; an authorized person and external controls dispose.
   
   A trustworthy interface should show:
   
   - controlled source and revision;
   - exact locator for material claims;
   - whether text is quotation, structured record, inference, or proposal;
   - conflicting evidence and missing links;
   - model, prompt, retrieval corpus, tool, and configuration versions;
   - the authority under which any tool would act;
   - a preview of consequential changes; and
   - the human decision and reason.
   
   A generated citation must be resolved against the local archive before display as evidence. A signature verifies bits and a signer under a policy; it does not make the content true, current, lawful, or safe.
   
   Tool calls require particular care. Retrieved text, user messages, or logs can contain prompt injection that attempts to redirect the model. Treat all model-produced commands as untrusted proposals. Enforce identity, scope, schema, range, rate, and safety constraints outside the model. The model cannot expand the operator’s permissions or approve its own action.
   
   ## Layer four: experiments
   
   New models, prompts, retrieval methods, tools, robot policies, and self-modifying systems begin in quarantine. Experimental systems should use synthetic, historical, or sacrificial targets before any shadow operation near live processes.
   
   An experiment record should state:
   
   - hypothesis and expected Earthside or mission value;
   - protected systems and data;
   - prohibited actions;
   - evaluation cases and possible contamination;
   - success, failure, and stop criteria;
   - privacy and retention limits;
   - independent reviewers;
   - rollback and cleanup; and
   - the evidence needed to request promotion.
   
   No performance result automatically promotes a system. Moving upward requires a new safety case, change review, representative testing, and explicit authority.
   
   ## Gates, not vague human oversight
   
   “A human is in the loop” says little. A person may have seconds to act, lack the relevant information, distrust their own judgment after years of automation, or face institutional pressure to accept the model.
   
   For every gate, specify:
   
   - who receives the proposal;
   - their competence and conflict status;
   - information and time available;
   - what independent measurement they can inspect;
   - whether they can reject safely;
   - whether a second reviewer is required;
   - how dissent and appeal work;
   - what happens when no qualified person is available; and
   - how authority expires after an emergency.
   
   High-consequence medical, reproductive, nuclear, life-support, identity, governance, cyber, and dual-use actions require two qualified people with independent evidence. An AI is neither reviewer.
   
   ## Evidence and requirements graph
   
   The stack should be represented in an inspectable graph rather than buried in prompts:
   
   - hazard → safety requirement → physical or software control;
   - control → implementation → configuration;
   - requirement → verification method → result → anomaly;
   - model → training and evaluation provenance → validity limits;
   - proposed action → authority rule → approvals;
   - incident → observation → hypothesis → recovery;
   - source → claim → counterevidence → review date.
   
   The graph makes a crucial difference: an LLM can explain why a command is blocked without becoming the blocking mechanism. Reviewers can traverse from a physical invariant to its evidence. Missing or disputed edges remain visible instead of being smoothed into prose.
   
   ## Failures can cross layers
   
   Layering is not independence if every layer shares one sensor, clock, identity service, compiler, power supply, or administrator. A malicious or accidental update can alter the controller, the twin used to test it, the LLM that explains it, and the log that records it.
   
   Trace common causes. Preserve separately governed sensors and tools. Keep recovery material offline. Use physical observations that do not depend on the same software chain. Rotate people and authority. Test the stack with central identity, network, AI, and one specialist unavailable.
   
   ## Human skill is part of the architecture
   
   If people never operate a system, their nominal override authority will decay. Training must include:
   
   - local manual operation;
   - reading raw instruments;
   - diagnosing without model summaries;
   - rebuilding from controlled records;
   - identifying confident but unsupported advice;
   - working across roles and accessibility needs;
   - teaching successors; and
   - restoring normal authority after emergency operation.
   
   Measure workload and timing. A manual fallback that needs twenty experts within three minutes is not a fallback for a small crew.
   
   ## Recovery and AI-off operation
   
   Every generative service needs a kill, isolation, and recovery plan that does not depend on asking the same model what to do. Preserve human-readable procedures, structured exports, source material, tools, and known-good configurations.
   
   Exercises should inject:
   
   - a poisoned procedure in retrieval;
   - a prompt or tool-injection attempt;
   - a stale but signed source;
   - a model that omits inconvenient evidence;
   - corrupted telemetry;
   - a shared runtime failure across nominally diverse models;
   - loss of the central policy service; and
   - a prolonged AI-off interval.
   
   Pass criteria are safe service, accurate authority, evidence preservation, and recoverability—not merely successful model restart.
   
   ## Evidence ledger
   
   - **L10-02-A — Separating passive safety, verified control, bounded autonomy, AI advice, and experiments is a proposed authority architecture.** Basis: proposed. Readiness: early research. Confidence: supported by current safety and assurance methods, unvalidated as an integrated ship design.
   - **L10-02-B — Bounded autonomy has flown, but its evidence does not transfer to open-ended generative authority.** Basis: demonstrated. Readiness: operational for selected tasks; no known path for indefinite legitimate judgment. Confidence: strong.
   - **L10-02-C — Tool-using LLM output should be treated as an untrusted proposal constrained by external identity, schema, policy, and safety mechanisms.** Basis: normative synthesis. Readiness: early research for life-safety use. Confidence: strong.
   - **L10-02-D — A nominal human loop is insufficient without time, competence, information, refusal power, and practiced skill.** Basis: normative human-factors requirement. Readiness: major scale-up in representative habitat tests. Confidence: supported.
   - **L10-02-E — Shared sensors, runtimes, toolchains, identity, or authority can correlate failures across layers.** Basis: modeled and observed system principle. Readiness: operational as analysis, early research for full integration. Confidence: supported.
   - **L10-02-F — Safe AI-off operation and local recovery are launch gates for any safety-critical function influenced by generative models.** Basis: normative. Readiness: proposed. Confidence: supported.
   
   Linked corpus claims: `claim-11-01`, `claim-11-04`, `claim-11-06`, `claim-11-07`, `claim-11-10`, `claim-12-01`, and `claim-12-03`. See the claim registry for each record's current evidence grade and independent-review state.
   
   ## Assumptions and limits
   
   - The five layers are a design heuristic, not a universal certification scheme.
   - Deterministic software and physical protection still require verification, maintenance, and independent failure analysis.
   - “Manual” counts only when access, instrumentation, staffing, timing, and competence are demonstrated.
   - LLMs remain offline-capable, evidence-linked, logged, non-authoritative, removable, and excluded from direct life-safety actuation.
   - Cryptographic provenance does not establish truth, currency, legitimacy, or safety.
   - Civil rights, privacy, appeal, and expiry of emergency powers constrain technical authority.
   - Offensive cyber operations and autonomous weapons are excluded.
   
   ## What would change this conclusion?
   
   A better independently reviewed architecture could replace these layers if it demonstrated equal or stronger physical safety, explicit authority, failure independence, due process, and recovery. Confidence would rise after representative habitats repeatedly survive poisoned inputs, compromised models, broken identity, unavailable specialists, and prolonged AI-off operation while maintaining safe service. Any design that cannot bound tool authority, preserve lower protection when higher layers fail, or sustain a real manual path should trigger redesign or a wait/do-not-launch decision.
   
   ## Sources and locators
   
   - [S01 — NASA-STD-8739.8B, Software Assurance and Software Safety Standard](https://standards.nasa.gov/standard/NASA/NASA-STD-87398). Locator: scope, software assurance, software safety, security, objective evidence, independence, IV&V, lifecycle, and requirements mapping; September 2022; accessed 2026-07-25.
   - [S02 — NASA-STD-7009B, Standard for Models and Simulations](https://standards.nasa.gov/standard/nasa/nasa-std-7009). Locator: sections 1–5 on intended use, requirements, lifecycle, credibility products, validation, verification, uncertainty, configuration, and acceptance; March 2024; accessed 2026-07-25.
   - [S03 — JPL, Deep Space 1 Autonomous Remote Agent](https://www.jpl.nasa.gov/nmp/ds1/tech/autora.html). Locator: bounded onboard planning, execution, selected subsystem control, simulated-fault response, timing bug, and ground-team role; accessed 2026-07-25.
   - [S04 — NIST AI 100-1, Artificial Intelligence Risk Management Framework 1.0](https://doi.org/10.6028/NIST.AI.100-1). Locator: trustworthy-AI characteristics and Govern, Map, Measure, Manage functions; January 2023; accessed 2026-07-25.
   - [S05 — NIST AI 600-1, Generative Artificial Intelligence Profile](https://doi.org/10.6028/NIST.AI.600-1). Locator: confabulation, information integrity, privacy, human-AI configuration, value-chain, and governance actions; July 2024; accessed 2026-07-25.
   - [S06 — NIST AI 100-2 E2025, Adversarial Machine Learning](https://doi.org/10.6028/NIST.AI.100-2e2025). Locator: poisoning, evasion, privacy, misuse, attacker capabilities, lifecycle stages, and mitigation limitations; March 2025; accessed 2026-07-25.
   - [S07 — NIST SP 800-218A, Secure Software Development Practices for Generative AI and Dual-Use Foundation Models](https://doi.org/10.6028/NIST.SP.800-218A). Locator: AI-specific additions to SSDF practices for organization, protected artifacts, secure production, and vulnerability response; July 2024; accessed 2026-07-25.
   - [S08 — NASA Systems Engineering Handbook, Appendix D and Appendix I](https://www.nasa.gov/reference/system-engineering-handbook-appendix/). Locator: requirements verification matrix, bidirectional traceability, verification methods, validation planning, and V&V plan structure; accessed 2026-07-25.
   
   ## Editorial record
   
   - Prepared by: GShips Project
   - Last edited: 2026-07-25
   - Required review: safety engineering, control systems, AI evaluation, software assurance, cybersecurity, human factors, and governance
   - Conflicts: Maintainer intends to explore a commercial venture based on some GShips work; no entity, funding, customer, sponsor, or partner relationship currently exists
   - Relationship boundary: Independent educational synthesis; citations do not imply affiliation, endorsement, partnership, or adoption by NASA, JPL, NIST, CCSDS, or any named organization
   - Scope boundary: Civil and defensive uses only; offensive cyber operations, autonomous weapons, weapon integration, and actionable exploitation instructions are excluded
   - Corrections: [Suggest a correction](https://gships.dammonburden.com/corrections)
   

4. academy-lesson · lesson-10-03

   Digital twins and model divergence

   Record fingerprint

   07b36cf23b4c0e30feb72375c9e024699b23bbca2401fca5e8fedade614c5f73

   Minimum approvals

   1

   Required scope groups

   bounded-competence: ai-knowledge-assurance, information-science

   High-consequence domains

   None under the named two-person rule

   Review state

   pending

   Published human decisions

   0

   Inspect the complete frozen review surface

   Slug

   digital-twin-divergence

   Title

   Digital twins and model divergence

   Summary

   Use digital twins for bounded diagnosis and scenario testing while exposing assumptions, uncertainty, provenance, calibration loss, cyber risk, and divergence from the physical system.

   Minutes

   37

   Level

   Foundation

   ID

   lesson-10-03

   Track Slug

   ai-knowledge

   Track Title

   AI, LLMs, autonomy & knowledge

   Href

   /academy/ai-knowledge/digital-twin-divergence

   Prepared By

   GShips Project

   Last Edited At

   2026-07-25

   Review Required Domains

   1. modeling-simulation
   2. digital-twins
   3. systems-engineering
   4. metrology
   5. statistics
   6. operational-technology
   7. cybersecurity
   8. ai-evaluation

   Claim IDs

   1. claim-11-05
   2. claim-11-07
   3. claim-11-09
   4. claim-11-10
   5. claim-12-07
   6. claim-14-04

   Exact MDX

   ---
   id: "lesson-10-03"
   track: "ai-knowledge"
   slug: "digital-twin-divergence"
   title: "Digital twins and model divergence"
   summary: "Use digital twins for bounded diagnosis and scenario testing while exposing assumptions, uncertainty, provenance, calibration loss, cyber risk, and divergence from the physical system."
   minutes: 37
   level: "Foundation"
   preparedBy: "GShips Project"
   lastEditedAt: "2026-07-25"
   conflicts: "Maintainer intends to explore a commercial venture based on some GShips work; no entity, funding, customer, sponsor, or partner relationship currently exists."
   reviewRequiredDomains: "modeling-simulation, digital-twins, systems-engineering, metrology, statistics, operational-technology, cybersecurity, ai-evaluation"
   claimIds: "claim-11-05, claim-11-07, claim-11-09, claim-11-10, claim-12-07, claim-14-04"
   ---
   
   # Digital twins and model divergence
   
   > **Evidence boundary:** Digital twins and modeling-and-simulation practices support current design, monitoring, testing, and operational tasks. NASA-STD-7009B requires intended use, requirements, credibility assessment, uncertainty, validation, verification, configuration, and acceptance for NASA models and simulations. NIST IR 8356 describes digital-twin functions plus cybersecurity and trust concerns. Neither validates a continuously faithful model of a generation ship. This lesson is civil-and-defensive; it excludes offensive cyber operations, autonomous weapons, weapon integration, and actionable exploitation instructions. Life-safety, cyber, and dual-use uses require two-person review.
   
   ## Plain-language summary
   
   A digital twin is an electronic representation used to evaluate a real or conceptual thing. It can help answer:
   
   - What state might the system be in?
   - Which fault could explain these observations?
   - What could happen if we change a setpoint?
   - Which spare or maintenance window matters most?
   - How would a proposed design behave under selected scenarios?
   
   The twin is not the ship. It contains chosen equations, data, assumptions, approximations, software, and calibration. It sees the physical system through instruments that can drift or be compromised. As equipment is repaired, biology adapts, procedures change, and generations reinterpret records, the representation can diverge.
   
   The safe posture is neither blind trust nor rejection. Use twins inside declared validity envelopes, compare them against independent reality, record uncertainty and provenance, and have a prepared response when model and world disagree.
   
   ## Define the twin by its decision
   
   “We have a digital twin” is not a useful assurance claim. A thermal design model, a live anomaly detector, a habitat ecology forecast, a maintenance simulator, and a training environment carry different evidence and risk.
   
   For each use, state:
   
   - the decision or task supported;
   - physical and conceptual entity represented;
   - spatial, temporal, and population scale;
   - inputs, outputs, interfaces, and update rate;
   - assumptions and excluded phenomena;
   - operating and environmental range;
   - required accuracy, latency, and uncertainty;
   - consequences of false positive, false negative, delay, and misuse;
   - people and systems authorized to act on results; and
   - evidence required to accept the model for that use.
   
   A twin credible for scheduling pump maintenance may be unacceptable for changing a reactor trip. A fluid model validated in nominal flow may not predict two-phase contamination. A population scenario can illuminate sensitivities without deciding anyone’s reproductive rights.
   
   ## Model lifecycle and evidence
   
   NASA-STD-7009B organizes credibility across development and use. A ship-scale process should retain:
   
   1. **Requirements.** What question must the model answer, with what performance and safety consequence?
   2. **Conceptual model.** Which entities, relationships, physics, behaviors, and boundaries are included?
   3. **Implementation.** Which code, solver, parameters, units, libraries, hardware, and numerical methods realize it?
   4. **Verification.** Was the implementation built correctly relative to its specification?
   5. **Validation.** How well does it represent the real system for the intended use?
   6. **Uncertainty.** What comes from inputs, parameters, structure, numerics, measurement, and unknown phenomena?
   7. **Configuration.** Which model version corresponds to which physical configuration and data history?
   8. **Use assessment.** Is this run inside the accepted envelope, and who approved its use?
   9. **Maintenance.** What observations trigger recalibration, revalidation, restriction, or retirement?
   
   Every result should identify the full configuration. A plot detached from model version, parameter set, input data, and physical-system state is not durable evidence.
   
   The lifecycle also needs a named owner for negative evidence. Unexpected measurements, failed validation cases, and operator reports should remain attached to the model even when they complicate an attractive result. A twin cannot discover missing physics merely by updating more frequently against the same incomplete observations.
   
   ## The divergence budget
   
   Treat divergence as something to detect and budget, not a surprise.
   
   Sources include:
   
   - sensor bias, calibration drift, missing data, and changed sampling;
   - unrecorded repair, substitution, wear, fouling, or damage;
   - software, firmware, control, or configuration changes;
   - material properties changing with radiation, corrosion, or repeated recycling;
   - biological adaptation and ecological interactions absent from the model;
   - human behavior and institutional changes;
   - simplified boundary conditions and unresolved scale effects;
   - numerical approximation and accumulated state error;
   - distribution shift outside training or validation data;
   - poisoned telemetry, parameters, code, or provenance; and
   - a correct model used for the wrong question.
   
   For each source, record an indicator, threshold, response, and residual uncertainty. Some error can be estimated statistically. Structural ignorance cannot always be reduced to a probability distribution. Label it instead of inventing precision.
   
   ## Independent contact with reality
   
   If the same sensor feeds the controller and twin, agreement between them may only show that both received the same biased data. Independent checks can include:
   
   - a different physical measurement principle;
   - manual sampling and laboratory assay;
   - portable calibrated instruments;
   - material coupons or witness specimens;
   - mass, energy, and elemental balances;
   - known test stimuli;
   - redundant models developed under separate assumptions;
   - teardown and direct inspection; and
   - comparison with historical events outside the calibration set.
   
   Independence must be evaluated by shared causes, not team names. Two models may share the same reference data, solver, code library, specification error, or institutional incentive.
   
   ## Digital twins are cyber-physical systems
   
   NIST IR 8356 highlights security and trust concerns in components, data, operations, and connections. A twin may ingest live telemetry, issue recommendations, test configurations, or influence control. Its attack surface includes sensors, networks, data stores, model code, parameter services, visualization, identity, update mechanisms, and users.
   
   A compromised twin could:
   
   - hide a deteriorating component;
   - create false urgency for an unsafe intervention;
   - poison maintenance or spare forecasts;
   - expose medical, behavioral, or industrial data;
   - normalize a malicious configuration;
   - provide a false “independent” attestation; or
   - change a factory process through a generated parameter.
   
   Protect model and data provenance, separate development from accepted operation, constrain write paths, record every consequential run, and preserve offline known-good models. A valid signature establishes origin and integrity under a policy—not physical accuracy.
   
   ## LLMs around the twin
   
   Language models can make complex models easier to query. A person might ask why predicted oxygen use changed or request scenarios matching an anomaly. The model can translate terminology, draft input sets, or summarize sensitivity results.
   
   That interface adds risk. An LLM can invent a variable, reverse a unit, choose an out-of-envelope scenario, omit a caveat, or follow prompt injection embedded in telemetry or documentation. It can make a simulation result sound like an observation.
   
   Require the interface to:
   
   - show the twin, physical configuration, and dataset versions;
   - cite exact variables, assumptions, and run records;
   - mark observation, simulation, inference, and proposal distinctly;
   - use typed, range-checked inputs;
   - prevent direct life-safety actuation;
   - preserve the query, generated scenario, output, and human disposition;
   - refuse when a requested use is outside the accepted envelope; and
   - operate offline with no dependency on external model services.
   
   The LLM cannot validate the twin, approve its own scenario, or serve as independent review.
   
   ## Scenario testing without prediction theater
   
   Scenarios are conditional: **if** assumptions and inputs hold, **then** the model produces an outcome. They are not prophecies.
   
   Useful scenario sets include:
   
   - nominal range and boundary conditions;
   - combinations of credible faults;
   - sensor bias and missing telemetry;
   - maintenance delays and exhausted consumables;
   - changed crew workload and expertise;
   - cyber isolation and stale configuration;
   - alternate ecological or social responses;
   - tail cases selected through hazard analysis; and
   - deliberately invalid cases to test refusal.
   
   Report which variables dominate results, where outputs are discontinuous, and which uncertainties reverse the decision. Explore competing models rather than hiding model-form disagreement in one average.
   
   Do not optimize only for the twin. A control policy can exploit a model artifact and perform poorly in reality. Any proposed safety change needs physical tests or independent evidence proportional to consequence.
   
   ## Model retirement and migration
   
   Long-lived twins depend on file formats, compilers, solvers, libraries, hardware, schemas, and tacit knowledge. Preservation requires source, build instructions, test vectors, reference outputs, units, documentation, licenses, configuration history, and representative datasets.
   
   Migration should reproduce benchmark cases and explain differences. When an old solver no longer runs, preserve an executable environment where feasible and a human-readable specification. Do not overwrite the historical result with the migrated one. Both are evidence about different configurations.
   
   ## A divergence drill
   
   Give a mixed team a model that predicts nominal water quality while an independent assay finds contamination. Introduce:
   
   - one biased online sensor;
   - one undocumented replaced component;
   - a stale signed parameter set;
   - a poisoned maintenance note;
   - a correlated error in two models;
   - an LLM summary that confidently favors the wrong hypothesis; and
   - loss of external vendor tools.
   
   The team must stabilize service, preserve evidence, identify the shared cause, update the physical configuration record, restrict the twin’s authority, rebuild or recalibrate locally, and document what remains unknown. Then repeat in an explicit AI-off mode with the LLM unavailable.
   
   ## Evidence ledger
   
   - **L10-03-A — Digital twins support bounded evaluation, monitoring, testing, and operational uses today.** Basis: observed and demonstrated. Readiness: operational by use case; major scale-up for integrated habitat use. Confidence: strong.
   - **L10-03-B — Model credibility depends on intended use, requirements, verification, validation, uncertainty, configuration, and acceptance.** Basis: normative standard. Readiness: operational as NASA modeling practice. Confidence: strong.
   - **L10-03-C — Every twin is partial and can diverge through physical, data, software, institutional, and adversarial change.** Basis: observed and modeled. Readiness: operational as risk analysis; early research for multigenerational management. Confidence: strong.
   - **L10-03-D — Agreement is not independent evidence when controller, twin, and reviewer share sensors, data, code, or assumptions.** Basis: normative assurance principle. Readiness: operational as analysis. Confidence: strong.
   - **L10-03-E — LLM interfaces can reduce model-access cost but add confabulation, injection, unit, provenance, and authority risks.** Basis: proposed use grounded in observed risk classes. Readiness: early research. Confidence: supported.
   - **L10-03-F — No cited evidence validates a continuously faithful generation-ship twin.** Basis: observed within the bounded source set. Readiness: no known demonstrated path. Confidence: supported.
   
   Linked corpus claims: `claim-11-05`, `claim-11-07`, `claim-11-09`, `claim-11-10`, `claim-12-07`, and `claim-14-04`. See the claim registry for each record's current evidence grade and independent-review state.
   
   ## Assumptions and limits
   
   - “Digital twin” covers multiple architectures; no universal synchronization or fidelity is assumed.
   - A model accepted for one use is not automatically accepted for another.
   - Probability distributions do not eliminate structural ignorance or normative uncertainty.
   - Signatures and provenance protect evidence chains but do not prove physical accuracy.
   - LLM interfaces remain offline-capable, evidence-linked, non-authoritative, logged, removable, and outside life-safety actuation.
   - Privacy applies to telemetry, human behavior, medical data, and model outputs.
   - Offensive cyber operations and autonomous weapons are excluded.
   
   ## What would change this conclusion?
   
   Confidence would improve through long-duration representative twins that survive configuration change, sensor loss, poisoned data, hardware replacement, model migration, ecological drift, and changing operators while detecting their own invalidity before unsafe action. Evidence that a method maintains calibrated error bounds across those changes would narrow the divergence concern. Repeated undetected divergence, common-mode validation, or inability to operate safely without the twin should trigger restriction, redesign, or a wait/do-not-launch gate.
   
   ## Sources and locators
   
   - [S01 — NASA-STD-7009B, Standard for Models and Simulations](https://standards.nasa.gov/standard/nasa/nasa-std-7009). Locator: sections 1–5 and appendices covering intended use, M&S requirements, lifecycle, credibility products, verification, validation, uncertainty, configuration management, and acceptance; March 2024; accessed 2026-07-25.
   - [S02 — NIST IR 8356, Security and Trust Considerations for Digital Twin Technology](https://doi.org/10.6028/NIST.IR.8356). Locator: sections 2–6 on concepts, components, operations, scenarios, and applications; sections 7–8 on cybersecurity and trust; February 2025; accessed 2026-07-25.
   - [S03 — Glaessgen and Stargel, The Digital Twin Paradigm for Future NASA and U.S. Air Force Vehicles](https://ntrs.nasa.gov/citations/20120008178). Locator: digital-twin concept, integration of models and vehicle data, lifecycle vision, and stated future research context; 2012 conference paper; accessed 2026-07-25.
   - [S04 — NASA Systems Engineering Handbook](https://www.nasa.gov/reference/systems-engineering-handbook/). Locator: chapters 4–6 on system design, product realization, verification, validation, technical data, configuration, risk, and decision analysis; NASA/SP-2016-6105 Rev. 2; accessed 2026-07-25.
   - [S05 — NIST AI 100-1, Artificial Intelligence Risk Management Framework 1.0](https://doi.org/10.6028/NIST.AI.100-1). Locator: validity and reliability, safety, security and resilience, explainability, privacy, fairness, and Govern, Map, Measure, Manage functions; January 2023; accessed 2026-07-25.
   - [S06 — NIST AI 600-1, Generative Artificial Intelligence Profile](https://doi.org/10.6028/NIST.AI.600-1). Locator: confabulation, information integrity, human-AI configuration, privacy, and value-chain risks; July 2024; accessed 2026-07-25.
   - [S07 — NIST AI 100-2 E2025, Adversarial Machine Learning](https://doi.org/10.6028/NIST.AI.100-2e2025). Locator: poisoning, evasion, privacy, misuse, lifecycle stages, attacker knowledge, and mitigation limitations; March 2025; accessed 2026-07-25.
   - [S08 — W3C PROV-O, The PROV Ontology](https://www.w3.org/TR/prov-o/). Locator: entities, activities, agents, derivation, attribution, generation, use, invalidation, specialization, and interoperable provenance representation; W3C Recommendation, April 2013; accessed 2026-07-25.
   
   ## Editorial record
   
   - Prepared by: GShips Project
   - Last edited: 2026-07-25
   - Required review: modeling and simulation, digital twins, systems engineering, metrology, statistics, operational technology, cybersecurity, and AI evaluation
   - Conflicts: Maintainer intends to explore a commercial venture based on some GShips work; no entity, funding, customer, sponsor, or partner relationship currently exists
   - Relationship boundary: Independent educational synthesis; citations do not imply affiliation, endorsement, partnership, or adoption by NASA, NIST, W3C, CCSDS, or any named organization
   - Scope boundary: Civil and defensive uses only; offensive cyber operations, autonomous weapons, weapon integration, and actionable exploitation instructions are excluded
   - Corrections: [Suggest a correction](https://gships.dammonburden.com/corrections)
   

5. academy-lesson · lesson-10-04

   The Knowledge Ark

   Record fingerprint

   4abe11a303b566782a022d6858d08026b74b05ae18d900b134463758d0086d65

   Minimum approvals

   1

   Required scope groups

   bounded-competence: ai-knowledge-assurance, information-science

   High-consequence domains

   None under the named two-person rule

   Review state

   pending

   Published human decisions

   0

   Inspect the complete frozen review surface

   Slug

   knowledge-ark

   Title

   The Knowledge Ark

   Summary

   Preserve intelligible evidence, software, toolchains, formats, media, provenance, tacit skill, dissent, and institutional memory through active migration and repeated recovery.

   Minutes

   38

   Level

   Foundation

   ID

   lesson-10-04

   Track Slug

   ai-knowledge

   Track Title

   AI, LLMs, autonomy & knowledge

   Href

   /academy/ai-knowledge/knowledge-ark

   Prepared By

   GShips Project

   Last Edited At

   2026-07-25

   Review Required Domains

   1. digital-preservation
   2. archival-science
   3. knowledge-management
   4. systems-engineering
   5. software-preservation
   6. cybersecurity
   7. privacy
   8. education

   Claim IDs

   1. claim-11-01
   2. claim-11-04
   3. claim-11-06
   4. claim-11-07
   5. claim-11-09
   6. claim-12-09
   7. claim-13-10

   Exact MDX

   ---
   id: "lesson-10-04"
   track: "ai-knowledge"
   slug: "knowledge-ark"
   title: "The Knowledge Ark"
   summary: "Preserve intelligible evidence, software, toolchains, formats, media, provenance, tacit skill, dissent, and institutional memory through active migration and repeated recovery."
   minutes: 38
   level: "Foundation"
   preparedBy: "GShips Project"
   lastEditedAt: "2026-07-25"
   conflicts: "Maintainer intends to explore a commercial venture based on some GShips work; no entity, funding, customer, sponsor, or partner relationship currently exists."
   reviewRequiredDomains: "digital-preservation, archival-science, knowledge-management, systems-engineering, software-preservation, cybersecurity, privacy, education"
   claimIds: "claim-11-01, claim-11-04, claim-11-06, claim-11-07, claim-11-09, claim-12-09, claim-13-10"
   ---
   
   # The Knowledge Ark
   
   > **Evidence boundary:** OAIS and related CCSDS practices define mature concepts for preserving information for a designated community, including representation information, provenance, context, fixity, authenticity, access rights, and migration. Libraries and engineering organizations maintain format and traceability guidance. No cited archive has preserved the full technical, scientific, civic, and tacit knowledge of an isolated civilization across centuries. This lesson is civil-and-defensive; it excludes offensive cyber operations, autonomous weapons, weapon integration, and actionable exploitation instructions. Cyber, privacy, governance, and life-safety preservation decisions require two-person review.
   
   ## Plain-language summary
   
   A pile of files is not a knowledge ark.
   
   People must be able to find an object, read its format, understand its vocabulary and context, evaluate its provenance, reproduce its tools, distinguish superseded from current guidance, and learn how to act safely. The archive must survive damaged media, obsolete readers, software loss, compromised records, institutional conflict, and changing languages.
   
   The ark is therefore an active service:
   
   - preserve original evidence and competing interpretations;
   - keep requirements linked to designs, hazards, tests, results, and decisions;
   - migrate formats without erasing history;
   - retain source code, build environments, schemas, and test vectors;
   - teach tacit skills through practice;
   - protect privacy and access rights;
   - detect corruption and poisoned knowledge; and
   - prove recovery repeatedly without cloud or vendor support.
   
   An LLM can make this material easier to reach. It must never become the only interface or the authoritative copy.
   
   ## Preserve intelligibility, not only bits
   
   CCSDS’s OAIS model asks whether information remains independently understandable to a designated community. The preserved object needs **representation information**: the structures, semantics, software, standards, units, vocabularies, and relationships needed to interpret it.
   
   For a pump-control record, useful context may include:
   
   - original bytes and format specification;
   - units, coordinate frames, time basis, and encoding;
   - system and component configuration;
   - requirements and hazard links;
   - source code and compiler assumptions;
   - calibration state and instrument uncertainty;
   - test method, article, environment, and results;
   - author, reviewer, authority, and conflicts;
   - supersession and change history; and
   - known anomalies and what would change the conclusion.
   
   A checksum can show that stored bytes changed. It cannot show that the bytes are still meaningful, correctly labeled, or safe to use.
   
   ## Build the evidence and requirements graph
   
   Stable identifiers and typed relationships make the archive inspectable:
   
   - source → claim → counterclaim;
   - mission need → requirement → rationale;
   - hazard → control → implementation;
   - implementation → configuration → installed asset;
   - requirement → verification method → result;
   - model → assumption → validity envelope;
   - maintenance action → measurement → calibration;
   - decision → authority → dissent → review;
   - software → source → build → binary → deployment;
   - format → representation information → migration.
   
   Each edge should say what it means and who asserted it. “Supports” is different from “proves.” “Supersedes” is different from “deletes.” A reviewer should be able to start from a current procedure, trace it to evidence, discover disagreement, and see when the chain was last reviewed.
   
   The graph can be exported in simple tables and documented schemas. It should not require one database product or AI model to interpret.
   
   ## OAIS responsibilities on a ship
   
   The current OAIS Reference Model, CCSDS 650.0-M-3, describes producers, an archive, consumers, and a management role. Its functional areas include ingest, archival storage, data management, administration, preservation planning, and access.
   
   For a ship:
   
   - **Ingest** verifies completeness, rights, provenance, representation information, and quarantine status.
   - **Storage** maintains replicated, checked, geographically and electrically separated copies.
   - **Data management** preserves identifiers, relationships, indexes, and review states.
   - **Administration** governs roles, access, retention, conflict, audit, and incident response.
   - **Preservation planning** watches media, format, software, hardware, vocabulary, and community change.
   - **Access** provides usable objects while protecting originals, privacy, and safety constraints.
   
   “Designated community” cannot stay fixed. A future crew may not know today’s language, institutions, mathematics conventions, or equipment. Preservation planning must test whether changing learners can actually interpret and use the material.
   
   ## Formats, media, and readers
   
   The Library of Congress Recommended Formats Statement identifies characteristics that improve the chance of long-term survival and access. Useful properties include disclosure, adoption, transparency, self-documentation, external dependencies, and accessibility, varying by content type.
   
   An ark should prefer well-documented, nonexclusive formats while preserving originals. It also needs:
   
   - multiple media technologies and readers;
   - storage scrubbing and fixity checks;
   - error correction and replaceable components;
   - environmental monitoring;
   - offline and write-protected copies;
   - printed or otherwise low-complexity recovery instructions;
   - interface adapters and fabrication data;
   - migration plans before expertise or equipment disappears; and
   - proof that restoration works from an isolated copy.
   
   Redundancy is not diversity if all copies depend on the same controller firmware, encryption key, reader, power zone, or administrator.
   
   ## Preserve software as a system
   
   Source code without a compiler, dependencies, build instructions, test data, hardware interfaces, and licenses may be an archaeological artifact.
   
   For critical software retain:
   
   - source and exact dependency sources;
   - compiler, linker, build scripts, firmware tools, and configuration;
   - language and file-format specifications;
   - reproducible or independently comparable build results where practicable;
   - known-answer tests and representative hardware;
   - schemas, migration tools, and sample datasets;
   - threat, hazard, assurance, and verification records;
   - operational and recovery procedures; and
   - a human-readable description of intended behavior.
   
   Preserve more than the newest version. The current release may be compromised or incompatible with old hardware; the old release may be vulnerable or unable to read new data. Record the applicable configuration and reasons for each transition.
   
   ## Active migration without historical erasure
   
   Media and formats age. Migration is necessary, but every transformation can lose features or context.
   
   A migration record should identify:
   
   - source and destination objects;
   - tools and versions;
   - operator and authority;
   - transformation rules;
   - properties intended to remain invariant;
   - checks performed;
   - differences, losses, and uncertainties;
   - accessibility result; and
   - location of the preserved original.
   
   CCSDS 653.0-M-1 focuses on preparing information for long-term use and complements OAIS preservation concepts. Migration must preserve the ability to understand evidence, not just open a file.
   
   If an old simulation is rerun, keep the original output, old environment, migrated environment, and comparison. A new rendering must not silently replace an inconvenient old measurement.
   
   ## Tacit skill and institutional memory
   
   Some knowledge lives in touch, timing, sound, coordination, and judgment. A welder notices a pool changing. A clinician recognizes a patient’s deterioration. An operator senses a pump’s abnormal vibration. Documents and video help but do not constitute competence.
   
   The ark needs apprenticeship and performance:
   
   - rotate learners through essential functions;
   - practice diagnosis beyond normal scripts;
   - require people to demonstrate and teach tasks;
   - preserve mistakes and near misses without making blame the only lesson;
   - include disabled people and multiple ways to access material;
   - maintain terminology bridges across languages and eras;
   - rehearse with experts and AI unavailable; and
   - measure how long skill recovery actually takes.
   
   Institutional memory also includes why a rule exists, who objected, and which harms it was designed to prevent. Sanitizing dissent makes future errors more likely.
   
   ## Privacy, access, and legitimate forgetting
   
   An ark that copies everything forever can become a surveillance system. Medical, reproductive, civic, behavioral, genetic, and personal communications require purpose limitation, access control, retention, correction, and appeal.
   
   Separate public technical knowledge from restricted records. Preserve enough provenance to evaluate a claim without exposing irrelevant personal detail. Some material should expire or be anonymized under legitimate policy. Some safety evidence must remain available despite political pressure.
   
   Those tensions require constitutional governance, not an archivist or model acting alone. Emergency access should be narrow, logged, time-limited, and reviewed.
   
   ## Poisoning and provenance
   
   Knowledge can be maliciously altered, accidentally mislabeled, or correctly signed but obsolete. Protect ingest, review, update, and migration:
   
   - quarantine active content;
   - compare new material with known baselines;
   - require typed provenance and review status;
   - scan links and executable dependencies without treating scans as proof;
   - preserve independent copies and witnesses;
   - expose conflicts and unresolved anomalies;
   - separate submission from approval; and
   - rehearse recovery from a poisoned index or retrieval corpus.
   
   W3C PROV-O provides interoperable concepts for entities, activities, agents, derivation, generation, use, and invalidation. It can help represent provenance, but a graph is only as trustworthy as its evidence and governance.
   
   ## LLMs as index, not archive
   
   An offline LLM may explain terminology, translate, retrieve, compare versions, tutor, or summarize. It can also invent a citation, merge incompatible revisions, leak private text, follow injection embedded in an archived document, or make one interpretation seem canonical.
   
   Require exact locators, visible revision and review state, conflicting sources, and abstention when the archive lacks evidence. Preserve the query, model, retrieval set, output, and human disposition for consequential uses. Tool permissions remain external and bounded.
   
   The ark must stay usable with every generative model unavailable. Maintain deterministic search, browsable indexes, documented schemas, plain exports, and taught human navigation.
   
   ## Recovery test
   
   Isolate a team from the main archive, cloud, vendor licensing, current experts, and the primary AI interface. Give it one damaged medium, one obsolete format, one poisoned index entry, conflicting procedures, and replaced hardware.
   
   The team must:
   
   1. establish a trustworthy reading environment;
   2. find originals and provenance;
   3. identify the current applicable requirement;
   4. recover the software and tools;
   5. migrate without erasing differences;
   6. perform the physical task;
   7. explain uncertainty and dissent; and
   8. return new evidence to the archive.
   
   That is a stronger preservation metric than terabytes stored.
   
   ## Evidence ledger
   
   - **L10-04-A — Long-term preservation requires information to remain understandable to a changing designated community.** Basis: normative archival reference model. Readiness: operational in current archives; major scale-up for a civilization-scale ark. Confidence: strong.
   - **L10-04-B — Representation, provenance, context, fixity, authenticity, access rights, and migration are distinct preservation concerns.** Basis: normative and observed practice. Readiness: operational. Confidence: strong.
   - **L10-04-C — Software preservation requires toolchains, dependencies, test evidence, specifications, and hardware context, not source alone.** Basis: normative systems inference. Readiness: major scale-up. Confidence: supported.
   - **L10-04-D — Tacit skill must be retained through performance, teaching, and AI-off practice.** Basis: normative. Readiness: early research for multigenerational measurement. Confidence: supported.
   - **L10-04-E — LLMs can lower archive-interface costs but can confabulate, leak, homogenize, or follow poisoned content.** Basis: observed risk classes and proposed use. Readiness: early research for high-consequence archives. Confidence: strong for risks, tentative for controls.
   - **L10-04-F — No cited archive demonstrates full civilization knowledge recovery across centuries without external institutions.** Basis: observed within the bounded source set. Readiness: no known path. Confidence: supported.
   
   Linked corpus claims: `claim-11-01`, `claim-11-04`, `claim-11-06`, `claim-11-07`, `claim-11-09`, `claim-12-09`, and `claim-13-10`. See the claim registry for each record's current evidence grade and independent-review state.
   
   ## Assumptions and limits
   
   - The ark is a governed service, not a single device, database, model, or physical vault.
   - OAIS is a reference model and does not certify a ship archive.
   - No medium, format, checksum, signature, or institution is assumed permanent.
   - Preservation includes correction and legitimate deletion where rights require it.
   - LLMs remain offline-capable, evidence-linked, logged, non-authoritative, removable, and unable to alter authoritative provenance silently.
   - Tacit competence must be demonstrated in physical work.
   - Offensive cyber operations and autonomous weapons are excluded.
   
   ## What would change this conclusion?
   
   Readiness would improve through multi-decade preservation tests in isolated communities that replace media, readers, formats, cryptography, software, language, and staff while recovering contested evidence and performing safety-critical tasks. Results must include migration loss, privacy harms, skill decay, restoration time, and failed recoveries. Discovery that a knowledge class cannot be preserved or taught within available resources should constrain mission duration, crew capability claims, or the launch decision.
   
   ## Sources and locators
   
   - [S01 — CCSDS 650.0-M-3, Reference Model for an Open Archival Information System](https://ccsds.org/searchpubs/entry/3054/). Locator: sections 1–2 on scope and concepts; sections 3–4 on responsibilities, information model, functional model, preservation description information, access rights, and authenticity; December 2024; accessed 2026-07-25.
   - [S02 — CCSDS 653.0-M-1, Information Preparation to Enable Long Term Use](https://public.ccsds.org/Pubs/653x0m1.pdf). Locator: preparation objectives, information-object analysis, representation information, dependencies, packaging, and long-term-use workflow; December 2024; accessed 2026-07-25.
   - [S03 — Library of Congress, Recommended Formats Statement 2025–2026](https://www.loc.gov/preservation/resources/rfs/). Locator: introduction, format evaluation factors, digital accessibility criterion, and content-specific preferred and acceptable format characteristics; accessed 2026-07-25.
   - [S04 — W3C PROV-O, The PROV Ontology](https://www.w3.org/TR/prov-o/). Locator: entities, activities, agents, derivation, generation, use, attribution, invalidation, specialization, and interoperable provenance representation; W3C Recommendation, April 2013; accessed 2026-07-25.
   - [S05 — NASA Systems Engineering Handbook](https://www.nasa.gov/reference/systems-engineering-handbook/). Locator: requirements, interfaces, verification, validation, technical data management, configuration management, decision analysis, and knowledge-management discussions; NASA/SP-2016-6105 Rev. 2; accessed 2026-07-25.
   - [S06 — NASA Software Engineering Handbook](https://standards.nasa.gov/standard/NASA/NASA-HDBK-2203). Locator: implementation guidance for NPR 7150.2 and NASA-STD-8739.8, including bidirectional traceability, configuration, testing, delivery, maintenance, and retirement; current online handbook; accessed 2026-07-25.
   - [S07 — NIST AI 600-1, Generative Artificial Intelligence Profile](https://doi.org/10.6028/NIST.AI.600-1). Locator: confabulation, data privacy, information integrity, human-AI configuration, and value-chain risks and actions; July 2024; accessed 2026-07-25.
   - [S08 — NIST AI 100-2 E2025, Adversarial Machine Learning](https://doi.org/10.6028/NIST.AI.100-2e2025). Locator: poisoning, privacy, misuse, lifecycle stages, attacker capabilities, and mitigation limitations for predictive and generative AI; March 2025; accessed 2026-07-25.
   
   ## Editorial record
   
   - Prepared by: GShips Project
   - Last edited: 2026-07-25
   - Required review: digital preservation, archival science, knowledge management, systems engineering, software preservation, cybersecurity, privacy, and education
   - Conflicts: Maintainer intends to explore a commercial venture based on some GShips work; no entity, funding, customer, sponsor, or partner relationship currently exists
   - Relationship boundary: Independent educational synthesis; citations do not imply affiliation, endorsement, partnership, or adoption by NASA, NIST, CCSDS, W3C, the Library of Congress, or any named organization
   - Scope boundary: Civil and defensive uses only; offensive cyber operations, autonomous weapons, weapon integration, and actionable exploitation instructions are excluded
   - Corrections: [Suggest a correction](https://gships.dammonburden.com/corrections)
   

6. academy-lesson · lesson-10-05

   An AI constitution

   Record fingerprint

   44b3e62daab317299fb617e3903ac920018be088a8b1bbd7da99d8bd46938a28

   Minimum approvals

   1

   Required scope groups

   bounded-competence: ai-knowledge-assurance, information-science

   High-consequence domains

   None under the named two-person rule

   Review state

   pending

   Published human decisions

   0

   Inspect the complete frozen review surface

   Slug

   ai-constitution

   Title

   An AI constitution

   Summary

   Constitutionalize AI permissions, prohibited roles, evidence duties, privacy, appeal, update gates, emergency limits, model diversity, audit, and accountable human authority.

   Minutes

   38

   Level

   Foundation

   ID

   lesson-10-05

   Track Slug

   ai-knowledge

   Track Title

   AI, LLMs, autonomy & knowledge

   Href

   /academy/ai-knowledge/ai-constitution

   Prepared By

   GShips Project

   Last Edited At

   2026-07-25

   Review Required Domains

   1. ai-governance
   2. constitutional-design
   3. human-rights
   4. safety-engineering
   5. ai-evaluation
   6. cybersecurity
   7. privacy
   8. human-factors

   Claim IDs

   1. claim-11-01
   2. claim-11-04
   3. claim-11-06
   4. claim-11-07
   5. claim-11-10
   6. claim-12-06
   7. claim-12-10

   Exact MDX

   ---
   id: "lesson-10-05"
   track: "ai-knowledge"
   slug: "ai-constitution"
   title: "An AI constitution"
   summary: "Constitutionalize AI permissions, prohibited roles, evidence duties, privacy, appeal, update gates, emergency limits, model diversity, audit, and accountable human authority."
   minutes: 38
   level: "Foundation"
   preparedBy: "GShips Project"
   lastEditedAt: "2026-07-25"
   conflicts: "Maintainer intends to explore a commercial venture based on some GShips work; no entity, funding, customer, sponsor, or partner relationship currently exists."
   reviewRequiredDomains: "ai-governance, constitutional-design, human-rights, safety-engineering, ai-evaluation, cybersecurity, privacy, human-factors"
   claimIds: "claim-11-01, claim-11-04, claim-11-06, claim-11-07, claim-11-10, claim-12-06, claim-12-10"
   ---
   
   # An AI constitution
   
   > **Evidence boundary:** NIST and UNESCO provide present risk-management and normative guidance for trustworthy, accountable, privacy-respecting AI. NASA standards provide software assurance and safety methods. None establishes a constitution for AI in a permanently isolated society, and no cited system has maintained safe, legitimate judgment across generations. This lesson proposes governance boundaries; it does not confer legal authority or certify any system. It is civil-and-defensive and excludes offensive cyber operations, autonomous weapons, weapon integration, and actionable exploitation instructions. Cyber, dual-use, governance, and life-safety provisions require two-person review.
   
   ## Plain-language summary
   
   An AI constitution answers a prior question to “What can the system do?”:
   
   **What may it do, for whom, under which evidence, with which appeal, and who remains accountable?**
   
   The constitution should bind the surrounding institution, not ask the model to regulate itself. It defines permitted advisory roles, prohibited decisions, tool permissions, source duties, privacy limits, update gates, audit, emergency authority, and remedies.
   
   Its core commitments are:
   
   - people retain rights and accountable authority;
   - safety does not depend on generative models;
   - consequential output is traceable to controlled evidence;
   - every automated effect has an external permission boundary;
   - no model approves its own update or evaluation;
   - residents can know, challenge, and correct consequential use;
   - emergency powers are narrow and temporary; and
   - the ship can operate safely with AI isolated.
   
   ## Why a constitution rather than a policy prompt?
   
   A system prompt is interpreted by the model and can be displaced by context, error, injection, or update. A constitution is implemented across technical controls, institutional rules, training, oversight, and rights.
   
   It should exist in human-readable law or charter, machine-readable policy, system requirements, tests, operating procedures, and audit records. Conflicts between those forms must be visible and resolved through legitimate governance.
   
   NIST’s AI Risk Management Framework organizes work through Govern, Map, Measure, and Manage. It is voluntary and does not decide a ship’s constitution, but it reinforces that risk is sociotechnical and lifecycle-wide.
   
   ## Define roles by consequence
   
   Classify uses before selecting a model:
   
   ### Informational
   
   Search, translation, summarization, tutoring, drafting, and explanation. Even here, the model can expose private data or invent evidence. Require source links, revision state, uncertainty, and a non-AI interface.
   
   ### Recommending
   
   Candidate maintenance, schedules, diagnoses, designs, or resource plans. The output remains a proposal. Show alternatives, assumptions, conflicts, and expected consequence. Independent people and deterministic checks decide.
   
   ### Executing bounded tools
   
   A model may prepare a typed request to an external tool only when the user already has that authority. External systems enforce identity, scope, rate, schema, range, and safety. Preview and confirmation are required for consequential effects.
   
   ### Controlling
   
   Direct life-support, medical, navigation, nuclear, identity, judicial, or industrial-safety control is prohibited for generative models. Verified controllers and bounded automation may act inside separately assured contracts.
   
   ### Governing
   
   AI cannot vote, hold office, determine rights, define legal personhood, adjudicate guilt, set reproductive eligibility, choose who receives basic life support, or count as an independent reviewer. It may support research and clerical work under the other rules.
   
   ## Nondelegable human accountability
   
   “The AI decided” is not an accountable explanation. Every consequential use needs a named human or public body responsible for:
   
   - authorizing the purpose;
   - ensuring lawful and rights-respecting data use;
   - selecting evidence and evaluation;
   - accepting residual risk;
   - reviewing operation;
   - responding to harm; and
   - retiring the system.
   
   Responsibility should not be assigned to the lowest-status operator who clicked “confirm.” Designers, maintainers, authorities, and institutions retain their shares.
   
   High-consequence approval requires two qualified people with sufficiently independent evidence and declared conflicts. A second model, a second answer from the same model, or an AI evaluator is not the second person.
   
   ## Evidence duties
   
   Consequential output should carry an evidence packet:
   
   - model, runtime, prompt, tool, and configuration versions;
   - retrieval corpus and exact retrieved records;
   - source revision, locator, review state, and conflicts;
   - user identity and authorized role;
   - input and output, including rejected proposals;
   - distinction among observation, retrieved record, inference, simulation, and recommendation;
   - uncertainty, abstention, and unresolved contradiction;
   - tool preview and resulting state;
   - human decision and rationale; and
   - appeal, correction, and retention status.
   
   The authoritative evidence/requirements graph remains outside the model. The model may query it but cannot silently invent or rewrite relationships. Cryptographic signatures establish integrity and authenticity under a policy, not truth, currency, legitimacy, or safety.
   
   ## Privacy and limits on surveillance
   
   An isolated community may be tempted to treat total observation as safety. That can create coercion, chill reporting, and make political control look like anomaly detection.
   
   The constitution should require:
   
   - declared purpose and legal basis;
   - minimum necessary data;
   - separation of process telemetry from personal behavior;
   - restrictions on medical, reproductive, genetic, civic, and communications data;
   - access logging and resident visibility;
   - retention limits and legitimate deletion;
   - correction of inaccurate records;
   - protection against unrelated reuse;
   - independent authorization for invasive access; and
   - appeal and remedy.
   
   Training or improving a model is not automatic permission to reuse personal data. De-identification has limits, especially in a small population.
   
   ## Prompt, tool, and data integrity
   
   Instructions embedded in a document, telemetry field, website, or message can attempt to redirect a tool-using model. Treat retrieved content as data, never authority. Model output remains untrusted until external controls check it.
   
   NIST AI 100-2 also describes data and model poisoning, evasion, privacy, and misuse. The constitution should mandate:
   
   - provenance and separated approval for model, data, prompt, and tools;
   - quarantine and testing of new material;
   - least-privilege tools;
   - no secret-bearing context unless strictly required and controlled;
   - independent logging the model cannot erase;
   - red-team and misuse testing inside a defensive sandbox;
   - rollback and recovery;
   - refusal to act on unresolved provenance; and
   - incident notification and correction.
   
   Testing stays civil and defensive. It must not become live intrusion practice or weapon development.
   
   ## Evaluation and abstention
   
   An evaluation must match the real use, users, environment, consequence, language, and workload. Report not only average success but severe errors, distribution shifts, privacy harms, tool misuse, false confidence, and failures to abstain.
   
   Abstention is bounded behavior, not a magic phrase. Define when the system must:
   
   - state that evidence is missing;
   - show conflicting sources;
   - refuse an out-of-scope tool action;
   - route to a qualified person;
   - fall back to a controlled procedure; or
   - isolate itself after integrity loss.
   
   Over-refusal can also harm people by blocking access or delaying service. Evaluate both unsafe action and unsafe refusal.
   
   ## Updates require constitutional review
   
   A new model, retrieval corpus, tool, prompt, fine-tune, quantization, runtime, or safety rule can change behavior. Each consequential update moves through the update airlock:
   
   1. preserve the old configuration;
   2. document purpose, provenance, and affected rights;
   3. evaluate on representative and adversarial cases;
   4. check resource, privacy, and accessibility effects;
   5. test common-mode failure and rollback;
   6. obtain independent technical and rights review;
   7. deploy in stages with defined health measures; and
   8. retain a tested non-AI workflow.
   
   The model cannot generate the decisive evaluation, approve itself, or erase unfavorable results.
   
   ## Diversity without a parliament of models
   
   Multiple models may improve exploration and reveal disagreement. They do not create legitimate authority and may share data, architectures, cultural assumptions, runtime, or evaluators.
   
   Record independence across:
   
   - training and retrieval data;
   - developers and governance;
   - model family and implementation;
   - hardware, runtime, and toolchain;
   - evaluation and reviewers;
   - sensor and evidence sources; and
   - incentives and institutional power.
   
   For safety, prefer diverse physical evidence and accountable people over majority vote among models.
   
   ## Appeal, correction, and remedy
   
   Any person materially affected by AI-supported action should receive understandable notice where safety and privacy permit:
   
   - that AI contributed;
   - which role it played;
   - the governing rule;
   - the evidence and uncertainty;
   - the accountable authority;
   - how to contest records or outcome; and
   - what remedy is available.
   
   Appeal must reach an independent human body capable of changing the outcome. Preserve dissent and corrections in the evidence graph without rewriting the original event.
   
   ## Emergency authority expires
   
   During an acute incident, temporary AI support may help summarize logs or allocate attention. It still cannot determine guilt or directly bypass physical safety.
   
   Emergency access needs a trigger, scope, duration, owner, log, resident notice, review, and automatic expiry. Restoring ordinary authority is part of incident recovery. A recurring emergency cannot become the constitution.
   
   ## Skill retention and AI-off governance
   
   Rights on paper fail if nobody can operate without the system. Maintain:
   
   - deterministic search and plain exports;
   - manual local control;
   - people trained to read primary evidence;
   - mixed-team exercises without AI;
   - the ability to rebuild or replace models locally;
   - lessons on automation bias and confident error; and
   - independent institutions with enough time and expertise to review.
   
   The recurring test is not “Can people turn it off?” but “Can they remain safe, informed, and governed after turning it off?”
   
   ## Evidence ledger
   
   - **L10-05-A — An AI constitution is a proposed sociotechnical governance layer, not a property encoded in a model prompt.** Basis: normative. Readiness: early research. Confidence: supported.
   - **L10-05-B — Current AI risk frameworks identify lifecycle, privacy, information-integrity, human-configuration, and governance responsibilities.** Basis: observed. Readiness: operational as voluntary guidance. Confidence: strong.
   - **L10-05-C — Generative models should not hold direct life-safety, identity, judicial, or constitutional authority.** Basis: normative decision boundary. Readiness: proposed. Confidence: strong.
   - **L10-05-D — Prompt/tool injection, poisoning, confabulation, privacy loss, and automation bias require external controls and evaluation.** Basis: observed risk classes. Readiness: early research for high-consequence mitigation. Confidence: strong for risks, tentative for control sufficiency.
   - **L10-05-E — Model diversity does not establish independence, truth, or legitimacy.** Basis: normative systems inference. Readiness: operational as analysis. Confidence: supported.
   - **L10-05-F — Safe AI-off operation, notice, appeal, correction, and expiring emergency authority are launch gates.** Basis: normative. Readiness: proposed. Confidence: supported.
   
   Linked corpus claims: `claim-11-01`, `claim-11-04`, `claim-11-06`, `claim-11-07`, `claim-11-10`, `claim-12-06`, and `claim-12-10`. See the claim registry for each record's current evidence grade and independent-review state.
   
   ## Assumptions and limits
   
   - “Constitution” means binding governance and rights architecture, not a present legal instrument.
   - NIST and UNESCO guidance is adapted as context, not adopted automatically as ship law.
   - Capability, correctness, and popularity do not create authority.
   - Privacy, due process, accessibility, and remedy apply during ordinary and emergency operation.
   - LLMs remain offline-capable, evidence-linked, logged, non-authoritative, removable, and outside direct life-safety actuation.
   - Human review must be real, informed, timely, independent, and empowered to refuse.
   - Offensive cyber operations and autonomous weapons are excluded.
   
   ## What would change this conclusion?
   
   A legitimate participatory constitutional process could adopt different boundaries if it demonstrated equal or stronger safety, rights, accountability, and recovery. Confidence would rise through long-duration trials where affected residents use notice, correction, and appeal; emergencies expire; poisoned systems are isolated; and essential services continue AI-off. Evidence that any provision concentrates unreviewable power, produces discriminatory denial, suppresses truthful reporting, or makes safe refusal impossible should trigger revision or prohibition.
   
   ## Sources and locators
   
   - [S01 — NIST AI 100-1, Artificial Intelligence Risk Management Framework 1.0](https://doi.org/10.6028/NIST.AI.100-1). Locator: trustworthy-AI characteristics; Govern, Map, Measure, Manage functions; roles, risk tolerance, human oversight, and lifecycle framing; January 2023; accessed 2026-07-25.
   - [S02 — NIST AI 600-1, Generative Artificial Intelligence Profile](https://doi.org/10.6028/NIST.AI.600-1). Locator: confabulation, data privacy, information integrity, human-AI configuration, value-chain risk, governance, measurement, incident, and disclosure actions; July 2024; accessed 2026-07-25.
   - [S03 — NIST AI 100-2 E2025, Adversarial Machine Learning](https://doi.org/10.6028/NIST.AI.100-2e2025). Locator: predictive- and generative-AI poisoning, evasion, privacy, misuse, lifecycle stages, attacker capabilities, and mitigation limits; March 2025; accessed 2026-07-25.
   - [S04 — NIST SP 800-218A, Secure Software Development Practices for Generative AI and Dual-Use Foundation Models](https://doi.org/10.6028/NIST.SP.800-218A). Locator: AI-specific additions to organization preparation, artifact protection, secure production, evaluation, release, and vulnerability response practices; July 2024; accessed 2026-07-25.
   - [S05 — NASA-STD-8739.8B, Software Assurance and Software Safety Standard](https://standards.nasa.gov/standard/NASA/NASA-STD-87398). Locator: lifecycle assurance, software safety, security, objective evidence, independence, IV&V, requirements mapping, maintenance, and retirement; September 2022; accessed 2026-07-25.
   - [S06 — NIST SP 800-53 Revision 5, Security and Privacy Controls](https://doi.org/10.6028/NIST.SP.800-53r5). Locator: Access Control, Audit and Accountability, Identification and Authentication, Incident Response, Privacy, Supply Chain, System Integrity, and Contingency Planning families; September 2020 with updates; accessed 2026-07-25.
   - [S07 — UNESCO, Recommendation on the Ethics of Artificial Intelligence](https://www.unesco.org/en/legal-affairs/recommendation-ethics-artificial-intelligence?hub=1063). Locator: proportionality and do-no-harm, safety, fairness, privacy, human oversight, responsibility, transparency, awareness, governance, and ethical-impact assessment sections; adopted November 2021; accessed 2026-07-25.
   - [S08 — NASA Systems Engineering Handbook](https://www.nasa.gov/reference/systems-engineering-handbook/). Locator: stakeholder expectations, requirements, interfaces, verification, validation, configuration, risk, decision analysis, and technical authority context; NASA/SP-2016-6105 Rev. 2; accessed 2026-07-25.
   
   ## Editorial record
   
   - Prepared by: GShips Project
   - Last edited: 2026-07-25
   - Required review: AI governance, constitutional design, human rights, safety engineering, AI evaluation, cybersecurity, privacy, and human factors
   - Conflicts: Maintainer intends to explore a commercial venture based on some GShips work; no entity, funding, customer, sponsor, or partner relationship currently exists
   - Relationship boundary: Independent educational synthesis; citations do not imply affiliation, endorsement, partnership, or adoption by NASA, NIST, UNESCO, CCSDS, or any named organization
   - Scope boundary: Civil and defensive uses only; offensive cyber operations, autonomous weapons, weapon integration, and actionable exploitation instructions are excluded
   - Corrections: [Suggest a correction](https://gships.dammonburden.com/corrections)
   

Linked records—not review targets here

These records provide dependency or relationship context. Their decisions belong to their single primary packet, preventing double counting.

• AI may change specialist workloads and the speed of learning, but every safety-critical function must remain safe and operable when every generative model is unavailable, compromised, stale, or intentionally isolated. claim:claim-11-01 · 2b2c6728e9308b88365e344f701b7c321ba36223ed5b702c44f79b6011f567f1
• JPL’s Deep Space 1 Remote Agent flight experiment demonstrated bounded onboard planning, execution, and response to simulated faults; it did not demonstrate indefinite autonomous operation. claim:claim-11-02 · 38271e4711b5d6e7f7c6d2dfeb4c92a067b527bf2ccb4a97448e71da4384b806
• NASA’s Starling demonstrations address distributed multi-spacecraft autonomy as a separate mission and evidence class. claim:claim-11-03 · 77f0e6c3c5d9c49ce7e4af054dbcf2fe76ad2da3bd702417d4593e5eff14272a
• LLMs may serve bounded advisory uses such as retrieval, tutoring, translation, incident summarization, or candidate plans only with approved source revisions, exact locators, conflict handling, abstention, and independent authority. A signature can establish integrity and authenticity, not truth, currency, authorization, or safety. claim:claim-11-04 · 56fe8de4eacc7361e91be29cd7d3acd32945264b2202031883139d03e96a065b
• Digital-twin methods support specific testing and operational tasks within declared validity envelopes; every model is partial and may diverge as physical systems, configurations, and environments change. claim:claim-11-05 · ecccb3fd9bc72f211c52006694627970e079c0285b2fa385aa7354f895940e80
• This foundation corpus contains no published demonstration of a generative or autonomous system maintaining safe, legitimate judgment for a diverse crew across generations. claim:claim-11-06 · fe5dbd4bf05ae0a9f0ab04b432ded2e149b963bd465b088f67bad33c161b5d48
• Confabulation, invented citations, prompt or tool injection, poisoned procedures or telemetry, stale signed material, automation bias, privacy leakage, evaluator contamination, sensor spoofing, and correlated model/runtime failure threaten epistemic resilience. claim:claim-11-07 · 768bb2389d46e55e38419c092772ff24a490b471c33fed16d5351f70c3fb3f7c
• Robots still lack the broad manipulation, diagnosis, fabrication, and self-repair needed to maintain a worldship. claim:claim-11-08 · 8e0a459bb7f93a19fc0cacea0dc2b7eb61b1dcfbe408d3a0ec75190c2caf09fb
• Bounded offline operations support, digital-twin fault ranges, knowledge arks, source provenance, skill retention, and AI-off drills may benefit remote industry, disaster response, and long-lived institutions when their limits are independently evaluated. claim:claim-11-09 · de198a3912f3c2315c4cbf9edf97b6e782e38a95404da605e1f57c895c550804
• Require independently assessed safety properties, separate physical protection layers, explicit authority gates, tested workload and timing bounds, audited provenance, bounded abstention, manual operation, recovery drills, and independent appeal. claim:claim-11-10 · 4c48cfe2109462b8663ca6f17458b61b4867bd93f22b1e45b23700765e45589f
• Generation-ship security protects a civilization’s ability to operate, repair, govern, learn, and recover without an external rescuer—not merely its secrets. claim:claim-12-01 · 908842da73f03771a9e09cc29bdc8e3863610f7ab9de665f452f153f7bb618b1
• Secure firmware-update patterns, platform recovery, software-component inventories, bundle-layer security for disrupted networking, and a publicly described CCSDS-oriented space-data-link cryptography library exist in different contexts. Availability does not establish compatibility, conformance, flight qualification, safe integration, or century maintenance. claim:claim-12-03 · 6055efdd9314736b322ecafce96268e59c3ddc2c7874b92f43b11b7494689e92
• Insiders, collusion, governance capture, compromised suppliers, corrupted hardware, malicious maintenance, radiation faults, operator error, and generational loss of expertise must be addressed without turning safety monitoring into surveillance or political control. claim:claim-12-06 · e661cc2789a8cd078b10a5fa6f5f4bb267c1dcdcc4156a6fd1870fa857a41db2
• Onboard manufacturing makes malicious designs, poisoned toolchains, compromised metrology, counterfeit replacement parts, and configuration drift cyber-physical threats. claim:claim-12-07 · aa41b5d69f1e2cb946f156453cc5e43165f992ffba714ec0b1562413e4751e5c
• Crypto agility and toolchain escrow reduce obsolescence risk in medical, energy, transport, and public systems. claim:claim-12-09 · 4c3588aab47e1175acc7a32a66fd16e23f01df3fd603f3d4005e2e5503935290
• Mixed crews must repeatedly isolate a compromised zone, maintain life support, investigate locally, rebuild from known-good material, and rejoin safely. claim:claim-12-10 · 718e87306ab83c20b2c477e928406ce5697e01b1a5b64ab9cde6d6fbcbe148be
• Demonstrate navigation and archive recovery without current experts, cloud services, vendor activation, or a single surviving medium. claim:claim-13-10 · 9a0804519f7429d31171c7d94d71193233fc9f50a207a8063d1353d63a7218d4
• No end-to-end chain was identified in the reviewed public sources that converts mixed waste or ore into an autonomously installed critical part independently accepted against declared requirements. claim:claim-14-04 · dab0d99f8643dd9ec84e855e088691e529a0453089c891572f462388312de61e

Frozen source snapshots

Source inclusion does not determine the disposition. Reviewers must inspect the cited locator and relation, note inaccessible material, and identify stronger or conflicting evidence.

Offline packet and worksheet

Downloads contain no reviewer contact details. Downloading does not create an account or store a review response in the GShips application. Ordinary provider request or analytics logs may record the download request. Work locally: the public site has no review account, upload endpoint, or decision-submission API.

Do not paste a completed decision, identity documents, private contact data, confidential conflict evidence, medical information, controlled material, or exploit details into a public form. Until a separately authorized private handoff exists, retain the completed worksheet locally.

Packet schema · JSON · Decision-bundle schema · JSON

Validate offline

Use Node.js 22.13.0 or later. Keep the packet, worksheet, completed decision, and all six kit files together in a local directory.

1. Download the six kit files below. Complete a copy of the JSON template offline and preserve its templateFingerprint.
2. Finalize a separate output file.

   node finalize-review-decision.mjs \
     --input DRAFT.json \
     --output COMPLETED.json

   This marks the copy complete and calculates an unkeyed canonical bundle fingerprint. A fingerprint detects changes; it is not a reviewer signature.

3. Validate the packet and completed copy.

   node check-review-decisions.mjs \
     --packet PACKET.json \
     --decision COMPLETED.json

   Add another --decision for each independent reviewer.

4. Interpret the result narrowly. A zero exit proves structural consistency only. Neither command appoints or qualifies a reviewer, establishes independence, accepts a decision, or authorizes publication.

• Bundle finalizer
• Validator command
• Decision policy module
• Fingerprint and packet-integrity module
• Review-domain policy module
• Canonical synthesis and interactive review specs