# Lab

## Part 1 — Purpose, Scope, and Operating Thesis

### 1. Purpose and Public-Good Function

1.1 The Future of Space Lab (“FoSp Lab”) is a governed, AI-assisted, community-operated **standards, frameworks, and intelligence commons** whose function is to convert multi-stakeholder contributions into **structured, versioned, reusable objects** for the future of space under deterministic lifecycle rules, explicit reliance bounds, and correctionability.

1.2 The FoSp Lab exists to reduce variance in **safety, mission assurance, resilience, security, sustainability, spectrum and interoperability discipline, supply-chain integrity, and cross-border coordination** by making space-relevant claims **machine-checkable where feasible**, audit-ready by design, and transparently correctable—without collapsing sovereignty, national security constraints, export controls, privacy, due process, lawful confidentiality, or regulated perimeters.

1.3 The operating thesis is continuous space intelligence with bounded reliance: space systems become safer, more resilient, and more investable when engineering, safety, and security claims are expressed as **testable, correctionable objects** with explicit uncertainty, lineage, handling controls, and reliance bounds—while preserving lawful authority boundaries, export-control constraints, and human judgment where required.

1.4 The FoSp Lab standardizes **how evidence is packaged**, **how claims are expressed**, **how conformance is tested**, and **how corrections propagate** across mission classes and jurisdictions, enabling diligence compression and coordination **without becoming** a mission operator, launch authority, range authority, SSA/STM operator, spectrum allocator, regulator, insurer, broker, or enforcement body.

1.5 Outputs are governance artifacts and evidence objects; they are **not operational commands**, not safety approvals, not flight rules, not mission authorization, not export-control determinations, and not instructions enabling intrusion, jamming, spoofing, targeting, weaponization, or evasion.

1.6 “Do-no-harm,” dual-use minimization, export-control aware handling, and safety-by-design are overriding constraints; where publication could plausibly increase harm capability, handling elevation, staged release, or refusal/redirection is mandatory.

### 2. Full Scope of “Future of Space”

2.1 “Future of space” includes, without limitation, governed objects covering:

2.1.1 **Mission assurance and system safety** (assurance case object patterns; hazard analysis evidence structures; reliability claims discipline; verification completeness and residual risk posture).

2.1.2 **Spacecraft, payloads, and avionics governance** (requirements traceability objects; V\&V evidence packs; configuration control integrity; interface compatibility profiles; environmental qualification evidence patterns).

2.1.3 **Launch systems, spaceports, and range safety interfaces** (non-operational readiness packs; safety evidence patterns; incident clocks; change notices; flight termination governance patterns as non-actionable objects).

2.1.4 **Orbit operations and ground segment resilience** (command authority and key governance patterns; redundancy and failover evidence; safe anomaly reporting; recovery and rollback objects; ground station and TT\&C continuity posture).

2.1.5 **Space situational awareness and traffic coordination** (conjunction governance and traceability objects; debris mitigation evidence; maneuver transparency patterns at safe granularity; non-weaponizable reporting semantics).

2.1.6 **Sustainability, debris, and end-of-life** (disposal posture evidence; passivation reporting; reentry risk disclosure patterns; sustainability indices and validity windows; correction clocks for evolving orbital conditions).

2.1.7 **Cybersecurity and cryptographic readiness** (secure-by-design control baselines; key management assurance objects; incident clocks; post-quantum transition governance; supply-chain compromise response posture).

2.1.8 **Software supply chain, autonomy, and AI governance** (SBOM/SLSA posture; release discipline; model/tool provenance; tool allowlists; logging, human override, kill-switch evidence; drift and rollback discipline).

2.1.9 **Earth observation and sensing integrity** (provenance, calibration, lineage; uncertainty cues; anti-tamper packaging; rights-safe distribution posture; misuse-aware redaction patterns).

2.1.10 **Communications, satcom, and spectrum interfaces** (interoperability profiles; link performance claims discipline; spectrum coordination artifacts as governance objects; latency/jitter disclosure and testability).

2.1.11 **PNT/GNSS dependencies** (resilience evidence patterns; service continuity posture; defensive-only integrity monitoring patterns at safe granularity; dependency maps to terrestrial critical infrastructure).

2.1.12 **In-space servicing, assembly, and manufacturing** (ISAM interface governance; docking/grappling compatibility evidence; maintenance assurance objects; safety posture without operational methods disclosure).

2.1.13 **Human spaceflight and habitability interfaces** (duty-of-care governance; privacy and biosecurity cues; non-clinical perimeter; incident clocks; confidentiality and handling elections).

2.1.14 **Planetary protection and environmental interfaces** (governance patterns; disclosure and audit objects; non-adjudicative boundary; correctionability for updated science and policy).

2.1.15 **Lunar and planetary surface systems** (power/comms/habitat resilience evidence; dust/thermal hazard packs; logistics continuity posture; corridor interoperability objects).

2.1.16 **Space resource and utilization governance** (terminology discipline; disclosure patterns; non-adjudicative boundary; rights/claims non-determination posture).

2.1.17 **Space economy and insurance interfaces** (claims integrity patterns; parametric evidence packaging patterns; non-underwriting boundary; diligence objects for financiers and insurers).

2.1.18 **Dual-use and national security constraints** (handling-first object design; staged release; export-control aware workflows; non-circumvention; segregation of restricted annexes and public-safe extracts).

2.1.19 **Space weather, geomagnetic risk, and atmospheric coupling** (indices; forecast uncertainty discipline; operational readiness packs; validity windows; correction clocks).

2.1.20 **Mega-constellations and systemic risk** (system-of-systems safety and sustainability objects; congestion risk indices; coordinated update and change-notice patterns; dependency and cascade risk objects).

2.2 The scope includes space-relevant system-of-systems dependencies treated as mission and program risks requiring governed evidence and correctionable decision influence: terrestrial critical infrastructure, launch and microelectronics supply chains, geopolitics/sanctions, export-control regimes, cloud dependencies, cyber threat landscapes, and disinformation/synthetic media affecting mission legitimacy and public trust.

2.3 Space is treated as a **critical infrastructure amplifier** (communications, observation, timing, climate intelligence) requiring high-integrity claims discipline and correctionable reliance under stress.

### 3. Intended Users and Outcomes

3.1 The FoSp Lab serves space agencies, mission directors, safety and assurance offices, commercial operators, launch providers, manufacturers, ground segment operators, SSA/STM coordination bodies within mandate, spectrum coordinators within mandate, insurers/assurers (through governance artifacts), auditors, standards bodies, and builders by producing objects that are:

3.1.1 Portable (profiles + deltas, not forks).\
3.1.2 Testable where claims are asserted (conformance suites).\
3.1.3 Correctionable (no silent edits; explicit supersession).\
3.1.4 Operator- and examiner-operable (truth surface: current, superseded, contested, tested, admissible).\
3.1.5 Handling-aware (staged release; distribution logs; leakage tested).\
3.1.6 Reliance-bounded (who may rely, for what purpose, for what duration, under what limits).

3.2 Outcomes include reduced mission risk variance, faster auditability, improved interoperability, higher supply-chain integrity, stronger sustainability and debris governance, safer autonomy and AI adoption under bounded reliance, and improved cross-border coordination without centralizing operational authority.

### 4. Output Classes

4.1 Outputs include standards; frameworks; profiles/implementation guides; taxonomies/ontologies; defensive typology libraries; artifacts and method cards; conformance suites; conformance reports; release bundles; corrections/supersessions; interoperability mappings; indices/metric definitions; learning modules; **Assurance & Evidence Packs (AEP-SPACE)**; and Future of Space Reports.

4.2 Outputs are objects with lifecycle state and registry pointers; documents are views.

4.3 Where outputs interface with regulated disclosure (export controls, spectrum, safety approvals, national security constraints, insurance/finance), outputs must carry explicit reliance bounds, non-endorsement statements, and handling elections.

***

## Part 2 — Boundary, Non-Executing Perimeter, and Firewall Doctrine

### 1. Boundary of the Lab

1.1 The FoSp Lab provides governance infrastructure for identity/participation; records-first workflows; canonical registers and truth surfaces; handling-separated indexing and retrieval; publication/versioning/correction discipline; conformance and reproducibility operations; report desks and subscription channels; cloneable instance kits; and federation-safe interoperability scaffolding.

1.2 The boundary includes standards operations, intelligence operations, and interoperability operations as governance infrastructure—not mission operations.

1.3 The Lab may publish transparency objects and evidence packaging patterns that improve interpretability and auditability; it does not compel disclosure by any sovereign, agency, or operator absent lawful authority outside the Lab.

### 2. Two-Stack Firewall Alignment

2.1 The FoSp Lab operates exclusively as public-good governance infrastructure: standards/schemas, evidence integrity, validity-by-record, handling and safeguards, conformance, release/correction discipline, and audit structures.

2.2 Execution occurs only outside the Lab in lawful institutional processes and licensed/mandated delivery stacks (space agencies, commercial operators, launch providers, range operators, regulators within mandate, spectrum authorities within mandate, insurers and brokers under license).

2.3 Integrations are limited to interoperability mappings, compatibility notes, conformance-tested connectors, and evidence packaging patterns; they do not widen the Lab into a mission operator, launch authority, range safety authority, SSA/STM operator, spectrum allocator, export-control authority, or regulatory body.

2.4 Separation-of-duties applies: an entity may not both author high-reliance conformance determinations and execute operational command actions under the same role marker for the same object family.

### 3. Non-Executing Perimeter

3.1 The FoSp Lab does not: command spacecraft; conduct launch operations; perform collision avoidance maneuvers; issue range clearances; allocate spectrum; make export-control determinations; conduct intelligence operations; authorize proximity operations; or perform adjudicative safety approvals.

3.2 The FoSp Lab does not publish actionable exploit paths or weaponizable instructions (intrusion steps, jamming/spoofing methods, targeting guidance, evasion strategies, or high-resolution operational playbooks).

3.3 All outputs are informational artifacts and must include intended use, prohibited use, limitations/uncertainty cues, expiry/review dates, and correction/dispute paths with clocks.

### 4. Refusal and Redirection Discipline

4.1 Requests increasing harm risk (weaponization enablement, intrusion, jamming/spoofing enablement, sabotage, targeting, evasion, export-control circumvention) are refused or redirected into defensive governance outputs (controls, safe indicators, conformance suites, audit checklists, incident clocks).

4.2 Sensitive legitimate contexts (assurance drills, incident simulations, supervisory testability) follow staged release: public-safe abstract first; controlled/restricted appendices gated, purpose-bound, expiry-bound, and logged.

***

## Part 3 — Validity-by-Record, Registers, and Dual-Logging for Designated Acts

### 1. Validity-by-Record

1.1 Standing arises only from record-valid acts executed through FoSpLP workflows and reflected in canonical registers and current pointers.

1.2 Off-platform statements have no standing unless represented as record-valid objects with required metadata, handling election, provenance/rights attestations, and registry pointers.

1.3 The truth surface must be examiner-operable: decision influence is reconstructable from records, not narratives.

### 2. Canonical Registers and Truth Surface

2.1 Each FoSp Instance maintains registers for: object identity/lifecycle; current pointer/supersession chain; conformance suites/reports; handling elections/distribution logs; COI disclosures/recusals/sanctions/appeals; report editions with dependency banners and contested propagation; incident and stop-the-line records; emergency declarations and expiry.

### 3. Dual-Logging for Designated Acts

3.1 For designated acts requiring cross-institution force-and-effect, validity is anchored by dual records: **GRF Council Register record** and **NSF protocol anchoring**.

3.2 Minimum designated acts include: recognition as current; release publication and pointer movement; conformance claims/reports; issuance of **AEP-SPACE** intended for external reliance; sanctions/revocations/reinstatements; withdrawals/emergency reliance constraints.

3.3 Mismatch lock applies: disagreement between register and anchor renders the act Inoperative (Mismatch) until reconciled; dependent objects display warnings.

### 4. Local-Only Standing

4.1 Deployments without dual anchoring must label designated acts Local-Only Standing; cross-node standing claims are prohibited.

***

## Part 4 — Canonical Object Model for Space Standards and Intelligence

### 1. Objects, Not Documents

1.1 Authority attaches only to versioned objects with registry pointers; documents are views.

1.2 Releases and report editions are immutable; updates occur only via corrections/supersessions with diffs and migration notes.

1.3 Dependency graphs must be reconstructable and publishable at appropriate handling.

### 2. Canonical Object Types

2.1 STD-FoSp Standards (normative invariants: assurance, safety evidence, sustainability posture, security-by-design, handling, correctionability).\
2.2 FRM-FoSp Frameworks (governance/control frameworks; bounded reliance).\
2.3 PRF/IG-FoSp Profiles / Implementation Guides (mission class overlays; explicit deltas; no forks).\
2.4 TAX/ONT-FoSp Taxonomies / Ontologies (hazards, failure modes, telemetry semantics, orbital object classes; drift-tested).\
2.5 TYP-FoSp Typology Library Objects (defensive: anomaly typologies, incident categories; handling-aware).\
2.6 ART-FoSp Artifacts (method cards, checklists, V\&V rubrics, model/dataset cards, assurance-case cards).\
2.7 AEP-SPACE Assurance & Evidence Packs (sealed determination artifacts: readiness posture, anomaly assessment posture, sustainability posture, supply-chain integrity posture).\
2.8 CS-FoSp / CR-FoSp Conformance Suites / Conformance Reports (tests, vectors, harness notes; signed results; validity window).\
2.9 REL-FoSp / COR-FoSp Release Bundles / Corrections-Supersessions.\
2.10 RPT-FoSp / SUB-FoSp Reports / Subscription Channels.\
2.11 MAP/IOP-FoSp Mappings & Interoperability Profiles (equivalence limits; warnings; testable transformations).\
2.12 WGC-FoSp / RM-FoSp / DR-FoSp / CFW-FoSp Working Group Charters / Role Markers / Decision Records / Calls for Work.\
2.13 CONSENT-FoSp / TRANSP-FoSp Consent and Transparency Elections (EO governance posture; confidentiality posture; export-control posture).\
2.14 IDX-FoSp Index and Metric Definitions (sustainability indices, resilience indices, assurance indices; assumptions and limits).\
2.15 SAFE-FoSp Safety Posture Objects (non-operational safety assertions; hazard cue libraries; incident clock hooks).

### 3. Mandatory Metadata and Release Blockers

3.1 Publishable objects require scope/exclusions; handling election; reliance bounds; expiry/review; correction/dispute paths + clocks; provenance/rights; COI link; dependencies; jurisdiction label; and dual-use harm statement where credible.

3.2 Missing metadata blocks publication; prohibited uses must be explicit where misuse risk exists.

3.3 Objects that could plausibly enable physical harm, national security harm, or evasion are handling-elevated or withheld, with public-safe extracts produced where feasible.

***

## Part 5 — Records-First Governance, Roles, and Due Process

### 1. Record-Valid Acts

1.1 All governance actions occur only through record-valid acts (onboarding, COI, handling, WG chartering, releases, conformance, corrections, disputes, waivers, sanctions).

1.2 AI may draft; standing is conferred only through human-authorized recorded acceptance under valid role markers.

1.3 High-reliance objects require multi-role review (records, handling, conformance; export-control review where applicable) prior to publication.

1.4 Waivers record scope, duration, compensating controls, and remediation clocks; waivers auto-expire unless renewed.

### 2. Minimum State Machines

2.1 Standards/Frameworks/Taxonomies: draft → review → candidate → accepted → published → maintained → superseded/withdrawn.\
2.2 AEP-SPACE: drafted → verified → issued → monitored → corrected/superseded → archived/expired.\
2.3 Releases/Reports: assembled → gated → reviewed → approved → published → monitored → corrected/superseded → archived/expired.\
2.4 Conformance: submitted → triaged → verified → accepted/rejected → registered → referenced → archived/expired.\
2.5 Disputes/appeals: filed → triaged → responded → resolved → remedied → closed; contestation propagates.

### 3. Due Process and Clocks

3.1 Decisions require Decision Records with rationale, scope, limitations, remedies, and reliance adjustments.

3.2 Integrity incidents may trigger stop-the-line: publication freeze, access revocation, distribution recall attempts where feasible, and mandatory public-safe incident abstracts.

### 4. Minimum Governance Spine

4.1 Records & Register Officer; Handling & Safety Officer; COI & Ethics Officer; Conformance Lead; Editorial Lead; Dispute Resolution Panel.

4.2 Export-Control & Dual-Use Steward is mandatory where object families interact with restricted technologies, national security constraints, or sanction regimes.

***

## Part 6 — Handling, Safety, Staged Release, and Dual-Use Governance

### 1. Handling Classes

1.1 Public-Safe / Controlled / Restricted handling with access gates, distribution logs, staged release rules, expiry enforcement, and leakage testing.

1.2 Handling inheritance applies to bundles and derivatives; down-classification requires recorded dual-use and safety review.

### 2. Dual-Use and Misuse Taxonomy

2.1 High-risk misuse includes intrusion enablement; jamming/spoofing enablement; targeting guidance; sabotage techniques; tracking evasion; export-control circumvention; weaponizable proximity operations; high-resolution command-and-control bypass instructions; site-specific vulnerability weaponization.

2.2 Assistants are prohibited from reconstructing restricted content or generating instructions enabling attack, evasion, sabotage, or circumvention.

### 3. Staged Release and Public-Good Extracts

3.1 Controlled/Restricted work must yield public-safe extracts where feasible: governance controls, safe indicators, conformance tests that do not expose exploit paths, and limitations disclosures.

3.2 Infeasibility is recorded with rationale and review date.

### 4. Leakage Testing

4.1 Leakage testing is continuous and event-triggered (model/provider change, index rebuild, connector change); failures trigger stop-the-line.

***

## Part 7 — Conformance, Reproducibility, Plugfests, and Drift Governance

### 1. Conformance Discipline

1.1 High-impact assurance claims require conformance suites and signed conformance reports; conformance is bounded and non-endorsing.

1.2 Releases claiming interoperability are gated unless linked to conformance evidence or time-boxed plans with interim reliance constraints.

### 2. Replication Cells

2.1 Replication cells rerun suites across environments; independence required where high reliance exists; failures trigger notices, freezes, withdrawals, and remediation clocks.

### 3. Plugfests

3.1 Plugfests validate interoperability across telemetry schemas, debris and conjunction reporting packaging, SBOM/SLSA reporting, cryptographic transition artifacts, and assistant safety under handling segregation.

### 4. Drift Testing

4.1 Drift governance covers ontology drift, mapping drift, assistant refusal/handling drift, and AI lifecycle drift; material drift triggers reliance tightening and status changes.

***

## Part 8 — Identity, Participation, Guild System, Credits, and KPIs

### 1. Participation Identity and Authority

1.1 “FoSp Passport” captures expertise, jurisdictions, languages, export-control constraints (where declared), and COI; authority arises only from role markers.

1.2 Capability progression is competence-based and record-attested.

### 2. Authentication and Authorization

2.1 SSO/MFA with step-up for controlled/restricted actions; RBAC+ABAC; restricted is deny-by-default; device posture gates and purpose-binding apply where lawful.

### 3. Guild System and Work Units

3.1 Work units include Guilds, Working Groups, Review Pools, Replication Cells, Clinics/Sessions, and Publisher Rooms; outputs have no standing until record-valid publication.

### 4. Credits, Anti-Gaming, and KPIs

4.1 Credits accrue only on accepted record-valid outcomes; spend does not buy influence.

4.2 Verification/replication outrank drafting; reviewer rotation; caps; clawbacks for misconduct.

4.3 KPIs include membership growth; conformance coverage; correction responsiveness; dispute-clock performance; handling compliance; integrity incident rate; dual-use refusal performance; time-to-assurance reduction.

***

## Part 9 — Intelligence, Assistants, Content Studio, and Constitutional Forms

### 1. Handling-Separated Intelligence Surfaces

1.1 Handling-separated indices govern retrieval and summarization; cross-class reconstruction is prohibited.

1.2 Recycling pipelines convert deliberations into candidate objects only through governed workflows with handling inheritance.

### 2. Assistive AI Boundaries

2.1 AI drafts and structures; it does not authorize missions, approve safety, allocate spectrum, execute cyber operations, or perform export-control determinations.

2.2 Tool allowlists, logging, human override, kill-switch evidence, and drift tests are mandatory for high-impact contexts; provider/model changes trigger leakage testing.

### 3. Content Studio and Normalization

3.1 Templates cover standards, profiles, taxonomies, evidence packs, conformance, and reports; no silent semantic changes; meaning changes require correction/supersession.

### 4. Constitutional Forms

4.1 Forms implement record-valid acts; AI may prefill; standing arises only upon recorded acceptance under valid role markers.

***

## Part 10 — Space Lanes and Deployment Expressions

### 1. Instance Types

1.1 FoSpLP supports deployable FoSp Instances for agencies, operators, manufacturers, launch providers, spaceports, ground segment operators, EO providers, and insurers/assurers (governance-only artifacts), each declaring scope, handling policy, lawful basis posture, and conformance election.

### 2. Mission Assurance Lane

2.1 Publishes assurance case patterns, V\&V evidence packaging, anomaly typologies at safe granularity, and readiness AEP-SPACE structures.

### 3. SSA/STM and Sustainability Lane

3.1 Publishes conjunction governance patterns, debris mitigation evidence packaging, sustainability indices, and reporting comparability objects with safe granularity.

### 4. Cyber and Cryptographic Readiness Lane

4.1 Publishes secure-by-design control baselines, incident clocks, post-quantum transition governance, and conformance suites—without exploit content.

### 5. EO Integrity and Provenance Lane

5.1 Publishes calibration/lineage objects, uncertainty cues, anti-tamper packaging patterns, and rights-safe distribution postures.

### 6. Spectrum and Interoperability Lane

6.1 Publishes interoperability profiles and disclosure minima; excludes spectrum allocation decisioning.

### 7. Space Weather Lane

7.1 Publishes indices, uncertainty discipline, readiness packs, validity windows, and correction clocks.

***

## Part 11 — Sovereign Data Zones, Compute-to-Data, Federation, and Interoperability Rails

11.1 SDZ-Local, SDZ-Federated, SDZ-Hybrid supported; default minimizes movement of sensitive mission and security data.

11.2 Compute-to-data jobs declare inputs, tool allowlists, output constraints, logs, and handling inheritance; outputs pass governance gates before indexing/publication.

11.3 Federation is metadata-first; controlled/restricted content federates only by explicit authorization with distribution logs and export-control posture enforcement.

11.4 Interoperability profiles disclose equivalence limits, mismatch risks, and testable transformations; execution remains external.

***

## Part 12 — Security, Auditability, Retention, DR, Observability, and Cost Governance

12.1 Immutable audit logs cover access, downloads, assistant retrieval, submissions, lifecycle transitions, distributions, publications, and admin changes; legal hold supported.

12.2 Retention is handling- and jurisdiction-specific; restricted emphasizes minimization, operational security, and export-control compliance.

12.3 DR preserves register integrity and correction lineage; restore drills are record-valid acts with post-restore integrity checks.

12.4 Component inventory and vulnerability clocks (SBOM/SLSA posture) are mandatory; integrity threats trigger stop-the-line.

12.5 Quotas, budgets, anomaly detection, and rate limits apply; no pay-to-publish influence.

***

## Part 13 — Neutrality, COI, Competition-Safe Mode, Misrepresentation, Sanctions

13.1 COI disclosures, recusals, reviewer rotation, influence caps, and transparent register states are mandatory; sponsor concentration triggers governance review.

13.2 Competition-safe agenda templates and minutes discipline apply in multi-vendor contexts; prohibited-topic gates apply where antitrust risks exist.

13.3 Misrepresentation triggers takedown, clarification, role/credit revocation, conformance suspension, and sanctions ladder with appeal rights.

13.4 No output may be marketed as “official,” “agency-approved,” or “regulator-endorsed” absent recorded standing and authorized scope.

***

## Part 14 — Change Control, Conformance Claims, and Standing Claims

14.1 Revisions publish as protocol releases with diffs and migration notes; nodes declare version and conformance scope (core | core+reports | core+federation | core+lanes).

14.2 “FoSpLP-Conformant” requires passing suites for object model/metadata gates, register integrity, handling segregation, immutability/correction discipline, audit logs, and federation invariants if enabled.

14.3 Claims auto-expire unless renewed; failures publish status changes and remediation clocks.

14.4 Standing claims specify scope, date, validity window, exclusions, and portability labels.

***

## Part 15 — Export Controls, National Security, and Sensitive Interfaces

15.1 Export-control aware participation and distribution controls are supported; participants may declare constraints in FoSp Passport; handling elections enforce segmentation.

15.2 Classified or restricted operational materials are out-of-scope unless a lawful sovereign instance implements containment; public-safe extracts are produced where feasible.

15.3 The Lab does not provide guidance to circumvent export controls, sanctions, or national security restrictions; such requests are refused.

***

## Part 16 — Emergency Posture and Incident Discipline

16.1 Emergency posture may be declared by record-valid decision with timebox, scope, rollback plan, and post-incident review obligation.

16.2 Emergency outputs must be labeled, expiry-bound, correction-clocked, and post-mortemed with public-safe extracts.

***

## Part 17 — Rights, Licensing, Liability, and Reliance Bounds

17.1 Contributions require rights attestations; unclear rights block publication.

17.2 Outputs are informational artifacts; not operational commands, not approvals, not legal determinations.

17.3 Reliance bounds, expiry, uncertainty cues, and correction paths are mandatory for publishable objects.

***

## Part 18 — Disputes, Remedies, and Transparency Minima

18.1 Disputes may be filed for any object; triage and response clocks are mandatory; contestation propagates to dependencies.

18.2 Remedies occur via correction/supersession/withdrawal with traceable lineage; silent edits prohibited.

18.3 Public-safe truth surface includes current/superseded/contested status, conformance status, and known limitations without leaking restricted operational details.

***

## Part 19 — Interoperability with Nexus Rails and External Standards

19.1 FoSpLP interoperates as governance-only infrastructure under One Rail, Two Stacks: evidence packs, conformance, correctionability, validity-by-record; execution remains external and lawful.

19.2 The Lab may publish mappings to relevant external standards and identifiers where lawful, with explicit equivalence limits and testable transformations.

***

## Part 20 — Adoption, Effective Date, and Survival

20.1 Effective upon record-valid adoption and publication of the initial current pointer in the canonical register; instances claiming conformance publish scope, overlays, and conformance status.

20.2 Validity-by-record, handling obligations, audit integrity, correction lineage, non-executing perimeter, export-control posture, dual-use safeguards, and emergency discipline survive amendments and wind-down to the maximum extent lawful.

***

### Binding Baselines

B.1 **Governance-only:** standards, frameworks, evidence packs, conformance, publication discipline.\
B.2 **Non-executing:** no mission command, no range authority, no spectrum allocation, no export-control determinations, no enforcement.\
B.3 **Validity-by-record:** only registered objects and acts have standing.\
B.4 **Correctionability:** explicit lineage; contestation propagation; no silent edits.\
B.5 **Dual-use safety:** refusal/redirection, staged release, leakage testing, export-control aware distribution.\
B.6 **Firewall doctrine:** strict separation from operational spaceflight, national security decisioning, and regulated execution.


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.therisk.global/organization/cooperation/nexus-guilds/future-of-space/lab.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.