{
  "schemaVersion": "gships-review-packet-1",
  "packetId": "academy:cyber-resilience",
  "stableId": "cyber-resilience",
  "family": "academy",
  "slug": "cyber-resilience",
  "title": "Cybersecurity, safety & recovery",
  "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/cyber-resilience",
    "family": "/review/academy",
    "packet": "/review-packets/academy/cyber-resilience.c4051c5ed74ce8c6.json",
    "decisionTemplate": "/review-packets/academy/cyber-resilience.c4051c5ed74ce8c6.decision-template.json",
    "worksheet": "/review-packets/academy/cyber-resilience.c4051c5ed74ce8c6.worksheet.md",
    "byFingerprint": "/review-packets/by-fingerprint/c4051c5ed74ce8c61ee7bbff31736a73acdf6fdfb9d07439352ebad356f2140e.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": [
      "defensive-cyber-safety",
      "information-science",
      "security-assurance",
      "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": "cyber-resilience",
      "title": "Cybersecurity, safety & recovery",
      "publicPath": "/academy/cyber-resilience",
      "recordFingerprint": "5d3049793c84dc33ef2f82972e4f925a269f130a09961c0ceb466460ff8728d9",
      "reviewRequirements": {
        "minimumIndependentApprovals": 1,
        "highConsequenceDomains": [],
        "requiredDomainCodes": [],
        "requiredComplementaryScopeGroups": [
          {
            "id": "bounded-competence",
            "scopeClass": "bounded-competence",
            "oneOf": [
              "defensive-cyber-safety",
              "security-assurance"
            ]
          }
        ],
        "unresolvedNegativeFindingBlocksPublication": true
      },
      "referenceIds": [],
      "snapshot": {
        "slug": "cyber-resilience",
        "number": 11,
        "title": "Cybersecurity, safety & recovery",
        "kicker": "Recover without an external rescuer",
        "summary": "Secure the cyber-physical ship through segmentation, local trust, secure updates, supply-chain provenance, crypto agility, and humane insider resilience.",
        "coreQuestion": "Can the crew keep living while assuming parts of the system are compromised?",
        "image": "/images/chapters/13-cyber-resilience.avif",
        "systems": [
          "cybersecurity",
          "ai-autonomy",
          "manufacturing-isru"
        ],
        "lessons": [
          {
            "slug": "threat-model-the-ship",
            "title": "Threat-model the whole ship",
            "summary": "Connect software, people, sensors, factories, archives, communications, and physical effects.",
            "minutes": 18,
            "level": "Foundation"
          },
          {
            "slug": "islands-and-conduits",
            "title": "Trust islands and safe conduits",
            "summary": "Segment critical domains and preserve manual, local, deterministic operation.",
            "minutes": 18,
            "level": "Foundation"
          },
          {
            "slug": "update-airlock",
            "title": "The update airlock",
            "summary": "Validate provenance, compatibility, signatures, staged rollout, health checks, and rollback.",
            "minutes": 18,
            "level": "Foundation"
          },
          {
            "slug": "cryptography-across-generations",
            "title": "Cryptography across generations",
            "summary": "Design algorithm inventories, replaceable interfaces, key recovery, and archive migration.",
            "minutes": 18,
            "level": "Foundation"
          },
          {
            "slug": "incident-without-earth",
            "title": "Incident response without Earth",
            "summary": "Contain, island, preserve evidence, restore, attest, reconnect, and protect due process.",
            "minutes": 22,
            "level": "Applied"
          }
        ]
      }
    },
    {
      "recordType": "academy-lesson",
      "recordId": "lesson-11-01",
      "title": "Threat-model the whole ship",
      "publicPath": "/academy/cyber-resilience/threat-model-the-ship",
      "recordFingerprint": "2262caf8dc1d3a40db09ec97759dbcaf61c6edc2e34c0e66be3d622e299b1437",
      "reviewRequirements": {
        "minimumIndependentApprovals": 1,
        "highConsequenceDomains": [],
        "requiredDomainCodes": [],
        "requiredComplementaryScopeGroups": [
          {
            "id": "bounded-competence",
            "scopeClass": "bounded-competence",
            "oneOf": [
              "defensive-cyber-safety",
              "security-assurance"
            ]
          }
        ],
        "unresolvedNegativeFindingBlocksPublication": true
      },
      "referenceIds": [],
      "snapshot": {
        "slug": "threat-model-the-ship",
        "title": "Threat-model the whole ship",
        "summary": "Model how software, people, sensors, factories, archives, governance, and physical processes can fail together—and preserve safe recovery without surveillance or offensive capability.",
        "minutes": 35,
        "level": "Foundation",
        "id": "lesson-11-01",
        "trackSlug": "cyber-resilience",
        "trackTitle": "Cybersecurity, safety & recovery",
        "href": "/academy/cyber-resilience/threat-model-the-ship",
        "preparedBy": "GShips Project",
        "lastEditedAt": "2026-07-26",
        "reviewRequiredDomains": [
          "cybersecurity",
          "safety-engineering",
          "operational-technology",
          "human-factors",
          "governance",
          "privacy",
          "ai-autonomy",
          "manufacturing-isru"
        ],
        "claimIds": [
          "claim-12-01",
          "claim-12-02",
          "claim-12-04",
          "claim-12-06",
          "claim-12-07",
          "claim-12-10"
        ],
        "exactMdx": "---\nid: \"lesson-11-01\"\ntrack: \"cyber-resilience\"\nslug: \"threat-model-the-ship\"\ntitle: \"Threat-model the whole ship\"\nsummary: \"Model how software, people, sensors, factories, archives, governance, and physical processes can fail together—and preserve safe recovery without surveillance or offensive capability.\"\nminutes: 35\nlevel: \"Foundation\"\npreparedBy: \"GShips Project\"\nlastEditedAt: \"2026-07-26\"\nconflicts: \"Maintainer intends to explore a commercial venture based on some GShips work; no entity, funding, customer, sponsor, or partner relationship currently exists.\"\nreviewRequiredDomains: \"cybersecurity, safety-engineering, operational-technology, human-factors, governance, privacy, ai-autonomy, manufacturing-isru\"\nclaimIds: \"claim-12-01, claim-12-02, claim-12-04, claim-12-06, claim-12-07, claim-12-10\"\n---\n\n# Threat-model the whole ship\n\n> **Evidence boundary:** Present standards address cyber-resilient systems, operational technology, software supply chains, zero trust, incident response, and AI risk in bounded terrestrial settings. They establish useful engineering practices, not a validated generation-ship security architecture. No cited source demonstrates century-scale cyber defense, permanent separation from external authorities, or safe recovery of an entire closed habitat. This lesson is a civil-and-defensive educational synthesis. It excludes offensive intrusion, autonomous weapons, weapon integration, and actionable exploitation instructions. Safety-critical cyber and dual-use conclusions require two-person review.\n\n## Plain-language summary\n\nA generation ship would not merely carry computers. It would be a civilization whose air, water, food, power, medicine, manufacturing, records, and government depend on computers. Cybersecurity therefore means preserving the ability to operate, diagnose, repair, learn, decide legitimately, and recover—not simply hiding information.\n\nThreat-modeling begins by asking what must remain true, what can cause it to become false, how anyone would know, and how the crew could recover without calling Earth. The answer must include accidents, radiation faults, worn hardware, bad updates, compromised suppliers, manipulated AI, insider misuse, collusion, lost expertise, and governance capture. It must also protect residents from a security program becoming a system of permanent surveillance.\n\nThe useful product is not an exhaustive list of villains. It is a living map from essential services to dependencies, dangerous states, detection evidence, bounded responses, recovery paths, and accountable decision rights.\n\n## Begin with missions, not malware\n\nNIST SP 800-160 Volume 2 defines cyber resiliency around the ability to anticipate, withstand, recover from, and adapt to adverse conditions involving cyber resources. That mission-centered framing fits a closed habitat better than a catalog of attack techniques.\n\nNASA-STD-1006A is an active Agency-level standard requiring NASA missions to address protection and resilience against threats. NASA’s Space Security Best Practices Guide Revision B translates selected NIST controls into space-vehicle and ground-segment language and describes itself as a risk-based starting point. These are important space-specific authorities and methods. Requirements and guidance are not evidence that a system has implemented them successfully, and neither source validates a generation-ship architecture.\n\nStart with functions whose loss could harm people:\n\n- maintain breathable atmosphere within declared limits;\n- keep safe water and sanitation available;\n- supply stable electrical power and heat rejection;\n- preserve medical capability and trustworthy patient records;\n- operate food production and ecological monitoring;\n- navigate, communicate, and maintain attitude or trajectory;\n- manufacture and qualify replacement parts;\n- preserve constitutional, scientific, and maintenance records; and\n- conduct legitimate emergency decisions and return authority afterward.\n\nFor each function, identify the minimum safe service, maximum tolerable outage, manual or local fallback, required measurements, recovery material, and people authorized to change it. “The network is up” is not a safety outcome. A water controller could be online while acting on a biased sensor. A medical archive could be confidential but incomplete. A factory could produce dimensionally correct parts from a poisoned process record.\n\n## Draw the cyber-physical chain\n\nA useful threat model follows effects in both directions. A digital change can move a valve, alter a nutrient dose, corrupt metrology, erase a legal record, or misroute power. A physical event can upset memory, break timing, damage a sensor, change a network topology, or force operators into an unsafe software state.\n\nFor each critical service, map:\n\n1. **Physical process.** What matter or energy changes, and what states are hazardous?\n2. **Sensing.** Which instruments indicate the state? What independent observation could challenge them?\n3. **Control.** Which deterministic controllers, software services, models, and human procedures choose actions?\n4. **Actuation.** Which devices create a physical effect, and what limits exist below application software?\n5. **Dependencies.** Which power, cooling, timing, identity, communications, calibration, and maintenance services are required?\n6. **Authority.** Who may observe, propose, approve, execute, override, and audit a change?\n7. **Recovery.** Which known-good code, configuration, tools, spares, and knowledge can restore service?\n\nNIST SP 800-82 warns that operational technology has performance, reliability, availability, safety, and physical-process constraints that differ from ordinary information systems. A security response that abruptly stops a business server may be acceptable; stopping circulation, thermal control, or a treatment process may create the greater hazard. The threat model must therefore represent both compromise risk and response risk.\n\n## Model causes, not stereotypes\n\nThe same dangerous state can arise from malice or error. A false oxygen reading might result from a manipulated calibration file, connector corrosion, radiation-induced bit upset, a maintenance mistake, a counterfeit sensor, or a model trained on the wrong operating regime. Designing detection around an imagined adversary can miss those shared failure paths.\n\nUse at least these cause classes:\n\n- hardware defect, wear, environmental damage, and common-mode failure;\n- software defect, unsafe interaction, stale configuration, and undocumented dependency;\n- corrupted design, build, update, calibration, or manufacturing data;\n- compromised supplier, toolchain, component, or maintenance instrument;\n- accidental operator action, fatigue, inadequate training, or ambiguous interface;\n- malicious insider, coercion, collusion, stolen identity, or abuse of emergency privilege;\n- institutional failure, discriminatory policy, governance capture, or loss of appeal;\n- AI confabulation, poisoned data or model, unsafe automation bias, and model drift; and\n- external communications carrying malformed, misleading, obsolete, or unauthorized material.\n\nThis classification avoids treating every anomaly as an attack and every resident as a suspect. It also creates common mitigations: independent sensing helps against sabotage and drift; signed configurations help against tampering and mistakes; rehearsed recovery helps after an attack or a radiation fault.\n\n## People, rights, and authority are inside the model\n\nAn onboard security system could become an extraordinary concentration of power. Identity services may mediate access to work, housing, medical care, archives, communications, and civic participation. Continuous monitoring can chill association or create permanent social scores. Emergency powers can outlive the emergency.\n\nSecurity requirements should therefore include civil constraints:\n\n- collect the least personal data consistent with a declared safety purpose;\n- separate process telemetry from behavioral surveillance;\n- require warrants or equivalent accountable process for invasive access, except under narrow emergency conditions;\n- log use of exceptional authority and require later independent review;\n- provide notice, correction, appeal, and restoration of wrongly restricted access;\n- rotate sensitive duties and separate authorization from execution;\n- preserve anonymous or confidential reporting channels; and\n- prohibit immutable caste, lineage, or political status in identity credentials.\n\nThese are normative choices, not conclusions proven by engineering standards. They belong in the threat model because governance abuse can disable truthful reporting and safe maintenance as effectively as a software compromise.\n\n## Manufacturing expands the attack surface\n\nOnboard industry turns information into physical artifacts. Product definitions, material pedigrees, toolpaths, heat-treatment recipes, acceptance thresholds, calibration corrections, and maintenance histories become safety assets.\n\nA threat model should trace a replacement part from requirement through feedstock, process, inspection, installation, and service history. It should ask whether a malicious design change, poisoned toolchain, counterfeit input, compromised metrology record, or silent configuration rollback would be detected by an independent path. Digital provenance helps, but a valid signature only identifies an approved signer and protected bits; it does not prove that the design is safe or the measurement true.\n\nHigh-consequence production changes should require two qualified people, independent measurement, and physical acceptance evidence. Cyber staff alone should not waive structural, medical, nuclear, ecological, or process-safety requirements.\n\n## LLMs change both capacity and risk\n\nAn offline language model could search manuals, compare logs, translate old terminology, draft hypotheses, or help a trainee understand a procedure. That may make a small crew more capable. It also creates new failure modes.\n\nModels can confabulate plausible but unsupported explanations. Retrieval stores, maintenance notes, or training data can be poisoned. A compromised model or prompt pipeline can omit evidence, frame uncertainty deceptively, or amplify a privileged operator’s assumptions. Repeatedly useful output can produce overreliance even when the model lacks authority or current context.\n\nThe defensible role is evidence-bounded and non-authoritative:\n\n- cite the controlled record and exact revision behind each material statement;\n- distinguish observation, inference, proposal, and unknown;\n- operate offline when external service cannot be trusted or reached;\n- have no direct path to life-support actuators, identity revocation, weapons, or final safety acceptance;\n- preserve inputs, outputs, model version, retrieval set, and human disposition for review;\n- compare recommendations against deterministic limits and approved procedures; and\n- rehearse operation with the model absent, corrupted, or confidently wrong.\n\nAI is one advisory channel. It is not the incident commander, judge, root of trust, or substitute for physical verification.\n\n## Turn the model into tests\n\nA threat register that never changes a test, architecture, spare, or decision is paperwork. Each high-consequence scenario should connect to a testable claim:\n\n- Can two independent measurements reveal a corrupted sensor family?\n- Can a zone continue minimum safe service when isolated?\n- Can operators identify a false but correctly signed configuration?\n- Can the crew rebuild a controller from locally held known-good material?\n- Can a resident challenge an erroneous access restriction during an incident?\n- Can a mixed-experience team work without a specialist or AI assistant?\n- Can investigators preserve evidence while restoring urgent service?\n\nThe strongest test combines conditions: communications lost, an update suspect, one trusted operator unavailable, one sensor family biased, and life support still required. NIST frameworks do not establish success in that environment. Repeated representative demonstrations would.\n\n## Evidence ledger\n\n- **L11-01-A — Cyber resilience should be framed around essential mission outcomes and recovery, not confidentiality alone.** Basis: normative synthesis grounded in NIST cyber-resiliency engineering. Readiness: operational as a systems-engineering practice; unproven for a generation ship. Confidence: strong for the framing, tentative for ship integration.\n- **L11-01-B — Current cyber-resilience, OT, zero-trust, supply-chain, and AI guidance provides relevant but fragmented reference points.** Basis: observed. Readiness: operational within bounded terrestrial contexts; major scale-up and integration required. Confidence: strong.\n- **L11-01-C — Cyber and physical causes can converge on the same hazardous state, so the model must include faults, mistakes, suppliers, insiders, institutions, and AI.** Basis: demonstrated across current system classes and proposed for this application. Readiness: operational as analysis; early research for integrated closed habitats. Confidence: supported.\n- **L11-01-D — Onboard manufacturing makes controlled engineering data and metrology cyber-physical safety assets.** Basis: normative inference from OT, supply-chain, and manufacturing assurance practice. Readiness: early research for a self-maintaining factory. Confidence: supported.\n- **L11-01-E — Privacy, due process, and bounded emergency authority are security requirements, not optional social additions.** Basis: normative. Readiness: proposed for this context. Confidence: supported as an ethical requirement; implementation is contested.\n- **L11-01-F — No source reviewed here demonstrates a generation-ship cyber standard or century-scale integrated deployment.** Basis: observed within the bounded source set. Readiness: no known path to demonstrated century assurance. Confidence: supported, not an exhaustive literature claim.\n\nLinked corpus claims: `claim-12-01`, `claim-12-02`, `claim-12-04`, `claim-12-06`, `claim-12-07`, 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- No particular population, network topology, propulsion system, constitutional order, adversary, or mission duration is assumed.\n- NIST publications are voluntary guidance for present organizations; citation does not make them flight requirements.\n- “Threat” includes hazardous causes and institutional misuse, not only intentional attackers.\n- Monitoring is not assumed to justify pervasive surveillance.\n- Cryptographic validity is not treated as proof of physical truth, competence, legitimacy, or safety.\n- LLM support is offline-capable, evidence-linked, logged, advisory, and removable; deterministic protection and accountable people retain authority.\n- This lesson offers no exploit sequence and no offensive or weapon-integration guidance.\n\n## What would change this conclusion?\n\nConfidence would rise if representative closed habitats repeatedly maintained essential service through combined cyber, physical, human, and governance failures; detected poisoned engineering and AI data; restored from locally held known-good material; and protected due process under independent observation. A failure to sustain minimum safe service, rotate authority, preserve recoverable trust, or operate without remote vendor support should narrow the mission, require redesign, or trigger a wait/do-not-launch gate.\n\n## Sources and locators\n\n- [S01 — NIST SP 800-160 Volume 2 Revision 1, Developing Cyber-Resilient Systems](https://doi.org/10.6028/NIST.SP.800-160v2r1). Locator: executive summary; chapters 2–3; cyber-resiliency goals, objectives, techniques, approaches, and design principles; December 2021; accessed 2026-07-25.\n- [S02 — NIST SP 800-82 Revision 3, Guide to Operational Technology Security](https://doi.org/10.6028/NIST.SP.800-82r3). Locator: sections 2–3 on OT characteristics and threats; sections 5–6 on risk management and countermeasures; September 2023; accessed 2026-07-25.\n- [S03 — NIST Cybersecurity Framework 2.0](https://doi.org/10.6028/NIST.CSWP.29). Locator: Govern, Identify, Protect, Detect, Respond, and Recover functions and Profiles; February 2024; accessed 2026-07-25.\n- [S04 — NIST SP 800-161 Revision 1 Update 1, Cybersecurity Supply Chain Risk Management Practices](https://doi.org/10.6028/NIST.SP.800-161r1-upd1). Locator: executive summary; sections 2–3; multilevel risk management and supply-chain threat examples; updated November 2024; accessed 2026-07-25.\n- [S05 — NIST SP 800-207, Zero Trust Architecture](https://doi.org/10.6028/NIST.SP.800-207). Locator: sections 2–3 on zero-trust tenets and logical components; August 2020; accessed 2026-07-25.\n- [S06 — NIST AI 100-2 E2025, Adversarial Machine Learning](https://doi.org/10.6028/NIST.AI.100-2e2025). Locator: taxonomy of evasion, poisoning, privacy, and misuse attacks; life-cycle stages and mitigation limits; March 2025; 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, information integrity, human-AI configuration, automation bias, and value-chain risk sections; July 2024; accessed 2026-07-25.\n- [S08 — NIST SP 800-154 Initial Public Draft, Guide to Data-Centric System Threat Modeling](https://csrc.nist.gov/pubs/sp/800/154/ipd). Locator: sections 2–4 on threat-modeling concepts, attack vectors, security controls, and iterative assessment; March 2016 draft, with NIST finalization planning note dated 2025-01-23; accessed 2026-07-25.\n- [S09 — NASA-STD-1006A, Space System Protection Standard](https://standards.nasa.gov/standard/NASA/NASA-STD-1006). Locator: active Agency-level protection requirements, mission-resilience scope, status, and applicability; 2022; accessed 2026-07-26. This is normative authority, not implementation evidence.\n- [S10 — NASA, Space Security: Best Practices Guide Revision B](https://swehb.nasa.gov/download/attachments/166592616/Space%20Security%20Best%20Practices%20Guide%20BPG%20REV%20B.pdf?api=v2). Locator: sections 1–3 on space-vehicle and ground-segment scope, mission-centered security principles, risk-based tailoring, and guidance status; 2024; accessed 2026-07-26.\n\n## Editorial record\n\n- Prepared by: GShips Project\n- Last edited: 2026-07-26\n- Required review: cybersecurity, safety engineering, operational technology, human factors, governance, privacy, AI/autonomy, and manufacturing assurance\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, CISA, IETF, or any named organization\n- Scope boundary: Civil and defensive resilience only; offensive intrusion, 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-11-02",
      "title": "Trust islands and safe conduits",
      "publicPath": "/academy/cyber-resilience/islands-and-conduits",
      "recordFingerprint": "ed99c094ef4da54a737a6eda2124f9972b8627525a604f8117abb9caeab74bed",
      "reviewRequirements": {
        "minimumIndependentApprovals": 1,
        "highConsequenceDomains": [],
        "requiredDomainCodes": [],
        "requiredComplementaryScopeGroups": [
          {
            "id": "bounded-competence",
            "scopeClass": "bounded-competence",
            "oneOf": [
              "defensive-cyber-safety",
              "security-assurance"
            ]
          }
        ],
        "unresolvedNegativeFindingBlocksPublication": true
      },
      "referenceIds": [],
      "snapshot": {
        "slug": "islands-and-conduits",
        "title": "Trust islands and safe conduits",
        "summary": "Partition critical services into independently survivable trust islands, constrain their conduits, and preserve local deterministic operation when identity, networks, AI, or governance fail.",
        "minutes": 34,
        "level": "Foundation",
        "id": "lesson-11-02",
        "trackSlug": "cyber-resilience",
        "trackTitle": "Cybersecurity, safety & recovery",
        "href": "/academy/cyber-resilience/islands-and-conduits",
        "preparedBy": "GShips Project",
        "lastEditedAt": "2026-07-26",
        "reviewRequiredDomains": [
          "cybersecurity-architecture",
          "operational-technology",
          "safety-engineering",
          "networks",
          "identity",
          "human-factors",
          "ai-autonomy"
        ],
        "claimIds": [
          "claim-12-01",
          "claim-12-02",
          "claim-12-03",
          "claim-12-05",
          "claim-12-08",
          "claim-12-10"
        ],
        "exactMdx": "---\nid: \"lesson-11-02\"\ntrack: \"cyber-resilience\"\nslug: \"islands-and-conduits\"\ntitle: \"Trust islands and safe conduits\"\nsummary: \"Partition critical services into independently survivable trust islands, constrain their conduits, and preserve local deterministic operation when identity, networks, AI, or governance fail.\"\nminutes: 34\nlevel: \"Foundation\"\npreparedBy: \"GShips Project\"\nlastEditedAt: \"2026-07-26\"\nconflicts: \"Maintainer intends to explore a commercial venture based on some GShips work; no entity, funding, customer, sponsor, or partner relationship currently exists.\"\nreviewRequiredDomains: \"cybersecurity-architecture, operational-technology, safety-engineering, networks, identity, human-factors, ai-autonomy\"\nclaimIds: \"claim-12-01, claim-12-02, claim-12-03, claim-12-05, claim-12-08, claim-12-10\"\n---\n\n# Trust islands and safe conduits\n\n> **Evidence boundary:** Segmentation, least privilege, zero-trust access decisions, redundant control, platform recovery, and delay-tolerant communications are established ideas in present systems. Their coexistence in standards does not demonstrate that they can safely govern a closed habitat for generations. A “trust island” here is a design pattern, not a certified product or a promise that isolation prevents compromise. This lesson is civil-and-defensive. It excludes offensive intrusion, autonomous weapons, weapon integration, and actionable exploitation instructions. Safety-critical architectural changes require two-person review.\n\n## Plain-language summary\n\nA ship-wide network that allows every useful system to reach every other useful system is convenient—and dangerous. One mistaken credential, compromised update, faulty time source, or damaged switch could spread failure across air, water, power, medicine, manufacturing, and records.\n\nThe alternative is not to disconnect everything. Essential services need carefully designed **trust islands** that can continue minimum safe operation with outside links unavailable. **Safe conduits** carry only declared information and commands across island boundaries, under explicit identity, direction, rate, validation, logging, and failure rules.\n\nSegmentation buys time and limits consequences; it does not create truth. A compromised sensor can lie inside an island, an authorized person can misuse a valid role, and a bad policy can pass every technical check. Each island therefore needs independent physical limits, local observability, recovery material, and people able to operate it without a central network or AI assistant.\n\n## What makes an island?\n\nA trust island is a bounded set of people, devices, software, data, and physical equipment that can perform a declared minimum mission without depending on continuous trust from the rest of the ship.\n\nCandidate islands might include:\n\n- local atmosphere and thermal control for a pressure zone;\n- water treatment with local sampling and manual routing;\n- a power microgrid capable of black start;\n- medical records and essential treatment equipment;\n- food-production environmental control;\n- manufacturing release, metrology, and machine control;\n- navigation and vehicle control;\n- identity and civic records;\n- a recovery vault containing known-good software, configuration, keys, documentation, and tools.\n\nThese are not necessarily separate networks in a simple one-to-one mapping. Some require multiple independent sub-islands. Others may share physical plant but should not share credentials, administrative consoles, or one unreviewed update path.\n\nFor every proposed boundary, write the invariant it protects. “The atmosphere controller shall maintain local safe limits for a declared interval without central identity or analytics” is testable. “Life support is segmented” is not.\n\n## A conduit is a contract\n\nEvery island must exchange something: power requests, water quality, medical inventory, clock information, maintenance status, navigation state, software updates, or human instructions. Treat each crossing as a contract with at least these fields:\n\n- source and destination identities;\n- message type and schema;\n- direction of travel;\n- allowed rate, size, and timing;\n- freshness and replay rules;\n- required authorization and separation of duties;\n- physical-range and semantic validation;\n- behavior on missing, contradictory, delayed, or excess data;\n- retained audit evidence and privacy limits; and\n- a tested way to close, degrade, or reopen the path.\n\nA network firewall can restrict addresses and ports, but it cannot decide whether a signed request for a chemically impossible nutrient concentration is safe. Application-level checks and physical interlocks must evaluate meaning. Conversely, a one-way data path may reduce remote control risk but can prevent acknowledgments, maintenance, or safe coordination. Directionality is an engineering trade, not a talisman.\n\n## Segmentation and zero trust solve different problems\n\nNIST SP 800-207 states that network location alone should not grant implicit trust. Identity and authorization decisions should focus on the subject, device, resource, and relevant context. That principle complements physical and logical segmentation.\n\nSegmentation limits reach and supports independent survival. Zero-trust principles constrain each requested access even when source and destination appear “inside.” A sound design uses both, but modifies terrestrial assumptions:\n\n- the policy engine itself can be unavailable or compromised;\n- a root identity authority cannot depend on Earth;\n- emergency access must work during network partition without becoming a permanent master key;\n- privacy and due process constrain continuous inspection;\n- old equipment may lack modern identity mechanisms;\n- secure time may be degraded or disputed; and\n- a safety controller may need deterministic response faster than a remote authorization loop.\n\nPlace basic safety below optional policy services where feasible. Hardwired limits, local control loops, and physically bounded modes should not require a ship-wide identity transaction to prevent immediate harm.\n\n## Preserve graceful degradation\n\nIsolation is useful only if an island remains understandable and operable. A minimum-safe mode should specify:\n\n- which functions continue;\n- which conveniences stop;\n- how long local power, storage, consumables, and staffing last;\n- how local measurements are checked;\n- which commands remain possible;\n- how residents receive truthful status;\n- what evidence is preserved; and\n- which conditions demand evacuation, assistance, or carefully controlled reconnection.\n\nNIST SP 800-160 describes diversity, redundancy, segmentation, substantiated integrity, and predefined safe states as cyber-resiliency techniques or approaches. On a ship, diversity should not mean arbitrary complexity. Two controllers that use different code but share the same sensor design, compiler, specification error, or power bus may still fail together. Independence must be demonstrated across the relevant cause.\n\nManual fallback also needs precision. A handwheel is not a fallback if nobody can reach it in protective equipment, interpret its position, or sustain the required workload. A paper checklist is not sufficient if it assumes unavailable instrumentation. Local drills should measure time, staffing, error rates, and physiological burden.\n\n## Recovery vaults and roots of trust\n\nAn island needs a path from “we no longer trust the running system” to “we can establish a bounded trusted state.” NIST SP 800-193 frames platform resiliency as protection, detection, and recovery for firmware and critical data. A ship-scale recovery vault might hold:\n\n- immutable or tightly controlled boot material;\n- multiple verified versions of firmware, operating systems, compilers, and configuration;\n- source code and reproducible build instructions where practicable;\n- cryptographic inventories and migration procedures;\n- calibration references and equipment;\n- offline documentation readable without a proprietary service;\n- spare controllers and interface adapters;\n- signed incident and change records; and\n- exercises showing that ordinary mixed teams can use the contents.\n\n“Air-gapped” is not synonymous with trustworthy. Media ages, keys are lost, readers become obsolete, insiders gain access, and restored code can be incompatible with changed hardware. Vaults require periodic read tests, controlled refresh, cross-generation training, and recovery rehearsals. Multiple vaults should not silently share one administrative or manufacturing failure mode.\n\n## Communications under delay and partition\n\nInter-island and inter-vehicle communications may face disruption, low bandwidth, and long delay. The IETF Bundle Protocol defines store-and-forward delivery across intermittently connected networks, while Bundle Protocol Security defines integrity and confidentiality services for that environment. These are relevant building blocks, not proof of a safe ship architecture.\n\nBPSec does not define key establishment, exchange, revocation, or a complete security policy, and it does not protect an implementation already compromised through shared software or hardware. Each trust island therefore needs explicit key-custody succession, algorithm migration, policy ownership, implementation assurance, and recovery tests. RFC 9173 supplies default security contexts for interoperability; it is not a turnkey key-governance system.\n\nCCSDS 350.0-G-3 describes security concepts and implementation options for CCSDS mission protocols, primarily across space-ground links. Its own scope states that it is an informational guide rather than a Recommended Standard and that detailed security analysis and risk assessment are outside its boundary. An abstract-only NASA CryptoLib conference record says the actively developed project aims at CCSDS Space Data Link Security compliance and reports selected frame cryptography functions. That public description does not establish conformance, secure implementation, deployment, flight qualification, key governance, or multigenerational maintainability.\n\nQueued data raises questions that continuous terrestrial services often hide. When does an old command expire? Which observation is authoritative after clocks diverge? Can a revoked identity’s delayed message still arrive? How are duplicates handled? Which emergency message displaces routine traffic? The conduit contract must make these rules explicit and test them during partition.\n\n## The role of LLMs\n\nAn offline LLM could summarize island status, search controlled manuals, translate a conduit alarm into operator language, or compare the current configuration with an approved baseline. It should not be a conduit’s policy authority or a safety actuator.\n\nModel and retrieval data can be poisoned. A model can confabulate a nonexistent bypass, omit a dependency, or make an unsafe reconnection sound routine. Operators may defer to it during fatigue. Controls should require exact citations to local controlled records, label uncertainty, log model and retrieval versions, and route every proposed high-consequence action to deterministic checks and two qualified people. A model must not approve its own update, change its evidence store, revoke identities, or bridge islands. Each drill should include an AI-off phase and occasional deliberately misleading advisory output.\n\n## Design and test sequence\n\nFor each island:\n\n1. Declare the essential function and minimum-safe envelope.\n2. Inventory dependencies and common-mode failures.\n3. Define conduits as explicit contracts.\n4. Establish local control and physical safety limits.\n5. Define identity, emergency authority, expiry, and appeal.\n6. Prepare recovery material and readable procedures.\n7. Isolate the island under realistic load.\n8. Introduce contradictory sensors, unavailable specialists, damaged links, stale messages, and a suspect update.\n9. Restore from known-good material.\n10. Reconnect through staged observation and renewed attestation.\n\nPassing once is not enough. Tests must cover changing crews, replaced hardware, old and new cryptography, different social conditions, and loss of central services. The result should be measured in safe service delivered and recovery evidence—not the number of security products installed.\n\n## Evidence ledger\n\n- **L11-02-A — Critical services benefit from boundaries that preserve minimum local operation during network or trust failure.** Basis: normative synthesis from cyber-resiliency and OT guidance. Readiness: operational in bounded systems; major scale-up for a closed habitat. Confidence: supported.\n- **L11-02-B — Segmentation does not replace per-request identity, authorization, semantic validation, or physical limits.** Basis: normative synthesis from NIST zero-trust and OT guidance. Readiness: operational as design practice. Confidence: strong.\n- **L11-02-C — Platform protection, detection, and recovery mechanisms exist, but century-maintained recovery vaults do not.** Basis: observed. Readiness: operational for current platforms; early research for multigenerational local recovery. Confidence: strong.\n- **L11-02-D — Delay-tolerant networking and bundle-layer security are standardized for disrupted communications.** Basis: demonstrated and standardized. Readiness: operational in bounded uses; integration remains unproven. Confidence: strong.\n- **L11-02-E — An island must be tested with central identity, communications, specialists, and AI unavailable.** Basis: normative. Readiness: proposed for generation-ship assurance. Confidence: supported.\n- **L11-02-F — Disconnected trust fabrics, update airlocks, recovery vaults, and cyber ranges have Earthside relevance for remote and critical infrastructure.** Basis: proposed extrapolation. Readiness: early research to operational by component. Confidence: tentative for net benefit until representative trials.\n\nLinked corpus claims: `claim-12-01`, `claim-12-02`, `claim-12-03`, `claim-12-05`, `claim-12-08`, 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- “Island” describes a survivability boundary, not a claim of complete isolation.\n- No topology, vendor, protocol suite, population, or required outage duration is prescribed.\n- Terrestrial zero-trust guidance assumes institutions and infrastructure that may not be available onboard.\n- Manual operation is counted only when access, measurement, staffing, duration, and training are demonstrated.\n- Cryptographic checks do not establish physical truth or legitimate policy.\n- LLMs remain offline-capable, evidence-linked, non-authoritative, logged, and physically unable to bridge trust zones or actuate safety systems.\n- No offensive technique or weapon integration is in scope.\n\n## What would change this conclusion?\n\nConfidence would rise after repeated whole-system exercises in which independently instrumented zones maintain minimum safe service while central identity, networking, vendor support, and AI are absent; then recover and reconnect without hidden shared-state corruption or rights violations. If isolation predictably causes unsafe workload, loss of medical or civic access, unrecoverable trust, or larger physical hazards, the proposed boundaries must change. Inability to rebuild and rejoin a compromised zone is a wait/do-not-launch result.\n\n## Sources and locators\n\n- [S01 — NIST SP 800-160 Volume 2 Revision 1, Developing Cyber-Resilient Systems](https://doi.org/10.6028/NIST.SP.800-160v2r1). Locator: chapters 2–3 and appendices on cyber-resiliency goals, techniques, segmentation, diversity, redundancy, predefined segmentation, and substantiated integrity; December 2021; accessed 2026-07-25.\n- [S02 — NIST SP 800-82 Revision 3, Guide to Operational Technology Security](https://doi.org/10.6028/NIST.SP.800-82r3). Locator: sections 2–3 on OT architectures and constraints; sections 5–6 on risk and countermeasures; September 2023; accessed 2026-07-25.\n- [S03 — NIST SP 800-207, Zero Trust Architecture](https://doi.org/10.6028/NIST.SP.800-207). Locator: section 2 zero-trust basics; section 3 logical components; section 7 threats; August 2020; accessed 2026-07-25.\n- [S04 — NIST SP 800-193, Platform Firmware Resiliency Guidelines](https://doi.org/10.6028/NIST.SP.800-193). Locator: sections 3–4 on roots of trust and the protect-detect-recover model; May 2018; accessed 2026-07-25.\n- [S05 — IETF RFC 9171, Bundle Protocol Version 7](https://www.rfc-editor.org/rfc/rfc9171). Locator: sections 1–5 on delay-tolerant store-and-forward architecture, bundles, endpoints, and processing; January 2022; accessed 2026-07-25.\n- [S06 — IETF RFC 9172, Bundle Protocol Security](https://www.rfc-editor.org/rfc/rfc9172). Locator: sections 1.1–1.2, 3, 6–9 on supported services, scope, security blocks, key-management boundary, policy, threats, and security contexts; January 2022; accessed 2026-07-26.\n- [S06a — IETF RFC 9173, Default Security Contexts for Bundle Protocol Security](https://www.rfc-editor.org/rfc/rfc9173). Locator: sections 1–2 and 4–6 on default integrity and confidentiality contexts and interoperability scope; January 2022; accessed 2026-07-26.\n- [S07 — NIST SP 800-53 Revision 5, Security and Privacy Controls](https://doi.org/10.6028/NIST.SP.800-53r5). Locator: Access Control, Contingency Planning, Identification and Authentication, Incident Response, System and Communications Protection, and System Integrity families; September 2020, updates through 2025; accessed 2026-07-25.\n- [S08 — NIST AI 600-1, Generative Artificial Intelligence Profile](https://doi.org/10.6028/NIST.AI.600-1). Locator: confabulation, human-AI configuration, information integrity, and value-chain risk sections; July 2024; accessed 2026-07-25.\n- [S09 — CCSDS 350.0-G-3, The Application of Security to CCSDS Protocols](https://public.ccsds.org/Pubs/350x0g3.pdf). Locator: sections 1.1–1.3 and 3–6 on informational scope, space-data-system security concepts, mechanisms, protocol options, and integration effects; March 2019; accessed 2026-07-26.\n- [S10 — NASA NTRS, The State of CryptoLib](https://ntrs.nasa.gov/citations/20230015937). Locator: abstract-only, professionally reviewed conference record reporting active development, an aim of CCSDS SDLS compliance, and selected Telecommand, Telemetry, and Advanced Orbiting Systems cryptography functions; acquired 2023; accessed 2026-07-26. It does not establish conformance, secure implementation, deployment, flight qualification, or safe key governance.\n\n## Editorial record\n\n- Prepared by: GShips Project\n- Last edited: 2026-07-26\n- Required review: cybersecurity architecture, operational technology, safety engineering, networks, identity, human factors, governance, and AI/autonomy\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, IETF, or any named organization\n- Scope boundary: Civil and defensive resilience only; offensive intrusion, 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-11-03",
      "title": "The update airlock",
      "publicPath": "/academy/cyber-resilience/update-airlock",
      "recordFingerprint": "71bb1e2a8cff187c0d06dc6301d7c982c11671a143dac7bb8714816198d39f40",
      "reviewRequirements": {
        "minimumIndependentApprovals": 1,
        "highConsequenceDomains": [],
        "requiredDomainCodes": [],
        "requiredComplementaryScopeGroups": [
          {
            "id": "bounded-competence",
            "scopeClass": "bounded-competence",
            "oneOf": [
              "defensive-cyber-safety",
              "security-assurance"
            ]
          }
        ],
        "unresolvedNegativeFindingBlocksPublication": true
      },
      "referenceIds": [],
      "snapshot": {
        "slug": "update-airlock",
        "title": "The update airlock",
        "summary": "Move software, firmware, models, data, and engineering changes through an evidence-preserving gate with provenance, compatibility tests, staged rollout, health checks, and recoverable rollback.",
        "minutes": 36,
        "level": "Foundation",
        "id": "lesson-11-03",
        "trackSlug": "cyber-resilience",
        "trackTitle": "Cybersecurity, safety & recovery",
        "href": "/academy/cyber-resilience/update-airlock",
        "preparedBy": "GShips Project",
        "lastEditedAt": "2026-07-26",
        "reviewRequiredDomains": [
          "software-assurance",
          "firmware-security",
          "operational-technology",
          "safety-engineering",
          "supply-chain-risk",
          "ai-autonomy",
          "configuration-management"
        ],
        "claimIds": [
          "claim-12-02",
          "claim-12-03",
          "claim-12-05",
          "claim-12-07",
          "claim-12-08",
          "claim-12-10"
        ],
        "exactMdx": "---\nid: \"lesson-11-03\"\ntrack: \"cyber-resilience\"\nslug: \"update-airlock\"\ntitle: \"The update airlock\"\nsummary: \"Move software, firmware, models, data, and engineering changes through an evidence-preserving gate with provenance, compatibility tests, staged rollout, health checks, and recoverable rollback.\"\nminutes: 36\nlevel: \"Foundation\"\npreparedBy: \"GShips Project\"\nlastEditedAt: \"2026-07-26\"\nconflicts: \"Maintainer intends to explore a commercial venture based on some GShips work; no entity, funding, customer, sponsor, or partner relationship currently exists.\"\nreviewRequiredDomains: \"software-assurance, firmware-security, operational-technology, safety-engineering, supply-chain-risk, ai-autonomy, configuration-management\"\nclaimIds: \"claim-12-02, claim-12-03, claim-12-05, claim-12-07, claim-12-08, claim-12-10\"\n---\n\n# The update airlock\n\n> **Evidence boundary:** Secure-development frameworks, signed firmware manifests, software bills of materials, platform recovery, and staged deployment practices exist today. They do not establish that a software, firmware, AI-model, data, or engineering update will remain interpretable, compatible, and safely reversible across centuries. A valid signature proves neither safety nor truth. This lesson is a civil-and-defensive assurance pattern, not an operational procedure or certification. It excludes offensive intrusion, autonomous weapons, weapon integration, and actionable exploitation instructions. Safety-critical releases and dual-use changes require two-person review.\n\n## Plain-language summary\n\nAn update can repair a vulnerability, improve a controller, add a scientific model, or preserve compatibility with replaced hardware. It can also disable life support, corrupt records, poison a factory, break recovery, or quietly change who holds authority.\n\nAn **update airlock** is a controlled path between untrusted or merely unproven material and a live system. It receives the candidate; identifies its origin and contents; rebuilds or inspects it where possible; tests compatibility and safety; checks authorization; deploys to a limited target; watches declared health signals; and either expands the release or rolls back to a known-good state.\n\nThe airlock is not one scanning appliance. It is a sociotechnical process with independent evidence, separated duties, physical test environments, and a refusal state. It must work after Earth, vendors, cloud services, and original developers are gone.\n\n## What counts as an update?\n\nTreat every executable or decision-shaping change as a release object:\n\n- application, operating-system, bootloader, and device firmware;\n- programmable-logic and controller configurations;\n- cryptographic algorithms, certificates, trust anchors, and revocation data;\n- AI model weights, prompts, retrieval collections, embeddings, and evaluation sets;\n- calibration curves, material specifications, toolpaths, and manufacturing recipes;\n- medical protocols, ecological thresholds, navigation tables, and digital-twin parameters;\n- identity policy, authorization rules, and emergency procedures; and\n- compilers, build systems, test tools, and the airlock’s own code.\n\nA text file can be safety critical if a person or model acts on it. A sensor-calibration update may produce a physical effect without containing conventional executable code. Scope must follow consequence, not file extension.\n\n## The release evidence packet\n\nNo object should enter the airlock alone. Its evidence packet should include:\n\n- unique identity, version, creation time or sequence, and intended targets;\n- content digest and authorized signatures;\n- human-readable purpose, hazards, assumptions, and affected requirements;\n- source, build recipe, compiler and tool versions where available;\n- component inventory, licenses, known defects, and supply-chain history;\n- compatibility bounds, dependencies, migration steps, and prohibited states;\n- test plan, expected results, independent results, and unresolved anomalies;\n- resource demands such as memory, power, bandwidth, storage, and operator time;\n- rollout groups, health metrics, pause thresholds, and rollback path; and\n- named proposers, reviewers, authorizers, and conflict disclosures.\n\nNIST SP 800-218 organizes secure software development around preparing the organization, protecting software, producing well-secured releases, and responding to vulnerabilities. NIST SP 800-161 adds supply-chain risk across acquisition and lifecycle. These are relevant disciplines; neither says that an SBOM or signature is enough.\n\nAn SBOM can expose declared components and versions. It may omit build-time dependencies, hardware behavior, data provenance, or undiscovered defects. A reproducible build can show that declared inputs produce matching outputs under controlled conditions; it does not prove that the inputs or design are safe. Provenance is evidence to reason with, not a ceremonial pass.\n\n## Intake without inheriting trust\n\nAn update arriving from Earth could be years old relative to onboard conditions. It may be authentic but obsolete, or based on hardware and regulations that no longer apply. A locally authored change could be relevant but compromised by a faulty toolchain, coerced reviewer, or poisoned reference corpus.\n\nIntake should therefore:\n\n1. preserve the received object and transport metadata;\n2. verify integrity and signatures against the applicable historical policy;\n3. quarantine active content and render documentation safely;\n4. resolve target identity and reject ambiguity;\n5. inventory components and compare with local vulnerability knowledge;\n6. reconstruct the change against the prior approved baseline;\n7. identify which assumptions can be tested locally; and\n8. flag unknown, expired, revoked, or politically disputed authority for accountable human resolution.\n\nRFC 9019’s firmware-update architecture distinguishes authoring, authorization, distribution, manifest processing, and installation. It also describes authenticated manifests, target matching, sequence checks, dependency handling, interruption tolerance, and recovery from invalid firmware. Those ideas matter beyond small devices, but a habitat needs additional safety and governance layers.\n\nNASA-STD-1006A and NASA’s Space Security Best Practices Guide add current mission-protection requirements and space-segment guidance. They strengthen the case that flight and ground systems need explicit protection planning. They do not demonstrate that a particular update path is safely integrated, flight-qualified, recoverable after key loss, or maintainable across generations.\n\n## Compatibility is multidimensional\n\n“It installed” is not a compatibility result. Evaluate at least:\n\n- hardware model, revision, wear state, and locally manufactured substitutions;\n- firmware, driver, protocol, schema, and file-format versions;\n- timing, processor, memory, storage, bandwidth, power, and thermal margins;\n- control-loop stability and physical safety limits;\n- human interface, alarms, accessibility, language, and training burden;\n- cryptographic and identity transitions;\n- interactions with neighboring islands;\n- recoverability of old records and configurations; and\n- the ability to build, inspect, and roll back with onboard tools.\n\nTest the candidate in an isolated digital environment, hardware-in-the-loop rig, physical test article, or sacrificial spare proportional to consequence. A digital twin is useful only within its validated range. It can miss manufacturing drift, sensor aging, emergent ecology, human adaptation, and unknown interactions.\n\n## Authorization and separation of duties\n\nOne identity should not be able to write, approve, deploy, and erase the evidence for a critical update. Roles can include proposer, builder, safety reviewer, security reviewer, mission owner, deployment operator, and auditor. Small populations may require role rotation and threshold approval rather than permanent specialists.\n\nEmergency changes need a narrow path:\n\n- a defined qualifying condition;\n- minimum necessary scope and lifetime;\n- two-person approval when physically possible;\n- automatic expiry or mandatory reassessment;\n- preserved before-and-after state;\n- resident-visible disclosure consistent with privacy and safety; and\n- independent retrospective review.\n\nThis boundary is especially important for identity, medical, reproductive, nuclear, ecological, navigation, and life-support systems. High consequence and dual use require two independent qualified reviewers. An AI system cannot serve as either reviewer.\n\n## Staged rollout and health evidence\n\nDeploy first to the least consequential representative target, never simultaneously to every redundant unit. Preserve diversity: if two independent controllers provide fault tolerance, do not erase that independence by giving both the same unproven release at once.\n\nBefore deployment, define:\n\n- expected functional and safety behavior;\n- invariant physical limits;\n- leading indicators of degradation;\n- observation duration across representative operating states;\n- who can pause, abort, or roll back;\n- what data may be collected and for how long; and\n- how success will be distinguished from an absence of detected failure.\n\nA signed health report from the updated system is not independent evidence. Compare external instruments, process outputs, operator observations, and known test stimuli. Do not let the same component make the change, evaluate itself, and certify success.\n\n## Rollback is a tested capability\n\nRollback may fail because data schemas changed, keys rotated, hardware fused a new state, the prior image was overwritten, or the old version cannot understand newly produced records. “A backup exists” is not proof.\n\nNIST SP 800-193’s protect-detect-recover model supports preserving recovery mechanisms and critical data. The update airlock should retain independently bootable known-good material, migration reversals where feasible, readable records, and a means to validate restored state. Anti-rollback controls that block a known vulnerable version must coexist with emergency recovery. The design needs an authorized way to choose the least unsafe recoverable state, not an irreversible monotonic rule whose assumptions cannot be revised.\n\nRehearse interruption during download, installation, migration, and restart. Test loss of power, clock disagreement, corrupt media, absent personnel, failed new hardware, and incompatible old data. Rollback completion should be measured by restored service and verified state, not by a boot message.\n\n## AI and model updates\n\nModels deserve stricter—not looser—airlock treatment because behavior is statistical and evidence can be hard to trace. NIST’s Generative AI Profile identifies confabulation, information-integrity, human-AI configuration, and value-chain risks. NIST AI 100-2 classifies model and data poisoning among adversarial-ML concerns.\n\nAn onboard model update should include model and dataset provenance, evaluation coverage, known limitations, resource demand, retrieval-store changes, and comparison against frozen safety cases. Tests should include misleading context, poisoned documents, unavailable retrieval, ambiguous instructions, and human overreliance.\n\nThe model remains offline-capable, evidence-linked, advisory, and separated from actuators and roots of trust. It may help compare evidence packets or explain logs. It cannot authorize itself, alter its evaluation record, approve a safety release, or decide that missing evidence is acceptable. Retain a usable non-AI workflow and regularly exercise it.\n\n## Evidence ledger\n\n- **L11-03-A — Secure update, software assurance, supply-chain, SBOM, and platform-recovery practices exist today.** Basis: observed and demonstrated. Readiness: operational in bounded contexts; integration and century sustainment unproven. Confidence: strong.\n- **L11-03-B — A valid signature establishes protected provenance under a policy, not safety, correctness, legitimacy, or compatibility.** Basis: normative inference from cryptographic and assurance boundaries. Readiness: operational as a review principle. Confidence: strong.\n- **L11-03-C — Safety-relevant updates require an evidence packet, separated duties, representative testing, staged deployment, independent health signals, and tested recovery.** Basis: normative synthesis. Readiness: major scale-up for an integrated closed habitat. Confidence: supported.\n- **L11-03-D — Onboard manufacturing and calibration data belong inside update assurance.** Basis: proposed application of OT and supply-chain principles. Readiness: early research. Confidence: supported.\n- **L11-03-E — AI model and retrieval updates introduce poisoning, confabulation, drift, and overreliance risks that conventional signature checks do not resolve.** Basis: observed risk taxonomy and modeled system concern. Readiness: early research for high-consequence onboard use. Confidence: strong for risk existence, tentative for controls.\n- **L11-03-F — No cited pattern demonstrates safe update and rollback across generational hardware, governance, cryptography, and expertise change.** Basis: observed within this source set. Readiness: no known demonstrated path. Confidence: supported.\n\nLinked corpus claims: `claim-12-02`, `claim-12-03`, `claim-12-05`, `claim-12-07`, `claim-12-08`, 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- The airlock covers local and externally received changes; neither is trusted by origin alone.\n- No specific operating system, compiler, signature scheme, vendor, or deployment platform is prescribed.\n- SBOMs, signatures, reproducible builds, attestation, simulations, and digital twins provide partial evidence only.\n- Some physical or data migrations may be irreversible; this must be disclosed before authorization.\n- Privacy limits apply to rollout telemetry and operator monitoring.\n- LLMs are offline-capable, evidence-linked, non-authoritative, logged, removable, and unable to approve or deploy their own changes.\n- No exploit instructions, offensive operations, or weapon integration are included.\n\n## What would change this conclusion?\n\nReadiness would improve through repeated representative releases across mixed old and new hardware, including interrupted installation, poisoned provenance, revoked authority, AI-data corruption, schema migration, failed health checks, and recovery without vendor services. The exercise must preserve minimum safe service and independently verify restored state. A system that cannot decline an update, rebuild its toolchain, explain its installed configuration, or recover after a failed release should not cross the relevant decision gate.\n\n## Sources and locators\n\n- [S01 — NIST SP 800-218, Secure Software Development Framework Version 1.1](https://doi.org/10.6028/NIST.SP.800-218). Locator: SSDF practices Prepare the Organization, Protect the Software, Produce Well-Secured Software, and Respond to Vulnerabilities; February 2022; accessed 2026-07-25.\n- [S02 — NIST SP 800-161 Revision 1 Update 1, Cybersecurity Supply Chain Risk Management Practices](https://doi.org/10.6028/NIST.SP.800-161r1-upd1). Locator: sections 2–3 and appendices on lifecycle, provenance, supplier risk, and multilevel controls; updated November 2024; accessed 2026-07-25.\n- [S03 — IETF RFC 9019, A Firmware Update Architecture for Internet of Things](https://www.rfc-editor.org/rfc/rfc9019). Locator: sections 3–7 and 10 on roles, manifests, target matching, sequence numbers, dependencies, installation, and recovery; April 2021; accessed 2026-07-25.\n- [S04 — NIST SP 800-193, Platform Firmware Resiliency Guidelines](https://doi.org/10.6028/NIST.SP.800-193). Locator: sections 3–4 on roots of trust, protection, detection, recovery, and critical data; May 2018; accessed 2026-07-25.\n- [S05 — CISA, Software Bill of Materials](https://www.cisa.gov/sbom). Locator: SBOM definition, ecosystem roles, use cases, and current minimum-elements resources; accessed 2026-07-25.\n- [S06 — NIST SP 800-82 Revision 3, Guide to Operational Technology Security](https://doi.org/10.6028/NIST.SP.800-82r3). Locator: OT safety and availability constraints, patch management, change control, maintenance, and recovery guidance; September 2023; 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, information integrity, human-AI configuration, and value-chain risk sections; 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: predictive- and generative-AI poisoning taxonomy, life-cycle stages, and mitigation limitations; March 2025; accessed 2026-07-25.\n- [S09 — NASA-STD-1006A, Space System Protection Standard](https://standards.nasa.gov/standard/NASA/NASA-STD-1006). Locator: active Agency-level space-system protection requirements and mission scope; 2022; accessed 2026-07-26. Requirements are not implementation evidence.\n- [S10 — NASA, Space Security: Best Practices Guide Revision B](https://swehb.nasa.gov/download/attachments/166592616/Space%20Security%20Best%20Practices%20Guide%20BPG%20REV%20B.pdf?api=v2). Locator: risk-based space-vehicle and ground-segment controls, planning context, and guidance boundary; 2024; accessed 2026-07-26.\n\n## Editorial record\n\n- Prepared by: GShips Project\n- Last edited: 2026-07-26\n- Required review: software assurance, firmware security, operational technology, safety engineering, supply-chain risk, AI/autonomy, and configuration management\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, CISA, IETF, or any named organization\n- Scope boundary: Civil and defensive resilience only; offensive intrusion, 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-11-04",
      "title": "Cryptography across generations",
      "publicPath": "/academy/cyber-resilience/cryptography-across-generations",
      "recordFingerprint": "e527ca3391fe2c6fbe76320b83ea0726bf0f90a311d97135fd95bef399d77e63",
      "reviewRequirements": {
        "minimumIndependentApprovals": 1,
        "highConsequenceDomains": [],
        "requiredDomainCodes": [],
        "requiredComplementaryScopeGroups": [
          {
            "id": "bounded-competence",
            "scopeClass": "bounded-competence",
            "oneOf": [
              "defensive-cyber-safety",
              "security-assurance"
            ]
          }
        ],
        "unresolvedNegativeFindingBlocksPublication": true
      },
      "referenceIds": [],
      "snapshot": {
        "slug": "cryptography-across-generations",
        "title": "Cryptography across generations",
        "summary": "Keep identities, records, commands, and recovery usable as algorithms, hardware, institutions, clocks, and generations change.",
        "minutes": 36,
        "level": "Foundation",
        "id": "lesson-11-04",
        "trackSlug": "cyber-resilience",
        "trackTitle": "Cybersecurity, safety & recovery",
        "href": "/academy/cyber-resilience/cryptography-across-generations",
        "preparedBy": "GShips Project",
        "lastEditedAt": "2026-07-25",
        "reviewRequiredDomains": [
          "cryptography",
          "key-management",
          "identity",
          "archival-science",
          "safety-engineering",
          "governance",
          "software-assurance"
        ],
        "claimIds": [
          "claim-12-02",
          "claim-12-04",
          "claim-12-05",
          "claim-12-06",
          "claim-12-09",
          "claim-12-10"
        ],
        "exactMdx": "---\nid: \"lesson-11-04\"\ntrack: \"cyber-resilience\"\nslug: \"cryptography-across-generations\"\ntitle: \"Cryptography across generations\"\nsummary: \"Keep identities, records, commands, and recovery usable as algorithms, hardware, institutions, clocks, and generations change.\"\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: \"cryptography, key-management, identity, archival-science, safety-engineering, governance, software-assurance\"\nclaimIds: \"claim-12-02, claim-12-04, claim-12-05, claim-12-06, claim-12-09, claim-12-10\"\n---\n\n# Cryptography across generations\n\n> **Evidence boundary:** Contemporary key-management guidance, cryptographic-transition practice, and post-quantum standards address present security horizons. They do not validate an algorithm, key store, identity institution, or archive for centuries. NIST standardized ML-KEM, ML-DSA, and SLH-DSA in 2024; standardization does not mean they are eternal, implementation-proof, or already integrated into safety-critical space systems. This lesson is a civil-and-defensive design synthesis, not cryptographic certification. It excludes offensive intrusion, autonomous weapons, weapon integration, and actionable exploitation instructions. High-consequence cryptographic, identity, and dual-use decisions require two-person review.\n\n## Plain-language summary\n\nCryptography helps a community answer questions such as:\n\n- Did this command come from an authorized role?\n- Has this medical or engineering record changed?\n- May this device join the control network?\n- Is this software release the one that reviewers approved?\n- Can only the intended people read this private information?\n\nThe mathematics is only part of the system. Keys must be generated, stored, used, recovered, revoked, and eventually destroyed. Devices and people need identities. Clocks and event sequences must remain interpretable. Old records must still be readable after algorithms and institutions change.\n\nA generation ship cannot assume that Earth will issue a replacement certificate, recover a lost key, publish a new cryptographic library, or resolve a disputed signature. The ship needs **crypto agility**: a measured ability to discover where cryptography is used, replace algorithms and implementations, migrate protected material, and keep essential service operating through the transition. Agility does not mean making every choice configurable by anyone.\n\n## Inventory before migration\n\nAn algorithm inventory should record more than the word “encryption.” For each use, capture:\n\n- purpose: confidentiality, integrity, authentication, key establishment, commitment, timestamping, or random generation;\n- algorithm, parameters, mode, protocol, library, hardware, and version;\n- keys, certificates, trust anchors, owners, custodians, and authorized uses;\n- protected data and required protection lifetime;\n- dependent devices, software, records, and recovery paths;\n- clock, sequence, revocation, and network assumptions;\n- migration and rollback capability;\n- known compatibility constraints; and\n- evidence that implementation behaves as intended.\n\nThe inventory must include hidden uses: boot verification, factory controllers, medical instruments, backup formats, database checksums, wireless links, access badges, archived legal signatures, AI-model provenance, and spare hardware sealed for later use. A migration that finds only central servers can strand the machines that sustain life.\n\nNIST’s 2025 crypto-agility guidance defines agility as the capability to replace and adapt algorithms in protocols, applications, software, hardware, firmware, and infrastructure while preserving security and ongoing operations. That is a present practice goal, not evidence of multigenerational success.\n\n## Separate purpose from mechanism\n\nDesign interfaces around required security properties and explicit policy, while keeping implementations replaceable. A record should say what kind of assurance it needs, for whom, and for how long—not merely that it uses one named algorithm.\n\nHowever, abstraction can conceal important differences. New algorithms may have larger keys or signatures, different failure modes, stronger randomness requirements, higher compute or memory demand, and incompatible hardware acceleration. A controller with small memory or a low-bandwidth conduit may not accept a simple library swap.\n\nTherefore agility needs:\n\n- multiple implementation paths where consequence justifies them;\n- test vectors and known-answer tests preserved offline;\n- capacity margins for larger keys, signatures, and protocol messages;\n- versioned formats that identify algorithms and parameters;\n- negotiation policies that prevent silent downgrade;\n- hardware-independent fallback for essential verification where feasible;\n- source, build tools, specifications, and readable reference implementations; and\n- representative migration exercises on old hardware.\n\nAlgorithm diversity can reduce common-mode risk, but unnecessary variants increase complexity. The objective is planned transition, not cryptographic abundance.\n\n## Keys are governed material\n\nNIST SP 800-57 covers key generation, storage, use, backup, recovery, compromise, revocation, archival, and destruction. On a ship, these functions become local civic institutions.\n\nNo single person should hold a universal key to identity, life support, archives, manufacturing, and recovery. High-consequence authority can use threshold control: several independently selected custodians must cooperate. Custodians should rotate, train successors, declare conflicts, and work under observable procedure.\n\nThreshold schemes do not solve governance by themselves. A coalition can collude; shares can be lost together; a rule can exclude disabled residents; emergency access can become permanent. Recovery design should specify:\n\n- how many independent shares exist and what failures they tolerate;\n- physical and institutional separation;\n- accessibility and succession;\n- activation conditions and time limits;\n- evidence recorded without exposing secret material;\n- appeal and retrospective review;\n- response when compromise is suspected; and\n- a path to replace the recovery system itself.\n\nBackup keys are dangerous because they preserve access. No backups are dangerous because loss can become irreversible. The correct balance depends on the consequence and protection lifetime.\n\n## Identity without a permanent Earth authority\n\nPeople are born, mature, change roles, lose capabilities, and die. Devices are manufactured, repaired, combined, reassigned, and retired. Institutions change legitimacy. Identity must represent that lifecycle without turning ancestry, occupation, or political status into an immutable hierarchy.\n\nDistinguish:\n\n- a person or device;\n- an identifier;\n- a credential binding an identifier to evidence;\n- a role granting bounded authority;\n- an authorization decision at a particular time; and\n- an audit record that may itself be contested.\n\nA credential validly issued under an old constitution may no longer authorize current action. A device may hold an intact key after its sensors become untrustworthy. A signed maintenance command can be authentic and unsafe. Cryptography supports policy; it does not decide legitimate policy or physical fitness.\n\nEmergency credentials should be scoped, expire, and trigger independent review. Identity services must preserve access to basic life and due process during partition or recovery. They must not become an unappealable social score.\n\n## Time, sequence, revocation, and partition\n\nMany security decisions ask whether a credential or message is still valid. That requires time or a reliable sequence. Yet clocks drift, timing hardware fails, zones partition, and delayed messages arrive later.\n\nThe design should separate:\n\n- physical mission time and its uncertainty;\n- local monotonic event sequence;\n- civil calendars and institutional terms;\n- cryptographic validity intervals;\n- evidence receipt time; and\n- claims about when an event actually happened.\n\nDuring partition, a zone may not receive revocation information. A strict refusal policy can halt care or control; unconditional acceptance can preserve compromised authority. Predeclared degraded modes should limit privilege, duration, and affected resources while recording evidence for reconciliation. No universal rule resolves every trade; safety and rights reviewers must examine each use.\n\n## Archives outlive algorithms\n\nA signature verifies under a particular algorithm, key, policy, and evidence context. Decades later, the algorithm may be deprecated, the key destroyed, the signer dead, the certificate authority reorganized, and the file format obscure.\n\nArchival preservation should retain:\n\n- original bytes and format documentation;\n- signature, certificate chain, policy, revocation evidence, and validation time;\n- contextual records explaining the signer’s authority;\n- independent hashes and replicated storage;\n- migration history and custodial actions;\n- periodic validation before algorithms weaken; and\n- renewed attestations that bind old evidence to new mechanisms without erasing the original.\n\nMigration is not permission to rewrite history. Preserve originals, explain transformations, and allow contested interpretations. Important constitutional, medical, scientific, and maintenance records may need different confidentiality and availability periods.\n\n## Post-quantum standards are a transition, not an ending\n\nNIST FIPS 203 defines ML-KEM for key establishment; FIPS 204 defines ML-DSA; FIPS 205 defines SLH-DSA. These standards provide present alternatives intended to resist known quantum attacks. They should be evaluated for protocol fit, implementation quality, performance, side-channel behavior, storage, bandwidth, and recovery.\n\nA generation-spanning design should expect further cryptanalysis and new standards. Hybrid transitions may preserve assurance from different assumptions, but add complexity and can fail if composed poorly. The correct claim is not “post-quantum forever.” It is “maintain an inventory, monitor evidence, test alternatives, migrate deliberately, and preserve fallback.”\n\n## LLMs are not roots of trust\n\nAn offline LLM could locate cryptographic uses in source code, explain an old certificate policy, compare inventories, or draft a migration checklist. It can also hallucinate an algorithm identifier, misunderstand a validity rule, leak sensitive context into logs, or be influenced by poisoned documentation.\n\nThe model must cite controlled local sources, distinguish retrieved fact from inference, and never receive secret keys merely to answer a question. It cannot generate production keys, approve identity, authorize revocation, interpret a constitutional dispute, or certify a migration. Model weights and retrieval data require provenance and poisoning checks. Human operators must avoid overreliance, retain non-AI procedures, and confirm critical outputs with deterministic tools and two qualified reviewers.\n\n## A migration exercise\n\nA meaningful test starts with an intentionally old but representative island. Inventory every cryptographic dependency. Announce deprecation of one algorithm and compromise of one authority. Partition the island from central identity. Replace a controller with locally available hardware. Migrate active communications, firmware verification, private records, and archival signatures while preserving minimum safe service.\n\nThen test loss of a key custodian, clock disagreement, delayed revocation, corrupt backup, a poisoned AI explanation, and rollback pressure. Independent observers should verify not just message success, but authority, rights, record continuity, physical safety, and recovery.\n\n## Evidence ledger\n\n- **L11-04-A — Present key-management and crypto-agility guidance covers inventories, lifecycle controls, transition planning, and operational continuity.** Basis: observed. Readiness: operational in current institutions; major scale-up for permanent local autonomy. Confidence: strong.\n- **L11-04-B — NIST standardized ML-KEM, ML-DSA, and SLH-DSA in 2024.** Basis: observed. Readiness: operational standards with implementation and integration work continuing. Confidence: strong.\n- **L11-04-C — Standardization does not establish century security, correct implementation, safe integration, or archival continuity.** Basis: normative evidence boundary. Readiness: no known demonstrated century path. Confidence: strong.\n- **L11-04-D — Trust anchors, identity, secure time, revocation, threshold recovery, migration, and archival interpretation must operate locally after Earth is unavailable.** Basis: proposed requirement. Readiness: early research as an integrated system. Confidence: supported.\n- **L11-04-E — Cryptography cannot by itself establish physical truth, competence, legitimacy, or justice.** Basis: normative systems boundary. Readiness: operational as a design principle. Confidence: strong.\n- **L11-04-F — Crypto agility and toolchain preservation have Earthside value for long-lived medical, energy, transport, and public systems.** Basis: proposed extrapolation from current transition problems. Readiness: operational to major scale-up by sector. Confidence: supported.\n\nLinked corpus claims: `claim-12-02`, `claim-12-04`, `claim-12-05`, `claim-12-06`, `claim-12-09`, 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- No current algorithm is assumed secure for the full mission.\n- NIST standards are present reference points, not generation-ship certification or universal law.\n- “Crypto agility” includes people, policy, hardware, formats, archives, and recovery—not only software interfaces.\n- Threshold custody does not eliminate coercion, collusion, exclusion, or institutional failure.\n- Archival renewal can preserve evidence chains but cannot recreate missing social context.\n- LLMs remain offline-capable, evidence-linked, non-authoritative, logged, and excluded from secrets and trust-anchor decisions.\n- This lesson contains no exploit procedure, offensive operation, or weapon integration.\n\n## What would change this conclusion?\n\nConfidence would increase after public, repeatable migrations across old hardware, partitioned identity, disputed time, lost custodians, revoked authorities, archival evidence, and locally rebuilt toolchains—without loss of minimum safe service or due process. Discovery of a practical long-duration primitive would change the migration cadence, not remove the need for inventory and governance. Inability to locate cryptographic dependencies, rotate root authority, interpret old records, or recover after compromise is a wait/do-not-launch condition.\n\n## Sources and locators\n\n- [S01 — NIST CSWP 39 Update 1, Considerations for Achieving Crypto Agility](https://csrc.nist.gov/pubs/cswp/39/upd1/considerations-for-achieving-crypto-agility/final). Locator: definition, inventory and discovery, transition strategies, protocol and application considerations, operational trade-offs, and future work; December 2025 with updates through 2026-06-29; accessed 2026-07-25.\n- [S02 — NIST SP 800-57 Part 1 Revision 5, Recommendation for Key Management](https://doi.org/10.6028/NIST.SP.800-57pt1r5). Locator: sections 5–8 on security services, algorithms, key lifecycle, protection, compromise, backup, recovery, archival, and destruction; May 2020; accessed 2026-07-25.\n- [S03 — NIST FIPS 203, Module-Lattice-Based Key-Encapsulation Mechanism Standard](https://doi.org/10.6028/NIST.FIPS.203). Locator: sections 1–7, approved ML-KEM parameter sets and implementation requirements; August 2024, errata noted by NIST; accessed 2026-07-25.\n- [S04 — NIST FIPS 204, Module-Lattice-Based Digital Signature Standard](https://doi.org/10.6028/NIST.FIPS.204). Locator: sections 1–7 and ML-DSA parameter sets; August 2024; accessed 2026-07-25.\n- [S05 — NIST FIPS 205, Stateless Hash-Based Digital Signature Standard](https://doi.org/10.6028/NIST.FIPS.205). Locator: sections 1–7 and SLH-DSA parameter sets; August 2024; accessed 2026-07-25.\n- [S06 — NIST SP 800-131A Revision 2, Transitioning the Use of Cryptographic Algorithms and Key Lengths](https://doi.org/10.6028/NIST.SP.800-131Ar2). Locator: transition status categories and guidance for algorithms and key lengths; March 2019; accessed 2026-07-25.\n- [S07 — NIST SP 800-130, A Framework for Designing Cryptographic Key Management Systems](https://doi.org/10.6028/NIST.SP.800-130). Locator: goals, policies, roles, lifecycle functions, compromise recovery, and design documentation; August 2013; accessed 2026-07-25.\n- [S08 — 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 risk sections; July 2024; accessed 2026-07-25.\n\n## Editorial record\n\n- Prepared by: GShips Project\n- Last edited: 2026-07-25\n- Required review: cryptography, key management, identity, archival science, safety engineering, governance, and software assurance\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 NIST or any named organization\n- Scope boundary: Civil and defensive resilience only; offensive intrusion, 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-11-05",
      "title": "Incident response without Earth",
      "publicPath": "/academy/cyber-resilience/incident-without-earth",
      "recordFingerprint": "8a0a9a1abea9615e0c99dd325a1008609a1e820cf53ff53dcee8fd333adc06ea",
      "reviewRequirements": {
        "minimumIndependentApprovals": 1,
        "highConsequenceDomains": [],
        "requiredDomainCodes": [],
        "requiredComplementaryScopeGroups": [
          {
            "id": "bounded-competence",
            "scopeClass": "bounded-competence",
            "oneOf": [
              "defensive-cyber-safety",
              "security-assurance"
            ]
          }
        ],
        "unresolvedNegativeFindingBlocksPublication": true
      },
      "referenceIds": [],
      "snapshot": {
        "slug": "incident-without-earth",
        "title": "Incident response without Earth",
        "summary": "Detect, stabilize, contain, investigate, restore, attest, and reconnect locally while protecting life, evidence, privacy, due process, and legitimate authority.",
        "minutes": 38,
        "level": "Applied",
        "id": "lesson-11-05",
        "trackSlug": "cyber-resilience",
        "trackTitle": "Cybersecurity, safety & recovery",
        "href": "/academy/cyber-resilience/incident-without-earth",
        "preparedBy": "GShips Project",
        "lastEditedAt": "2026-07-25",
        "reviewRequiredDomains": [
          "incident-response",
          "operational-technology",
          "safety-engineering",
          "digital-forensics",
          "human-factors",
          "governance",
          "privacy",
          "ai-autonomy"
        ],
        "claimIds": [
          "claim-12-01",
          "claim-12-05",
          "claim-12-06",
          "claim-12-08",
          "claim-12-10"
        ],
        "exactMdx": "---\nid: \"lesson-11-05\"\ntrack: \"cyber-resilience\"\nslug: \"incident-without-earth\"\ntitle: \"Incident response without Earth\"\nsummary: \"Detect, stabilize, contain, investigate, restore, attest, and reconnect locally while protecting life, evidence, privacy, due process, and legitimate authority.\"\nminutes: 38\nlevel: \"Applied\"\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: \"incident-response, operational-technology, safety-engineering, digital-forensics, human-factors, governance, privacy, ai-autonomy\"\nclaimIds: \"claim-12-01, claim-12-05, claim-12-06, claim-12-08, claim-12-10\"\n---\n\n# Incident response without Earth\n\n> **Evidence boundary:** NIST incident-response and recovery guidance integrates preparation, detection, response, recovery, and improvement into present organizational risk management. Operational-technology guidance adds safety and availability constraints. Neither demonstrates autonomous incident response in a century-scale closed habitat. This lesson provides civil-and-defensive principles, not live incident instructions, forensic certification, medical advice, or legal process. It excludes offensive intrusion, autonomous weapons, weapon integration, and actionable exploitation instructions. High-consequence cyber, safety, rights, and dual-use decisions require two-person review whenever physically possible.\n\n## Plain-language summary\n\nOn Earth, an organization can call a vendor, national response team, insurer, regulator, laboratory, police service, or cloud provider. A generation ship may receive advice only after a delay, or never. It must recognize incidents, keep people alive, preserve enough evidence to learn, restore trustworthy service, and resolve responsibility using onboard institutions.\n\nThe first question is not “who attacked us?” It is “what essential service is at risk, what do we actually know, and what action reduces total harm?” A radiation fault, worn sensor, mistaken update, malicious insider, compromised toolchain, and poisoned AI model can produce similar symptoms.\n\nGood response separates immediate safety from attribution. It contains only as much as necessary, makes uncertainty visible, protects private and civic rights, preserves an appeal path, and returns emergency powers after the incident. Recovery ends when service and trust are independently re-established—not merely when devices reboot.\n\n## Prepare before the alarm\n\nNIST SP 800-61 Revision 3 treats incident response as part of cybersecurity risk management across the Cybersecurity Framework’s Govern, Identify, Protect, Detect, Respond, and Recover functions. That matters because response capability cannot be improvised after the only copy of a procedure or key has been corrupted.\n\nPreparation should establish:\n\n- essential services, minimum-safe states, and maximum tolerable outages;\n- local incident roles, alternates, succession, and conflicts-of-interest rules;\n- authority to isolate, override, inspect, restore, and reconnect;\n- conditions and expiry for emergency powers;\n- private, safe reporting and protection against retaliation;\n- independent sensors, logs, time sources, and evidence stores;\n- known-good software, configurations, hardware, documentation, keys, and tools;\n- medical, psychological, fatigue, and accessibility support for responders;\n- communication plans for residents and separated zones;\n- recovery priorities and explicit do-not-reconnect conditions; and\n- exercises that include unavailable experts, broken automation, and ambiguous cause.\n\nResponse staff must know the physical process. An information-technology team should not disconnect a controller without understanding how the plant fails. A process operator should not erase a suspect device merely to restore convenience. The incident structure needs cybersecurity, safety, operations, maintenance, governance, privacy, and affected-community representation.\n\n## Detect without pretending certainty\n\nAn alert is an observation produced by a detector under assumptions. It is not a verdict.\n\nDetection should compare several evidence classes:\n\n- physical measurements and independent instruments;\n- command, network, identity, and configuration records;\n- software and firmware integrity checks;\n- operator reports and observed behavior;\n- maintenance, calibration, and manufacturing history;\n- expected process relationships and invariant limits; and\n- changes in AI models, retrieval data, or automated recommendations.\n\nRecord what was observed, by which instrument, under which calibration and clock, and who interpreted it. Preserve contradictory evidence. If two oxygen sensors disagree, do not silently choose the one that matches the dashboard. If a signed log conflicts with a physical witness, investigate both.\n\nTriage should express confidence and consequence separately. A low-confidence indicator of catastrophic life-support danger may justify a reversible precaution. A high-confidence integrity fault in a nonessential archive may allow slower investigation. Avoid premature attribution, which can turn technical ambiguity into political conflict.\n\n## Stabilize life, then contain deliberately\n\nContainment can stop propagation, but it can also remove service. NIST SP 800-82 emphasizes that OT decisions must respect safety, availability, performance, and physical-process timing.\n\nUse a hierarchy:\n\n1. protect people from immediate physical hazard;\n2. move the affected service toward a predefined minimum-safe mode;\n3. restrict suspect identities, conduits, functions, or changes at the narrowest effective boundary;\n4. preserve independent observability and communication;\n5. protect recovery material from the suspected cause; and\n6. reassess continuously as evidence changes.\n\nA broad shutdown may be justified, but should not be automatic. Isolation should have a declared owner, reason, expected duration, review time, and exit criteria. Residents need truthful status without publication of private medical data or details that would make the incident worse.\n\nEmergency access is especially dangerous. A break-glass credential should be narrow, time-limited, logged, and reviewed. No incident should create a permanent unaccountable administrator.\n\n## Preserve evidence without sacrificing survival\n\nEvidence helps distinguish defect, error, malicious action, and institutional failure. It supports repair, accountability, and future design. Yet preserving a disk image is secondary to keeping air or water safe.\n\nBefore changing a suspect system, where time permits:\n\n- capture volatile state and relevant process conditions;\n- identify the collector, tool, time basis, and method;\n- preserve originals or clearly mark any transformation;\n- calculate integrity checks and store copies across independent zones;\n- record gaps, failed collection, and uncertainty;\n- limit access to private or legally sensitive material; and\n- maintain a chain of custody that can be challenged.\n\nDigital evidence does not interpret itself. Clocks can disagree, logs can be incomplete, sensors can drift, and administrators can have legitimate reasons for unusual actions. Due process requires separating containment from guilt and providing an independent forum for contested findings.\n\n## Investigate locally and test competing explanations\n\nBuild a timeline with explicit uncertainty. For each event, distinguish observation, inference, hypothesis, and decision. Maintain several plausible explanations until evidence separates them.\n\nA disciplined investigation asks:\n\n- What changed before the unsafe state?\n- Which independent observations corroborate it?\n- Could one common dependency explain multiple symptoms?\n- Did the response itself alter or destroy evidence?\n- What assumptions were inherited from software, vendors, or past governance?\n- Which people or systems benefit from one interpretation?\n- What evidence would falsify each hypothesis?\n\nAdversarial testing belongs in a contained cyber range or representative test article. It should reproduce defensive conditions without teaching or exercising offensive intrusion against live systems. Investigators should not “prove” a theory by experimenting on active life support.\n\n## Restore from a bounded base\n\nRecovery is not a return to the exact pre-incident state if that state was vulnerable or already compromised. Define a **recovery point**: a known, documented configuration whose residual risks are understood.\n\nRecovery may require:\n\n- replacing suspect hardware or sensors;\n- booting from independently protected firmware;\n- rebuilding software with preserved tools and source;\n- restoring data while separating executable content;\n- rotating keys and narrowing privileges;\n- recalibrating against physical references;\n- manually reconstructing disputed records;\n- monitoring with independent instruments; and\n- maintaining the affected zone in degraded service until evidence is sufficient.\n\nNIST SP 800-184 frames recovery around planning, playbooks, testing, improvement, and restoration of capabilities. For a ship, the decisive constraint is local closure: spares, readers, compilers, keys, calibration standards, and competent people must exist onboard.\n\n## Attest and reconnect\n\nAttestation reports properties of a component or state under a defined mechanism. It does not establish that the whole zone is safe. Reconnection should combine:\n\n- verified hardware and firmware state;\n- known software and configuration;\n- validated data and schema migration;\n- independent physical health observations;\n- narrowed identities and refreshed credentials;\n- observation through a restricted conduit;\n- a staged increase in privileges and traffic; and\n- an immediate return-to-isolation path.\n\nThe incident commander should not be the sole authority certifying recovery. Safety owners, operators, security reviewers, and an independent rights or governance reviewer should sign the record appropriate to consequence. High-consequence reconnection requires two qualified people and cannot be delegated to AI.\n\n## LLMs in the response room\n\nAn offline LLM can search controlled manuals, summarize large logs, translate between disciplines, propose competing hypotheses, or draft a status report. It can also confabulate a timeline, follow poisoned log text, misread technical evidence, reveal private information, or cause tired humans to converge too early.\n\nControls should require source citations and exact record locations, preserve model version and retrieval set, label inferences, redact secrets and private data, and test recommendations against deterministic tools and physical evidence. The model should have no direct access to actuators, identity revocation, evidence deletion, or deployment. It cannot determine guilt, command the response, approve restoration, or count as an independent reviewer. Teams must rehearse with AI absent and with deliberately unreliable advisory output.\n\n## Learn without creating surveillance\n\nAfter minimum safe service is stable, review the technical cause, organizational conditions, decision quality, human workload, rights impacts, and response-induced harm. Publish a resident-readable account consistent with privacy and remaining security needs. Track corrective actions to owners and tests.\n\nMore logging is not always the answer. Collect evidence tied to declared hazards and retention periods. Delete or de-identify data that no longer serves a legitimate purpose. An incident cannot become a blank check for permanent monitoring.\n\n## Evidence ledger\n\n- **L11-05-A — Incident response is a cross-lifecycle risk-management capability, not a single containment phase.** Basis: observed in current NIST guidance. Readiness: operational in present organizations; major scale-up for autonomous habitats. Confidence: strong.\n- **L11-05-B — OT containment and recovery must balance cyber risk with physical safety and availability.** Basis: observed and normative. Readiness: operational in bounded industrial contexts. Confidence: strong.\n- **L11-05-C — A generation ship must preserve local incident command, trust recovery, evidence interpretation, and succession after loss of Earth.** Basis: proposed requirement. Readiness: early research as an integrated capability. Confidence: supported.\n- **L11-05-D — Mixed crews should repeatedly isolate a compromised zone, maintain minimum safe service, rebuild, and safely rejoin.** Basis: normative decision gate. Readiness: proposed; no cited generation-ship demonstration. Confidence: supported.\n- **L11-05-E — Due process, privacy, appeal, and expiry of emergency authority are incident-resilience requirements.** Basis: normative. Readiness: proposed for this context. Confidence: supported; governance implementation remains contested.\n- **L11-05-F — Offline evidence-linked LLMs may assist analysis but add poisoning, confabulation, privacy, and overreliance risk.** Basis: observed risk taxonomy and proposed use. Readiness: early research for high-consequence response. Confidence: supported.\n\nLinked corpus claims: `claim-12-01`, `claim-12-05`, `claim-12-06`, `claim-12-08`, 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- Cause and attacker are not assumed; faults, mistakes, malicious acts, and institutional failures remain competing explanations.\n- Life safety can justify urgent reversible action, not permanent suspension of rights.\n- Evidence preservation is bounded by immediate safety, privacy, and available resources.\n- A cryptographic integrity result or attestation is not whole-system proof.\n- Recovery guidance must be tailored to the physical process and independently reviewed.\n- LLMs remain offline-capable, evidence-linked, logged, non-authoritative, removable, and barred from actuation, guilt, revocation, and reconnection authority.\n- No offensive method, live exploitation instruction, autonomous weapon, or weapon integration is in scope.\n\n## What would change this conclusion?\n\nConfidence would improve through repeated blind exercises in representative closed habitats: ambiguous anomaly, central services unavailable, one insider hypothesis, one physical fault, one poisoned AI evidence source, limited spares, and residents exercising appeal rights. Teams must maintain essential service, preserve and challenge evidence, rebuild locally, reconnect in stages, and retire emergency powers. Failure to do those things without outside rescue is a wait/do-not-launch result, not a training score to explain away.\n\n## Sources and locators\n\n- [S01 — NIST SP 800-61 Revision 3, Incident Response Recommendations and Considerations for Cybersecurity Risk Management](https://doi.org/10.6028/NIST.SP.800-61r3). Locator: CSF 2.0 Community Profile covering Govern, Identify, Protect, Detect, Respond, Recover, preparation, communication, analysis, mitigation, recovery, and improvement; April 2025; accessed 2026-07-25.\n- [S02 — NIST SP 800-184, Guide for Cybersecurity Event Recovery](https://doi.org/10.6028/NIST.SP.800-184). Locator: sections 2–4 on recovery planning, playbooks, testing, metrics, restoration, and improvement; December 2016; accessed 2026-07-25.\n- [S03 — NIST SP 800-82 Revision 3, Guide to Operational Technology Security](https://doi.org/10.6028/NIST.SP.800-82r3). Locator: OT safety, availability, timing, incident response, contingency planning, and recovery considerations; September 2023; accessed 2026-07-25.\n- [S04 — NIST SP 800-160 Volume 2 Revision 1, Developing Cyber-Resilient Systems](https://doi.org/10.6028/NIST.SP.800-160v2r1). Locator: anticipate, withstand, recover, adapt; cyber-resiliency techniques and design principles; December 2021; accessed 2026-07-25.\n- [S05 — NIST SP 800-86, Guide to Integrating Forensic Techniques into Incident Response](https://doi.org/10.6028/NIST.SP.800-86). Locator: sections 2–3 and media, operating-system, network, and application evidence chapters; August 2006; 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: Incident Response, Contingency Planning, Audit and Accountability, Identification and Authentication, Privacy, and System Integrity control families; September 2020, updates through 2025; 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 risk sections; 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 and misuse taxonomy, attacker goals and capabilities, lifecycle stages, and mitigation limits; 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: incident response, operational technology, safety engineering, digital forensics, human factors, governance, privacy, and AI/autonomy\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, CISA, IETF, or any named organization\n- Scope boundary: Civil and defensive resilience only; offensive intrusion, 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-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-02",
      "title": "Space-sector guidance and protocol-security reports, operational-technology, software-supply-chain, zero-trust, post-quantum, and cyber-resilience standards provide relevant but fragmented reference points; their existence does not establish integration or assurance.",
      "publicPath": "/claims/claim-12-02",
      "recordFingerprint": "0f49699074aad1bdc4026a7e08cecd517f96beb614fa4055762c508de9fa31fc"
    },
    {
      "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-04",
      "title": "Within the public sources sampled for this foundation draft, we did not identify a generation-ship cybersecurity standard or a demonstrated century-scale cryptographic deployment.",
      "publicPath": "/claims/claim-12-04",
      "recordFingerprint": "1f2f998d50f9608459ee4d3da4ac355a5bf83f8c7d328e5d931ade7d5e4ec478"
    },
    {
      "recordType": "claim",
      "recordId": "claim-12-05",
      "title": "Trust anchors, identity, secure time, revocation, incident command, threshold recovery, crypto-agile migration, anti-rollback, and archival signature interpretation must work locally after permanent loss of Earth.",
      "publicPath": "/claims/claim-12-05",
      "recordFingerprint": "2811cbe867ae12c3b3d54f9da45439d26535ec4349f41ae4a7cb36eb37ea26a1"
    },
    {
      "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-08",
      "title": "Disconnected trust fabrics, update airlocks, recovery vaults, and cyber ranges benefit critical infrastructure and remote industry.",
      "publicPath": "/claims/claim-12-08",
      "recordFingerprint": "cf9e9af24876befe4386e5d20c5bd3940c82a2f55d410ae762b76cc43357ca22"
    },
    {
      "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"
    }
  ],
  "referenceSnapshots": [
    {
      "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-nasa-std-1006a",
      "sourceRecordType": "claim-source",
      "sourceFingerprint": "21bc08c8476b722c9011a875a0feeef60390048860f419d797f96be3a5cf998a",
      "snapshot": {
        "id": "src-cr-nasa-std-1006a",
        "title": "Space System Protection Standard",
        "authors": [
          "National Aeronautics and Space Administration"
        ],
        "publisher": "NASA Technical Standards System",
        "year": 2022,
        "url": "https://standards.nasa.gov/standard/NASA/NASA-STD-1006",
        "kind": "active-nasa-mandatory-standard",
        "checkedAt": "2026-07-26",
        "version": "A",
        "documentDate": "2022-07-15",
        "status": "ACTIVE",
        "reviewDue": "2027-07-15",
        "scopeNote": "Active Agency-level protection requirements intended to make NASA missions resilient to threats. The standard is normative authority for its NASA scope, not demonstration that a particular system satisfies the requirements or that a generation-ship architecture is integrated or assured."
      }
    },
    {
      "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-fips203-mlkem",
      "sourceRecordType": "claim-source",
      "sourceFingerprint": "a8bc98ef3f8daf79edc2206df6273a4f8e046a98b172df40a11061d4b936f78a",
      "snapshot": {
        "id": "src-cr-nist-fips203-mlkem",
        "title": "Module-Lattice-Based Key-Encapsulation Mechanism Standard",
        "authors": [
          "National Institute of Standards and Technology"
        ],
        "publisher": "NIST",
        "year": 2024,
        "url": "https://doi.org/10.6028/NIST.FIPS.203",
        "kind": "government-cryptographic-standard",
        "checkedAt": "2026-07-25",
        "scopeNote": "ML-KEM algorithms and parameter sets for establishing shared secrets; NIST lists potential updates and does not claim century-scale security or implementation assurance."
      }
    },
    {
      "sourceId": "src-cr-nist-fips204-mldsa",
      "sourceRecordType": "claim-source",
      "sourceFingerprint": "4b47fc94489002ab20d4e7858bcf1ddfce9f09ec939fa84ced8271cb124eba1e",
      "snapshot": {
        "id": "src-cr-nist-fips204-mldsa",
        "title": "Module-Lattice-Based Digital Signature Standard",
        "authors": [
          "National Institute of Standards and Technology"
        ],
        "publisher": "NIST",
        "year": 2024,
        "url": "https://doi.org/10.6028/NIST.FIPS.204",
        "kind": "government-cryptographic-standard",
        "checkedAt": "2026-07-25",
        "scopeNote": "ML-DSA digital-signature algorithms and parameter sets; standardization does not establish indefinite security, implementation correctness, or archival continuity."
      }
    },
    {
      "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-cr-nist-zero-trust-800207",
      "sourceRecordType": "claim-source",
      "sourceFingerprint": "4084c1d50c6edb3efc017ff0bfe23d5280297df0258c440ca27973d10702e901",
      "snapshot": {
        "id": "src-cr-nist-zero-trust-800207",
        "title": "Zero Trust Architecture",
        "authors": [
          "Scott Rose",
          "Oliver Borchert",
          "Stu Mitchell",
          "Sean Connelly"
        ],
        "publisher": "NIST",
        "year": 2020,
        "url": "https://doi.org/10.6028/NIST.SP.800-207",
        "kind": "government-cybersecurity-architecture-guidance",
        "checkedAt": "2026-07-25",
        "scopeNote": "Resource-focused zero-trust tenets, logical components, deployment models, and threats for enterprise systems; does not establish closed-habitat integration."
      }
    },
    {
      "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-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-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-jpl-dsac",
      "sourceRecordType": "claim-source",
      "sourceFingerprint": "eb44d6f5e829543be29e410f9cc10f9588df681ae8fe28478bfb705f4c47c199",
      "snapshot": {
        "id": "src-pn-jpl-dsac",
        "title": "Working Overtime: NASA's Deep Space Atomic Clock Completes Mission",
        "authors": [
          "Jet Propulsion Laboratory"
        ],
        "publisher": "NASA Jet Propulsion Laboratory",
        "year": 2021,
        "url": "https://www.jpl.nasa.gov/news/working-overtime-nasas-deep-space-atomic-clock-completes-mission/",
        "kind": "technology-demonstration-record",
        "checkedAt": "2026-07-25",
        "scopeNote": "Deep Space Atomic Clock mission duration, spaceflight technology-demonstration boundary, and reported timing stability over more than twenty days."
      }
    }
  ],
  "packetFingerprint": "c4051c5ed74ce8c61ee7bbff31736a73acdf6fdfb9d07439352ebad356f2140e"
}