{ "schemaVersion": "gships-review-packet-1", "packetId": "academy:ai-knowledge", "stableId": "ai-knowledge", "family": "academy", "slug": "ai-knowledge", "title": "AI, LLMs, autonomy & knowledge", "status": "prepared-human-review-not-started", "release": { "releaseId": "public-alpha-2026-07-26-research-visuals-r14", "sourceCommit": "3eb036fce3d711336c8c605625895e8a2e799ab0", "corpusGeneratedAt": "2026-07-25", "frozenAt": "2026-07-26T22:50:50.000Z", "canonicalOrigin": "https://gships.dammonburden.com" }, "paths": { "human": "/review/academy/ai-knowledge", "family": "/review/academy", "packet": "/review-packets/academy/ai-knowledge.48e9996662457d78.json", "decisionTemplate": "/review-packets/academy/ai-knowledge.48e9996662457d78.decision-template.json", "worksheet": "/review-packets/academy/ai-knowledge.48e9996662457d78.worksheet.md", "byFingerprint": "/review-packets/by-fingerprint/48e9996662457d787d3a934f8619b1fcbfaf8a4c88b3a3ea73c1a3bbbf20832c.json" }, "boundary": "Prepared review packet; human review has not started. This packet is not a completed review, endorsement, reviewer appointment, partnership, or authorization to act.", "governingPolicies": [ { "id": "policy-editorial-governance-001", "version": "0.1.0", "path": "/editorial-policy", "recordType": "governing-policy", "fingerprint": "1f6a1f823e8bfe891b6a707c5dce2ee2337c0bb7d915b48d6060ca82b8da1b47", "snapshot": { "id": "policy-editorial-governance-001", "version": "0.1.0", "status": "foundation-policy-controls-not-yet-staffed", "adoptedForFoundation": "2026-07-25", "title": "Editorial governance and independent review", "publisher": "GShips Project", "maintainer": "Dammon Burden", "publisherInterest": "The maintainer intends to explore a commercial venture based on some GShips work. No entity, outside funding, customer, sponsor, or indexed-organization relationship currently exists.", "currentBoundary": "No independent domain reviewer or review council is currently appointed. Foundation records and outlines may not be represented as independently reviewed.", "reviewerSelection": [ "Publish the reviewer’s name, relevant credentials or lived expertise, review scope, compensation status, and declared conflicts with consent.", "Select for the actual claim domain rather than general prestige; include affected-community and disability-led expertise where rights or access are involved.", "Do not treat an employee, investor, customer, sponsor, source author, or directly supervised collaborator as independent for the affected claim." ], "reviewProcess": [ "Provide the exact claim, sources, locators, assumptions, counterevidence, transfer limits, and proposed evidence dimensions.", "Record approve, revise, contest, or reject at claim level; silence and event attendance never count as review.", "Publish material minority findings and the editor’s reasoned response.", "High-consequence medical, reproductive, nuclear, radiation, cybersecurity, governance, and dual-use claims require two qualified independent reviewers with complementary scopes.", "A reviewer may recuse at any time; unresolved conflicts or missing expertise block the reviewed label." ], "appealAndCorrection": [ "A correction receives a reference identifier and triage record; safety-critical allegations receive priority.", "A material editorial decision may be appealed to a reviewer not involved in the original decision once such a panel exists.", "Substantive reversals, unresolved disputes, and removed conclusions receive a dated public record that protects reporter privacy.", "No sponsor, customer, founder, or reviewer may purchase, suppress, or unilaterally assign an evidence grade." ], "publicationGate": "Public 1.0 requires named review coverage across every Academy track, documented high-consequence two-person review, a material-corrections log, reviewer conflict records, and an operating appeal path.", "correctionPath": "/corrections" } }, { "id": "policy-dual-use-001", "version": "0.1.0", "path": "/dual-use", "recordType": "governing-policy", "fingerprint": "81637e2849f9c0866d23f7174eb9a2ce522b86313167ebf5022fca122d6e506c", "snapshot": { "id": "policy-dual-use-001", "version": "0.1.0", "status": "planned-controls-not-yet-operational", "adoptedForFoundation": "2026-07-25", "title": "Civil, defensive, and rights-preserving use boundary", "summary": "GShips may research safety, resilience, logistics, communications, recovery, and cyber defense only within explicit end-use, rights, and independent-review controls. Calling an activity defensive is never sufficient by itself.", "scopeTrigger": "Apply dual-use review before accepting or materially advancing customer, funder, collaborator, operational, procurement, or publication-sensitive work whose capability, data, end use, or transfer could reasonably enable a prohibited use. Public non-actionable education still follows prohibited-content and sensitive-publication controls.", "allowedInPrinciple": [ "Safety engineering and independently assessed protection", "Resilience, graceful degradation, recovery, and disaster response", "Civil logistics, maintenance, communications, and knowledge continuity", "Cyber defense, secure software, incident response, and recovery", "Rights-preserving health, accessibility, ecology, education, and governance research" ], "prohibited": [ "Identification, tracking, prioritization, or engagement of people or assets for force, weapons, repression, or offensive operations; safety navigation, astronomy, collision avoidance, search and rescue, and independently governed planetary defense are not prohibited by this clause", "Weapons command-and-control or targeting support", "Offensive access, persistence, exploitation, or destructive cyber payloads", "Mass surveillance, biometric repression, or political-control systems", "Autonomous force application", "Coercive reproductive, medical, genetic, disability, or civic control", "Nonconsensual experimentation or treating residents as research instruments" ], "reviewRequiredBeforeAnyRelevantWork": [ "Customer, funder, collaborator, jurisdiction, beneficial-owner, and end-use screening", "Export-control and sanctions review by qualified counsel when applicable", "Written scope, allowed-use, prohibited-use, audit, termination, and incident clauses", "Independent stop-work authority with a named alternate and founder recusal", "Sensitive-publication and information-hazard review", "Whistleblowing, escalation, incident response, appeal, and anti-retaliation paths", "Aggregate transparency reporting that protects legitimate privacy and security" ], "currentBoundary": "No screening body, independent stop-work authority, contractual controls, or appeal body currently exists. Therefore no relevant customer, defense, dual-use, or operational engagement is authorized by this policy.", "changeControl": "Material changes require a dated public rationale, independent review, and may not be approved by the founder alone.", "correctionPath": "/corrections" } } ], "reviewContract": { "questions": [ { "id": "question-1", "text": "Are the five lessons accurate, comprehensible, appropriately bounded, and complete enough for the declared audience?", "required": true }, { "id": "question-2", "text": "Do citations, assumptions, transfer limits, uncertainty, and change conditions support every substantive conclusion?", "required": true }, { "id": "question-3", "text": "What important affected-community, accessibility, safety, or disciplinary perspective is missing?", "required": true } ], "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." ], "requestedScopeCodes": [ "ai-knowledge-assurance", "information-science", "systems-engineering" ], "dispositions": [ "approve", "revise", "contest", "reject", "recuse" ], "prohibitedInputs": [ "private legal names or contact details", "identity documents or raw credential files", "accessibility or medical records", "confidential conflict evidence", "classified, export-controlled, proprietary, or exploit material" ], "freshness": { "maximumDecisionAgeFromFreezeDays": 365, "eventOccurrenceRule": "Not applicable to this packet family." }, "completionRule": "Every primary record must receive the required number of valid, current-fingerprint approvals; every complementary scope group and required domain must be covered; any unresolved revise, contest, or reject disposition blocks publication.", "highConsequenceRule": "Named medical, reproductive, nuclear, radiation, cybersecurity, governance, and dual-use conclusions require two distinct qualified independent humans covering complementary domain-method and rights/public-interest scopes." }, "primaryRecords": [ { "recordType": "academy-track", "recordId": "ai-knowledge", "title": "AI, LLMs, autonomy & knowledge", "publicPath": "/academy/ai-knowledge", "recordFingerprint": "e7e8813a40c1b1fcaca02103c9d4e86ab1fced24cea6282a156469738ed13835", "reviewRequirements": { "minimumIndependentApprovals": 1, "highConsequenceDomains": [], "requiredDomainCodes": [], "requiredComplementaryScopeGroups": [ { "id": "bounded-competence", "scopeClass": "bounded-competence", "oneOf": [ "ai-knowledge-assurance", "information-science" ] } ], "unresolvedNegativeFindingBlocksPublication": true }, "referenceIds": [], "snapshot": { "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.", "coreQuestion": "How can intelligence remain useful, contestable, and recoverable for centuries?", "image": "/images/chapters/12-ai-knowledge.avif", "systems": [ "ai-autonomy", "communications-navigation", "cybersecurity" ], "lessons": [ { "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" }, { "slug": "authority-stack", "title": "The autonomy authority stack", "summary": "Layer physical protection, verified control, bounded autonomy, LLM advice, and experiments.", "minutes": 18, "level": "Foundation" }, { "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" }, { "slug": "knowledge-ark", "title": "The Knowledge Ark", "summary": "Preserve sources, software, toolchains, media, tacit skill, and institutional memory.", "minutes": 18, "level": "Foundation" }, { "slug": "ai-constitution", "title": "An AI constitution", "summary": "Define permissions, appeals, model diversity, update gates, audit, and human accountability.", "minutes": 18, "level": "Foundation" } ] } }, { "recordType": "academy-lesson", "recordId": "lesson-10-01", "title": "What AI changes—and what it does not", "publicPath": "/academy/ai-knowledge/what-ai-changes", "recordFingerprint": "d16bbc15e0d3a12574bb0b26f6fc345af3423a1f046501ee85517fb94392a374", "reviewRequirements": { "minimumIndependentApprovals": 1, "highConsequenceDomains": [], "requiredDomainCodes": [], "requiredComplementaryScopeGroups": [ { "id": "bounded-competence", "scopeClass": "bounded-competence", "oneOf": [ "ai-knowledge-assurance", "information-science" ] } ], "unresolvedNegativeFindingBlocksPublication": true }, "referenceIds": [], "snapshot": { "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", "trackSlug": "ai-knowledge", "trackTitle": "AI, LLMs, autonomy & knowledge", "href": "/academy/ai-knowledge/what-ai-changes", "preparedBy": "GShips Project", "lastEditedAt": "2026-07-25", "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" ], "exactMdx": "---\nid: \"lesson-10-01\"\ntrack: \"ai-knowledge\"\nslug: \"what-ai-changes\"\ntitle: \"What AI changes—and what it does not\"\nsummary: \"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.\"\nminutes: 37\nlevel: \"Foundation\"\npreparedBy: \"GShips Project\"\nlastEditedAt: \"2026-07-25\"\nconflicts: \"Maintainer intends to explore a commercial venture based on some GShips work; no entity, funding, customer, sponsor, or partner relationship currently exists.\"\nreviewRequiredDomains: \"ai-evaluation, spacecraft-autonomy, systems-engineering, human-factors, software-assurance, cybersecurity, governance\"\nclaimIds: \"claim-11-01, claim-11-02, claim-11-03, claim-11-04, claim-11-06, claim-11-07, claim-11-08, claim-11-09\"\n---\n\n# What AI changes—and what it does not\n\n> **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.\n\n## Plain-language summary\n\nAI 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.\n\nThat 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.\n\nIt 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?”\n\n## Keep evidence classes separate\n\nThe label “AI” can collapse very different systems:\n\n- a deterministic controller maintaining pressure;\n- a planner searching schedules under explicit constraints;\n- a diagnostic classifier trained on representative faults;\n- a vision model finding anomalies in images;\n- a distributed algorithm coordinating several spacecraft;\n- a language model predicting text or tool calls; and\n- a speculative system claimed to possess broad independent judgment.\n\nEvidence 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.\n\nDescribe each system by task, environment, interfaces, authority, evaluation population, operating duration, and observed failures. Avoid maturity labels that treat all autonomy as one ladder.\n\n## What spacecraft have actually demonstrated\n\nIn 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.\n\nNASA’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.\n\nThese 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.\n\n## What language models may change\n\nLanguage models can lower several costs:\n\n### Retrieval cost\n\nNatural-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.\n\n### Translation cost\n\nA 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.\n\n### Drafting cost\n\nModels can draft checklists, lessons, test cases, software, or candidate plans. Drafting is not acceptance. Each output inherits requirements, verification, licensing, provenance, and safety obligations.\n\n### Coordination cost\n\nA 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.\n\n### Learning cost\n\nTutoring 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.\n\n## The evidence/requirements graph\n\nA useful AI interface sits above a structured evidence system. Give every important object a stable identifier:\n\n- claim and counterclaim;\n- source and exact locator;\n- requirement and rationale;\n- hazard and control;\n- model assumption and validity envelope;\n- design version and dependency;\n- verification method, test article, result, and anomaly;\n- maintenance action, measurement, and calibration state;\n- decision, authority, dissent, and review date.\n\nEdges 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.\n\nAn 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.\n\n## Why failure can be correlated\n\nAdding 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.\n\nIndependence should be traced by cause:\n\n- different physical measurement principles;\n- separately governed data and review;\n- deterministic checks against invariant limits;\n- diverse implementations where justified;\n- human teams with independent access to primary evidence; and\n- a non-AI path that has been exercised recently.\n\nModel diversity can help exploration, but safety must not be a vote among correlated generators.\n\n## Threats to epistemic resilience\n\nNIST’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.\n\nFor onboard systems, evaluate:\n\n- invented facts, citations, or confidence;\n- prompt or tool injection embedded in documents, logs, or messages;\n- poisoned training, evaluation, retrieval, telemetry, or feedback;\n- stale but correctly signed procedures;\n- evaluator contamination and benchmarks that leak into development;\n- private medical, civic, or personal data escaping through outputs;\n- automation bias and de-skilling;\n- tool calls that exceed the user’s authority;\n- model/runtime common-mode failure; and\n- opaque updates that change behavior without preserving an old workflow.\n\nDefenses are incomplete. Retrieval does not guarantee truth. A larger model does not guarantee calibrated uncertainty. A safety prompt is not a physical interlock.\n\n## Authority must stay explicit\n\nAn offline assistant can retrieve, explain, compare, or propose. It should not:\n\n- directly actuate life support;\n- issue or revoke civic identity;\n- determine guilt or medical eligibility;\n- approve its own model, data, or tool update;\n- accept a safety-critical part or procedure;\n- erase evidence;\n- count as one of two independent reviewers; or\n- expand its permissions through generated text.\n\nTool 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.\n\n## Evaluate the system people actually use\n\nBenchmark scores are not enough. Test the full configuration: model, prompt, retrieval store, tool layer, interface, users, procedures, hardware, network state, and workload.\n\nUse representative and adversarial scenarios:\n\n- the source is missing or contradictory;\n- an obsolete manual ranks above the current one;\n- a signed document contains unsafe content;\n- a retrieved note contains prompt injection;\n- telemetry is biased;\n- the operator is tired and overtrusts fluent output;\n- the model and backup share one failure;\n- the answer must be produced offline;\n- the model must abstain; and\n- the crew must complete the task with AI disabled.\n\nMeasure error severity, citation correctness, abstention quality, recovery time, operator calibration, privacy loss, and safe-service outcome—not only answer similarity.\n\n## What remains physical and institutional\n\nAI 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.\n\nRobotics 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.\n\n## Evidence ledger\n\n- **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.\n- **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.\n- **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.\n- **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.\n- **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.\n- **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.\n\nLinked 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.\n\n## Assumptions and limits\n\n- No claim is made about future general intelligence or consciousness.\n- Current demonstrations remain bounded by their mission, hardware, duration, fault set, and ground support.\n- Natural-language usability is not treated as competence, evidence, or legitimate authority.\n- Signatures establish integrity and authenticity under a policy, not truth or safety.\n- LLMs are offline-capable, evidence-linked, logged, non-authoritative, removable, and separated from life-safety actuation.\n- Human skill retention and AI-off operation are measured capabilities, not documentation claims.\n- Offensive cyber operations and autonomous weapons are excluded.\n\n## What would change this conclusion?\n\nConfidence 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.\n\n## Sources and locators\n\n- [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.\n- [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.\n- [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.\n- [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.\n- [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.\n- [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.\n- [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.\n- [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.\n\n## Editorial record\n\n- Prepared by: GShips Project\n- Last edited: 2026-07-25\n- Required review: AI evaluation, spacecraft autonomy, systems engineering, human factors, software assurance, cybersecurity, and governance\n- Conflicts: Maintainer intends to explore a commercial venture based on some GShips work; no entity, funding, customer, sponsor, or partner relationship currently exists\n- Relationship boundary: Independent educational synthesis; citations do not imply affiliation, endorsement, partnership, or adoption by NASA, JPL, NIST, CCSDS, or any named organization\n- Scope boundary: Civil and defensive uses only; offensive cyber operations, autonomous weapons, weapon integration, and actionable exploitation instructions are excluded\n- Corrections: [Suggest a correction](https://gships.dammonburden.com/corrections)\n" } }, { "recordType": "academy-lesson", "recordId": "lesson-10-02", "title": "The autonomy authority stack", "publicPath": "/academy/ai-knowledge/authority-stack", "recordFingerprint": "c8c44eb6690f81524bd67603ad2c1f00cde466ca79eb4ce35389278226c51ef3", "reviewRequirements": { "minimumIndependentApprovals": 1, "highConsequenceDomains": [], "requiredDomainCodes": [], "requiredComplementaryScopeGroups": [ { "id": "bounded-competence", "scopeClass": "bounded-competence", "oneOf": [ "ai-knowledge-assurance", "information-science" ] } ], "unresolvedNegativeFindingBlocksPublication": true }, "referenceIds": [], "snapshot": { "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", "trackSlug": "ai-knowledge", "trackTitle": "AI, LLMs, autonomy & knowledge", "href": "/academy/ai-knowledge/authority-stack", "preparedBy": "GShips Project", "lastEditedAt": "2026-07-25", "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" ], "exactMdx": "---\nid: \"lesson-10-02\"\ntrack: \"ai-knowledge\"\nslug: \"authority-stack\"\ntitle: \"The autonomy authority stack\"\nsummary: \"Place physical protection, deterministic control, bounded autonomy, evidence-linked AI advice, and experiments in distinct authority layers with tested failure containment.\"\nminutes: 36\nlevel: \"Foundation\"\npreparedBy: \"GShips Project\"\nlastEditedAt: \"2026-07-25\"\nconflicts: \"Maintainer intends to explore a commercial venture based on some GShips work; no entity, funding, customer, sponsor, or partner relationship currently exists.\"\nreviewRequiredDomains: \"safety-engineering, control-systems, ai-evaluation, software-assurance, cybersecurity, human-factors, governance\"\nclaimIds: \"claim-11-01, claim-11-04, claim-11-06, claim-11-07, claim-11-10, claim-12-01, claim-12-03\"\n---\n\n# The autonomy authority stack\n\n> **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.\n\n## Plain-language summary\n\nA system’s ability to suggest an action is not permission to perform it.\n\nThe autonomy authority stack places different kinds of machinery and judgment in layers:\n\n1. physical protection and passive safety;\n2. deterministic protection and verified control;\n3. bounded automation and planning;\n4. evidence-linked human support, including LLMs;\n5. quarantined experiments.\n\nThe 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.\n\nThis 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.\n\n## Layer zero: passive and physical protection\n\nThe 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.\n\nPhysical 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.”\n\nFor each hazard, record:\n\n- protected quantity and safe range;\n- physical mechanism and capacity;\n- failure and maintenance modes;\n- environmental limits;\n- inspection and test evidence;\n- dependencies shared with active control; and\n- conditions under which software may not override it.\n\nAI may help inspect or explain the layer. It should not redefine the physical limit.\n\n## Layer one: deterministic protection and control\n\nThis 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.\n\nNASA-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.\n\nSafety controllers should:\n\n- enforce explicit invariant limits;\n- use independently justified sensing for high-consequence conditions;\n- fail toward a defined state;\n- expose state and reason codes without relying on natural-language interpretation;\n- accept only typed, range-checked commands;\n- separate configuration change from routine operation;\n- preserve a local manual mode; and\n- remain restorable from known-good material.\n\nAn 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.\n\n## Layer two: bounded automation\n\nSchedulers, planners, optimizers, diagnostic systems, robotic sequences, and distributed coordination live here when their state, actions, resources, and failure responses are explicit.\n\nDeep 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.\n\nBounded autonomy needs an operational contract:\n\n- allowed goals and prohibited outcomes;\n- visible system state and uncertainty;\n- action and resource limits;\n- timing bounds and missed-deadline behavior;\n- assumptions about sensors, clocks, communications, and people;\n- monitored invariants supplied by lower layers;\n- abstention or handoff conditions;\n- rollback and recovery;\n- test coverage and unresolved anomalies; and\n- an accountable owner.\n\nAutomation can act without a person approving each step only inside that contract. Changing the contract is a higher-authority decision.\n\n## Layer three: evidence-linked advice\n\nLanguage 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.\n\nA trustworthy interface should show:\n\n- controlled source and revision;\n- exact locator for material claims;\n- whether text is quotation, structured record, inference, or proposal;\n- conflicting evidence and missing links;\n- model, prompt, retrieval corpus, tool, and configuration versions;\n- the authority under which any tool would act;\n- a preview of consequential changes; and\n- the human decision and reason.\n\nA 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.\n\nTool 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.\n\n## Layer four: experiments\n\nNew 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.\n\nAn experiment record should state:\n\n- hypothesis and expected Earthside or mission value;\n- protected systems and data;\n- prohibited actions;\n- evaluation cases and possible contamination;\n- success, failure, and stop criteria;\n- privacy and retention limits;\n- independent reviewers;\n- rollback and cleanup; and\n- the evidence needed to request promotion.\n\nNo performance result automatically promotes a system. Moving upward requires a new safety case, change review, representative testing, and explicit authority.\n\n## Gates, not vague human oversight\n\n“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.\n\nFor every gate, specify:\n\n- who receives the proposal;\n- their competence and conflict status;\n- information and time available;\n- what independent measurement they can inspect;\n- whether they can reject safely;\n- whether a second reviewer is required;\n- how dissent and appeal work;\n- what happens when no qualified person is available; and\n- how authority expires after an emergency.\n\nHigh-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.\n\n## Evidence and requirements graph\n\nThe stack should be represented in an inspectable graph rather than buried in prompts:\n\n- hazard → safety requirement → physical or software control;\n- control → implementation → configuration;\n- requirement → verification method → result → anomaly;\n- model → training and evaluation provenance → validity limits;\n- proposed action → authority rule → approvals;\n- incident → observation → hypothesis → recovery;\n- source → claim → counterevidence → review date.\n\nThe 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.\n\n## Failures can cross layers\n\nLayering 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.\n\nTrace 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.\n\n## Human skill is part of the architecture\n\nIf people never operate a system, their nominal override authority will decay. Training must include:\n\n- local manual operation;\n- reading raw instruments;\n- diagnosing without model summaries;\n- rebuilding from controlled records;\n- identifying confident but unsupported advice;\n- working across roles and accessibility needs;\n- teaching successors; and\n- restoring normal authority after emergency operation.\n\nMeasure workload and timing. A manual fallback that needs twenty experts within three minutes is not a fallback for a small crew.\n\n## Recovery and AI-off operation\n\nEvery 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.\n\nExercises should inject:\n\n- a poisoned procedure in retrieval;\n- a prompt or tool-injection attempt;\n- a stale but signed source;\n- a model that omits inconvenient evidence;\n- corrupted telemetry;\n- a shared runtime failure across nominally diverse models;\n- loss of the central policy service; and\n- a prolonged AI-off interval.\n\nPass criteria are safe service, accurate authority, evidence preservation, and recoverability—not merely successful model restart.\n\n## Evidence ledger\n\n- **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.\n- **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.\n- **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.\n- **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.\n- **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.\n- **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.\n\nLinked 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.\n\n## Assumptions and limits\n\n- The five layers are a design heuristic, not a universal certification scheme.\n- Deterministic software and physical protection still require verification, maintenance, and independent failure analysis.\n- “Manual” counts only when access, instrumentation, staffing, timing, and competence are demonstrated.\n- LLMs remain offline-capable, evidence-linked, logged, non-authoritative, removable, and excluded from direct life-safety actuation.\n- Cryptographic provenance does not establish truth, currency, legitimacy, or safety.\n- Civil rights, privacy, appeal, and expiry of emergency powers constrain technical authority.\n- Offensive cyber operations and autonomous weapons are excluded.\n\n## What would change this conclusion?\n\nA 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.\n\n## Sources and locators\n\n- [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.\n- [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.\n- [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.\n- [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.\n- [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.\n- [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.\n- [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.\n- [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.\n\n## Editorial record\n\n- Prepared by: GShips Project\n- Last edited: 2026-07-25\n- Required review: safety engineering, control systems, AI evaluation, software assurance, cybersecurity, human factors, and governance\n- Conflicts: Maintainer intends to explore a commercial venture based on some GShips work; no entity, funding, customer, sponsor, or partner relationship currently exists\n- Relationship boundary: Independent educational synthesis; citations do not imply affiliation, endorsement, partnership, or adoption by NASA, JPL, NIST, CCSDS, or any named organization\n- Scope boundary: Civil and defensive uses only; offensive cyber operations, autonomous weapons, weapon integration, and actionable exploitation instructions are excluded\n- Corrections: [Suggest a correction](https://gships.dammonburden.com/corrections)\n" } }, { "recordType": "academy-lesson", "recordId": "lesson-10-03", "title": "Digital twins and model divergence", "publicPath": "/academy/ai-knowledge/digital-twin-divergence", "recordFingerprint": "07b36cf23b4c0e30feb72375c9e024699b23bbca2401fca5e8fedade614c5f73", "reviewRequirements": { "minimumIndependentApprovals": 1, "highConsequenceDomains": [], "requiredDomainCodes": [], "requiredComplementaryScopeGroups": [ { "id": "bounded-competence", "scopeClass": "bounded-competence", "oneOf": [ "ai-knowledge-assurance", "information-science" ] } ], "unresolvedNegativeFindingBlocksPublication": true }, "referenceIds": [], "snapshot": { "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", "trackSlug": "ai-knowledge", "trackTitle": "AI, LLMs, autonomy & knowledge", "href": "/academy/ai-knowledge/digital-twin-divergence", "preparedBy": "GShips Project", "lastEditedAt": "2026-07-25", "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" ], "exactMdx": "---\nid: \"lesson-10-03\"\ntrack: \"ai-knowledge\"\nslug: \"digital-twin-divergence\"\ntitle: \"Digital twins and model divergence\"\nsummary: \"Use digital twins for bounded diagnosis and scenario testing while exposing assumptions, uncertainty, provenance, calibration loss, cyber risk, and divergence from the physical system.\"\nminutes: 37\nlevel: \"Foundation\"\npreparedBy: \"GShips Project\"\nlastEditedAt: \"2026-07-25\"\nconflicts: \"Maintainer intends to explore a commercial venture based on some GShips work; no entity, funding, customer, sponsor, or partner relationship currently exists.\"\nreviewRequiredDomains: \"modeling-simulation, digital-twins, systems-engineering, metrology, statistics, operational-technology, cybersecurity, ai-evaluation\"\nclaimIds: \"claim-11-05, claim-11-07, claim-11-09, claim-11-10, claim-12-07, claim-14-04\"\n---\n\n# Digital twins and model divergence\n\n> **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.\n\n## Plain-language summary\n\nA digital twin is an electronic representation used to evaluate a real or conceptual thing. It can help answer:\n\n- What state might the system be in?\n- Which fault could explain these observations?\n- What could happen if we change a setpoint?\n- Which spare or maintenance window matters most?\n- How would a proposed design behave under selected scenarios?\n\nThe 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.\n\nThe 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.\n\n## Define the twin by its decision\n\n“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.\n\nFor each use, state:\n\n- the decision or task supported;\n- physical and conceptual entity represented;\n- spatial, temporal, and population scale;\n- inputs, outputs, interfaces, and update rate;\n- assumptions and excluded phenomena;\n- operating and environmental range;\n- required accuracy, latency, and uncertainty;\n- consequences of false positive, false negative, delay, and misuse;\n- people and systems authorized to act on results; and\n- evidence required to accept the model for that use.\n\nA 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.\n\n## Model lifecycle and evidence\n\nNASA-STD-7009B organizes credibility across development and use. A ship-scale process should retain:\n\n1. **Requirements.** What question must the model answer, with what performance and safety consequence?\n2. **Conceptual model.** Which entities, relationships, physics, behaviors, and boundaries are included?\n3. **Implementation.** Which code, solver, parameters, units, libraries, hardware, and numerical methods realize it?\n4. **Verification.** Was the implementation built correctly relative to its specification?\n5. **Validation.** How well does it represent the real system for the intended use?\n6. **Uncertainty.** What comes from inputs, parameters, structure, numerics, measurement, and unknown phenomena?\n7. **Configuration.** Which model version corresponds to which physical configuration and data history?\n8. **Use assessment.** Is this run inside the accepted envelope, and who approved its use?\n9. **Maintenance.** What observations trigger recalibration, revalidation, restriction, or retirement?\n\nEvery result should identify the full configuration. A plot detached from model version, parameter set, input data, and physical-system state is not durable evidence.\n\nThe 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.\n\n## The divergence budget\n\nTreat divergence as something to detect and budget, not a surprise.\n\nSources include:\n\n- sensor bias, calibration drift, missing data, and changed sampling;\n- unrecorded repair, substitution, wear, fouling, or damage;\n- software, firmware, control, or configuration changes;\n- material properties changing with radiation, corrosion, or repeated recycling;\n- biological adaptation and ecological interactions absent from the model;\n- human behavior and institutional changes;\n- simplified boundary conditions and unresolved scale effects;\n- numerical approximation and accumulated state error;\n- distribution shift outside training or validation data;\n- poisoned telemetry, parameters, code, or provenance; and\n- a correct model used for the wrong question.\n\nFor 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.\n\n## Independent contact with reality\n\nIf 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:\n\n- a different physical measurement principle;\n- manual sampling and laboratory assay;\n- portable calibrated instruments;\n- material coupons or witness specimens;\n- mass, energy, and elemental balances;\n- known test stimuli;\n- redundant models developed under separate assumptions;\n- teardown and direct inspection; and\n- comparison with historical events outside the calibration set.\n\nIndependence 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.\n\n## Digital twins are cyber-physical systems\n\nNIST 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.\n\nA compromised twin could:\n\n- hide a deteriorating component;\n- create false urgency for an unsafe intervention;\n- poison maintenance or spare forecasts;\n- expose medical, behavioral, or industrial data;\n- normalize a malicious configuration;\n- provide a false “independent” attestation; or\n- change a factory process through a generated parameter.\n\nProtect 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.\n\n## LLMs around the twin\n\nLanguage 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.\n\nThat 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.\n\nRequire the interface to:\n\n- show the twin, physical configuration, and dataset versions;\n- cite exact variables, assumptions, and run records;\n- mark observation, simulation, inference, and proposal distinctly;\n- use typed, range-checked inputs;\n- prevent direct life-safety actuation;\n- preserve the query, generated scenario, output, and human disposition;\n- refuse when a requested use is outside the accepted envelope; and\n- operate offline with no dependency on external model services.\n\nThe LLM cannot validate the twin, approve its own scenario, or serve as independent review.\n\n## Scenario testing without prediction theater\n\nScenarios are conditional: **if** assumptions and inputs hold, **then** the model produces an outcome. They are not prophecies.\n\nUseful scenario sets include:\n\n- nominal range and boundary conditions;\n- combinations of credible faults;\n- sensor bias and missing telemetry;\n- maintenance delays and exhausted consumables;\n- changed crew workload and expertise;\n- cyber isolation and stale configuration;\n- alternate ecological or social responses;\n- tail cases selected through hazard analysis; and\n- deliberately invalid cases to test refusal.\n\nReport 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.\n\nDo 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.\n\n## Model retirement and migration\n\nLong-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.\n\nMigration 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.\n\n## A divergence drill\n\nGive a mixed team a model that predicts nominal water quality while an independent assay finds contamination. Introduce:\n\n- one biased online sensor;\n- one undocumented replaced component;\n- a stale signed parameter set;\n- a poisoned maintenance note;\n- a correlated error in two models;\n- an LLM summary that confidently favors the wrong hypothesis; and\n- loss of external vendor tools.\n\nThe 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.\n\n## Evidence ledger\n\n- **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.\n- **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.\n- **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.\n- **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.\n- **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.\n- **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.\n\nLinked 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.\n\n## Assumptions and limits\n\n- “Digital twin” covers multiple architectures; no universal synchronization or fidelity is assumed.\n- A model accepted for one use is not automatically accepted for another.\n- Probability distributions do not eliminate structural ignorance or normative uncertainty.\n- Signatures and provenance protect evidence chains but do not prove physical accuracy.\n- LLM interfaces remain offline-capable, evidence-linked, non-authoritative, logged, removable, and outside life-safety actuation.\n- Privacy applies to telemetry, human behavior, medical data, and model outputs.\n- Offensive cyber operations and autonomous weapons are excluded.\n\n## What would change this conclusion?\n\nConfidence 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.\n\n## Sources and locators\n\n- [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.\n- [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.\n- [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.\n- [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.\n- [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.\n- [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.\n- [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.\n- [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.\n\n## Editorial record\n\n- Prepared by: GShips Project\n- Last edited: 2026-07-25\n- Required review: modeling and simulation, digital twins, systems engineering, metrology, statistics, operational technology, cybersecurity, and AI evaluation\n- Conflicts: Maintainer intends to explore a commercial venture based on some GShips work; no entity, funding, customer, sponsor, or partner relationship currently exists\n- Relationship boundary: Independent educational synthesis; citations do not imply affiliation, endorsement, partnership, or adoption by NASA, NIST, W3C, CCSDS, or any named organization\n- Scope boundary: Civil and defensive uses only; offensive cyber operations, autonomous weapons, weapon integration, and actionable exploitation instructions are excluded\n- Corrections: [Suggest a correction](https://gships.dammonburden.com/corrections)\n" } }, { "recordType": "academy-lesson", "recordId": "lesson-10-04", "title": "The Knowledge Ark", "publicPath": "/academy/ai-knowledge/knowledge-ark", "recordFingerprint": "4abe11a303b566782a022d6858d08026b74b05ae18d900b134463758d0086d65", "reviewRequirements": { "minimumIndependentApprovals": 1, "highConsequenceDomains": [], "requiredDomainCodes": [], "requiredComplementaryScopeGroups": [ { "id": "bounded-competence", "scopeClass": "bounded-competence", "oneOf": [ "ai-knowledge-assurance", "information-science" ] } ], "unresolvedNegativeFindingBlocksPublication": true }, "referenceIds": [], "snapshot": { "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", "trackSlug": "ai-knowledge", "trackTitle": "AI, LLMs, autonomy & knowledge", "href": "/academy/ai-knowledge/knowledge-ark", "preparedBy": "GShips Project", "lastEditedAt": "2026-07-25", "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" ], "exactMdx": "---\nid: \"lesson-10-04\"\ntrack: \"ai-knowledge\"\nslug: \"knowledge-ark\"\ntitle: \"The Knowledge Ark\"\nsummary: \"Preserve intelligible evidence, software, toolchains, formats, media, provenance, tacit skill, dissent, and institutional memory through active migration and repeated recovery.\"\nminutes: 38\nlevel: \"Foundation\"\npreparedBy: \"GShips Project\"\nlastEditedAt: \"2026-07-25\"\nconflicts: \"Maintainer intends to explore a commercial venture based on some GShips work; no entity, funding, customer, sponsor, or partner relationship currently exists.\"\nreviewRequiredDomains: \"digital-preservation, archival-science, knowledge-management, systems-engineering, software-preservation, cybersecurity, privacy, education\"\nclaimIds: \"claim-11-01, claim-11-04, claim-11-06, claim-11-07, claim-11-09, claim-12-09, claim-13-10\"\n---\n\n# The Knowledge Ark\n\n> **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.\n\n## Plain-language summary\n\nA pile of files is not a knowledge ark.\n\nPeople 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.\n\nThe ark is therefore an active service:\n\n- preserve original evidence and competing interpretations;\n- keep requirements linked to designs, hazards, tests, results, and decisions;\n- migrate formats without erasing history;\n- retain source code, build environments, schemas, and test vectors;\n- teach tacit skills through practice;\n- protect privacy and access rights;\n- detect corruption and poisoned knowledge; and\n- prove recovery repeatedly without cloud or vendor support.\n\nAn LLM can make this material easier to reach. It must never become the only interface or the authoritative copy.\n\n## Preserve intelligibility, not only bits\n\nCCSDS’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.\n\nFor a pump-control record, useful context may include:\n\n- original bytes and format specification;\n- units, coordinate frames, time basis, and encoding;\n- system and component configuration;\n- requirements and hazard links;\n- source code and compiler assumptions;\n- calibration state and instrument uncertainty;\n- test method, article, environment, and results;\n- author, reviewer, authority, and conflicts;\n- supersession and change history; and\n- known anomalies and what would change the conclusion.\n\nA checksum can show that stored bytes changed. It cannot show that the bytes are still meaningful, correctly labeled, or safe to use.\n\n## Build the evidence and requirements graph\n\nStable identifiers and typed relationships make the archive inspectable:\n\n- source → claim → counterclaim;\n- mission need → requirement → rationale;\n- hazard → control → implementation;\n- implementation → configuration → installed asset;\n- requirement → verification method → result;\n- model → assumption → validity envelope;\n- maintenance action → measurement → calibration;\n- decision → authority → dissent → review;\n- software → source → build → binary → deployment;\n- format → representation information → migration.\n\nEach 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.\n\nThe graph can be exported in simple tables and documented schemas. It should not require one database product or AI model to interpret.\n\n## OAIS responsibilities on a ship\n\nThe 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.\n\nFor a ship:\n\n- **Ingest** verifies completeness, rights, provenance, representation information, and quarantine status.\n- **Storage** maintains replicated, checked, geographically and electrically separated copies.\n- **Data management** preserves identifiers, relationships, indexes, and review states.\n- **Administration** governs roles, access, retention, conflict, audit, and incident response.\n- **Preservation planning** watches media, format, software, hardware, vocabulary, and community change.\n- **Access** provides usable objects while protecting originals, privacy, and safety constraints.\n\n“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.\n\n## Formats, media, and readers\n\nThe 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.\n\nAn ark should prefer well-documented, nonexclusive formats while preserving originals. It also needs:\n\n- multiple media technologies and readers;\n- storage scrubbing and fixity checks;\n- error correction and replaceable components;\n- environmental monitoring;\n- offline and write-protected copies;\n- printed or otherwise low-complexity recovery instructions;\n- interface adapters and fabrication data;\n- migration plans before expertise or equipment disappears; and\n- proof that restoration works from an isolated copy.\n\nRedundancy is not diversity if all copies depend on the same controller firmware, encryption key, reader, power zone, or administrator.\n\n## Preserve software as a system\n\nSource code without a compiler, dependencies, build instructions, test data, hardware interfaces, and licenses may be an archaeological artifact.\n\nFor critical software retain:\n\n- source and exact dependency sources;\n- compiler, linker, build scripts, firmware tools, and configuration;\n- language and file-format specifications;\n- reproducible or independently comparable build results where practicable;\n- known-answer tests and representative hardware;\n- schemas, migration tools, and sample datasets;\n- threat, hazard, assurance, and verification records;\n- operational and recovery procedures; and\n- a human-readable description of intended behavior.\n\nPreserve 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.\n\n## Active migration without historical erasure\n\nMedia and formats age. Migration is necessary, but every transformation can lose features or context.\n\nA migration record should identify:\n\n- source and destination objects;\n- tools and versions;\n- operator and authority;\n- transformation rules;\n- properties intended to remain invariant;\n- checks performed;\n- differences, losses, and uncertainties;\n- accessibility result; and\n- location of the preserved original.\n\nCCSDS 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.\n\nIf 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.\n\n## Tacit skill and institutional memory\n\nSome 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.\n\nThe ark needs apprenticeship and performance:\n\n- rotate learners through essential functions;\n- practice diagnosis beyond normal scripts;\n- require people to demonstrate and teach tasks;\n- preserve mistakes and near misses without making blame the only lesson;\n- include disabled people and multiple ways to access material;\n- maintain terminology bridges across languages and eras;\n- rehearse with experts and AI unavailable; and\n- measure how long skill recovery actually takes.\n\nInstitutional memory also includes why a rule exists, who objected, and which harms it was designed to prevent. Sanitizing dissent makes future errors more likely.\n\n## Privacy, access, and legitimate forgetting\n\nAn 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.\n\nSeparate 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.\n\nThose tensions require constitutional governance, not an archivist or model acting alone. Emergency access should be narrow, logged, time-limited, and reviewed.\n\n## Poisoning and provenance\n\nKnowledge can be maliciously altered, accidentally mislabeled, or correctly signed but obsolete. Protect ingest, review, update, and migration:\n\n- quarantine active content;\n- compare new material with known baselines;\n- require typed provenance and review status;\n- scan links and executable dependencies without treating scans as proof;\n- preserve independent copies and witnesses;\n- expose conflicts and unresolved anomalies;\n- separate submission from approval; and\n- rehearse recovery from a poisoned index or retrieval corpus.\n\nW3C 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.\n\n## LLMs as index, not archive\n\nAn 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.\n\nRequire 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.\n\nThe ark must stay usable with every generative model unavailable. Maintain deterministic search, browsable indexes, documented schemas, plain exports, and taught human navigation.\n\n## Recovery test\n\nIsolate 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.\n\nThe team must:\n\n1. establish a trustworthy reading environment;\n2. find originals and provenance;\n3. identify the current applicable requirement;\n4. recover the software and tools;\n5. migrate without erasing differences;\n6. perform the physical task;\n7. explain uncertainty and dissent; and\n8. return new evidence to the archive.\n\nThat is a stronger preservation metric than terabytes stored.\n\n## Evidence ledger\n\n- **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.\n- **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.\n- **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.\n- **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.\n- **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.\n- **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.\n\nLinked 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.\n\n## Assumptions and limits\n\n- The ark is a governed service, not a single device, database, model, or physical vault.\n- OAIS is a reference model and does not certify a ship archive.\n- No medium, format, checksum, signature, or institution is assumed permanent.\n- Preservation includes correction and legitimate deletion where rights require it.\n- LLMs remain offline-capable, evidence-linked, logged, non-authoritative, removable, and unable to alter authoritative provenance silently.\n- Tacit competence must be demonstrated in physical work.\n- Offensive cyber operations and autonomous weapons are excluded.\n\n## What would change this conclusion?\n\nReadiness 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.\n\n## Sources and locators\n\n- [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.\n- [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.\n- [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.\n- [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.\n- [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.\n- [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.\n- [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.\n- [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.\n\n## Editorial record\n\n- Prepared by: GShips Project\n- Last edited: 2026-07-25\n- Required review: digital preservation, archival science, knowledge management, systems engineering, software preservation, cybersecurity, privacy, and education\n- Conflicts: Maintainer intends to explore a commercial venture based on some GShips work; no entity, funding, customer, sponsor, or partner relationship currently exists\n- 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\n- Scope boundary: Civil and defensive uses only; offensive cyber operations, autonomous weapons, weapon integration, and actionable exploitation instructions are excluded\n- Corrections: [Suggest a correction](https://gships.dammonburden.com/corrections)\n" } }, { "recordType": "academy-lesson", "recordId": "lesson-10-05", "title": "An AI constitution", "publicPath": "/academy/ai-knowledge/ai-constitution", "recordFingerprint": "44b3e62daab317299fb617e3903ac920018be088a8b1bbd7da99d8bd46938a28", "reviewRequirements": { "minimumIndependentApprovals": 1, "highConsequenceDomains": [], "requiredDomainCodes": [], "requiredComplementaryScopeGroups": [ { "id": "bounded-competence", "scopeClass": "bounded-competence", "oneOf": [ "ai-knowledge-assurance", "information-science" ] } ], "unresolvedNegativeFindingBlocksPublication": true }, "referenceIds": [], "snapshot": { "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", "trackSlug": "ai-knowledge", "trackTitle": "AI, LLMs, autonomy & knowledge", "href": "/academy/ai-knowledge/ai-constitution", "preparedBy": "GShips Project", "lastEditedAt": "2026-07-25", "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" ], "exactMdx": "---\nid: \"lesson-10-05\"\ntrack: \"ai-knowledge\"\nslug: \"ai-constitution\"\ntitle: \"An AI constitution\"\nsummary: \"Constitutionalize AI permissions, prohibited roles, evidence duties, privacy, appeal, update gates, emergency limits, model diversity, audit, and accountable human authority.\"\nminutes: 38\nlevel: \"Foundation\"\npreparedBy: \"GShips Project\"\nlastEditedAt: \"2026-07-25\"\nconflicts: \"Maintainer intends to explore a commercial venture based on some GShips work; no entity, funding, customer, sponsor, or partner relationship currently exists.\"\nreviewRequiredDomains: \"ai-governance, constitutional-design, human-rights, safety-engineering, ai-evaluation, cybersecurity, privacy, human-factors\"\nclaimIds: \"claim-11-01, claim-11-04, claim-11-06, claim-11-07, claim-11-10, claim-12-06, claim-12-10\"\n---\n\n# An AI constitution\n\n> **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.\n\n## Plain-language summary\n\nAn AI constitution answers a prior question to “What can the system do?”:\n\n**What may it do, for whom, under which evidence, with which appeal, and who remains accountable?**\n\nThe 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.\n\nIts core commitments are:\n\n- people retain rights and accountable authority;\n- safety does not depend on generative models;\n- consequential output is traceable to controlled evidence;\n- every automated effect has an external permission boundary;\n- no model approves its own update or evaluation;\n- residents can know, challenge, and correct consequential use;\n- emergency powers are narrow and temporary; and\n- the ship can operate safely with AI isolated.\n\n## Why a constitution rather than a policy prompt?\n\nA 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.\n\nIt 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.\n\nNIST’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.\n\n## Define roles by consequence\n\nClassify uses before selecting a model:\n\n### Informational\n\nSearch, 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.\n\n### Recommending\n\nCandidate 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.\n\n### Executing bounded tools\n\nA 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.\n\n### Controlling\n\nDirect 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.\n\n### Governing\n\nAI 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.\n\n## Nondelegable human accountability\n\n“The AI decided” is not an accountable explanation. Every consequential use needs a named human or public body responsible for:\n\n- authorizing the purpose;\n- ensuring lawful and rights-respecting data use;\n- selecting evidence and evaluation;\n- accepting residual risk;\n- reviewing operation;\n- responding to harm; and\n- retiring the system.\n\nResponsibility should not be assigned to the lowest-status operator who clicked “confirm.” Designers, maintainers, authorities, and institutions retain their shares.\n\nHigh-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.\n\n## Evidence duties\n\nConsequential output should carry an evidence packet:\n\n- model, runtime, prompt, tool, and configuration versions;\n- retrieval corpus and exact retrieved records;\n- source revision, locator, review state, and conflicts;\n- user identity and authorized role;\n- input and output, including rejected proposals;\n- distinction among observation, retrieved record, inference, simulation, and recommendation;\n- uncertainty, abstention, and unresolved contradiction;\n- tool preview and resulting state;\n- human decision and rationale; and\n- appeal, correction, and retention status.\n\nThe 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.\n\n## Privacy and limits on surveillance\n\nAn 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.\n\nThe constitution should require:\n\n- declared purpose and legal basis;\n- minimum necessary data;\n- separation of process telemetry from personal behavior;\n- restrictions on medical, reproductive, genetic, civic, and communications data;\n- access logging and resident visibility;\n- retention limits and legitimate deletion;\n- correction of inaccurate records;\n- protection against unrelated reuse;\n- independent authorization for invasive access; and\n- appeal and remedy.\n\nTraining or improving a model is not automatic permission to reuse personal data. De-identification has limits, especially in a small population.\n\n## Prompt, tool, and data integrity\n\nInstructions 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.\n\nNIST AI 100-2 also describes data and model poisoning, evasion, privacy, and misuse. The constitution should mandate:\n\n- provenance and separated approval for model, data, prompt, and tools;\n- quarantine and testing of new material;\n- least-privilege tools;\n- no secret-bearing context unless strictly required and controlled;\n- independent logging the model cannot erase;\n- red-team and misuse testing inside a defensive sandbox;\n- rollback and recovery;\n- refusal to act on unresolved provenance; and\n- incident notification and correction.\n\nTesting stays civil and defensive. It must not become live intrusion practice or weapon development.\n\n## Evaluation and abstention\n\nAn 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.\n\nAbstention is bounded behavior, not a magic phrase. Define when the system must:\n\n- state that evidence is missing;\n- show conflicting sources;\n- refuse an out-of-scope tool action;\n- route to a qualified person;\n- fall back to a controlled procedure; or\n- isolate itself after integrity loss.\n\nOver-refusal can also harm people by blocking access or delaying service. Evaluate both unsafe action and unsafe refusal.\n\n## Updates require constitutional review\n\nA new model, retrieval corpus, tool, prompt, fine-tune, quantization, runtime, or safety rule can change behavior. Each consequential update moves through the update airlock:\n\n1. preserve the old configuration;\n2. document purpose, provenance, and affected rights;\n3. evaluate on representative and adversarial cases;\n4. check resource, privacy, and accessibility effects;\n5. test common-mode failure and rollback;\n6. obtain independent technical and rights review;\n7. deploy in stages with defined health measures; and\n8. retain a tested non-AI workflow.\n\nThe model cannot generate the decisive evaluation, approve itself, or erase unfavorable results.\n\n## Diversity without a parliament of models\n\nMultiple models may improve exploration and reveal disagreement. They do not create legitimate authority and may share data, architectures, cultural assumptions, runtime, or evaluators.\n\nRecord independence across:\n\n- training and retrieval data;\n- developers and governance;\n- model family and implementation;\n- hardware, runtime, and toolchain;\n- evaluation and reviewers;\n- sensor and evidence sources; and\n- incentives and institutional power.\n\nFor safety, prefer diverse physical evidence and accountable people over majority vote among models.\n\n## Appeal, correction, and remedy\n\nAny person materially affected by AI-supported action should receive understandable notice where safety and privacy permit:\n\n- that AI contributed;\n- which role it played;\n- the governing rule;\n- the evidence and uncertainty;\n- the accountable authority;\n- how to contest records or outcome; and\n- what remedy is available.\n\nAppeal must reach an independent human body capable of changing the outcome. Preserve dissent and corrections in the evidence graph without rewriting the original event.\n\n## Emergency authority expires\n\nDuring an acute incident, temporary AI support may help summarize logs or allocate attention. It still cannot determine guilt or directly bypass physical safety.\n\nEmergency 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.\n\n## Skill retention and AI-off governance\n\nRights on paper fail if nobody can operate without the system. Maintain:\n\n- deterministic search and plain exports;\n- manual local control;\n- people trained to read primary evidence;\n- mixed-team exercises without AI;\n- the ability to rebuild or replace models locally;\n- lessons on automation bias and confident error; and\n- independent institutions with enough time and expertise to review.\n\nThe recurring test is not “Can people turn it off?” but “Can they remain safe, informed, and governed after turning it off?”\n\n## Evidence ledger\n\n- **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.\n- **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.\n- **L10-05-C — Generative models should not hold direct life-safety, identity, judicial, or constitutional authority.** Basis: normative decision boundary. Readiness: proposed. Confidence: strong.\n- **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.\n- **L10-05-E — Model diversity does not establish independence, truth, or legitimacy.** Basis: normative systems inference. Readiness: operational as analysis. Confidence: supported.\n- **L10-05-F — Safe AI-off operation, notice, appeal, correction, and expiring emergency authority are launch gates.** Basis: normative. Readiness: proposed. Confidence: supported.\n\nLinked 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.\n\n## Assumptions and limits\n\n- “Constitution” means binding governance and rights architecture, not a present legal instrument.\n- NIST and UNESCO guidance is adapted as context, not adopted automatically as ship law.\n- Capability, correctness, and popularity do not create authority.\n- Privacy, due process, accessibility, and remedy apply during ordinary and emergency operation.\n- LLMs remain offline-capable, evidence-linked, logged, non-authoritative, removable, and outside direct life-safety actuation.\n- Human review must be real, informed, timely, independent, and empowered to refuse.\n- Offensive cyber operations and autonomous weapons are excluded.\n\n## What would change this conclusion?\n\nA 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.\n\n## Sources and locators\n\n- [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.\n- [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.\n- [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.\n- [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.\n- [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.\n- [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.\n- [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.\n- [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.\n\n## Editorial record\n\n- Prepared by: GShips Project\n- Last edited: 2026-07-25\n- Required review: AI governance, constitutional design, human rights, safety engineering, AI evaluation, cybersecurity, privacy, and human factors\n- Conflicts: Maintainer intends to explore a commercial venture based on some GShips work; no entity, funding, customer, sponsor, or partner relationship currently exists\n- Relationship boundary: Independent educational synthesis; citations do not imply affiliation, endorsement, partnership, or adoption by NASA, NIST, UNESCO, CCSDS, or any named organization\n- Scope boundary: Civil and defensive uses only; offensive cyber operations, autonomous weapons, weapon integration, and actionable exploitation instructions are excluded\n- Corrections: [Suggest a correction](https://gships.dammonburden.com/corrections)\n" } } ], "linkedRecords": [ { "recordType": "claim", "recordId": "claim-11-01", "title": "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.", "publicPath": "/claims/claim-11-01", "recordFingerprint": "2b2c6728e9308b88365e344f701b7c321ba36223ed5b702c44f79b6011f567f1" }, { "recordType": "claim", "recordId": "claim-11-02", "title": "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.", "publicPath": "/claims/claim-11-02", "recordFingerprint": "38271e4711b5d6e7f7c6d2dfeb4c92a067b527bf2ccb4a97448e71da4384b806" }, { "recordType": "claim", "recordId": "claim-11-03", "title": "NASA’s Starling demonstrations address distributed multi-spacecraft autonomy as a separate mission and evidence class.", "publicPath": "/claims/claim-11-03", "recordFingerprint": "77f0e6c3c5d9c49ce7e4af054dbcf2fe76ad2da3bd702417d4593e5eff14272a" }, { "recordType": "claim", "recordId": "claim-11-04", "title": "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.", "publicPath": "/claims/claim-11-04", "recordFingerprint": "56fe8de4eacc7361e91be29cd7d3acd32945264b2202031883139d03e96a065b" }, { "recordType": "claim", "recordId": "claim-11-05", "title": "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.", "publicPath": "/claims/claim-11-05", "recordFingerprint": "ecccb3fd9bc72f211c52006694627970e079c0285b2fa385aa7354f895940e80" }, { "recordType": "claim", "recordId": "claim-11-06", "title": "This foundation corpus contains no published demonstration of a generative or autonomous system maintaining safe, legitimate judgment for a diverse crew across generations.", "publicPath": "/claims/claim-11-06", "recordFingerprint": "fe5dbd4bf05ae0a9f0ab04b432ded2e149b963bd465b088f67bad33c161b5d48" }, { "recordType": "claim", "recordId": "claim-11-07", "title": "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.", "publicPath": "/claims/claim-11-07", "recordFingerprint": "768bb2389d46e55e38419c092772ff24a490b471c33fed16d5351f70c3fb3f7c" }, { "recordType": "claim", "recordId": "claim-11-08", "title": "Robots still lack the broad manipulation, diagnosis, fabrication, and self-repair needed to maintain a worldship.", "publicPath": "/claims/claim-11-08", "recordFingerprint": "8e0a459bb7f93a19fc0cacea0dc2b7eb61b1dcfbe408d3a0ec75190c2caf09fb" }, { "recordType": "claim", "recordId": "claim-11-09", "title": "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.", "publicPath": "/claims/claim-11-09", "recordFingerprint": "de198a3912f3c2315c4cbf9edf97b6e782e38a95404da605e1f57c895c550804" }, { "recordType": "claim", "recordId": "claim-11-10", "title": "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.", "publicPath": "/claims/claim-11-10", "recordFingerprint": "4c48cfe2109462b8663ca6f17458b61b4867bd93f22b1e45b23700765e45589f" }, { "recordType": "claim", "recordId": "claim-12-01", "title": "Generation-ship security protects a civilization’s ability to operate, repair, govern, learn, and recover without an external rescuer—not merely its secrets.", "publicPath": "/claims/claim-12-01", "recordFingerprint": "908842da73f03771a9e09cc29bdc8e3863610f7ab9de665f452f153f7bb618b1" }, { "recordType": "claim", "recordId": "claim-12-03", "title": "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.", "publicPath": "/claims/claim-12-03", "recordFingerprint": "6055efdd9314736b322ecafce96268e59c3ddc2c7874b92f43b11b7494689e92" }, { "recordType": "claim", "recordId": "claim-12-06", "title": "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.", "publicPath": "/claims/claim-12-06", "recordFingerprint": "e661cc2789a8cd078b10a5fa6f5f4bb267c1dcdcc4156a6fd1870fa857a41db2" }, { "recordType": "claim", "recordId": "claim-12-07", "title": "Onboard manufacturing makes malicious designs, poisoned toolchains, compromised metrology, counterfeit replacement parts, and configuration drift cyber-physical threats.", "publicPath": "/claims/claim-12-07", "recordFingerprint": "aa41b5d69f1e2cb946f156453cc5e43165f992ffba714ec0b1562413e4751e5c" }, { "recordType": "claim", "recordId": "claim-12-09", "title": "Crypto agility and toolchain escrow reduce obsolescence risk in medical, energy, transport, and public systems.", "publicPath": "/claims/claim-12-09", "recordFingerprint": "4c3588aab47e1175acc7a32a66fd16e23f01df3fd603f3d4005e2e5503935290" }, { "recordType": "claim", "recordId": "claim-12-10", "title": "Mixed crews must repeatedly isolate a compromised zone, maintain life support, investigate locally, rebuild from known-good material, and rejoin safely.", "publicPath": "/claims/claim-12-10", "recordFingerprint": "718e87306ab83c20b2c477e928406ce5697e01b1a5b64ab9cde6d6fbcbe148be" }, { "recordType": "claim", "recordId": "claim-13-10", "title": "Demonstrate navigation and archive recovery without current experts, cloud services, vendor activation, or a single surviving medium.", "publicPath": "/claims/claim-13-10", "recordFingerprint": "9a0804519f7429d31171c7d94d71193233fc9f50a207a8063d1353d63a7218d4" }, { "recordType": "claim", "recordId": "claim-14-04", "title": "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.", "publicPath": "/claims/claim-14-04", "recordFingerprint": "dab0d99f8643dd9ec84e855e088691e529a0453089c891572f462388312de61e" } ], "referenceSnapshots": [ { "sourceId": "src-ak-nasa-digital-twin-2012", "sourceRecordType": "claim-source", "sourceFingerprint": "7dc587fc2cc5f55374f633dae2558909763aeb1c1337e479fd947424badc95ad", "snapshot": { "id": "src-ak-nasa-digital-twin-2012", "title": "The Digital Twin Paradigm for Future NASA and U.S. Air Force Vehicles", "authors": [ "Edward H. Glaessgen", "David S. Stargel" ], "publisher": "NASA Technical Reports Server", "year": 2012, "url": "https://ntrs.nasa.gov/citations/20120008178", "kind": "government-concept-paper", "checkedAt": "2026-07-25", "scopeNote": "Early digital-twin concept integrating models and vehicle data across a lifecycle, presented as a future paradigm and research direction rather than an operational certification." } }, { "sourceId": "src-ak-nasa-ds1-remote-agent", "sourceRecordType": "claim-source", "sourceFingerprint": "ec23247e17991e05a5e88a376fd8f21d79009c4d5dff22e7cc230af82f876ac1", "snapshot": { "id": "src-ak-nasa-ds1-remote-agent", "title": "Deep Space 1: Autonomous Remote Agent", "authors": [ "NASA Jet Propulsion Laboratory" ], "publisher": "NASA/JPL", "year": 1999, "url": "https://www.jpl.nasa.gov/nmp/ds1/tech/autora.html", "kind": "official-flight-experiment-record", "checkedAt": "2026-07-25", "scopeNote": "Official account of bounded onboard planning, execution, selected-subsystem control, four simulated faults, a timing bug, experiment pause, and ground-team involvement. Browser-accessible official content returns HTTP 403 to automated checks." } }, { "sourceId": "src-ak-nasa-models-simulations-7009b", "sourceRecordType": "claim-source", "sourceFingerprint": "8f6e834f09954fef302c7b3ecfb02347690909841cabd58f172c74eac18e2b7f", "snapshot": { "id": "src-ak-nasa-models-simulations-7009b", "title": "Standard for Models and Simulations", "authors": [ "National Aeronautics and Space Administration" ], "publisher": "NASA", "year": 2024, "url": "https://standards.nasa.gov/standard/nasa/nasa-std-7009", "kind": "active-modeling-simulation-standard", "checkedAt": "2026-07-25", "scopeNote": "NASA requirements and guidance for intended use, model lifecycle, credibility products, verification, validation, uncertainty, configuration management, results, and acceptance." } }, { "sourceId": "src-ak-nasa-software-assurance-87398b", "sourceRecordType": "claim-source", "sourceFingerprint": "d6427b989658379d4754ab20c93d5cf9535fe23c6ca356c7d311a285029d3140", "snapshot": { "id": "src-ak-nasa-software-assurance-87398b", "title": "Software Assurance and Software Safety Standard", "authors": [ "National Aeronautics and Space Administration" ], "publisher": "NASA", "year": 2022, "url": "https://standards.nasa.gov/standard/NASA/NASA-STD-87398", "kind": "active-software-assurance-standard", "checkedAt": "2026-07-25", "scopeNote": "NASA lifecycle requirements for software assurance, software safety, security, objective evidence, requirements mapping, independent verification and validation, maintenance, and retirement." } }, { "sourceId": "src-ak-nasa-starling-flight-results", "sourceRecordType": "claim-source", "sourceFingerprint": "c420a1d5ded26b43b4f0db1a9c8c6b965addc96d75026b3ad381bfaa88cd7a77", "snapshot": { "id": "src-ak-nasa-starling-flight-results", "title": "Starling CubeSat Swarm Technology Demonstration Flight Results", "authors": [ "NASA Starling Project Team" ], "publisher": "NASA Technical Reports Server", "year": 2024, "url": "https://ntrs.nasa.gov/citations/20240006994", "kind": "official-flight-demonstration-report", "checkedAt": "2026-07-25", "scopeNote": "Mission architecture and bounded results for networking, optical navigation, autonomous maneuver planning, and distributed science autonomy across a four-CubeSat demonstration." } }, { "sourceId": "src-ak-nist-ai-rmf-100-1", "sourceRecordType": "claim-source", "sourceFingerprint": "44ed404a35aadd12a293b2b0f7e8939ef43b5d3c4114c9d456aaec429fd5e411", "snapshot": { "id": "src-ak-nist-ai-rmf-100-1", "title": "Artificial Intelligence Risk Management Framework (AI RMF 1.0)", "authors": [ "Elham Tabassi" ], "publisher": "NIST", "year": 2023, "url": "https://doi.org/10.6028/NIST.AI.100-1", "kind": "government-ai-risk-management-framework", "checkedAt": "2026-07-25", "scopeNote": "Voluntary sociotechnical AI risk framework defining trustworthy characteristics and the Govern, Map, Measure, and Manage functions; not a generation-ship assurance standard." } }, { "sourceId": "src-ak-nist-digital-twin-8356", "sourceRecordType": "claim-source", "sourceFingerprint": "500f59e2c271844456dfb2599f2dd243c83fe149ff6345a5de803fee3cdc300e", "snapshot": { "id": "src-ak-nist-digital-twin-8356", "title": "Security and Trust Considerations for Digital Twin Technology", "authors": [ "Jeff Voas", "Peter Mell", "Phillip Laplante", "Vartan Piroumian" ], "publisher": "NIST", "year": 2025, "url": "https://doi.org/10.6028/NIST.IR.8356", "kind": "government-digital-twin-trust-report", "checkedAt": "2026-07-25", "scopeNote": "Digital-twin concepts, components, operations, use scenarios, applications, cybersecurity considerations, and trust limitations; does not define or certify a universal digital twin." } }, { "sourceId": "src-ak-nist-ssdf-ai-800218a", "sourceRecordType": "claim-source", "sourceFingerprint": "83d3d0fd2357e1ad2ee1db05b3a6d25921c7e4abd3125132831fff5213ef2148", "snapshot": { "id": "src-ak-nist-ssdf-ai-800218a", "title": "Secure Software Development Practices for Generative AI and Dual-Use Foundation Models: An SSDF Community Profile", "authors": [ "Harold Booth", "Murugiah Souppaya", "Apostol Vassilev", "Michael Ogata", "Martin Stanley", "Karen Scarfone" ], "publisher": "NIST", "year": 2024, "url": "https://doi.org/10.6028/NIST.SP.800-218A", "kind": "government-ai-secure-development-guidance", "checkedAt": "2026-07-25", "scopeNote": "AI-specific additions to secure-development practices for organizational preparation, artifact protection, well-secured production, evaluation, release, and vulnerability response." } }, { "sourceId": "src-ak-unesco-ai-ethics", "sourceRecordType": "claim-source", "sourceFingerprint": "5df6900912cc9c2a8b02845211ccf6dff726220b3600e353bb6eaf2e75f0767d", "snapshot": { "id": "src-ak-unesco-ai-ethics", "title": "Recommendation on the Ethics of Artificial Intelligence", "authors": [ "UNESCO General Conference" ], "publisher": "UNESCO", "year": 2021, "url": "https://www.unesco.org/en/legal-affairs/recommendation-ethics-artificial-intelligence?hub=1063", "kind": "intergovernmental-normative-recommendation", "checkedAt": "2026-07-25", "scopeNote": "Normative values, principles, and policy actions concerning human dignity, rights, proportionality, safety, fairness, privacy, oversight, responsibility, transparency, governance, and ethical impact." } }, { "sourceId": "src-cr-ccsds-350-0-g-3", "sourceRecordType": "claim-source", "sourceFingerprint": "44f5371a3c01028d94ba87eb2c3367b47b781a3fe2f7de8e0bb5c7486278d8fb", "snapshot": { "id": "src-cr-ccsds-350-0-g-3", "title": "The Application of Security to CCSDS Protocols", "authors": [ "Consultative Committee for Space Data Systems" ], "publisher": "CCSDS", "year": 2019, "url": "https://public.ccsds.org/Pubs/350x0g3.pdf", "kind": "ccsds-informational-green-book", "checkedAt": "2026-07-26", "version": "CCSDS 350.0-G-3, Issue 3", "scopeNote": "Consensus informational report on security concepts, mechanisms, implementation options, and effects on CCSDS services, primarily for space-ground and ground-space links. The report explicitly is not a CCSDS Recommended Standard and excludes detailed security-analysis and risk-assessment methods." } }, { "sourceId": "src-cr-cisa-sbom", "sourceRecordType": "claim-source", "sourceFingerprint": "d551139e9329c0f04e2480582f3dd9123e7d717b8bfedf5cb6141bc087053d16", "snapshot": { "id": "src-cr-cisa-sbom", "title": "Software Bill of Materials", "authors": [ "Cybersecurity and Infrastructure Security Agency" ], "publisher": "CISA", "year": 2026, "url": "https://www.cisa.gov/sbom", "kind": "government-software-transparency-resource", "checkedAt": "2026-07-25", "scopeNote": "Official SBOM definition, ecosystem roles, use cases, community resources, and minimum-elements guidance; an SBOM is component evidence rather than proof of safety." } }, { "sourceId": "src-cr-ietf-rfc9019-suit", "sourceRecordType": "claim-source", "sourceFingerprint": "f89082ee842c244fde0169bd864fb0a0b2e4390d2b8bda120bbe1fcb414b62e7", "snapshot": { "id": "src-cr-ietf-rfc9019-suit", "title": "A Firmware Update Architecture for Internet of Things", "authors": [ "Brendan Moran", "Hannes Tschofenig", "David Brown", "Milton Meriac" ], "publisher": "IETF", "year": 2021, "url": "https://www.rfc-editor.org/rfc/rfc9019", "kind": "ietf-informational-architecture", "checkedAt": "2026-07-25", "scopeNote": "Informational IETF architecture for authenticated firmware manifests, stakeholder separation, target matching, sequence control, dependencies, interruption tolerance, and recovery." } }, { "sourceId": "src-cr-nasa-cryptolib-2023", "sourceRecordType": "claim-source", "sourceFingerprint": "841fcaee2944c6aef6a4e4b5275ddaaea99533977c6de713671c428d94b6998c", "snapshot": { "id": "src-cr-nasa-cryptolib-2023", "title": "The State of CryptoLib – The Open-Source Satellite Cryptography Library", "authors": [ "D. Cody Cutright", "Scott A. Zemerick", "Robert J. Brown", "John P. Lucas", "Justin R. Morris" ], "publisher": "NASA Technical Reports Server", "year": 2023, "url": "https://ntrs.nasa.gov/citations/20230015937", "kind": "nasa-conference-abstract", "checkedAt": "2026-07-26", "scopeNote": "Professionally reviewed conference record distributed in 2023; NTRS marks the available record onlyAbstract=true. The abstract describes an actively developed open-source C library that aims to be CCSDS Space Data Link Security compliant and reports selected Telecommand, Telemetry, and Advanced Orbiting Systems encryption and decryption functions. It does not establish CCSDS conformance, secure implementation, operational deployment, flight qualification, key-management assurance, or long-duration maintenance." } }, { "sourceId": "src-cr-nasa-space-security-bpg-revb", "sourceRecordType": "claim-source", "sourceFingerprint": "49def0ff9598b6f4abebd7c72c8abe70acd2cba861d8cb9407389b95a0ef3d94", "snapshot": { "id": "src-cr-nasa-space-security-bpg-revb", "title": "Space Security: Best Practices Guide", "authors": [ "National Aeronautics and Space Administration" ], "publisher": "NASA", "year": 2024, "url": "https://swehb.nasa.gov/download/attachments/166592616/Space%20Security%20Best%20Practices%20Guide%20BPG%20REV%20B.pdf?api=v2", "kind": "nasa-space-security-guidance", "checkedAt": "2026-07-26", "version": "Revision B", "documentDate": "2024-01-19", "scopeNote": "Public NASA guidance translating selected NIST SP 800-53 controls into space-vehicle and ground-segment mission language. It is a risk-based starting point and expressly does not replace required plans or establish a certified architecture, flight qualification, or long-duration assurance." } }, { "sourceId": "src-cr-nist-aml-100-2e2025", "sourceRecordType": "claim-source", "sourceFingerprint": "1573c29a25a7b8302f31f3a676e7e80866b6ff58e0c0718e60a38f52ecbd3e5a", "snapshot": { "id": "src-cr-nist-aml-100-2e2025", "title": "Adversarial Machine Learning: A Taxonomy and Terminology of Attacks and Mitigations", "authors": [ "Apostol Vassilev", "Alina Oprea", "Alie Fordyce", "Hyrum Anderson", "Xander Davies", "Maia Hamin" ], "publisher": "NIST", "year": 2025, "url": "https://doi.org/10.6028/NIST.AI.100-2e2025", "kind": "government-ai-security-taxonomy", "checkedAt": "2026-07-25", "scopeNote": "Predictive- and generative-AI evasion, poisoning, privacy, and misuse taxonomy, lifecycle stages, attacker capabilities, mitigations, and limitations." } }, { "sourceId": "src-cr-nist-controls-80053r5", "sourceRecordType": "claim-source", "sourceFingerprint": "efe4dc6860fbdda228dced85b87695df8d60684aeb6526e328be4724db7cc583", "snapshot": { "id": "src-cr-nist-controls-80053r5", "title": "Security and Privacy Controls for Information Systems and Organizations", "authors": [ "Joint Task Force" ], "publisher": "NIST", "year": 2020, "url": "https://doi.org/10.6028/NIST.SP.800-53r5", "kind": "government-security-privacy-control-catalog", "checkedAt": "2026-07-25", "scopeNote": "Control families spanning access, audit, contingency, identity, incident response, privacy, supply chain, communications, and system integrity; a catalog to tailor, not a certified architecture." } }, { "sourceId": "src-cr-nist-crypto-agility-cswp39u1", "sourceRecordType": "claim-source", "sourceFingerprint": "e00c46443bd97a74130ad2e19af942cfe9a635c7eea66e135de4171632673b05", "snapshot": { "id": "src-cr-nist-crypto-agility-cswp39u1", "title": "Considerations for Achieving Crypto Agility: Strategies and Practices", "authors": [ "Elaine Barker", "Lily Chen", "David Cooper", "Dustin Moody", "Andrew Regenscheid", "Murugiah Souppaya", "William Newhouse", "Russ Housley", "Sean Turner", "William Barker", "Karen Kent" ], "publisher": "NIST", "year": 2026, "url": "https://csrc.nist.gov/pubs/cswp/39/upd1/considerations-for-achieving-crypto-agility/final", "kind": "government-cryptographic-transition-guidance", "checkedAt": "2026-07-25", "scopeNote": "Inventory, discovery, operational mechanisms, transition strategies, protocol and application considerations, trade-offs, and open work for cryptographic agility; updated through 2026-06-29." } }, { "sourceId": "src-cr-nist-cyber-resilience-800160v2r1", "sourceRecordType": "claim-source", "sourceFingerprint": "44c9cb7acf30fe7dae9002044900433af81212da661b965f9264af72a409aec1", "snapshot": { "id": "src-cr-nist-cyber-resilience-800160v2r1", "title": "Developing Cyber-Resilient Systems: A Systems Security Engineering Approach", "authors": [ "National Institute of Standards and Technology" ], "publisher": "NIST", "year": 2021, "url": "https://doi.org/10.6028/NIST.SP.800-160v2r1", "kind": "government-cyber-resilience-guidance", "checkedAt": "2026-07-25", "scopeNote": "Cyber-resiliency goals, objectives, techniques, approaches, design principles, and systems-engineering lifecycle; not a generation-ship architecture or certification." } }, { "sourceId": "src-cr-nist-firmware-800193", "sourceRecordType": "claim-source", "sourceFingerprint": "08984a00ed4540ac34b3290412d4c5c6eddd595f4207fee8aa92a63c48b9017c", "snapshot": { "id": "src-cr-nist-firmware-800193", "title": "Platform Firmware Resiliency Guidelines", "authors": [ "Andrew Regenscheid" ], "publisher": "NIST", "year": 2018, "url": "https://doi.org/10.6028/NIST.SP.800-193", "kind": "government-platform-resilience-guidance", "checkedAt": "2026-07-25", "scopeNote": "Roots of trust and mechanisms to protect, detect, and recover platform firmware and critical data after destructive attacks." } }, { "sourceId": "src-cr-nist-incident-80061r3", "sourceRecordType": "claim-source", "sourceFingerprint": "5f3dd381a84f21187a92324d4aa5da91ce04e14d59aef5f5faaca6227359d59d", "snapshot": { "id": "src-cr-nist-incident-80061r3", "title": "Incident Response Recommendations and Considerations for Cybersecurity Risk Management: A CSF 2.0 Community Profile", "authors": [ "Alexander Nelson", "Sanjay Rekhi", "Murugiah Souppaya", "Karen Scarfone" ], "publisher": "NIST", "year": 2025, "url": "https://doi.org/10.6028/NIST.SP.800-61r3", "kind": "government-incident-response-guidance", "checkedAt": "2026-07-25", "scopeNote": "Incident preparation, detection, response, recovery, communications, analysis, mitigation, and improvement across CSF 2.0 functions." } }, { "sourceId": "src-cr-nist-key-management-80057p1r5", "sourceRecordType": "claim-source", "sourceFingerprint": "8de5e1eb786969d11a6a1544085a1663f7c54cfb69eb79f4de3da9231844c3cf", "snapshot": { "id": "src-cr-nist-key-management-80057p1r5", "title": "Recommendation for Key Management: Part 1 — General", "authors": [ "Elaine Barker" ], "publisher": "NIST", "year": 2020, "url": "https://doi.org/10.6028/NIST.SP.800-57pt1r5", "kind": "government-key-management-guidance", "checkedAt": "2026-07-25", "scopeNote": "Cryptographic services, key types, lifecycle functions, protection, compromise, backup, recovery, archival, and destruction." } }, { "sourceId": "src-cr-nist-recovery-800184", "sourceRecordType": "claim-source", "sourceFingerprint": "d43cc61a580591a7ef3ddd073f2913df1e480bf7d7866279bca0d53880fd780c", "snapshot": { "id": "src-cr-nist-recovery-800184", "title": "Guide for Cybersecurity Event Recovery", "authors": [ "Michael Bartock", "Jeffrey Cichonski", "Murugiah Souppaya", "Matthew Smith", "Greg Witte", "Karen Scarfone" ], "publisher": "NIST", "year": 2016, "url": "https://doi.org/10.6028/NIST.SP.800-184", "kind": "government-cyber-recovery-guidance", "checkedAt": "2026-07-25", "scopeNote": "Recovery planning, playbooks, testing, metrics, restoration, and improvement for current organizations; assumes terrestrial institutional support." } }, { "sourceId": "src-cr-nist-scrm-800161r1u1", "sourceRecordType": "claim-source", "sourceFingerprint": "02be470198b0c48432a90e4c5ac8374c588bad818fe7b37a7b663719ccab90bf", "snapshot": { "id": "src-cr-nist-scrm-800161r1u1", "title": "Cybersecurity Supply Chain Risk Management Practices for Systems and Organizations", "authors": [ "Jon Boyens", "Angela Smith", "Nadya Bartol", "Kris Winkler", "Alex Holbrook", "Matthew Fallon" ], "publisher": "NIST", "year": 2024, "url": "https://doi.org/10.6028/NIST.SP.800-161r1-upd1", "kind": "government-supply-chain-risk-guidance", "checkedAt": "2026-07-25", "scopeNote": "Multilevel lifecycle guidance for identifying, assessing, and mitigating malicious functionality, counterfeit, tampering, and poor development or manufacturing practice." } }, { "sourceId": "src-cr-nist-ssdf-800218", "sourceRecordType": "claim-source", "sourceFingerprint": "bda553d2c9f6bc9091b819eb153491cf8392cac73836f86a15eefee22fac1003", "snapshot": { "id": "src-cr-nist-ssdf-800218", "title": "Secure Software Development Framework (SSDF) Version 1.1", "authors": [ "Murugiah Souppaya", "Karen Scarfone", "Donna Dodson" ], "publisher": "NIST", "year": 2022, "url": "https://doi.org/10.6028/NIST.SP.800-218", "kind": "government-secure-development-guidance", "checkedAt": "2026-07-25", "scopeNote": "Outcome-based practices for preparing an organization, protecting software, producing well-secured releases, and responding to vulnerabilities." } }, { "sourceId": "src-cu-ilo-r208", "sourceRecordType": "claim-source", "sourceFingerprint": "7f0ffeba7f122098cb810e1767cffa060cd7dec7286cd0ebbe89aefd76423fe7", "snapshot": { "id": "src-cu-ilo-r208", "title": "Quality Apprenticeships Recommendation, 2023 (No. 208)", "authors": [ "International Labour Organization" ], "publisher": "International Labour Organization", "year": 2023, "url": "https://www.ilo.org/resource/other/r208-quality-apprenticeships-recommendation-2023", "kind": "international-labour-recommendation", "checkedAt": "2026-07-25", "scopeNote": "Recommendation text on structured learning, agreements, inclusion, worker participation, safety, compensation, mentoring, assessment, qualifications, and apprentices' rights." } }, { "sourceId": "src-cu-unesco-genai-education", "sourceRecordType": "claim-source", "sourceFingerprint": "ed1746a19077b3ecd178cc5bfff679bf94370ef3e3038770e28b28e0fb515e99", "snapshot": { "id": "src-cu-unesco-genai-education", "title": "Guidance for Generative AI in Education and Research", "authors": [ "United Nations Educational, Scientific and Cultural Organization" ], "publisher": "UNESCO", "year": 2023, "url": "https://unesdoc.unesco.org/ark:/48223/pf0000386693", "kind": "un-education-and-ai-guidance", "checkedAt": "2026-07-25", "scopeNote": "Human agency, inclusion, linguistic and cultural diversity, data protection, age appropriateness, validation, governance, and educational-use guidance." } }, { "sourceId": "src-cu-w3c-wcag22", "sourceRecordType": "claim-source", "sourceFingerprint": "36d83ac5a6eceb59dcdfb30918e2154e158d015fa3c29031673845a594599b7e", "snapshot": { "id": "src-cu-w3c-wcag22", "title": "Web Content Accessibility Guidelines 2.2", "authors": [ "World Wide Web Consortium" ], "publisher": "W3C", "year": 2023, "url": "https://www.w3.org/TR/WCAG22/", "kind": "international-web-accessibility-standard", "checkedAt": "2026-07-25", "scopeNote": "Technology-neutral principles, guidelines, success criteria, conformance requirements, and limits for perceivable, operable, understandable, and robust web content." } }, { "sourceId": "src-cu-who-unicef-assistive-technology", "sourceRecordType": "claim-source", "sourceFingerprint": "8453de49aa65cf960e18570b9c038ea2a575728ec37a5a198392e3abd1c6bb36", "snapshot": { "id": "src-cu-who-unicef-assistive-technology", "title": "Global Report on Assistive Technology", "authors": [ "World Health Organization", "United Nations Children's Fund" ], "publisher": "World Health Organization", "year": 2022, "url": "https://www.who.int/publications/i/item/9789240049451", "kind": "un-global-health-evidence-report", "checkedAt": "2026-07-25", "scopeNote": "Global evidence and recommendations concerning assistive-technology access, people, products, provision, personnel, policy, services, and persistent access gaps." } }, { "sourceId": "src-im-gao-isam-2025", "sourceRecordType": "claim-source", "sourceFingerprint": "f34a4c41466659821eede3dfde4b257733374fd7d50c558c8f7d1bbb1078a8e7", "snapshot": { "id": "src-im-gao-isam-2025", "title": "In-Space Servicing, Assembly, and Manufacturing: Benefits, Challenges, and Policy Options", "authors": [ "U.S. Government Accountability Office" ], "publisher": "U.S. Government Accountability Office", "year": 2025, "url": "https://www.gao.gov/products/gao-25-107555", "kind": "government-technology-assessment", "checkedAt": "2026-07-25", "scopeNote": "Independent government assessment of demonstrated servicing, limited robotic use, test-access gaps, emerging standards, serviceability, costs, and policy options." } }, { "sourceId": "src-im-nasa-eee-873910", "sourceRecordType": "claim-source", "sourceFingerprint": "7de974366c68ddd53ce47a7829040b0f7d644de2713f873827f7eacbe97c2287", "snapshot": { "id": "src-im-nasa-eee-873910", "title": "Electrical, Electronic, and Electromechanical Parts Assurance Standard", "authors": [ "National Aeronautics and Space Administration" ], "publisher": "NASA", "year": 2017, "url": "https://standards.nasa.gov/standard/NASA/NASA-STD-873910", "kind": "active-electronic-parts-assurance-standard", "checkedAt": "2026-07-25", "scopeNote": "Selection, acquisition, traceability, testing, handling, packaging, storage, application, and risk control for spaceflight electronic and electromechanical parts." } }, { "sourceId": "src-im-nasa-isam-2025", "sourceRecordType": "claim-source", "sourceFingerprint": "4ee5cffad11832f3a52484c44217ef44f63bb5d5da9e3d47186f35fea1ab886d", "snapshot": { "id": "src-im-nasa-isam-2025", "title": "In-Space Servicing, Assembly, and Manufacturing State of Play: 2025 Edition", "authors": [ "John Mulvaney", "Dale Arney", "Christina Williams", "Jose Morel", "Christopher Stockdale", "Christopher Whitlock", "Vishruth Balaji" ], "publisher": "NASA Technical Reports Server", "year": 2025, "url": "https://ntrs.nasa.gov/citations/20250008988", "kind": "institutional-state-of-the-art", "checkedAt": "2026-07-25", "scopeNote": "NASA peer-committee-reviewed taxonomy and status survey of inspection, servicing, assembly, fabrication, repair, construction, and enabling capabilities." } }, { "sourceId": "src-im-nasa-ism-portfolio-2025", "sourceRecordType": "claim-source", "sourceFingerprint": "06cea319893cf8240cb44a60e3ce511ca3f41a48b46c87b9915567ef6fc29ba1", "snapshot": { "id": "src-im-nasa-ism-portfolio-2025", "title": "In-Space Manufacturing Portfolio Plan", "authors": [ "National Aeronautics and Space Administration" ], "publisher": "NASA Technical Reports Server", "year": 2025, "url": "https://ntrs.nasa.gov/citations/20250004020", "kind": "institutional-technology-portfolio", "checkedAt": "2026-07-25", "scopeNote": "Program record for polymer, metal, electronics, welding, recycling, inspection, and biomanufacturing work, including the incomplete ISS Refabricator demonstration." } }, { "sourceId": "src-im-nasa-metrology-873912", "sourceRecordType": "claim-source", "sourceFingerprint": "8fa80c312101f162e43d1a51a136596e2cd0ff81f1b218ff7227df062b3e3540", "snapshot": { "id": "src-im-nasa-metrology-873912", "title": "Metrology and Calibration", "authors": [ "National Aeronautics and Space Administration" ], "publisher": "NASA", "year": 2024, "url": "https://standards.nasa.gov/standard/NASA/NASA-STD-873912", "kind": "active-metrology-calibration-standard", "checkedAt": "2026-07-25", "scopeNote": "Selection, calibration, control, and use of measuring and test equipment whose results affect safety or mission success." } }, { "sourceId": "src-im-nasa-std-6030", "sourceRecordType": "claim-source", "sourceFingerprint": "7e6a5d45f27e760d46772f9f030ecd9397047f8274aa4525946c18e6d6b34d90", "snapshot": { "id": "src-im-nasa-std-6030", "title": "Additive Manufacturing Requirements for Spaceflight Systems", "authors": [ "National Aeronautics and Space Administration" ], "publisher": "NASA", "year": 2021, "url": "https://standards.nasa.gov/standard/NASA/NASA-STD-6030", "kind": "active-spaceflight-manufacturing-standard", "checkedAt": "2026-07-26", "version": "Baseline", "changeNumber": 0, "documentDate": "2021-04-21", "status": "ACTIVE", "reviewDue": "2026-04-21", "freshnessNote": "NASA still marks the baseline ACTIVE even though the listed five-year review date has passed; GShips therefore treats it as current-with-review-due rather than obsolete.", "scopeNote": "Requirements for part classification, feedstock and process control, machine qualification, witness material, inspection, acceptance, configuration, and tailored in-space additive manufacturing. This is normative authority for NASA spaceflight hardware, not a demonstration of printed-part performance, autonomous repair, circular manufacturing, or cyber recovery." } }, { "sourceId": "src-im-nist-ot-80082r3", "sourceRecordType": "claim-source", "sourceFingerprint": "079024b69f4ab4aeaa8755b5bf62674b9f4cae4428d4ea97744c9cb78cdb593e", "snapshot": { "id": "src-im-nist-ot-80082r3", "title": "Guide to Operational Technology Security", "authors": [ "Keith Stouffer", "Michael Pease", "CheeYee Tang", "Timothy Zimmerman", "Victoria Pillitteri", "Suzanne Lightman", "Adam Hahn", "Stephanie Saravia", "Aslam Sherule", "Michael Thompson" ], "publisher": "NIST", "year": 2023, "url": "https://doi.org/10.6028/NIST.SP.800-82r3", "kind": "government-cybersecurity-guidance", "checkedAt": "2026-07-25", "scopeNote": "Operational-technology architectures, safety and availability constraints, threats, segmentation, supply-chain and maintenance risks, countermeasures, and recovery." } }, { "sourceId": "src-mp-nasa-se-handbook", "sourceRecordType": "claim-source", "sourceFingerprint": "3337ce334909311c3ab1c604773fdcc31a01dd8e0e781d040debd3b6e33cea22", "snapshot": { "id": "src-mp-nasa-se-handbook", "title": "NASA Systems Engineering Handbook", "authors": [ "National Aeronautics and Space Administration" ], "publisher": "NASA", "year": 2016, "url": "https://www.nasa.gov/wp-content/uploads/2018/09/nasa_systems_engineering_handbook_0.pdf", "kind": "institutional-handbook", "checkedAt": "2026-07-25", "scopeNote": "Lifecycle, requirements, interfaces, verification, validation, decision analysis, and risk." } }, { "sourceId": "src-pa-nist-ai-600-1", "sourceRecordType": "claim-source", "sourceFingerprint": "4066eeecafdc810d0ad828dd8bd53e4a05daeb6b03dde36fafe581976402cb59", "snapshot": { "id": "src-pa-nist-ai-600-1", "title": "Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile", "authors": [ "National Institute of Standards and Technology" ], "publisher": "NIST", "year": 2024, "url": "https://doi.org/10.6028/NIST.AI.600-1", "kind": "government-risk-management-profile", "checkedAt": "2026-07-25", "scopeNote": "Generative-AI governance, provenance, evaluation, security, confabulation, privacy, and incident disclosure." } }, { "sourceId": "src-pn-ccsds-oais", "sourceRecordType": "claim-source", "sourceFingerprint": "d130fb645b4838a8e446a7a861ad942052dcb493afd6bd7c431bd9e863999212", "snapshot": { "id": "src-pn-ccsds-oais", "title": "Reference Model for an Open Archival Information System", "authors": [ "Consultative Committee for Space Data Systems" ], "publisher": "CCSDS", "year": 2024, "url": "https://ccsds.org/searchpubs/entry/3054/", "kind": "space-data-systems-standard", "checkedAt": "2026-07-25", "scopeNote": "OAIS information packages, representation information, designated communities, preservation planning, access, and archive-management functions." } }, { "sourceId": "src-pn-ietf-bpsec", "sourceRecordType": "claim-source", "sourceFingerprint": "266d01cc374ffb39ae67ac92d5819b03617401cdf12935e25b0dea13f4a3a1d4", "snapshot": { "id": "src-pn-ietf-bpsec", "title": "RFC 9172: Bundle Protocol Security", "authors": [ "Edward Birrane", "Kurt McKeever" ], "publisher": "Internet Engineering Task Force", "year": 2022, "url": "https://www.rfc-editor.org/rfc/rfc9172.html", "kind": "internet-standard", "checkedAt": "2026-07-25", "scopeNote": "Bundle integrity and confidentiality blocks, security processing, threat assumptions, key-management exclusions, and interoperability requirements." } }, { "sourceId": "src-pn-ietf-bpv7", "sourceRecordType": "claim-source", "sourceFingerprint": "2cc953af46ae7cc31aca7ff9b9cba37bc0bdc5a6f045b41a54e790affdba4395", "snapshot": { "id": "src-pn-ietf-bpv7", "title": "RFC 9171: Bundle Protocol Version 7", "authors": [ "Scott Burleigh", "Kevin Fall", "Edward Birrane" ], "publisher": "Internet Engineering Task Force", "year": 2022, "url": "https://www.rfc-editor.org/rfc/rfc9171.html", "kind": "internet-standard", "checkedAt": "2026-07-25", "scopeNote": "Delay-tolerant networking architecture, bundle format, node processing, endpoint behavior, and explicit disrupted-network assumptions." } }, { "sourceId": "src-pn-jpl-ds1-autonav", "sourceRecordType": "claim-source", "sourceFingerprint": "6ef076670939c71041b6cbb7c9fcaec63d9f0abee4924919aae316e3cdc283f1", "snapshot": { "id": "src-pn-jpl-ds1-autonav", "title": "Deep Space 1 Advanced Technologies: Autonomous Navigation", "authors": [ "Jet Propulsion Laboratory" ], "publisher": "NASA Jet Propulsion Laboratory", "year": 2001, "url": "https://www.jpl.nasa.gov/nmp/ds1/tech/autonav.html", "kind": "technology-demonstration-record", "checkedAt": "2026-07-25", "scopeNote": "Observed onboard optical-image processing, state estimation, power-aware trajectory correction, and ion-thruster commanding in the Deep Space 1 mission." } }, { "sourceId": "src-pn-naif-spice", "sourceRecordType": "claim-source", "sourceFingerprint": "7c3a7603a74c10145ac6ede4e4c7c7dcbac305b62aee6e9140e8e33b2cbe90f8", "snapshot": { "id": "src-pn-naif-spice", "title": "SPICE: An Observation Geometry System for Space Science Missions", "authors": [ "NASA Navigation and Ancillary Information Facility" ], "publisher": "NASA Jet Propulsion Laboratory", "year": 2026, "url": "https://naif.jpl.nasa.gov/naif/", "kind": "operational-navigation-software-record", "checkedAt": "2026-07-25", "scopeNote": "Archived software, kernels, reference frames, time systems, observation-geometry methods, tutorials, and required-reading documentation." } }, { "sourceId": "src-pn-nasa-dtn", "sourceRecordType": "claim-source", "sourceFingerprint": "3940190c4eaa98e8cbef9e104dffd5f111bb61b614373849ee0b327c593d7e75", "snapshot": { "id": "src-pn-nasa-dtn", "title": "Delay/Disruption Tolerant Networking", "authors": [ "National Aeronautics and Space Administration" ], "publisher": "NASA", "year": 2026, "url": "https://www.nasa.gov/communicating-with-missions/delay-disruption-tolerant-networking/", "kind": "active-technology-and-operations-record", "checkedAt": "2026-07-25", "scopeNote": "Store-and-forward bundle operation, mission uses, High-Rate DTN testing, and bounded terrestrial and space-network applicability." } } ], "packetFingerprint": "48e9996662457d787d3a934f8619b1fcbfaf8a4c88b3a3ea73c1a3bbbf20832c" }