Cybersecurity, safety & recovery

Packet identity

Packet ID

academy:cyber-resilience

Packet SHA-256 identity

c4051c5ed74ce8c61ee7bbff31736a73acdf6fdfb9d07439352ebad356f2140e

Corpus SHA-256 identity

8fa944604ca189f5a9216ca59f640ad2ca20972ad512f2f4970764716782e18d

Release ID

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

Source commit

3eb036fce3d711336c8c605625895e8a2e799ab0

Frozen corpus date

2026-07-25

Primary records

6

Reference sources

26

Questions and exclusions

Required questions

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

Explicit exclusions

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

Requested controlled scopes: defensive-cyber-safety, information-science, security-assurance, systems-engineering

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

Complete primary record set

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

1. academy-track · cyber-resilience

   Cybersecurity, safety & recovery

   Record fingerprint

   5d3049793c84dc33ef2f82972e4f925a269f130a09961c0ceb466460ff8728d9

   Minimum approvals

   1

   Required scope groups

   bounded-competence: defensive-cyber-safety, security-assurance

   High-consequence domains

   None under the named two-person rule

   Review state

   pending

   Published human decisions

   0

   Inspect the complete frozen review surface

   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.

   Core Question

   Can the crew keep living while assuming parts of the system are compromised?

   Image

   /images/chapters/13-cyber-resilience.avif

   Systems

   1. cybersecurity
   2. ai-autonomy
   3. manufacturing-isru

   Lessons

   1. 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

   2. Slug

      islands-and-conduits

      Title

      Trust islands and safe conduits

      Summary

      Segment critical domains and preserve manual, local, deterministic operation.

      Minutes

      18

      Level

      Foundation

   3. Slug

      update-airlock

      Title

      The update airlock

      Summary

      Validate provenance, compatibility, signatures, staged rollout, health checks, and rollback.

      Minutes

      18

      Level

      Foundation

   4. Slug

      cryptography-across-generations

      Title

      Cryptography across generations

      Summary

      Design algorithm inventories, replaceable interfaces, key recovery, and archive migration.

      Minutes

      18

      Level

      Foundation

   5. 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

2. academy-lesson · lesson-11-01

   Threat-model the whole ship

   Record fingerprint

   2262caf8dc1d3a40db09ec97759dbcaf61c6edc2e34c0e66be3d622e299b1437

   Minimum approvals

   1

   Required scope groups

   bounded-competence: defensive-cyber-safety, security-assurance

   High-consequence domains

   None under the named two-person rule

   Review state

   pending

   Published human decisions

   0

   Inspect the complete frozen review surface

   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

   Track Slug

   cyber-resilience

   Track Title

   Cybersecurity, safety & recovery

   Href

   /academy/cyber-resilience/threat-model-the-ship

   Prepared By

   GShips Project

   Last Edited At

   2026-07-26

   Review Required Domains

   1. cybersecurity
   2. safety-engineering
   3. operational-technology
   4. human-factors
   5. governance
   6. privacy
   7. ai-autonomy
   8. manufacturing-isru

   Claim IDs

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

   Exact MDX

   ---
   id: "lesson-11-01"
   track: "cyber-resilience"
   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"
   preparedBy: "GShips Project"
   lastEditedAt: "2026-07-26"
   conflicts: "Maintainer intends to explore a commercial venture based on some GShips work; no entity, funding, customer, sponsor, or partner relationship currently exists."
   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"
   ---
   
   # Threat-model the whole ship
   
   > **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.
   
   ## Plain-language summary
   
   A 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.
   
   Threat-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.
   
   The 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.
   
   ## Begin with missions, not malware
   
   NIST 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.
   
   NASA-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.
   
   Start with functions whose loss could harm people:
   
   - maintain breathable atmosphere within declared limits;
   - keep safe water and sanitation available;
   - supply stable electrical power and heat rejection;
   - preserve medical capability and trustworthy patient records;
   - operate food production and ecological monitoring;
   - navigate, communicate, and maintain attitude or trajectory;
   - manufacture and qualify replacement parts;
   - preserve constitutional, scientific, and maintenance records; and
   - conduct legitimate emergency decisions and return authority afterward.
   
   For 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.
   
   ## Draw the cyber-physical chain
   
   A 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.
   
   For each critical service, map:
   
   1. **Physical process.** What matter or energy changes, and what states are hazardous?
   2. **Sensing.** Which instruments indicate the state? What independent observation could challenge them?
   3. **Control.** Which deterministic controllers, software services, models, and human procedures choose actions?
   4. **Actuation.** Which devices create a physical effect, and what limits exist below application software?
   5. **Dependencies.** Which power, cooling, timing, identity, communications, calibration, and maintenance services are required?
   6. **Authority.** Who may observe, propose, approve, execute, override, and audit a change?
   7. **Recovery.** Which known-good code, configuration, tools, spares, and knowledge can restore service?
   
   NIST 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.
   
   ## Model causes, not stereotypes
   
   The 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.
   
   Use at least these cause classes:
   
   - hardware defect, wear, environmental damage, and common-mode failure;
   - software defect, unsafe interaction, stale configuration, and undocumented dependency;
   - corrupted design, build, update, calibration, or manufacturing data;
   - compromised supplier, toolchain, component, or maintenance instrument;
   - accidental operator action, fatigue, inadequate training, or ambiguous interface;
   - malicious insider, coercion, collusion, stolen identity, or abuse of emergency privilege;
   - institutional failure, discriminatory policy, governance capture, or loss of appeal;
   - AI confabulation, poisoned data or model, unsafe automation bias, and model drift; and
   - external communications carrying malformed, misleading, obsolete, or unauthorized material.
   
   This 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.
   
   ## People, rights, and authority are inside the model
   
   An 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.
   
   Security requirements should therefore include civil constraints:
   
   - collect the least personal data consistent with a declared safety purpose;
   - separate process telemetry from behavioral surveillance;
   - require warrants or equivalent accountable process for invasive access, except under narrow emergency conditions;
   - log use of exceptional authority and require later independent review;
   - provide notice, correction, appeal, and restoration of wrongly restricted access;
   - rotate sensitive duties and separate authorization from execution;
   - preserve anonymous or confidential reporting channels; and
   - prohibit immutable caste, lineage, or political status in identity credentials.
   
   These 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.
   
   ## Manufacturing expands the attack surface
   
   Onboard industry turns information into physical artifacts. Product definitions, material pedigrees, toolpaths, heat-treatment recipes, acceptance thresholds, calibration corrections, and maintenance histories become safety assets.
   
   A 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.
   
   High-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.
   
   ## LLMs change both capacity and risk
   
   An 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.
   
   Models 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.
   
   The defensible role is evidence-bounded and non-authoritative:
   
   - cite the controlled record and exact revision behind each material statement;
   - distinguish observation, inference, proposal, and unknown;
   - operate offline when external service cannot be trusted or reached;
   - have no direct path to life-support actuators, identity revocation, weapons, or final safety acceptance;
   - preserve inputs, outputs, model version, retrieval set, and human disposition for review;
   - compare recommendations against deterministic limits and approved procedures; and
   - rehearse operation with the model absent, corrupted, or confidently wrong.
   
   AI is one advisory channel. It is not the incident commander, judge, root of trust, or substitute for physical verification.
   
   ## Turn the model into tests
   
   A threat register that never changes a test, architecture, spare, or decision is paperwork. Each high-consequence scenario should connect to a testable claim:
   
   - Can two independent measurements reveal a corrupted sensor family?
   - Can a zone continue minimum safe service when isolated?
   - Can operators identify a false but correctly signed configuration?
   - Can the crew rebuild a controller from locally held known-good material?
   - Can a resident challenge an erroneous access restriction during an incident?
   - Can a mixed-experience team work without a specialist or AI assistant?
   - Can investigators preserve evidence while restoring urgent service?
   
   The 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.
   
   ## Evidence ledger
   
   - **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.
   - **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.
   - **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.
   - **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.
   - **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.
   - **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.
   
   Linked 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.
   
   ## Assumptions and limits
   
   - No particular population, network topology, propulsion system, constitutional order, adversary, or mission duration is assumed.
   - NIST publications are voluntary guidance for present organizations; citation does not make them flight requirements.
   - “Threat” includes hazardous causes and institutional misuse, not only intentional attackers.
   - Monitoring is not assumed to justify pervasive surveillance.
   - Cryptographic validity is not treated as proof of physical truth, competence, legitimacy, or safety.
   - LLM support is offline-capable, evidence-linked, logged, advisory, and removable; deterministic protection and accountable people retain authority.
   - This lesson offers no exploit sequence and no offensive or weapon-integration guidance.
   
   ## What would change this conclusion?
   
   Confidence 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.
   
   ## Sources and locators
   
   - [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.
   - [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.
   - [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.
   - [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.
   - [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.
   - [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.
   - [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.
   - [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.
   - [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.
   - [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.
   
   ## Editorial record
   
   - Prepared by: GShips Project
   - Last edited: 2026-07-26
   - Required review: cybersecurity, safety engineering, operational technology, human factors, governance, privacy, AI/autonomy, and manufacturing assurance
   - Conflicts: Maintainer intends to explore a commercial venture based on some GShips work; no entity, funding, customer, sponsor, or partner relationship currently exists
   - Relationship boundary: Independent educational synthesis; citations do not imply affiliation, endorsement, partnership, or adoption by NASA, NIST, CISA, IETF, or any named organization
   - Scope boundary: Civil and defensive resilience only; offensive intrusion, autonomous weapons, weapon integration, and actionable exploitation instructions are excluded
   - Corrections: [Suggest a correction](https://gships.dammonburden.com/corrections)
   

3. academy-lesson · lesson-11-02

   Trust islands and safe conduits

   Record fingerprint

   ed99c094ef4da54a737a6eda2124f9972b8627525a604f8117abb9caeab74bed

   Minimum approvals

   1

   Required scope groups

   bounded-competence: defensive-cyber-safety, security-assurance

   High-consequence domains

   None under the named two-person rule

   Review state

   pending

   Published human decisions

   0

   Inspect the complete frozen review surface

   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

   Track Slug

   cyber-resilience

   Track Title

   Cybersecurity, safety & recovery

   Href

   /academy/cyber-resilience/islands-and-conduits

   Prepared By

   GShips Project

   Last Edited At

   2026-07-26

   Review Required Domains

   1. cybersecurity-architecture
   2. operational-technology
   3. safety-engineering
   4. networks
   5. identity
   6. human-factors
   7. ai-autonomy

   Claim IDs

   1. claim-12-01
   2. claim-12-02
   3. claim-12-03
   4. claim-12-05
   5. claim-12-08
   6. claim-12-10

   Exact MDX

   ---
   id: "lesson-11-02"
   track: "cyber-resilience"
   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"
   preparedBy: "GShips Project"
   lastEditedAt: "2026-07-26"
   conflicts: "Maintainer intends to explore a commercial venture based on some GShips work; no entity, funding, customer, sponsor, or partner relationship currently exists."
   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"
   ---
   
   # Trust islands and safe conduits
   
   > **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.
   
   ## Plain-language summary
   
   A 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.
   
   The 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.
   
   Segmentation 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.
   
   ## What makes an island?
   
   A 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.
   
   Candidate islands might include:
   
   - local atmosphere and thermal control for a pressure zone;
   - water treatment with local sampling and manual routing;
   - a power microgrid capable of black start;
   - medical records and essential treatment equipment;
   - food-production environmental control;
   - manufacturing release, metrology, and machine control;
   - navigation and vehicle control;
   - identity and civic records;
   - a recovery vault containing known-good software, configuration, keys, documentation, and tools.
   
   These 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.
   
   For 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.
   
   ## A conduit is a contract
   
   Every 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:
   
   - source and destination identities;
   - message type and schema;
   - direction of travel;
   - allowed rate, size, and timing;
   - freshness and replay rules;
   - required authorization and separation of duties;
   - physical-range and semantic validation;
   - behavior on missing, contradictory, delayed, or excess data;
   - retained audit evidence and privacy limits; and
   - a tested way to close, degrade, or reopen the path.
   
   A 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.
   
   ## Segmentation and zero trust solve different problems
   
   NIST 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.
   
   Segmentation 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:
   
   - the policy engine itself can be unavailable or compromised;
   - a root identity authority cannot depend on Earth;
   - emergency access must work during network partition without becoming a permanent master key;
   - privacy and due process constrain continuous inspection;
   - old equipment may lack modern identity mechanisms;
   - secure time may be degraded or disputed; and
   - a safety controller may need deterministic response faster than a remote authorization loop.
   
   Place 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.
   
   ## Preserve graceful degradation
   
   Isolation is useful only if an island remains understandable and operable. A minimum-safe mode should specify:
   
   - which functions continue;
   - which conveniences stop;
   - how long local power, storage, consumables, and staffing last;
   - how local measurements are checked;
   - which commands remain possible;
   - how residents receive truthful status;
   - what evidence is preserved; and
   - which conditions demand evacuation, assistance, or carefully controlled reconnection.
   
   NIST 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.
   
   Manual 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.
   
   ## Recovery vaults and roots of trust
   
   An 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:
   
   - immutable or tightly controlled boot material;
   - multiple verified versions of firmware, operating systems, compilers, and configuration;
   - source code and reproducible build instructions where practicable;
   - cryptographic inventories and migration procedures;
   - calibration references and equipment;
   - offline documentation readable without a proprietary service;
   - spare controllers and interface adapters;
   - signed incident and change records; and
   - exercises showing that ordinary mixed teams can use the contents.
   
   “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.
   
   ## Communications under delay and partition
   
   Inter-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.
   
   BPSec 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.
   
   CCSDS 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.
   
   Queued 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.
   
   ## The role of LLMs
   
   An 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.
   
   Model 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.
   
   ## Design and test sequence
   
   For each island:
   
   1. Declare the essential function and minimum-safe envelope.
   2. Inventory dependencies and common-mode failures.
   3. Define conduits as explicit contracts.
   4. Establish local control and physical safety limits.
   5. Define identity, emergency authority, expiry, and appeal.
   6. Prepare recovery material and readable procedures.
   7. Isolate the island under realistic load.
   8. Introduce contradictory sensors, unavailable specialists, damaged links, stale messages, and a suspect update.
   9. Restore from known-good material.
   10. Reconnect through staged observation and renewed attestation.
   
   Passing 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.
   
   ## Evidence ledger
   
   - **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.
   - **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.
   - **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.
   - **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.
   - **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.
   - **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.
   
   Linked 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.
   
   ## Assumptions and limits
   
   - “Island” describes a survivability boundary, not a claim of complete isolation.
   - No topology, vendor, protocol suite, population, or required outage duration is prescribed.
   - Terrestrial zero-trust guidance assumes institutions and infrastructure that may not be available onboard.
   - Manual operation is counted only when access, measurement, staffing, duration, and training are demonstrated.
   - Cryptographic checks do not establish physical truth or legitimate policy.
   - LLMs remain offline-capable, evidence-linked, non-authoritative, logged, and physically unable to bridge trust zones or actuate safety systems.
   - No offensive technique or weapon integration is in scope.
   
   ## What would change this conclusion?
   
   Confidence 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.
   
   ## Sources and locators
   
   - [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.
   - [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.
   - [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.
   - [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.
   - [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.
   - [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.
   - [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.
   - [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.
   - [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.
   - [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.
   - [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.
   
   ## Editorial record
   
   - Prepared by: GShips Project
   - Last edited: 2026-07-26
   - Required review: cybersecurity architecture, operational technology, safety engineering, networks, identity, human factors, governance, and AI/autonomy
   - Conflicts: Maintainer intends to explore a commercial venture based on some GShips work; no entity, funding, customer, sponsor, or partner relationship currently exists
   - Relationship boundary: Independent educational synthesis; citations do not imply affiliation, endorsement, partnership, or adoption by NASA, NIST, IETF, or any named organization
   - Scope boundary: Civil and defensive resilience only; offensive intrusion, autonomous weapons, weapon integration, and actionable exploitation instructions are excluded
   - Corrections: [Suggest a correction](https://gships.dammonburden.com/corrections)
   

4. academy-lesson · lesson-11-03

   The update airlock

   Record fingerprint

   71bb1e2a8cff187c0d06dc6301d7c982c11671a143dac7bb8714816198d39f40

   Minimum approvals

   1

   Required scope groups

   bounded-competence: defensive-cyber-safety, security-assurance

   High-consequence domains

   None under the named two-person rule

   Review state

   pending

   Published human decisions

   0

   Inspect the complete frozen review surface

   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

   Track Slug

   cyber-resilience

   Track Title

   Cybersecurity, safety & recovery

   Href

   /academy/cyber-resilience/update-airlock

   Prepared By

   GShips Project

   Last Edited At

   2026-07-26

   Review Required Domains

   1. software-assurance
   2. firmware-security
   3. operational-technology
   4. safety-engineering
   5. supply-chain-risk
   6. ai-autonomy
   7. configuration-management

   Claim IDs

   1. claim-12-02
   2. claim-12-03
   3. claim-12-05
   4. claim-12-07
   5. claim-12-08
   6. claim-12-10

   Exact MDX

   ---
   id: "lesson-11-03"
   track: "cyber-resilience"
   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"
   preparedBy: "GShips Project"
   lastEditedAt: "2026-07-26"
   conflicts: "Maintainer intends to explore a commercial venture based on some GShips work; no entity, funding, customer, sponsor, or partner relationship currently exists."
   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"
   ---
   
   # The update airlock
   
   > **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.
   
   ## Plain-language summary
   
   An 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.
   
   An **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.
   
   The 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.
   
   ## What counts as an update?
   
   Treat every executable or decision-shaping change as a release object:
   
   - application, operating-system, bootloader, and device firmware;
   - programmable-logic and controller configurations;
   - cryptographic algorithms, certificates, trust anchors, and revocation data;
   - AI model weights, prompts, retrieval collections, embeddings, and evaluation sets;
   - calibration curves, material specifications, toolpaths, and manufacturing recipes;
   - medical protocols, ecological thresholds, navigation tables, and digital-twin parameters;
   - identity policy, authorization rules, and emergency procedures; and
   - compilers, build systems, test tools, and the airlock’s own code.
   
   A 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.
   
   ## The release evidence packet
   
   No object should enter the airlock alone. Its evidence packet should include:
   
   - unique identity, version, creation time or sequence, and intended targets;
   - content digest and authorized signatures;
   - human-readable purpose, hazards, assumptions, and affected requirements;
   - source, build recipe, compiler and tool versions where available;
   - component inventory, licenses, known defects, and supply-chain history;
   - compatibility bounds, dependencies, migration steps, and prohibited states;
   - test plan, expected results, independent results, and unresolved anomalies;
   - resource demands such as memory, power, bandwidth, storage, and operator time;
   - rollout groups, health metrics, pause thresholds, and rollback path; and
   - named proposers, reviewers, authorizers, and conflict disclosures.
   
   NIST 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.
   
   An 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.
   
   ## Intake without inheriting trust
   
   An 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.
   
   Intake should therefore:
   
   1. preserve the received object and transport metadata;
   2. verify integrity and signatures against the applicable historical policy;
   3. quarantine active content and render documentation safely;
   4. resolve target identity and reject ambiguity;
   5. inventory components and compare with local vulnerability knowledge;
   6. reconstruct the change against the prior approved baseline;
   7. identify which assumptions can be tested locally; and
   8. flag unknown, expired, revoked, or politically disputed authority for accountable human resolution.
   
   RFC 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.
   
   NASA-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.
   
   ## Compatibility is multidimensional
   
   “It installed” is not a compatibility result. Evaluate at least:
   
   - hardware model, revision, wear state, and locally manufactured substitutions;
   - firmware, driver, protocol, schema, and file-format versions;
   - timing, processor, memory, storage, bandwidth, power, and thermal margins;
   - control-loop stability and physical safety limits;
   - human interface, alarms, accessibility, language, and training burden;
   - cryptographic and identity transitions;
   - interactions with neighboring islands;
   - recoverability of old records and configurations; and
   - the ability to build, inspect, and roll back with onboard tools.
   
   Test 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.
   
   ## Authorization and separation of duties
   
   One 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.
   
   Emergency changes need a narrow path:
   
   - a defined qualifying condition;
   - minimum necessary scope and lifetime;
   - two-person approval when physically possible;
   - automatic expiry or mandatory reassessment;
   - preserved before-and-after state;
   - resident-visible disclosure consistent with privacy and safety; and
   - independent retrospective review.
   
   This 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.
   
   ## Staged rollout and health evidence
   
   Deploy 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.
   
   Before deployment, define:
   
   - expected functional and safety behavior;
   - invariant physical limits;
   - leading indicators of degradation;
   - observation duration across representative operating states;
   - who can pause, abort, or roll back;
   - what data may be collected and for how long; and
   - how success will be distinguished from an absence of detected failure.
   
   A 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.
   
   ## Rollback is a tested capability
   
   Rollback 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.
   
   NIST 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.
   
   Rehearse 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.
   
   ## AI and model updates
   
   Models 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.
   
   An 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.
   
   The 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.
   
   ## Evidence ledger
   
   - **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.
   - **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.
   - **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.
   - **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.
   - **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.
   - **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.
   
   Linked 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.
   
   ## Assumptions and limits
   
   - The airlock covers local and externally received changes; neither is trusted by origin alone.
   - No specific operating system, compiler, signature scheme, vendor, or deployment platform is prescribed.
   - SBOMs, signatures, reproducible builds, attestation, simulations, and digital twins provide partial evidence only.
   - Some physical or data migrations may be irreversible; this must be disclosed before authorization.
   - Privacy limits apply to rollout telemetry and operator monitoring.
   - LLMs are offline-capable, evidence-linked, non-authoritative, logged, removable, and unable to approve or deploy their own changes.
   - No exploit instructions, offensive operations, or weapon integration are included.
   
   ## What would change this conclusion?
   
   Readiness 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.
   
   ## Sources and locators
   
   - [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.
   - [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.
   - [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.
   - [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.
   - [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.
   - [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.
   - [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.
   - [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.
   - [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.
   - [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.
   
   ## Editorial record
   
   - Prepared by: GShips Project
   - Last edited: 2026-07-26
   - Required review: software assurance, firmware security, operational technology, safety engineering, supply-chain risk, AI/autonomy, and configuration management
   - Conflicts: Maintainer intends to explore a commercial venture based on some GShips work; no entity, funding, customer, sponsor, or partner relationship currently exists
   - Relationship boundary: Independent educational synthesis; citations do not imply affiliation, endorsement, partnership, or adoption by NASA, NIST, CISA, IETF, or any named organization
   - Scope boundary: Civil and defensive resilience only; offensive intrusion, autonomous weapons, weapon integration, and actionable exploitation instructions are excluded
   - Corrections: [Suggest a correction](https://gships.dammonburden.com/corrections)
   

5. academy-lesson · lesson-11-04

   Cryptography across generations

   Record fingerprint

   e527ca3391fe2c6fbe76320b83ea0726bf0f90a311d97135fd95bef399d77e63

   Minimum approvals

   1

   Required scope groups

   bounded-competence: defensive-cyber-safety, security-assurance

   High-consequence domains

   None under the named two-person rule

   Review state

   pending

   Published human decisions

   0

   Inspect the complete frozen review surface

   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

   Track Slug

   cyber-resilience

   Track Title

   Cybersecurity, safety & recovery

   Href

   /academy/cyber-resilience/cryptography-across-generations

   Prepared By

   GShips Project

   Last Edited At

   2026-07-25

   Review Required Domains

   1. cryptography
   2. key-management
   3. identity
   4. archival-science
   5. safety-engineering
   6. governance
   7. software-assurance

   Claim IDs

   1. claim-12-02
   2. claim-12-04
   3. claim-12-05
   4. claim-12-06
   5. claim-12-09
   6. claim-12-10

   Exact MDX

   ---
   id: "lesson-11-04"
   track: "cyber-resilience"
   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"
   preparedBy: "GShips Project"
   lastEditedAt: "2026-07-25"
   conflicts: "Maintainer intends to explore a commercial venture based on some GShips work; no entity, funding, customer, sponsor, or partner relationship currently exists."
   reviewRequiredDomains: "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"
   ---
   
   # Cryptography across generations
   
   > **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.
   
   ## Plain-language summary
   
   Cryptography helps a community answer questions such as:
   
   - Did this command come from an authorized role?
   - Has this medical or engineering record changed?
   - May this device join the control network?
   - Is this software release the one that reviewers approved?
   - Can only the intended people read this private information?
   
   The 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.
   
   A 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.
   
   ## Inventory before migration
   
   An algorithm inventory should record more than the word “encryption.” For each use, capture:
   
   - purpose: confidentiality, integrity, authentication, key establishment, commitment, timestamping, or random generation;
   - algorithm, parameters, mode, protocol, library, hardware, and version;
   - keys, certificates, trust anchors, owners, custodians, and authorized uses;
   - protected data and required protection lifetime;
   - dependent devices, software, records, and recovery paths;
   - clock, sequence, revocation, and network assumptions;
   - migration and rollback capability;
   - known compatibility constraints; and
   - evidence that implementation behaves as intended.
   
   The 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.
   
   NIST’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.
   
   ## Separate purpose from mechanism
   
   Design 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.
   
   However, 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.
   
   Therefore agility needs:
   
   - multiple implementation paths where consequence justifies them;
   - test vectors and known-answer tests preserved offline;
   - capacity margins for larger keys, signatures, and protocol messages;
   - versioned formats that identify algorithms and parameters;
   - negotiation policies that prevent silent downgrade;
   - hardware-independent fallback for essential verification where feasible;
   - source, build tools, specifications, and readable reference implementations; and
   - representative migration exercises on old hardware.
   
   Algorithm diversity can reduce common-mode risk, but unnecessary variants increase complexity. The objective is planned transition, not cryptographic abundance.
   
   ## Keys are governed material
   
   NIST SP 800-57 covers key generation, storage, use, backup, recovery, compromise, revocation, archival, and destruction. On a ship, these functions become local civic institutions.
   
   No 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.
   
   Threshold 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:
   
   - how many independent shares exist and what failures they tolerate;
   - physical and institutional separation;
   - accessibility and succession;
   - activation conditions and time limits;
   - evidence recorded without exposing secret material;
   - appeal and retrospective review;
   - response when compromise is suspected; and
   - a path to replace the recovery system itself.
   
   Backup 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.
   
   ## Identity without a permanent Earth authority
   
   People 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.
   
   Distinguish:
   
   - a person or device;
   - an identifier;
   - a credential binding an identifier to evidence;
   - a role granting bounded authority;
   - an authorization decision at a particular time; and
   - an audit record that may itself be contested.
   
   A 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.
   
   Emergency 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.
   
   ## Time, sequence, revocation, and partition
   
   Many 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.
   
   The design should separate:
   
   - physical mission time and its uncertainty;
   - local monotonic event sequence;
   - civil calendars and institutional terms;
   - cryptographic validity intervals;
   - evidence receipt time; and
   - claims about when an event actually happened.
   
   During 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.
   
   ## Archives outlive algorithms
   
   A 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.
   
   Archival preservation should retain:
   
   - original bytes and format documentation;
   - signature, certificate chain, policy, revocation evidence, and validation time;
   - contextual records explaining the signer’s authority;
   - independent hashes and replicated storage;
   - migration history and custodial actions;
   - periodic validation before algorithms weaken; and
   - renewed attestations that bind old evidence to new mechanisms without erasing the original.
   
   Migration 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.
   
   ## Post-quantum standards are a transition, not an ending
   
   NIST 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.
   
   A 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.”
   
   ## LLMs are not roots of trust
   
   An 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.
   
   The 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.
   
   ## A migration exercise
   
   A 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.
   
   Then 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.
   
   ## Evidence ledger
   
   - **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.
   - **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.
   - **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.
   - **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.
   - **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.
   - **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.
   
   Linked 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.
   
   ## Assumptions and limits
   
   - No current algorithm is assumed secure for the full mission.
   - NIST standards are present reference points, not generation-ship certification or universal law.
   - “Crypto agility” includes people, policy, hardware, formats, archives, and recovery—not only software interfaces.
   - Threshold custody does not eliminate coercion, collusion, exclusion, or institutional failure.
   - Archival renewal can preserve evidence chains but cannot recreate missing social context.
   - LLMs remain offline-capable, evidence-linked, non-authoritative, logged, and excluded from secrets and trust-anchor decisions.
   - This lesson contains no exploit procedure, offensive operation, or weapon integration.
   
   ## What would change this conclusion?
   
   Confidence 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.
   
   ## Sources and locators
   
   - [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.
   - [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.
   - [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.
   - [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.
   - [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.
   - [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.
   - [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.
   - [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.
   
   ## Editorial record
   
   - Prepared by: GShips Project
   - Last edited: 2026-07-25
   - Required review: cryptography, key management, identity, archival science, safety engineering, governance, and software assurance
   - Conflicts: Maintainer intends to explore a commercial venture based on some GShips work; no entity, funding, customer, sponsor, or partner relationship currently exists
   - Relationship boundary: Independent educational synthesis; citations do not imply affiliation, endorsement, partnership, or adoption by NIST or any named organization
   - Scope boundary: Civil and defensive resilience only; offensive intrusion, autonomous weapons, weapon integration, and actionable exploitation instructions are excluded
   - Corrections: [Suggest a correction](https://gships.dammonburden.com/corrections)
   

6. academy-lesson · lesson-11-05

   Incident response without Earth

   Record fingerprint

   8a0a9a1abea9615e0c99dd325a1008609a1e820cf53ff53dcee8fd333adc06ea

   Minimum approvals

   1

   Required scope groups

   bounded-competence: defensive-cyber-safety, security-assurance

   High-consequence domains

   None under the named two-person rule

   Review state

   pending

   Published human decisions

   0

   Inspect the complete frozen review surface

   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

   Track Slug

   cyber-resilience

   Track Title

   Cybersecurity, safety & recovery

   Href

   /academy/cyber-resilience/incident-without-earth

   Prepared By

   GShips Project

   Last Edited At

   2026-07-25

   Review Required Domains

   1. incident-response
   2. operational-technology
   3. safety-engineering
   4. digital-forensics
   5. human-factors
   6. governance
   7. privacy
   8. ai-autonomy

   Claim IDs

   1. claim-12-01
   2. claim-12-05
   3. claim-12-06
   4. claim-12-08
   5. claim-12-10

   Exact MDX

   ---
   id: "lesson-11-05"
   track: "cyber-resilience"
   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"
   preparedBy: "GShips Project"
   lastEditedAt: "2026-07-25"
   conflicts: "Maintainer intends to explore a commercial venture based on some GShips work; no entity, funding, customer, sponsor, or partner relationship currently exists."
   reviewRequiredDomains: "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"
   ---
   
   # Incident response without Earth
   
   > **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.
   
   ## Plain-language summary
   
   On 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.
   
   The 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.
   
   Good 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.
   
   ## Prepare before the alarm
   
   NIST 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.
   
   Preparation should establish:
   
   - essential services, minimum-safe states, and maximum tolerable outages;
   - local incident roles, alternates, succession, and conflicts-of-interest rules;
   - authority to isolate, override, inspect, restore, and reconnect;
   - conditions and expiry for emergency powers;
   - private, safe reporting and protection against retaliation;
   - independent sensors, logs, time sources, and evidence stores;
   - known-good software, configurations, hardware, documentation, keys, and tools;
   - medical, psychological, fatigue, and accessibility support for responders;
   - communication plans for residents and separated zones;
   - recovery priorities and explicit do-not-reconnect conditions; and
   - exercises that include unavailable experts, broken automation, and ambiguous cause.
   
   Response 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.
   
   ## Detect without pretending certainty
   
   An alert is an observation produced by a detector under assumptions. It is not a verdict.
   
   Detection should compare several evidence classes:
   
   - physical measurements and independent instruments;
   - command, network, identity, and configuration records;
   - software and firmware integrity checks;
   - operator reports and observed behavior;
   - maintenance, calibration, and manufacturing history;
   - expected process relationships and invariant limits; and
   - changes in AI models, retrieval data, or automated recommendations.
   
   Record 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.
   
   Triage 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.
   
   ## Stabilize life, then contain deliberately
   
   Containment 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.
   
   Use a hierarchy:
   
   1. protect people from immediate physical hazard;
   2. move the affected service toward a predefined minimum-safe mode;
   3. restrict suspect identities, conduits, functions, or changes at the narrowest effective boundary;
   4. preserve independent observability and communication;
   5. protect recovery material from the suspected cause; and
   6. reassess continuously as evidence changes.
   
   A 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.
   
   Emergency access is especially dangerous. A break-glass credential should be narrow, time-limited, logged, and reviewed. No incident should create a permanent unaccountable administrator.
   
   ## Preserve evidence without sacrificing survival
   
   Evidence 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.
   
   Before changing a suspect system, where time permits:
   
   - capture volatile state and relevant process conditions;
   - identify the collector, tool, time basis, and method;
   - preserve originals or clearly mark any transformation;
   - calculate integrity checks and store copies across independent zones;
   - record gaps, failed collection, and uncertainty;
   - limit access to private or legally sensitive material; and
   - maintain a chain of custody that can be challenged.
   
   Digital 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.
   
   ## Investigate locally and test competing explanations
   
   Build a timeline with explicit uncertainty. For each event, distinguish observation, inference, hypothesis, and decision. Maintain several plausible explanations until evidence separates them.
   
   A disciplined investigation asks:
   
   - What changed before the unsafe state?
   - Which independent observations corroborate it?
   - Could one common dependency explain multiple symptoms?
   - Did the response itself alter or destroy evidence?
   - What assumptions were inherited from software, vendors, or past governance?
   - Which people or systems benefit from one interpretation?
   - What evidence would falsify each hypothesis?
   
   Adversarial 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.
   
   ## Restore from a bounded base
   
   Recovery 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.
   
   Recovery may require:
   
   - replacing suspect hardware or sensors;
   - booting from independently protected firmware;
   - rebuilding software with preserved tools and source;
   - restoring data while separating executable content;
   - rotating keys and narrowing privileges;
   - recalibrating against physical references;
   - manually reconstructing disputed records;
   - monitoring with independent instruments; and
   - maintaining the affected zone in degraded service until evidence is sufficient.
   
   NIST 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.
   
   ## Attest and reconnect
   
   Attestation reports properties of a component or state under a defined mechanism. It does not establish that the whole zone is safe. Reconnection should combine:
   
   - verified hardware and firmware state;
   - known software and configuration;
   - validated data and schema migration;
   - independent physical health observations;
   - narrowed identities and refreshed credentials;
   - observation through a restricted conduit;
   - a staged increase in privileges and traffic; and
   - an immediate return-to-isolation path.
   
   The 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.
   
   ## LLMs in the response room
   
   An 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.
   
   Controls 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.
   
   ## Learn without creating surveillance
   
   After 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.
   
   More 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.
   
   ## Evidence ledger
   
   - **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.
   - **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.
   - **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.
   - **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.
   - **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.
   - **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.
   
   Linked 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.
   
   ## Assumptions and limits
   
   - Cause and attacker are not assumed; faults, mistakes, malicious acts, and institutional failures remain competing explanations.
   - Life safety can justify urgent reversible action, not permanent suspension of rights.
   - Evidence preservation is bounded by immediate safety, privacy, and available resources.
   - A cryptographic integrity result or attestation is not whole-system proof.
   - Recovery guidance must be tailored to the physical process and independently reviewed.
   - LLMs remain offline-capable, evidence-linked, logged, non-authoritative, removable, and barred from actuation, guilt, revocation, and reconnection authority.
   - No offensive method, live exploitation instruction, autonomous weapon, or weapon integration is in scope.
   
   ## What would change this conclusion?
   
   Confidence 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.
   
   ## Sources and locators
   
   - [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.
   - [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.
   - [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.
   - [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.
   - [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.
   - [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.
   - [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.
   - [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.
   
   ## Editorial record
   
   - Prepared by: GShips Project
   - Last edited: 2026-07-25
   - Required review: incident response, operational technology, safety engineering, digital forensics, human factors, governance, privacy, and AI/autonomy
   - Conflicts: Maintainer intends to explore a commercial venture based on some GShips work; no entity, funding, customer, sponsor, or partner relationship currently exists
   - Relationship boundary: Independent educational synthesis; citations do not imply affiliation, endorsement, partnership, or adoption by NASA, NIST, CISA, IETF, or any named organization
   - Scope boundary: Civil and defensive resilience only; offensive intrusion, autonomous weapons, weapon integration, and actionable exploitation instructions are excluded
   - Corrections: [Suggest a correction](https://gships.dammonburden.com/corrections)
   

Linked records—not review targets here

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

• Generation-ship security protects a civilization’s ability to operate, repair, govern, learn, and recover without an external rescuer—not merely its secrets. claim:claim-12-01 · 908842da73f03771a9e09cc29bdc8e3863610f7ab9de665f452f153f7bb618b1
• 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. claim:claim-12-02 · 0f49699074aad1bdc4026a7e08cecd517f96beb614fa4055762c508de9fa31fc
• Secure firmware-update patterns, platform recovery, software-component inventories, bundle-layer security for disrupted networking, and a publicly described CCSDS-oriented space-data-link cryptography library exist in different contexts. Availability does not establish compatibility, conformance, flight qualification, safe integration, or century maintenance. claim:claim-12-03 · 6055efdd9314736b322ecafce96268e59c3ddc2c7874b92f43b11b7494689e92
• 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. claim:claim-12-04 · 1f2f998d50f9608459ee4d3da4ac355a5bf83f8c7d328e5d931ade7d5e4ec478
• 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. claim:claim-12-05 · 2811cbe867ae12c3b3d54f9da45439d26535ec4349f41ae4a7cb36eb37ea26a1
• Insiders, collusion, governance capture, compromised suppliers, corrupted hardware, malicious maintenance, radiation faults, operator error, and generational loss of expertise must be addressed without turning safety monitoring into surveillance or political control. claim:claim-12-06 · e661cc2789a8cd078b10a5fa6f5f4bb267c1dcdcc4156a6fd1870fa857a41db2
• Onboard manufacturing makes malicious designs, poisoned toolchains, compromised metrology, counterfeit replacement parts, and configuration drift cyber-physical threats. claim:claim-12-07 · aa41b5d69f1e2cb946f156453cc5e43165f992ffba714ec0b1562413e4751e5c
• Disconnected trust fabrics, update airlocks, recovery vaults, and cyber ranges benefit critical infrastructure and remote industry. claim:claim-12-08 · cf9e9af24876befe4386e5d20c5bd3940c82a2f55d410ae762b76cc43357ca22
• Crypto agility and toolchain escrow reduce obsolescence risk in medical, energy, transport, and public systems. claim:claim-12-09 · 4c3588aab47e1175acc7a32a66fd16e23f01df3fd603f3d4005e2e5503935290
• Mixed crews must repeatedly isolate a compromised zone, maintain life support, investigate locally, rebuild from known-good material, and rejoin safely. claim:claim-12-10 · 718e87306ab83c20b2c477e928406ce5697e01b1a5b64ab9cde6d6fbcbe148be

Frozen source snapshots

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

Offline packet and worksheet

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

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

Packet schema · JSON · Decision-bundle schema · JSON

Validate offline

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

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

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

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

3. Validate the packet and completed copy.

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

   Add another --decision for each independent reviewer.

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

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