space-data-module-sdk 0.8.14 → 0.8.16

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
Files changed (125) hide show
  1. package/bin/space-data-module.js +91 -0
  2. package/docs/_shell/consumer-assets.html +5 -0
  3. package/docs/browser-wasmedge-isomorphic.html +261 -0
  4. package/docs/byo-wasm-quickstart.html +226 -0
  5. package/docs/byo-wasm-quickstart.md +204 -0
  6. package/docs/conformance.html +156 -0
  7. package/docs/conformance.md +92 -0
  8. package/docs/emception-shared-memory-verdict.md +209 -0
  9. package/docs/events-abi.html +313 -0
  10. package/docs/events-abi.md +530 -0
  11. package/docs/families/analytics.html +178 -0
  12. package/docs/families/analytics.md +104 -0
  13. package/docs/families/attitude.html +157 -0
  14. package/docs/families/attitude.md +36 -0
  15. package/docs/families/behavior.html +157 -0
  16. package/docs/families/behavior.md +36 -0
  17. package/docs/families/breakup.html +157 -0
  18. package/docs/families/breakup.md +36 -0
  19. package/docs/families/conjunction.html +186 -0
  20. package/docs/families/conjunction.md +121 -0
  21. package/docs/families/data-source.html +318 -0
  22. package/docs/families/effects.html +157 -0
  23. package/docs/families/effects.md +36 -0
  24. package/docs/families/environment.html +170 -0
  25. package/docs/families/environment.md +73 -0
  26. package/docs/families/estimation.html +190 -0
  27. package/docs/families/estimation.md +128 -0
  28. package/docs/families/gnc.html +157 -0
  29. package/docs/families/gnc.md +36 -0
  30. package/docs/families/maneuver.html +209 -0
  31. package/docs/families/maneuver.md +206 -0
  32. package/docs/families/obstruction.html +191 -0
  33. package/docs/families/obstruction.md +96 -0
  34. package/docs/families/propagator.html +333 -0
  35. package/docs/families/propulsion.html +157 -0
  36. package/docs/families/propulsion.md +36 -0
  37. package/docs/families/reentry.html +157 -0
  38. package/docs/families/reentry.md +36 -0
  39. package/docs/families/rf.html +193 -0
  40. package/docs/families/rf.md +136 -0
  41. package/docs/families/scheduler.html +157 -0
  42. package/docs/families/scheduler.md +36 -0
  43. package/docs/families/sensor.html +157 -0
  44. package/docs/families/sensor.md +36 -0
  45. package/docs/families/signature.html +157 -0
  46. package/docs/families/signature.md +36 -0
  47. package/docs/flatsql-host-contract.html +176 -0
  48. package/docs/flatsql-streaming-standard.html +375 -0
  49. package/docs/gpu-module-abi.html +233 -0
  50. package/docs/harness-family-matrix.md +135 -0
  51. package/docs/index.html +216 -85
  52. package/docs/isomorphic-pthreads.html +228 -0
  53. package/docs/isomorphic-pthreads.md +84 -0
  54. package/docs/isomorphic-sdn-runtime-plan.html +274 -0
  55. package/docs/language-runtime-matrix.html +182 -0
  56. package/docs/llms.txt +86 -0
  57. package/docs/module-bundle-runtime-plan.html +146 -0
  58. package/docs/module-publication-standard.html +503 -0
  59. package/docs/node-red-default-node-parity.html +201 -0
  60. package/docs/propagator-abi.md +73 -21
  61. package/docs/protect-and-sign.html +181 -0
  62. package/docs/protect-and-sign.md +120 -0
  63. package/docs/protocol-installation.html +296 -0
  64. package/docs/publication-submission.html +158 -0
  65. package/docs/publication-submission.md +78 -0
  66. package/docs/secrets-capability.html +206 -0
  67. package/docs/styles.css +860 -167
  68. package/docs/testing-harness.html +408 -0
  69. package/docs/tri-runtime-parity-gate.html +182 -0
  70. package/docs/tri-runtime-parity.html +203 -0
  71. package/include/orbpro/orbpro_event_runner.h +951 -0
  72. package/include/orbpro/orbpro_events_abi.h +565 -0
  73. package/include/orbpro/orbpro_propagator_abi.h +17 -0
  74. package/package.json +15 -5
  75. package/schemas/orbpro/Events.fbs +501 -0
  76. package/schemas/orbpro/Propagator.fbs +72 -9
  77. package/schemas/orbpro/reference-frame-crosswalk.json +108 -0
  78. package/schemas/orbpro/reference-frame.lock.json +98 -0
  79. package/src/browser.js +13 -0
  80. package/src/conformance/abiDriver.js +225 -0
  81. package/src/conformance/index.js +151 -0
  82. package/src/conformance/propagatorSuite.js +526 -0
  83. package/src/conformance/selfTest.js +275 -0
  84. package/src/conformance/selfTestCorpus.js +68 -0
  85. package/src/conformance/twoBodyReference.js +132 -0
  86. package/src/generated/orbpro/events-abi.js +206 -0
  87. package/src/generated/orbpro/events-abi.ts +319 -0
  88. package/src/generated/orbpro/propagator/reference-frame.js +17 -0
  89. package/src/generated/orbpro/propagator/reference-frame.ts +91 -1
  90. package/src/generated/orbpro/propagator-abi.js +17 -0
  91. package/src/generated/orbpro/propagator-abi.ts +17 -0
  92. package/src/generated/spacedatastandards/plg/CCT.d.ts +94 -0
  93. package/src/generated/spacedatastandards/plg/CCT.d.ts.map +1 -0
  94. package/src/generated/spacedatastandards/plg/CCT.js +208 -0
  95. package/src/generated/spacedatastandards/plg/CCT.ts +281 -0
  96. package/src/generated/spacedatastandards/plg/CCTCategory.d.ts +98 -0
  97. package/src/generated/spacedatastandards/plg/CCTCategory.d.ts.map +1 -0
  98. package/src/generated/spacedatastandards/plg/CCTCategory.js +177 -0
  99. package/src/generated/spacedatastandards/plg/CCTCategory.ts +269 -0
  100. package/src/generated/spacedatastandards/plg/CCTCategoryRollup.d.ts +54 -0
  101. package/src/generated/spacedatastandards/plg/CCTCategoryRollup.d.ts.map +1 -0
  102. package/src/generated/spacedatastandards/plg/CCTCategoryRollup.js +106 -0
  103. package/src/generated/spacedatastandards/plg/CCTCategoryRollup.ts +144 -0
  104. package/src/generated/spacedatastandards/plg/PLG.d.ts +46 -2
  105. package/src/generated/spacedatastandards/plg/PLG.d.ts.map +1 -1
  106. package/src/generated/spacedatastandards/plg/PLG.js +78 -5
  107. package/src/generated/spacedatastandards/plg/PLG.ts +90 -5
  108. package/src/generated/spacedatastandards/plg/capabilityClass.d.ts +181 -0
  109. package/src/generated/spacedatastandards/plg/capabilityClass.d.ts.map +1 -0
  110. package/src/generated/spacedatastandards/plg/capabilityClass.js +183 -0
  111. package/src/generated/spacedatastandards/plg/capabilityClass.ts +208 -0
  112. package/src/generated/spacedatastandards/plg/main.d.ts +4 -0
  113. package/src/generated/spacedatastandards/plg/main.d.ts.map +1 -1
  114. package/src/generated/spacedatastandards/plg/main.js +4 -0
  115. package/src/generated/spacedatastandards/plg/main.ts +4 -0
  116. package/src/generated/spacedatastandards/plg/pluginCategory.d.ts +40 -2
  117. package/src/generated/spacedatastandards/plg/pluginCategory.d.ts.map +1 -1
  118. package/src/generated/spacedatastandards/plg/pluginCategory.js +40 -2
  119. package/src/generated/spacedatastandards/plg/pluginCategory.ts +40 -2
  120. package/src/host/browserModuleHarness.js +8 -0
  121. package/src/host/wasiThreadHost.js +189 -14
  122. package/src/index.d.ts +18 -1
  123. package/src/testing/isomorphicHarness.js +233 -0
  124. package/src/transport/index.js +16 -0
  125. package/src/transport/records.js +1015 -3
package/docs/index.html CHANGED
@@ -3,8 +3,8 @@
3
3
  <head>
4
4
  <meta charset="utf-8" />
5
5
  <meta name="viewport" content="width=device-width, initial-scale=1" />
6
- <meta name="description" content="Space Data Module SDK documentation for building, validating, signing, and deploying WebAssembly modules on the Space Data Network." />
7
- <title>Space Data Module SDK</title>
6
+ <meta name="description" content="The nineteen harness families of the Space Data Module SDK — uniform WASM plugin contracts for every kind of scenario behavior." />
7
+ <title>Harness family matrix — Space Data Module SDK</title>
8
8
  <link rel="stylesheet" href="./styles.css" />
9
9
  <!-- SDN_CONSUMER_ASSETS_START -->
10
10
  <link rel="stylesheet" href="https://static.spacedatanetwork.org/assets/hd-wallet-ui/2.0.28/sdn-wallet-public-client.c3f68d1cfd88478f10d836a5e829d1dfc6a10157972cf0f7d4d319d0636f2cc4.css" integrity="sha384-fICuhN4I9xqOK1F5vGGzl26opuO+xQIvTZXMSV76lWTBiQ6AfzztMGLLDw8yRT8i" crossorigin="anonymous">
@@ -13,113 +13,244 @@
13
13
  <!-- SDN_CONSUMER_ASSETS_END -->
14
14
  </head>
15
15
  <body>
16
+ <a class="skip-link" href="#main">Skip to content</a>
16
17
  <sdn-stack-nav active="module-sdk"></sdn-stack-nav>
17
18
  <header class="site-header">
18
19
  <a class="site-brand" href="./">Space Data Module SDK</a>
19
- <a class="stack-button" href="#stack">Stack</a>
20
+ <nav class="header-links" aria-label="Site">
21
+ <a href="./byo-wasm-quickstart.html">Quickstart</a>
22
+ <a href="./conformance.html">Conformance</a>
23
+ <a href="https://github.com/DigitalArsenal/space-data-module-sdk">GitHub</a>
24
+ <a class="stack-button" href="#stack">Stack</a>
25
+ </nav>
20
26
  </header>
21
-
22
- <main>
23
- <section class="hero" aria-labelledby="page-title">
24
- <div class="hero-copy">
25
- <p class="eyebrow">Space Data Network</p>
26
- <h1 id="page-title">Space Data Module SDK</h1>
27
- <p class="lede">
28
- Build portable WebAssembly modules with embedded FlatBuffer manifests,
29
- standards-aware validation, browser and WasmEdge harnesses, and signed
30
- delivery records for SDN hosts.
31
- </p>
32
- <div class="actions" aria-label="Primary links">
33
- <a class="button primary" href="https://github.com/DigitalArsenal/space-data-module-sdk">GitHub</a>
34
- <a class="button" href="./module-publication-standard.md">Publication Standard</a>
35
- <a class="button" href="./testing-harness.md">Testing Harness</a>
36
- </div>
27
+ <main id="main">
28
+ <section class="hero">
29
+ <p class="eyebrow">Space Data Network</p>
30
+ <h1>Harness families</h1>
31
+ <p class="lede">
32
+ One uniform WASM plugin contract per kind of scenario behavior. Point
33
+ an LLM at your codebase and at this site, build a module, host it on
34
+ the SDN, and any consumer loads it — with no modification to the
35
+ rendering engine.
36
+ </p>
37
+ <div class="actions">
38
+ <a class="button primary" href="./byo-wasm-quickstart.html">Build a module</a>
39
+ <a class="button" href="./families/propagator.html">Read a shipped ABI</a>
40
+ <a class="button" href="https://github.com/DigitalArsenal/space-data-module-sdk">GitHub</a>
37
41
  </div>
38
- <figure class="architecture">
39
- <img src="./architecture.svg" alt="Module architecture overview" />
40
- </figure>
41
- </section>
42
-
43
- <section class="quick-grid" aria-label="SDK capabilities">
44
- <article>
45
- <h2>Author</h2>
46
- <p>Start from the examples and declare module methods, ports, runtime targets, and standards references in one manifest.</p>
47
- </article>
48
- <article>
49
- <h2>Validate</h2>
50
- <p>Check manifests and wasm artifacts against the SDK contract, exported ABI symbols, and canonical SDS type names.</p>
51
- </article>
52
- <article>
53
- <h2>Package</h2>
54
- <p>Append REC and MBL bundle metadata, attach publication records, and keep module artifacts single-file deployable.</p>
55
- </article>
56
- <article>
57
- <h2>Run</h2>
58
- <p>Exercise the same module through browser, Node, process, and WasmEdge harnesses before publishing to SDN hosts.</p>
59
- </article>
60
42
  </section>
61
43
 
62
- <section class="docs-list" aria-labelledby="docs-title">
44
+ <section class="section" aria-labelledby="families-title">
63
45
  <div class="section-head">
64
- <p class="eyebrow">Reference</p>
65
- <h2 id="docs-title">Core Documents</h2>
46
+ <p class="eyebrow">The matrix</p>
47
+ <h2 id="families-title">Nineteen families, one spine</h2>
48
+ <p>
49
+ Every family is documented against the same thirteen-section spine.
50
+ Status is stated honestly: only families marked Shipped have a
51
+ ratified generated header, a conformance kit, and a reference module.
52
+ </p>
66
53
  </div>
67
- <div class="link-list">
68
- <a href="./module-publication-standard.md">
69
- <span>Module Publication Standard</span>
70
- <small>Manifest, REC, MBL, PNM, and ENC publication contract.</small>
54
+ <div class="family-group">
55
+ <h3>Dynamics</h3>
56
+ <p>How a vehicle's state evolves: propagation, maneuvers, thrust, orientation, and closed-loop control.</p>
57
+ <div class="card-grid">
58
+ <a class="card" href="./families/propagator.html">
59
+ <div class="card-head"><h4>Propagator</h4><span class="pill pill-shipped">shipped</span></div>
60
+ <p>Advance a vehicle state to a requested epoch. The reference family: generated header, conformance kit, reference module.</p>
71
61
  </a>
72
- <a href="./flatsql-streaming-standard.md">
73
- <span>FlatSQL Streaming Standard</span>
74
- <small>Binary FlatBuffer stream transport and runtime-host storage.</small>
62
+ <a class="card" href="./families/maneuver.html">
63
+ <div class="card-head"><h4>Maneuver</h4><span class="pill pill-experimental">experimental</span></div>
64
+ <p>Apply an impulsive or finite burn to a state and report the resulting trajectory change.</p>
75
65
  </a>
76
- <a href="./browser-wasmedge-isomorphic.md">
77
- <span>Browser and WasmEdge Isomorphic Runtime</span>
78
- <small>One module artifact across browser and server-side execution.</small>
66
+ <a class="card" href="./families/propulsion.html">
67
+ <div class="card-head"><h4>Propulsion</h4><span class="pill pill-planned">planned</span></div>
68
+ <p>Model thrust production and propellant consumption as a supplier to the maneuver family.</p>
79
69
  </a>
80
- <a href="./testing-harness.md">
81
- <span>Testing Harness</span>
82
- <small>Process, browser, WasmEdge, and module stream test entrypoints.</small>
70
+ <a class="card" href="./families/attitude.html">
71
+ <div class="card-head"><h4>Attitude</h4><span class="pill pill-planned">planned</span></div>
72
+ <p>Produce body orientation over time, independent of translational state.</p>
83
73
  </a>
84
- <a href="./protocol-installation.md">
85
- <span>Protocol Installation</span>
86
- <small>Protocol identity, deployment routing, and installation metadata.</small>
74
+ <a class="card" href="./families/gnc.html">
75
+ <div class="card-head"><h4>GNC</h4><span class="pill pill-planned">planned</span></div>
76
+ <p>Closed-loop guidance, navigation and control that commands the maneuver and attitude families.</p>
77
+ </a>
78
+ </div>
79
+ </div>
80
+ <div class="family-group">
81
+ <h3>Environment and interaction</h3>
82
+ <p>How a vehicle interacts with its surroundings: radio frequency, sensing, observable signature, environment models, and line-of-sight obstruction.</p>
83
+ <div class="card-grid">
84
+ <a class="card" href="./families/rf.html">
85
+ <div class="card-head"><h4>RF</h4><span class="pill pill-designed">designed</span></div>
86
+ <p>Link budgets, coverage and interference. Records-in/records-out RF needs no harness; the harness exists for RF that writes scene state.</p>
87
87
  </a>
88
- <a href="./secrets-capability.md">
89
- <span>Credential Lanes</span>
90
- <small>Operator-defined secrets lanes, per-lane approval, and plaintext handling rules.</small>
88
+ <a class="card" href="./families/sensor.html">
89
+ <div class="card-head"><h4>Sensor</h4><span class="pill pill-planned">planned</span></div>
90
+ <p>Detection geometry and sensor tasking: what an instrument can see, when.</p>
91
+ </a>
92
+ <a class="card" href="./families/signature.html">
93
+ <div class="card-head"><h4>Signature</h4><span class="pill pill-planned">planned</span></div>
94
+ <p>Observable signature models — radar cross section, optical magnitude, thermal.</p>
95
+ </a>
96
+ <a class="card" href="./families/environment.html">
97
+ <div class="card-head"><h4>Environment</h4><span class="pill pill-planned">planned</span></div>
98
+ <p>Atmosphere, gravity field, magnetic field, and radiation environment models consumed by other families.</p>
99
+ </a>
100
+ <a class="card" href="./families/obstruction.html">
101
+ <div class="card-head"><h4>Obstruction</h4><span class="pill pill-designed">designed</span></div>
102
+ <p>Line-of-sight occlusion against arbitrary 3D geometry with per-material electromagnetic properties.</p>
91
103
  </a>
92
104
  </div>
93
- </section>
94
-
95
- <section id="stack" class="stack-list" aria-labelledby="stack-title">
96
- <div class="section-head">
97
- <p class="eyebrow">SDN Stack</p>
98
- <h2 id="stack-title">Connected Sites</h2>
105
+ </div>
106
+ <div class="family-group">
107
+ <h3>Event physics</h3>
108
+ <p>Discrete events that create or destroy state: fragmentation, atmospheric reentry, close approaches, and their visual effects.</p>
109
+ <div class="card-grid">
110
+ <a class="card" href="./families/breakup.html">
111
+ <div class="card-head"><h4>Breakup</h4><span class="pill pill-planned">planned</span></div>
112
+ <p>Fragmentation events producing a debris population that must match the standard breakup model.</p>
113
+ </a>
114
+ <a class="card" href="./families/reentry.html">
115
+ <div class="card-head"><h4>Reentry</h4><span class="pill pill-planned">planned</span></div>
116
+ <p>Atmospheric reentry survivability, ablation, and ground footprint.</p>
117
+ </a>
118
+ <a class="card" href="./families/conjunction.html">
119
+ <div class="card-head"><h4>Conjunction</h4><span class="pill pill-designed">designed</span></div>
120
+ <p>Close-approach screening and probability of collision over a catalog.</p>
121
+ </a>
122
+ <a class="card" href="./families/effects.html">
123
+ <div class="card-head"><h4>Effects</h4><span class="pill pill-planned">planned</span></div>
124
+ <p>Visual and volumetric effects driven by an event physics family.</p>
125
+ </a>
99
126
  </div>
100
- <div class="link-list">
101
- <a href="https://spacedatastandards.org/">
102
- <span>Standards</span>
103
- <small>Canonical schemas, record contracts, and generated bindings.</small>
127
+ </div>
128
+ <div class="family-group">
129
+ <h3>Estimation, data and logic</h3>
130
+ <p>Turning observations into state, bringing data in, and deciding what happens next.</p>
131
+ <div class="card-grid">
132
+ <a class="card" href="./families/estimation.html">
133
+ <div class="card-head"><h4>Estimation</h4><span class="pill pill-experimental">experimental</span></div>
134
+ <p>Orbit determination and filtering: observations in, estimated state and covariance out.</p>
104
135
  </a>
105
- <a href="https://digitalarsenal.github.io/flatbuffers/">
106
- <span>FlatBuffers</span>
107
- <small>Binary encoding, schema tooling, and runtime documentation.</small>
136
+ <a class="card" href="./families/data-source.html">
137
+ <div class="card-head"><h4>Data source</h4><span class="pill pill-shipped">shipped</span></div>
138
+ <p>Fetch, parse and normalize external provider data into standards records inside the module.</p>
108
139
  </a>
109
- <a href="https://digitalarsenal.github.io/flatsql/">
110
- <span>FlatSQL</span>
111
- <small>SQL-style queries over FlatBuffer-backed datasets and streams.</small>
140
+ <a class="card" href="./families/analytics.html">
141
+ <div class="card-head"><h4>Analytics</h4><span class="pill pill-experimental">experimental</span></div>
142
+ <p>Derived figures of merit computed over a scenario. The event-location sub-harness is shaped and measured; the rest is planned.</p>
112
143
  </a>
113
- <a href="https://spacedatanetwork.org/">
114
- <span>SDN</span>
115
- <small>Distributed publication, discovery, delivery, and marketplace infrastructure.</small>
144
+ <a class="card" href="./families/scheduler.html">
145
+ <div class="card-head"><h4>Scheduler</h4><span class="pill pill-planned">planned</span></div>
146
+ <p>Ordering and tasking of activities across a scenario timeline.</p>
116
147
  </a>
117
- <a href="https://digitalarsenal.github.io/space-data-module-sdk/" class="active">
118
- <span>Module SDK</span>
119
- <small>WASM module packaging, validation, and host compatibility tooling.</small>
148
+ <a class="card" href="./families/behavior.html">
149
+ <div class="card-head"><h4>Behavior</h4><span class="pill pill-planned">planned</span></div>
150
+ <p>Scripted or reactive decision logic that drives other families.</p>
120
151
  </a>
121
152
  </div>
153
+ </div>
154
+ </section>
155
+
156
+ <section class="section" aria-labelledby="matrix-doc-title">
157
+ <div class="section-head">
158
+ <p class="eyebrow">Doctrine</p>
159
+ <h2 id="matrix-doc-title">How the taxonomy works</h2>
160
+ </div>
161
+ <div class="doc" style="padding:0">
162
+ <p>The Space Data Module SDK exposes one <em>harness family</em> per kind of scenario behavior. A harness family is a uniform WASM ABI: a named export set, a generated wire layout, declared units and frames, named error codes, and a conformance kit that proves an implementation satisfies it. A third party implements the exports, compiles to WebAssembly, and the module is loadable by any consumer of that family — with no modification to the consuming engine.</p>
163
+ <p>A family port that cannot absorb a legitimate module without an engine edit is itself the defect.</p>
164
+ <h2 id="the-uniform-spine"><a class="anchor" href="#the-uniform-spine" aria-hidden="true">#</a>The uniform spine</h2>
165
+ <p>Every family is specified and documented against the same spine, in the same order. The propagator family is the reference implementation of the spine; read <a href="./families/propagator.html">Propagator</a> first, whichever family you are building for.</p>
166
+ <div class="table-wrap"><table><thead><tr><th>Section</th><th>What it fixes</th></tr></thead><tbody><tr><td>Doctrine</td><td>Why this family exists and what it is explicitly not</td></tr><tr><td>Capability</td><td>What a module of this family is allowed to compute and to touch</td></tr><tr><td>Import / export set</td><td>The exact symbols the guest must export and may import</td></tr><tr><td>Wire layout</td><td>Byte-exact structs, generated from a single <code>.fbs</code> source</td></tr><tr><td>Units and frames</td><td>The unit of every field and the reference frame of every vector</td></tr><tr><td>Sentinels</td><td>The reserved values that mean &quot;absent&quot;, &quot;unknown&quot;, &quot;refused&quot;</td></tr><tr><td>Identity</td><td>How an entity is addressed across calls</td></tr><tr><td>Threading</td><td>The threading model and the shard-write discipline</td></tr><tr><td>Error codes</td><td>The named negative codes; never a generic <code>-1</code></td></tr><tr><td>Lifetime</td><td>Init, reuse, and a real idempotent teardown</td></tr><tr><td>Parity envelope</td><td>What must be byte-identical across browser, WasmEdge and Docker WasmEdge</td></tr><tr><td>Consumer seam</td><td>How a consuming surface takes the module as a pluggable port</td></tr><tr><td>Guest C++ example</td><td>A compilable starting point</td></tr></tbody></table></div>
167
+ <h2 id="how-a-family-is-built"><a class="anchor" href="#how-a-family-is-built" aria-hidden="true">#</a>How a family is built</h2>
168
+ <ol>
169
+ <li>A single <code>.fbs</code> schema is the source of the wire layout. Nothing is hand-written twice.</li>
170
+ <li>A generator emits the ABI header (and the JS/TS bindings) from that schema, and a drift gate byte-diffs the generated output against what is committed. A schema edit that is not regenerated fails the gate.</li>
171
+ <li>Modules are compiled <code>wasm32-wasip1-threads</code>. This is isomorphic by construction: the same artifact runs in the browser, under WasmEdge, and under Docker WasmEdge.</li>
172
+ <li>Data in and out of a module is Space Data Standards records, never a bespoke JSON shape.</li>
173
+ <li>A conformance kit and a reference module ship with the family. The kit carries its own negative control, so a kit that cannot catch a planted defect fails itself.</li>
174
+ <li>The artifact is protected, signed, published and listed. See the integrator path below.</li>
175
+ <li>Exactly one generic consumer port exists per family.</li>
176
+ </ol>
177
+ <h2 id="status-vocabulary"><a class="anchor" href="#status-vocabulary" aria-hidden="true">#</a>Status vocabulary</h2>
178
+ <p>Status on this site is literal, and is taken from the ratified harness-family taxonomy of 2026-08-14. It is not aspirational.</p>
179
+ <div class="table-wrap"><table><thead><tr><th>Status</th><th>Meaning</th></tr></thead><tbody><tr><td>Shipped</td><td>Ratified <code>.fbs</code> single source, generated header with a drift gate, conformance kit, reference module. Build against it.</td></tr><tr><td>Experimental</td><td>Real code exists and the shape is taking form, but it is not frozen and known defects are open. Do not ship a commercial module against it.</td></tr><tr><td>Designed</td><td>An ABI has been drafted against a real consumer. No generated header, no conformance kit, no reference module has landed.</td></tr><tr><td>Planned</td><td>A ratified entry in the taxonomy whose individual shape has not been ratified. Nothing is implemented.</td></tr></tbody></table></div>
180
+ <p>Only <strong>propagator</strong> and <strong>data-source</strong> are Shipped. <strong>maneuver</strong>, <strong>estimation</strong> and <strong>analytics</strong> are Experimental — analytics on the strength of ONE sub-harness, <a href="./events-abi.html">event location</a>, whose <code>.fbs</code>, generated header, drift gate, shared runner and measured parity envelope have landed and whose conformance kit has not. Only <strong>rf</strong>, <strong>obstruction</strong> and <strong>conjunction</strong> are Designed. Every other family is Planned, and its status has not been ratified individually — a Planned page states scope and nothing more.</p>
181
+ <p>A sub-harness is not a twentieth family. The nineteen-family taxonomy above is owner-ratified: a capability that fits inside a ratified family arrives as a sub-harness with its own contract document, and the family page states exactly which part of it is shaped.</p>
182
+ <p>Where a family page says a thing does not exist, that is a checked statement about the tree today, not a placeholder.</p>
183
+ <h2 id="vehicle-domains-are-not-a-harness-family"><a class="anchor" href="#vehicle-domains-are-not-a-harness-family" aria-hidden="true">#</a>Vehicle domains are not a harness family</h2>
184
+ <p>Space, air, ground and naval vehicles do not each get a harness. The vehicle domain is a declaration in the module manifest — state space, frames, and degrees of freedom — consumed by whichever family the module implements. A ground-vehicle propagator and a spacecraft propagator implement the same propagator export set and differ in the manifest.</p>
185
+ <h2 id="harness-families-are-not-the-runtime-pluginfamily-enum"><a class="anchor" href="#harness-families-are-not-the-runtime-pluginfamily-enum" aria-hidden="true">#</a>Harness families are not the runtime <code>PluginFamily</code> enum</h2>
186
+ <p>Two vocabularies exist and they are not the same list.</p>
187
+ <ul>
188
+ <li>The <strong>harness-family taxonomy</strong> on this site is the owner-ratified list of ABI-bearing plugin kinds: propagator, maneuver, propulsion, attitude, gnc, rf, sensor, signature, environment, obstruction, breakup, reentry, conjunction, effects, estimation, data-source, analytics, scheduler, behavior.</li>
189
+ <li>The <strong><code>PluginFamily</code> enum</strong> in <code>schemas/PluginManifest.fbs</code> is the SDK's internal manifest classification (<code>SENSOR</code>, <code>PROPAGATOR</code>, <code>RENDERER</code>, <code>ANALYSIS</code>, <code>DATA_SOURCE</code>, <code>COMMS</code>, <code>SHADER</code>, <code>SDF</code>, <code>INFRASTRUCTURE</code>, <code>FLOW</code>, <code>BRIDGE</code>, <code>MANEUVER</code>, <code>ORBIT_DETERMINATION</code>, <code>FOUNDATION</code>, <code>PARSER</code>, <code>VALIDATOR</code>, <code>EXPORTER</code>, <code>PUBLISHER</code>, <code>BASILISK</code>). It is what a manifest declares today.</li>
190
+ </ul>
191
+ <p>They overlap but do not correspond one-to-one, and a family in the taxonomy may project onto a broader <code>PluginFamily</code> member until a dedicated one is minted. Do not file a mismatch between the two lists as a bug; the family pages state which enum member each family projects onto.</p>
192
+ <h2 id="internal-plumbing-is-never-a-public-contract"><a class="anchor" href="#internal-plumbing-is-never-a-public-contract" aria-hidden="true">#</a>Internal plumbing is never a public contract</h2>
193
+ <p>Two boundaries are permanent rulings, not maturity gaps:</p>
194
+ <ul>
195
+ <li><strong>JavaScript registries are internal engine plumbing.</strong> They are how a consuming engine dispatches to compiled modules. They are never offered as a public extension point. Harness contracts are WASM ABIs only.</li>
196
+ <li><strong>Scalar kernel-op ABIs behind closed modules are internal.</strong> In particular the closed scalar <code>rf_*</code> kernel ABI is never the public RF contract. The public RF surface is the <code>.fbs</code>-defined harness ABI plus the record types a module consumes and emits.</li>
197
+ </ul>
198
+ <h2 id="the-integrator-path"><a class="anchor" href="#the-integrator-path" aria-hidden="true">#</a>The integrator path</h2>
199
+ <ol>
200
+ <li><a href="./byo-wasm-quickstart.html">BYO-wasm quickstart</a> — multi-translation-unit C++ against the pinned <code>wasm32-wasip1-threads</code> toolchain, to a loadable artifact.</li>
201
+ <li><a href="./conformance.html">Conformance kit</a> and the <a href="./tri-runtime-parity-gate.html">tri-runtime parity gate</a> — prove the ABI, then prove byte-identical behavior in every lane.</li>
202
+ <li><a href="./protect-and-sign.html">Protect and sign</a> — encrypt the payload where the module is closed, attach the manifest, sign the artifact.</li>
203
+ <li><a href="./publication-submission.html">Publication and listing</a> — the publication record layout, delivery, and the current state of self-serve listing.</li>
204
+ </ol>
205
+ <p>An LLM building a module against this SDK should start at <a href="./llms.txt">llms.txt</a>.</p>
206
+ </div>
207
+ </section>
208
+
209
+ <section class="section" aria-labelledby="path-title">
210
+ <div class="section-head">
211
+ <p class="eyebrow">Integrator path</p>
212
+ <h2 id="path-title">From your C++ to a listed module</h2>
213
+ </div>
214
+ <div class="link-list">
215
+ <a href="./byo-wasm-quickstart.html"><span>1. BYO-wasm quickstart</span><small>Multi-TU C++ against the pinned wasm32-wasip1-threads toolchain.</small></a>
216
+ <a href="./conformance.html"><span>2. Conformance and parity</span><small>Self-test the ABI, then prove byte-identical tri-runtime behavior.</small></a>
217
+ <a href="./protect-and-sign.html"><span>3. Protect and sign</span><small>Encrypt the payload, attach the manifest, sign the artifact.</small></a>
218
+ <a href="./publication-submission.html"><span>4. Publish and list</span><small>Publication records, delivery, and the listing submission flow.</small></a>
219
+ <a href="./llms.txt"><span>LLM integrator contract</span><small>llms.txt — the machine-readable entry point for a coding agent.</small></a>
220
+ </div>
122
221
  </section>
222
+ <section id="stack" class="section" aria-labelledby="stack-title">
223
+ <div class="section-head">
224
+ <p class="eyebrow">SDN Stack</p>
225
+ <h2 id="stack-title">Connected sites</h2>
226
+ </div>
227
+ <div class="link-list">
228
+ <a href="https://spacedatastandards.org/">
229
+ <span>Standards</span>
230
+ <small>Canonical schemas, record contracts, and generated bindings.</small>
231
+ </a>
232
+ <a href="https://digitalarsenal.github.io/flatbuffers/">
233
+ <span>FlatBuffers</span>
234
+ <small>Binary encoding, schema tooling, and runtime documentation.</small>
235
+ </a>
236
+ <a href="https://digitalarsenal.github.io/flatsql/">
237
+ <span>FlatSQL</span>
238
+ <small>SQL-style queries over FlatBuffer-backed datasets and streams.</small>
239
+ </a>
240
+ <a href="https://spacedatanetwork.org/">
241
+ <span>SDN</span>
242
+ <small>Distributed publication, discovery, delivery, and marketplace infrastructure.</small>
243
+ </a>
244
+ <a href="https://digitalarsenal.github.io/space-data-module-sdk/" class="active">
245
+ <span>Module SDK</span>
246
+ <small>WASM module packaging, validation, and host compatibility tooling.</small>
247
+ </a>
248
+ </div>
249
+ </section>
123
250
  </main>
251
+ <footer class="site-footer">
252
+ Space Data Module SDK — Apache-2.0. Every ABI page renders a Markdown
253
+ source in <code>docs/</code>; edit the Markdown, never the HTML.
254
+ </footer>
124
255
  </body>
125
256
  </html>