space-data-module-sdk 0.8.15 → 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 (116) hide show
  1. package/docs/_shell/consumer-assets.html +5 -0
  2. package/docs/browser-wasmedge-isomorphic.html +261 -0
  3. package/docs/byo-wasm-quickstart.html +226 -0
  4. package/docs/byo-wasm-quickstart.md +204 -0
  5. package/docs/conformance.html +156 -0
  6. package/docs/emception-shared-memory-verdict.md +209 -0
  7. package/docs/events-abi.html +313 -0
  8. package/docs/events-abi.md +530 -0
  9. package/docs/families/analytics.html +178 -0
  10. package/docs/families/analytics.md +104 -0
  11. package/docs/families/attitude.html +157 -0
  12. package/docs/families/attitude.md +36 -0
  13. package/docs/families/behavior.html +157 -0
  14. package/docs/families/behavior.md +36 -0
  15. package/docs/families/breakup.html +157 -0
  16. package/docs/families/breakup.md +36 -0
  17. package/docs/families/conjunction.html +186 -0
  18. package/docs/families/conjunction.md +121 -0
  19. package/docs/families/data-source.html +318 -0
  20. package/docs/families/effects.html +157 -0
  21. package/docs/families/effects.md +36 -0
  22. package/docs/families/environment.html +170 -0
  23. package/docs/families/environment.md +73 -0
  24. package/docs/families/estimation.html +190 -0
  25. package/docs/families/estimation.md +128 -0
  26. package/docs/families/gnc.html +157 -0
  27. package/docs/families/gnc.md +36 -0
  28. package/docs/families/maneuver.html +209 -0
  29. package/docs/families/maneuver.md +206 -0
  30. package/docs/families/obstruction.html +191 -0
  31. package/docs/families/obstruction.md +96 -0
  32. package/docs/families/propagator.html +333 -0
  33. package/docs/families/propulsion.html +157 -0
  34. package/docs/families/propulsion.md +36 -0
  35. package/docs/families/reentry.html +157 -0
  36. package/docs/families/reentry.md +36 -0
  37. package/docs/families/rf.html +193 -0
  38. package/docs/families/rf.md +136 -0
  39. package/docs/families/scheduler.html +157 -0
  40. package/docs/families/scheduler.md +36 -0
  41. package/docs/families/sensor.html +157 -0
  42. package/docs/families/sensor.md +36 -0
  43. package/docs/families/signature.html +157 -0
  44. package/docs/families/signature.md +36 -0
  45. package/docs/flatsql-host-contract.html +176 -0
  46. package/docs/flatsql-streaming-standard.html +375 -0
  47. package/docs/gpu-module-abi.html +233 -0
  48. package/docs/harness-family-matrix.md +135 -0
  49. package/docs/index.html +216 -85
  50. package/docs/isomorphic-pthreads.html +228 -0
  51. package/docs/isomorphic-pthreads.md +84 -0
  52. package/docs/isomorphic-sdn-runtime-plan.html +274 -0
  53. package/docs/language-runtime-matrix.html +182 -0
  54. package/docs/llms.txt +86 -0
  55. package/docs/module-bundle-runtime-plan.html +146 -0
  56. package/docs/module-publication-standard.html +503 -0
  57. package/docs/node-red-default-node-parity.html +201 -0
  58. package/docs/propagator-abi.md +45 -12
  59. package/docs/protect-and-sign.html +181 -0
  60. package/docs/protect-and-sign.md +120 -0
  61. package/docs/protocol-installation.html +296 -0
  62. package/docs/publication-submission.html +158 -0
  63. package/docs/publication-submission.md +78 -0
  64. package/docs/secrets-capability.html +206 -0
  65. package/docs/styles.css +860 -167
  66. package/docs/testing-harness.html +408 -0
  67. package/docs/tri-runtime-parity-gate.html +182 -0
  68. package/docs/tri-runtime-parity.html +203 -0
  69. package/include/orbpro/orbpro_event_runner.h +951 -0
  70. package/include/orbpro/orbpro_events_abi.h +565 -0
  71. package/include/orbpro/orbpro_propagator_abi.h +17 -0
  72. package/package.json +11 -4
  73. package/schemas/orbpro/Events.fbs +501 -0
  74. package/schemas/orbpro/Propagator.fbs +72 -9
  75. package/schemas/orbpro/reference-frame-crosswalk.json +108 -0
  76. package/schemas/orbpro/reference-frame.lock.json +98 -0
  77. package/src/browser.js +13 -0
  78. package/src/generated/orbpro/events-abi.js +206 -0
  79. package/src/generated/orbpro/events-abi.ts +319 -0
  80. package/src/generated/orbpro/propagator/reference-frame.js +17 -0
  81. package/src/generated/orbpro/propagator/reference-frame.ts +91 -1
  82. package/src/generated/orbpro/propagator-abi.js +17 -0
  83. package/src/generated/orbpro/propagator-abi.ts +17 -0
  84. package/src/generated/spacedatastandards/plg/CCT.d.ts +94 -0
  85. package/src/generated/spacedatastandards/plg/CCT.d.ts.map +1 -0
  86. package/src/generated/spacedatastandards/plg/CCT.js +208 -0
  87. package/src/generated/spacedatastandards/plg/CCT.ts +281 -0
  88. package/src/generated/spacedatastandards/plg/CCTCategory.d.ts +98 -0
  89. package/src/generated/spacedatastandards/plg/CCTCategory.d.ts.map +1 -0
  90. package/src/generated/spacedatastandards/plg/CCTCategory.js +177 -0
  91. package/src/generated/spacedatastandards/plg/CCTCategory.ts +269 -0
  92. package/src/generated/spacedatastandards/plg/CCTCategoryRollup.d.ts +54 -0
  93. package/src/generated/spacedatastandards/plg/CCTCategoryRollup.d.ts.map +1 -0
  94. package/src/generated/spacedatastandards/plg/CCTCategoryRollup.js +106 -0
  95. package/src/generated/spacedatastandards/plg/CCTCategoryRollup.ts +144 -0
  96. package/src/generated/spacedatastandards/plg/PLG.d.ts +46 -2
  97. package/src/generated/spacedatastandards/plg/PLG.d.ts.map +1 -1
  98. package/src/generated/spacedatastandards/plg/PLG.js +78 -5
  99. package/src/generated/spacedatastandards/plg/PLG.ts +90 -5
  100. package/src/generated/spacedatastandards/plg/capabilityClass.d.ts +181 -0
  101. package/src/generated/spacedatastandards/plg/capabilityClass.d.ts.map +1 -0
  102. package/src/generated/spacedatastandards/plg/capabilityClass.js +183 -0
  103. package/src/generated/spacedatastandards/plg/capabilityClass.ts +208 -0
  104. package/src/generated/spacedatastandards/plg/main.d.ts +4 -0
  105. package/src/generated/spacedatastandards/plg/main.d.ts.map +1 -1
  106. package/src/generated/spacedatastandards/plg/main.js +4 -0
  107. package/src/generated/spacedatastandards/plg/main.ts +4 -0
  108. package/src/generated/spacedatastandards/plg/pluginCategory.d.ts +40 -2
  109. package/src/generated/spacedatastandards/plg/pluginCategory.d.ts.map +1 -1
  110. package/src/generated/spacedatastandards/plg/pluginCategory.js +40 -2
  111. package/src/generated/spacedatastandards/plg/pluginCategory.ts +40 -2
  112. package/src/host/browserModuleHarness.js +8 -0
  113. package/src/host/wasiThreadHost.js +189 -14
  114. package/src/index.d.ts +18 -1
  115. package/src/transport/index.js +16 -0
  116. package/src/transport/records.js +1015 -3
@@ -0,0 +1,233 @@
1
+ <!doctype html>
2
+ <html lang="en">
3
+ <head>
4
+ <meta charset="utf-8" />
5
+ <meta name="viewport" content="width=device-width, initial-scale=1" />
6
+ <meta name="description" content="This document defines the SDK-level standard for modules that can use GPU" />
7
+ <title>GPU module ABI — Space Data Module SDK</title>
8
+ <link rel="stylesheet" href="./styles.css" />
9
+ <!-- SDN_CONSUMER_ASSETS_START -->
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">
11
+ <script defer src="https://static.spacedatanetwork.org/assets/hd-wallet-ui/2.0.28/sdn-wallet-public-client.f611e7e151a3b5c38384272f8894a4c6634f0a29bf925b0e02e0e27f8db0bfff.js" integrity="sha384-R+QqsKoWJIS7iWrtPmgJ49DVnb1hSGjZokupbLInJd1PLp8RwQhtF/hnaerc33ci" crossorigin="anonymous" data-sdn-wallet-public-client="v1"></script>
12
+ <script defer src="https://static.spacedatanetwork.org/assets/sdn-stack-nav/1.0.0/sdn-stack-nav.52fde607eee38ffa116188201f50258ed50bd18c9f06c1af9678f763147a8fe5.js" integrity="sha384-dgeojhJ8vTszHXIbv7O7nZcEzqD10oUYYJjBmPrV7+kLQEUlXLQD4ek5Q7HOFiO5" crossorigin="anonymous" data-nav-style-url="https://static.spacedatanetwork.org/assets/sdn-stack-nav/1.0.0/sdn-stack-nav.36a36359ce18322185e9ff179f88175bab67d5ad84a14d9c08a54f2ff27267e7.css" data-nav-style-integrity="sha384-c4M8Fg+kYaeOYYtJVr7jJsde24IhSWkWaRyAOHEZU9jozhRck089aw+mnHwxymds" data-wallet-client-url="https://static.spacedatanetwork.org/assets/hd-wallet-ui/2.0.28/sdn-wallet-public-client.f611e7e151a3b5c38384272f8894a4c6634f0a29bf925b0e02e0e27f8db0bfff.js" data-wallet-client-integrity="sha384-R+QqsKoWJIS7iWrtPmgJ49DVnb1hSGjZokupbLInJd1PLp8RwQhtF/hnaerc33ci" data-wallet-style-url="https://static.spacedatanetwork.org/assets/hd-wallet-ui/2.0.28/sdn-wallet-public-client.c3f68d1cfd88478f10d836a5e829d1dfc6a10157972cf0f7d4d319d0636f2cc4.css" data-wallet-style-integrity="sha384-fICuhN4I9xqOK1F5vGGzl26opuO+xQIvTZXMSV76lWTBiQ6AfzztMGLLDw8yRT8i" data-wallet-client-id="sdn-module-sdk-pages-v1" data-wallet-callback-uri="https://digitalarsenal.github.io/space-data-module-sdk/wallet-callback.html" data-wallet-registry-sha256="e1ce6fe903c9700484a8a87d96581c8cad97063dabf63030b4518a31a3bdaa93"></script>
13
+ <!-- SDN_CONSUMER_ASSETS_END -->
14
+ </head>
15
+ <body>
16
+ <a class="skip-link" href="#main">Skip to content</a>
17
+ <sdn-stack-nav active="module-sdk"></sdn-stack-nav>
18
+ <header class="site-header">
19
+ <a class="site-brand" href="./">Space Data Module SDK</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>
26
+ </header>
27
+ <div class="shell">
28
+ <nav class="sidebar" id="sidebar" aria-label="Documentation">
29
+ <h2>Start here</h2><ul>
30
+ <li><a href="./index.html"><span>Harness family matrix</span></a></li>
31
+ <li><a href="./byo-wasm-quickstart.html"><span>BYO-wasm quickstart</span></a></li>
32
+ <li><a href="./conformance.html"><span>Conformance kit</span></a></li>
33
+ <li><a href="./protect-and-sign.html"><span>Protect and sign</span></a></li>
34
+ <li><a href="./publication-submission.html"><span>Publication and listing</span></a></li>
35
+ </ul>
36
+ <h2>Dynamics</h2><ul>
37
+ <li><a href="./families/propagator.html"><span>Propagator</span><span class="tag tag-shipped">shipped</span></a></li>
38
+ <li><a href="./families/maneuver.html"><span>Maneuver</span><span class="tag tag-experimental">experimental</span></a></li>
39
+ <li><a href="./families/propulsion.html"><span>Propulsion</span><span class="tag tag-planned">planned</span></a></li>
40
+ <li><a href="./families/attitude.html"><span>Attitude</span><span class="tag tag-planned">planned</span></a></li>
41
+ <li><a href="./families/gnc.html"><span>GNC</span><span class="tag tag-planned">planned</span></a></li>
42
+ </ul>
43
+ <h2>Environment and interaction</h2><ul>
44
+ <li><a href="./families/rf.html"><span>RF</span><span class="tag tag-designed">designed</span></a></li>
45
+ <li><a href="./families/sensor.html"><span>Sensor</span><span class="tag tag-planned">planned</span></a></li>
46
+ <li><a href="./families/signature.html"><span>Signature</span><span class="tag tag-planned">planned</span></a></li>
47
+ <li><a href="./families/environment.html"><span>Environment</span><span class="tag tag-planned">planned</span></a></li>
48
+ <li><a href="./families/obstruction.html"><span>Obstruction</span><span class="tag tag-designed">designed</span></a></li>
49
+ </ul>
50
+ <h2>Event physics</h2><ul>
51
+ <li><a href="./families/breakup.html"><span>Breakup</span><span class="tag tag-planned">planned</span></a></li>
52
+ <li><a href="./families/reentry.html"><span>Reentry</span><span class="tag tag-planned">planned</span></a></li>
53
+ <li><a href="./families/conjunction.html"><span>Conjunction</span><span class="tag tag-designed">designed</span></a></li>
54
+ <li><a href="./families/effects.html"><span>Effects</span><span class="tag tag-planned">planned</span></a></li>
55
+ </ul>
56
+ <h2>Estimation, data and logic</h2><ul>
57
+ <li><a href="./families/estimation.html"><span>Estimation</span><span class="tag tag-experimental">experimental</span></a></li>
58
+ <li><a href="./families/data-source.html"><span>Data source</span><span class="tag tag-shipped">shipped</span></a></li>
59
+ <li><a href="./families/analytics.html"><span>Analytics</span><span class="tag tag-experimental">experimental</span></a></li>
60
+ <li><a href="./families/scheduler.html"><span>Scheduler</span><span class="tag tag-planned">planned</span></a></li>
61
+ <li><a href="./families/behavior.html"><span>Behavior</span><span class="tag tag-planned">planned</span></a></li>
62
+ </ul>
63
+ <h2>Runtime contract</h2><ul>
64
+ <li><a href="./events-abi.html"><span>Event locator ABI</span></a></li>
65
+ <li><a href="./module-publication-standard.html"><span>Module publication standard</span></a></li>
66
+ <li><a href="./browser-wasmedge-isomorphic.html"><span>Browser / WasmEdge isomorphism</span></a></li>
67
+ <li><a href="./isomorphic-pthreads.html"><span>Isomorphic pthreads</span></a></li>
68
+ <li><a href="./tri-runtime-parity.html"><span>Tri-runtime parity</span></a></li>
69
+ <li><a href="./tri-runtime-parity-gate.html"><span>Tri-runtime parity gate</span></a></li>
70
+ <li><a href="./testing-harness.html"><span>Testing harness</span></a></li>
71
+ <li><a href="./language-runtime-matrix.html"><span>Language and runtime matrix</span></a></li>
72
+ </ul>
73
+ <h2>Host surfaces</h2><ul>
74
+ <li><a href="./flatsql-host-contract.html"><span>FlatSQL host contract</span></a></li>
75
+ <li><a href="./flatsql-streaming-standard.html"><span>FlatSQL streaming standard</span></a></li>
76
+ <li><a href="./secrets-capability.html"><span>Credential lanes</span></a></li>
77
+ <li><a href="./protocol-installation.html"><span>Protocol installation</span></a></li>
78
+ <li><a href="./gpu-module-abi.html" aria-current="page"><span>GPU module ABI</span></a></li>
79
+ <li><a href="./module-bundle-runtime-plan.html"><span>Module bundle runtime</span></a></li>
80
+ <li><a href="./isomorphic-sdn-runtime-plan.html"><span>Isomorphic SDN runtime</span></a></li>
81
+ <li><a href="./node-red-default-node-parity.html"><span>Node-RED node parity</span></a></li>
82
+ </ul>
83
+ </nav>
84
+ <main class="doc" id="main">
85
+ <h1>GPU module ABI</h1>
86
+ <p>This document defines the SDK-level standard for modules that can use GPU compute acceleration while remaining portable across browser and WasmEdge module runtimes.</p>
87
+ <h2 id="scope"><a class="anchor" href="#scope" aria-hidden="true">#</a>Scope</h2>
88
+ <p>The standard covers:</p>
89
+ <ul>
90
+ <li>the manifest capability used by module authors</li>
91
+ <li>the host-owned async dispatch boundary used by browsers and native hosts</li>
92
+ <li>the C/C++ layout header shared by module code, browser adapters, and native Dawn-backed hosts</li>
93
+ <li>the artifact layout for portable CPU fallback plus optional GPU adapters</li>
94
+ </ul>
95
+ <p>It does not add a new SDS FlatBuffer schema or a new <code>space_data_module_host</code> sync import. GPU dispatch is asynchronous in browser WebGPU and must stay outside the current sync guest hostcall bridge.</p>
96
+ <h2 id="capability"><a class="anchor" href="#capability" aria-hidden="true">#</a>Capability</h2>
97
+ <p>GPU-capable modules declare the coarse capability id:</p>
98
+ <div class="codeblock"><div class="codeblock-head">json</div><pre><code>{
99
+ &quot;capability&quot;: &quot;gpu_compute&quot;,
100
+ &quot;scope&quot;: &quot;webgpu.v1&quot;,
101
+ &quot;required&quot;: false,
102
+ &quot;description&quot;: &quot;Optional WebGPU/Dawn compute acceleration.&quot;
103
+ }</code></pre></div>
104
+ <p>Use <code>required: false</code> unless the module has no correct CPU path. A missing GPU adapter must degrade to the module's CPU implementation, not to an incomplete result.</p>
105
+ <p>The <code>gpu_compute</code> id is part of the SDK recommended capability vocabulary. The typed PLG <code>HOST_CAPABILITIES</code> enum cannot carry a dedicated GPU enum value until the canonical standards schema adds one. Until that SDS change lands, module manifests should use the string/object capability form above and avoid claiming a typed PLG host capability enum for GPU.</p>
106
+ <h2 id="artifact-layout"><a class="anchor" href="#artifact-layout" aria-hidden="true">#</a>Artifact Layout</h2>
107
+ <p>The canonical portable artifact remains:</p>
108
+ <div class="codeblock"><div class="codeblock-head">text</div><pre><code>dist/isomorphic/module.wasm</code></pre></div>
109
+ <p>That artifact must be valid without GPU access. Optional GPU adapters belong outside the shared guest binary:</p>
110
+ <div class="codeblock"><div class="codeblock-head">text</div><pre><code>dist/browser/module.js
111
+ dist/browser/module.wasm
112
+ dist/wasmedge/gpu-host.{so,dylib,dll}</code></pre></div>
113
+ <p>The browser adapter owns the browser <code>GPUDevice</code>. The WasmEdge host extension owns the native Dawn instance/device. The guest module owns correctness, fallback, exact refinement, and final result validation.</p>
114
+ <h2 id="abi-layers"><a class="anchor" href="#abi-layers" aria-hidden="true">#</a>ABI Layers</h2>
115
+ <h3 id="1-data-layout-abi"><a class="anchor" href="#1-data-layout-abi" aria-hidden="true">#</a>1. Data Layout ABI</h3>
116
+ <p>The reusable C/C++ header is:</p>
117
+ <div class="codeblock"><div class="codeblock-head">text</div><pre><code>templates/gpu-module/include/space_data_gpu_abi.h</code></pre></div>
118
+ <p>It defines:</p>
119
+ <ul>
120
+ <li><code>SDN_GPU_ABI_VERSION</code></li>
121
+ <li>the <code>gpu_compute</code> capability id and <code>webgpu.v1</code> scope</li>
122
+ <li>status codes</li>
123
+ <li>backend and buffer role enums</li>
124
+ <li>split <code>f64</code> helpers using high/low <code>f32</code></li>
125
+ <li>packed dispatch/result descriptors</li>
126
+ </ul>
127
+ <p>All multi-byte fields are little-endian in serialized buffers. Structs in the header are fixed-width and intentionally avoid owning pointers. Pointers are runtime-local implementation details and must not appear in durable manifests, publication metadata, or cross-process descriptors.</p>
128
+ <h3 id="2-host-dispatch-abi"><a class="anchor" href="#2-host-dispatch-abi" aria-hidden="true">#</a>2. Host Dispatch ABI</h3>
129
+ <p>The canonical operation is:</p>
130
+ <div class="codeblock"><div class="codeblock-head">text</div><pre><code>gpu_compute.dispatch.v1</code></pre></div>
131
+ <p>The host adapter receives:</p>
132
+ <ul>
133
+ <li>an ABI version</li>
134
+ <li>a stable kernel id</li>
135
+ <li>storage/uniform buffer descriptors</li>
136
+ <li>little-endian input bytes</li>
137
+ <li>requested workgroup counts</li>
138
+ <li>declared output buffer sizes</li>
139
+ </ul>
140
+ <p>The host adapter returns:</p>
141
+ <ul>
142
+ <li>a status code</li>
143
+ <li>backend metadata (<code>browser-webgpu</code>, <code>dawn-native</code>, or <code>cpu-fallback</code>)</li>
144
+ <li>output buffer bytes</li>
145
+ <li>optional counters such as candidates emitted, overflow count, and elapsed device time</li>
146
+ </ul>
147
+ <p>Browser and native hosts may expose this through their existing async capability adapter registries. A shared browser/WasmEdge guest must not depend on raw asynchronous wasm imports for this operation.</p>
148
+ <h3 id="3-module-level-api"><a class="anchor" href="#3-module-level-api" aria-hidden="true">#</a>3. Module-Level API</h3>
149
+ <p>Module methods should keep the public invoke contract domain-specific. For example, a conjunction assessment module should expose conjunction assessment request/response ports, not generic WebGPU command buffers.</p>
150
+ <p>The GPU dispatch boundary is an implementation detail between the host runtime and the module/adapter pair. Hosts may precompute a GPU broadphase and pass coarse hits into the guest, or they may let a browser-specific adapter call the guest's exact refinement entry points after dispatch.</p>
151
+ <h2 id="browser-backend"><a class="anchor" href="#browser-backend" aria-hidden="true">#</a>Browser Backend</h2>
152
+ <p>Browser adapters use WebGPU through browser APIs or Emscripten's WebGPU/Dawn surface. They must:</p>
153
+ <ul>
154
+ <li>request and cache the <code>GPUAdapter</code> and <code>GPUDevice</code></li>
155
+ <li>validate device limits before accepting a dispatch</li>
156
+ <li>compile WGSL from a module-owned or SDK-owned source string</li>
157
+ <li>copy results back through mapped buffers or equivalent browser APIs</li>
158
+ <li>return a CPU fallback status when WebGPU is unavailable</li>
159
+ </ul>
160
+ <p>Browser WebGPU setup and buffer mapping are asynchronous. Do not model them as sync <code>space_data_module_host</code> calls.</p>
161
+ <h2 id="wasmedge-backend"><a class="anchor" href="#wasmedge-backend" aria-hidden="true">#</a>WasmEdge Backend</h2>
162
+ <p>WasmEdge deployments that need GPU acceleration should use a native host extension linked against Dawn. The native host implements the same <code>gpu_compute.dispatch.v1</code> operation and uses the same C/C++ layout header.</p>
163
+ <p>The shared module artifact should still be loadable without that extension. A pure <code>[&quot;wasmedge&quot;]</code> artifact may choose a higher-capability native host profile, but a <code>[&quot;browser&quot;, &quot;wasmedge&quot;]</code> artifact must retain the portable fallback contract documented in <code>docs/browser-wasmedge-isomorphic.md</code>.</p>
164
+ <h2 id="numerical-rules"><a class="anchor" href="#numerical-rules" aria-hidden="true">#</a>Numerical Rules</h2>
165
+ <p>GPU kernels that need double-like position precision should use split high/low <code>f32</code> values:</p>
166
+ <div class="codeblock"><div class="codeblock-head">c</div><pre><code>SdnGpuSplitF64 x = sdn_gpu_split_f64(x_km);</code></pre></div>
167
+ <p>For orbital screening, store position components in kilometers unless a module contract states otherwise. The high component is the nearest <code>f32</code>; the low component is the residual:</p>
168
+ <div class="codeblock"><div class="codeblock-head">text</div><pre><code>hi = f32(value)
169
+ lo = f32(value - f64(hi))</code></pre></div>
170
+ <p>GPU broadphase kernels must be conservative. They may emit extra candidates, but they must not drop candidates that the CPU exact path would refine. Exact TCA, probability, and final acceptance logic remain in the CPU double-precision module path unless a module ships a separately validated exact GPU algorithm.</p>
171
+ <h2 id="template"><a class="anchor" href="#template" aria-hidden="true">#</a>Template</h2>
172
+ <p>Start new GPU-capable modules from:</p>
173
+ <div class="codeblock"><div class="codeblock-head">text</div><pre><code>templates/gpu-module/</code></pre></div>
174
+ <p>The template contains:</p>
175
+ <ul>
176
+ <li><code>include/space_data_gpu_abi.h</code>: reusable C/C++ ABI layout header</li>
177
+ <li><code>manifest.json</code>: manifest fragment showing <code>gpu_compute</code></li>
178
+ <li><code>README.md</code>: integration notes for browser WebGPU and WasmEdge/Dawn hosts</li>
179
+ </ul>
180
+ <p>Use the template as a layout and ABI starting point. Real module repos should still define domain-specific FlatBuffer request/response schemas and must keep their canonical compiled artifact at <code>dist/isomorphic/module.wasm</code>.</p>
181
+
182
+ <p class="doc-footer">
183
+ Source of truth for this page:
184
+ <code>docs/gpu-module-abi.md</code>. Regenerate with
185
+ <code>npm run build:docs</code>.
186
+ </p>
187
+ </main>
188
+ <nav class="rail" aria-label="On this page"><h2>On this page</h2><ul><li><a class="depth-2" href="#scope">Scope</a></li>
189
+ <li><a class="depth-2" href="#capability">Capability</a></li>
190
+ <li><a class="depth-2" href="#artifact-layout">Artifact Layout</a></li>
191
+ <li><a class="depth-2" href="#abi-layers">ABI Layers</a></li>
192
+ <li><a class="depth-3" href="#1-data-layout-abi">1. Data Layout ABI</a></li>
193
+ <li><a class="depth-3" href="#2-host-dispatch-abi">2. Host Dispatch ABI</a></li>
194
+ <li><a class="depth-3" href="#3-module-level-api">3. Module-Level API</a></li>
195
+ <li><a class="depth-2" href="#browser-backend">Browser Backend</a></li>
196
+ <li><a class="depth-2" href="#wasmedge-backend">WasmEdge Backend</a></li>
197
+ <li><a class="depth-2" href="#numerical-rules">Numerical Rules</a></li>
198
+ <li><a class="depth-2" href="#template">Template</a></li></ul></nav>
199
+ </div>
200
+ <section id="stack" class="section" aria-labelledby="stack-title">
201
+ <div class="section-head">
202
+ <p class="eyebrow">SDN Stack</p>
203
+ <h2 id="stack-title">Connected sites</h2>
204
+ </div>
205
+ <div class="link-list">
206
+ <a href="https://spacedatastandards.org/">
207
+ <span>Standards</span>
208
+ <small>Canonical schemas, record contracts, and generated bindings.</small>
209
+ </a>
210
+ <a href="https://digitalarsenal.github.io/flatbuffers/">
211
+ <span>FlatBuffers</span>
212
+ <small>Binary encoding, schema tooling, and runtime documentation.</small>
213
+ </a>
214
+ <a href="https://digitalarsenal.github.io/flatsql/">
215
+ <span>FlatSQL</span>
216
+ <small>SQL-style queries over FlatBuffer-backed datasets and streams.</small>
217
+ </a>
218
+ <a href="https://spacedatanetwork.org/">
219
+ <span>SDN</span>
220
+ <small>Distributed publication, discovery, delivery, and marketplace infrastructure.</small>
221
+ </a>
222
+ <a href="https://digitalarsenal.github.io/space-data-module-sdk/" class="active">
223
+ <span>Module SDK</span>
224
+ <small>WASM module packaging, validation, and host compatibility tooling.</small>
225
+ </a>
226
+ </div>
227
+ </section>
228
+ <footer class="site-footer">
229
+ Space Data Module SDK — Apache-2.0. Every ABI page renders a Markdown
230
+ source in <code>docs/</code>; edit the Markdown, never the HTML.
231
+ </footer>
232
+ </body>
233
+ </html>
@@ -0,0 +1,135 @@
1
+ # Harness family matrix
2
+
3
+ The Space Data Module SDK exposes one *harness family* per kind of scenario
4
+ behavior. A harness family is a uniform WASM ABI: a named export set, a
5
+ generated wire layout, declared units and frames, named error codes, and a
6
+ conformance kit that proves an implementation satisfies it. A third party
7
+ implements the exports, compiles to WebAssembly, and the module is loadable by
8
+ any consumer of that family — with no modification to the consuming engine.
9
+
10
+ A family port that cannot absorb a legitimate module without an engine edit is
11
+ itself the defect.
12
+
13
+ ## The uniform spine
14
+
15
+ Every family is specified and documented against the same spine, in the same
16
+ order. The propagator family is the reference implementation of the spine; read
17
+ [Propagator](families/propagator.html) first, whichever family you are building for.
18
+
19
+ | Section | What it fixes |
20
+ | --- | --- |
21
+ | Doctrine | Why this family exists and what it is explicitly not |
22
+ | Capability | What a module of this family is allowed to compute and to touch |
23
+ | Import / export set | The exact symbols the guest must export and may import |
24
+ | Wire layout | Byte-exact structs, generated from a single `.fbs` source |
25
+ | Units and frames | The unit of every field and the reference frame of every vector |
26
+ | Sentinels | The reserved values that mean "absent", "unknown", "refused" |
27
+ | Identity | How an entity is addressed across calls |
28
+ | Threading | The threading model and the shard-write discipline |
29
+ | Error codes | The named negative codes; never a generic `-1` |
30
+ | Lifetime | Init, reuse, and a real idempotent teardown |
31
+ | Parity envelope | What must be byte-identical across browser, WasmEdge and Docker WasmEdge |
32
+ | Consumer seam | How a consuming surface takes the module as a pluggable port |
33
+ | Guest C++ example | A compilable starting point |
34
+
35
+ ## How a family is built
36
+
37
+ 1. A single `.fbs` schema is the source of the wire layout. Nothing is
38
+ hand-written twice.
39
+ 2. A generator emits the ABI header (and the JS/TS bindings) from that schema,
40
+ and a drift gate byte-diffs the generated output against what is committed.
41
+ A schema edit that is not regenerated fails the gate.
42
+ 3. Modules are compiled `wasm32-wasip1-threads`. This is isomorphic by
43
+ construction: the same artifact runs in the browser, under WasmEdge, and
44
+ under Docker WasmEdge.
45
+ 4. Data in and out of a module is Space Data Standards records, never a bespoke
46
+ JSON shape.
47
+ 5. A conformance kit and a reference module ship with the family. The kit
48
+ carries its own negative control, so a kit that cannot catch a planted defect
49
+ fails itself.
50
+ 6. The artifact is protected, signed, published and listed. See the integrator
51
+ path below.
52
+ 7. Exactly one generic consumer port exists per family.
53
+
54
+ ## Status vocabulary
55
+
56
+ Status on this site is literal, and is taken from the ratified harness-family
57
+ taxonomy of 2026-08-14. It is not aspirational.
58
+
59
+ | Status | Meaning |
60
+ | --- | --- |
61
+ | Shipped | Ratified `.fbs` single source, generated header with a drift gate, conformance kit, reference module. Build against it. |
62
+ | Experimental | 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. |
63
+ | Designed | An ABI has been drafted against a real consumer. No generated header, no conformance kit, no reference module has landed. |
64
+ | Planned | A ratified entry in the taxonomy whose individual shape has not been ratified. Nothing is implemented. |
65
+
66
+ Only **propagator** and **data-source** are Shipped. **maneuver**,
67
+ **estimation** and **analytics** are Experimental — analytics on the strength
68
+ of ONE sub-harness, [event location](events-abi.html), whose `.fbs`, generated
69
+ header, drift gate, shared runner and measured parity envelope have landed and
70
+ whose conformance kit has not. Only **rf**, **obstruction** and **conjunction**
71
+ are Designed. Every other family is Planned, and its status has not been
72
+ ratified individually — a Planned page states scope and nothing more.
73
+
74
+ A sub-harness is not a twentieth family. The nineteen-family taxonomy above is
75
+ owner-ratified: a capability that fits inside a ratified family arrives as a
76
+ sub-harness with its own contract document, and the family page states exactly
77
+ which part of it is shaped.
78
+
79
+ Where a family page says a thing does not exist, that is a checked statement
80
+ about the tree today, not a placeholder.
81
+
82
+ ## Vehicle domains are not a harness family
83
+
84
+ Space, air, ground and naval vehicles do not each get a harness. The vehicle
85
+ domain is a declaration in the module manifest — state space, frames, and
86
+ degrees of freedom — consumed by whichever family the module implements. A
87
+ ground-vehicle propagator and a spacecraft propagator implement the same
88
+ propagator export set and differ in the manifest.
89
+
90
+ ## Harness families are not the runtime `PluginFamily` enum
91
+
92
+ Two vocabularies exist and they are not the same list.
93
+
94
+ - The **harness-family taxonomy** on this site is the owner-ratified list of
95
+ ABI-bearing plugin kinds: propagator, maneuver, propulsion, attitude, gnc, rf,
96
+ sensor, signature, environment, obstruction, breakup, reentry, conjunction,
97
+ effects, estimation, data-source, analytics, scheduler, behavior.
98
+ - The **`PluginFamily` enum** in `schemas/PluginManifest.fbs` is the SDK's
99
+ internal manifest classification (`SENSOR`, `PROPAGATOR`, `RENDERER`,
100
+ `ANALYSIS`, `DATA_SOURCE`, `COMMS`, `SHADER`, `SDF`, `INFRASTRUCTURE`, `FLOW`,
101
+ `BRIDGE`, `MANEUVER`, `ORBIT_DETERMINATION`, `FOUNDATION`, `PARSER`,
102
+ `VALIDATOR`, `EXPORTER`, `PUBLISHER`, `BASILISK`). It is what a manifest
103
+ declares today.
104
+
105
+ They overlap but do not correspond one-to-one, and a family in the taxonomy may
106
+ project onto a broader `PluginFamily` member until a dedicated one is minted.
107
+ Do not file a mismatch between the two lists as a bug; the family pages state
108
+ which enum member each family projects onto.
109
+
110
+ ## Internal plumbing is never a public contract
111
+
112
+ Two boundaries are permanent rulings, not maturity gaps:
113
+
114
+ - **JavaScript registries are internal engine plumbing.** They are how a
115
+ consuming engine dispatches to compiled modules. They are never offered as a
116
+ public extension point. Harness contracts are WASM ABIs only.
117
+ - **Scalar kernel-op ABIs behind closed modules are internal.** In particular
118
+ the closed scalar `rf_*` kernel ABI is never the public RF contract. The
119
+ public RF surface is the `.fbs`-defined harness ABI plus the record types
120
+ a module consumes and emits.
121
+
122
+ ## The integrator path
123
+
124
+ 1. [BYO-wasm quickstart](byo-wasm-quickstart.html) — multi-translation-unit C++
125
+ against the pinned `wasm32-wasip1-threads` toolchain, to a loadable artifact.
126
+ 2. [Conformance kit](conformance.html) and the
127
+ [tri-runtime parity gate](tri-runtime-parity-gate.html) — prove the ABI, then
128
+ prove byte-identical behavior in every lane.
129
+ 3. [Protect and sign](protect-and-sign.html) — encrypt the payload where the
130
+ module is closed, attach the manifest, sign the artifact.
131
+ 4. [Publication and listing](publication-submission.html) — the publication
132
+ record layout, delivery, and the current state of self-serve listing.
133
+
134
+ An LLM building a module against this SDK should start at
135
+ [llms.txt](llms.txt).