docs(splat-native): cross-workspace integration plan v1 (canonical, 14 D-SPLAT-* deliverables, §6 FMA-litmus customer, SaMD Class IIa)#471
Merged
Conversation
…ance-graph side)
Cross-workspace integration plan for a CPU-only Gaussian-splat ultrasound
SaMD pipeline triggered by user-supplied architecture diagrams (English
6-stage + German business-facing). The pipeline turns certified ultrasound
probes (Clarius / Telemed ArtUs / us4us) into anisotropic 3D Gaussian
volumes, accumulates them via IMU/POSE 4D, registers against the FMA
anatomical atlas (Σ-sandwich Mahalanobis ICP), and renders patient-aligned
AR overlays. Same splat math serves acquisition, registration, rendering.
This plan is the CANONICAL home; companion docs live in ndarray, OGAR,
and MedCare-rs (separate PRs from new branches).
## What this PR ships
`docs/board only — no code; cargo not invoked.
- `.claude/plans/splat-native-ultrasound-v1.md` (~930 LOC, 12 sections)
- §0 executive summary; §1 architectural mapping (diagrams ↔ existing
workspace substrate); §2 workspace cross-cuts; §3 14 per-deliverable
specs (D-SPLAT-1..14); §4 phase sequencing P1..P7; §5 deps graph;
§6 5 open questions OQ-SPLAT-1..5; §7 risk matrix; §8 success
criteria; §9 cross-references; §10 PER-REPO PERSPECTIVES (ownership
matrix + work-division principles + interconnect map + sprint-cadence
schedule + cross-repo coordination protocol); §11 what's NOT covered.
- `.claude/board/INTEGRATION_PLANS.md` — PREPEND new plan entry.
- `.claude/board/STATUS_BOARD.md` — new section with 14 D-SPLAT-* rows.
- `.claude/board/AGENT_LOG.md` — PREPEND this run.
## Anchored to existing FINDING-grade epiphanies (inherits; no new claims)
- `E-SOA-IS-THE-ONLY` (one substrate, three operations: fit / accumulate
/ render — splat-native is the medical-imaging incarnation)
- `E-BATON-1` (each frame is one ractor mailbox handoff, 13 + 10·count B
wire cost)
- `E-RUBICON-RACTOR` (Libet −550 ms 4-phase kanban; splat actors map
Planning=pose-accumulate → Cognitive=splat-fit → Evaluation=ICP residual
→ Commit/Plan/Prune)
- `I-VSA-IDENTITIES` (Gaussian class_id points to FMA URI; never bundle
the Gaussians themselves)
- `I-NOISE-FLOOR-JIRAK` (Mahalanobis significance + ICP convergence
thresholds cite Jirak under weak dependence)
- `I-LEGACY-API-FEATURE-GATED` (governs MailboxSoAHeader version gate
on Gaussian3D schema upgrades)
## 14 deliverables, 4 repos, 3 new standalone crates
| Repo | Owns | Sprint |
|---|---|---|
| `ndarray` | D-SPLAT-2 (SIMD batch ops) | P1 sprint 1-2 |
| `lance-graph-contract` | D-SPLAT-1/3 (Gaussian3D + SplatBatch carriers) | P1 sprint 1-2 |
| `lance-graph` | D-SPLAT-4/5/8/9 (SH palette + registration + FMA atlas + style_recipe) | P3-P4 sprint 4-8 |
| `crates/splat-fit` (new) | D-SPLAT-6 (RF → splat-fit engine) | P2 sprint 3 |
| `crates/splat-actors` (new) | D-SPLAT-7/13 (actors + IMU/POSE) | P3 sprint 4-5 |
| `crates/splat-render` (new) | D-SPLAT-12 (AR renderer) | P6 sprint 11-13 |
| `MedCare-rs` | D-SPLAT-10/11 (HIPAA wire + audit) | P5 sprint 9-10 |
| `OGAR` | Phase 8 FMA hydrate + KnowableFromStore reg | P4 sprint 6-8 |
| `q2`/`quarto` | D-SPLAT-14 (SaMD Forschungstool → Class IIa docs) | P7 sprint 14+ |
## Critical-path edges (cross-repo coordination)
1. ndarray D-SPLAT-2 → all SIMD consumers (carrier layout meets SIMD
load width; design-time handshake).
2. lance-graph-contract D-SPLAT-1/3 → all carrier consumers (the wire
format).
3. OGAR Phase 8 → lance-graph D-SPLAT-8 (FMA TTL → Lance dataset; tight
coordination, ship together).
4. lance-graph D-SPLAT-12 → cesium/HoloLens adapter (end-game; doesn't
block earlier phases).
## Inherits (no new build)
- bardioc PR #17 Rubicon kanban (frame ratification gate; consumed
verbatim by D-SPLAT-7)
- callcenter PR #467 `LanceMembrane::commit_event` (audit home for
D-SPLAT-11)
- OGAR PR #25/#31 `KnowableFromStore` (splat-ingest registration with
OGIT-prefixed canonical identity)
- lance-graph PR #434 unified-SoA carrier doctrine (E-SOA-IS-THE-ONLY)
- ndarray PR #189 `OntologySchema::is_ancestor` (FMA atlas traversal;
sub-millisecond is the §6 acceptance gate)
- ndarray PR #463 (ndarray-is-mandatory in lance-graph; splat-fit feature
flag pattern)
- OGAR PR #30 §6 FMA bones-rendering litmus (this arc IS the customer)
## The §6 litmus, restated for splat-native
> Given a live ultrasound splat volume (~10⁶–10⁷ Gaussians/frame, ~30 fps,
> CPU-only on a HoloLens-class device) and the FMA atlas splat volume
> (~150M Gaussians, ~5 GB on disk, region-paged), the inner loop must:
> (1) resolve atlas_region_id via NiblePath traversal — sub-millisecond;
> (2) page the matching atlas-region Gaussians — <10ms; (3) Σ-sandwich
> Mahalanobis ICP — <100ms; (4) emit pose + per-Gaussian class_id back;
> (5) render the patient-aligned overlay — <33ms.
> Total inner-loop budget: <150ms/frame, CPU-only, no GPU vendor lock.
> The sub-millisecond §6 traversal IS the gating threshold.
## 5 open questions for user ratification
- OQ-SPLAT-1: first probe SDK? Default: Telemed ArtUs (RF direct, USB).
- OQ-SPLAT-2: SH degree budget? Default: ℓ=3 (16 coefficients).
- OQ-SPLAT-3: ship own beamformer vs consume probe's? Default: consume
where available, ship DAS fallback for Clarius B-mode.
- OQ-SPLAT-4: does AR-rendered splat volume leave the device? Default:
no, on-device only.
- OQ-SPLAT-5: plan home? Resolved: lance-graph canonical + per-repo
companions in ndarray/OGAR/MedCare-rs.
## Test plan
- [x] Docs/board only — no source code; no build/test invoked.
- [x] Cross-workspace plan: lance-graph canonical, companion docs in
ndarray + OGAR + MedCare-rs as separate PRs from new branches.
- [x] Board hygiene: INTEGRATION_PLANS PREPEND + STATUS_BOARD section +
AGENT_LOG PREPEND in this PR.
- [ ] User ratification of OQ-SPLAT-1..4 before any D-SPLAT-* implementation
starts.
- [ ] cross-link PRs (this PR ↔ ndarray PR ↔ OGAR PR ↔ MedCare-rs PR)
after each lands.
📝 WalkthroughWalkthroughThis PR adds a complete v1 integration plan for CPU-only ultrasound-to-Gaussian splat SaMD workflow. Four documentation files are updated: an agent log entry, integration plan index, status board, and a new 782-line detailed plan. The plan specifies 14 deliverables, 7 migration phases, repo-by-repo coordination, and cross-workspace dependencies without introducing code or tests. ChangesSplat-Native Ultrasound v1 Plan
Estimated code review effort🎯 1 (Trivial) | ⏱️ ~5 minutes Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 28192199f9
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| - `StepDomain::SplatFit` (the engine consumes RF/IQ → emits SoA) | ||
| - `StepDomain::SplatRender` (the renderer consumes SoA → emits pixels) | ||
|
|
||
| These compose with existing `StepDomain::{Codec, Thinking, Query, Semantic, Persistence, Inference, Learning}` per OrchestrationBridge contract. |
There was a problem hiding this comment.
This line makes the runtime coordination plan depend on existing StepDomain variants that are not in the shipped OrchestrationBridge contract; I checked crates/lance-graph-contract/src/orchestration.rs, where the enum currently contains Crew, Ladybug, N8n, LanceGraph, Ndarray, Smb, Medcare, and Kanban. For implementers following this plan to add SplatFit/SplatRender, the surrounding guidance points them at a non-existent taxonomy/prefix model, so the first code PR is likely to wire against the wrong contract or stall on reconciling the mismatch.
Useful? React with 👍 / 👎.
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 4
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In @.claude/board/STATUS_BOARD.md:
- Around line 7-20: Several table rows (e.g., D-SPLAT-1 through D-SPLAT-14) have
non-canonical Status cells like "**Queued — P1 sprint 1-2**"; change each Status
cell to the canonical enum value only (Queued, In progress, In PR, Shipped,
etc.) and move the sprint/timing text into a separate column (e.g., add a
"Sprint" or "Timing" column to the board header) or into the existing Notes
column so tooling that parses the Status column still sees only the canonical
value; update the table header to include the new column and adjust any
consumers that expect the original two-column layout if needed.
In @.claude/plans/splat-native-ultrasound-v1.md:
- Around line 268-269: Sections that describe PHI for splat geometry are
contradictory: one asserts "splat coordinates" contain PHI while another says
coordinates are "scanner-frame and not patient-identifying." Pick a single
normative rule (example: "Scanner-frame splat geometry is non-identifying unless
linked with patient identifiers or patient landmarks") and update both the
paragraph that currently states "Raw RF/IQ stays out of MedCare-rs entirely —
only fitted splats land" and the paragraph that refers to "scanner-frame"
coordinates to reference that single rule; explicitly name the rule in both
places (and in the `column_mask_bridge` extension description) so policy
enforcement and masking/audit logic can unambiguously rely on the same
classification.
- Around line 262-263: The declared column pose_se3 uses FixedSizeBinary(16) but
the described payload is 12 f16 values (3 translation + 9 rotation) which is
12×2=24 bytes; update the schema to use FixedSizeBinary(24) (or otherwise match
the described storage format) so the FixedSizeBinary size matches the 12 f16
elements for pose_se3.
- Around line 403-418: The markdown fenced code blocks shown (the ASCII diagram
beginning with "OGAR `#30` Phase 8 (FMA hydrate prep)" and the other multi-line
block around lines 659-718) are missing language identifiers and trigger MD040;
update their opening fences from ``` to ```text (or another appropriate language
token) so the blocks are explicitly tagged, ensuring both fenced blocks are
changed consistently.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro Plus
Run ID: c422b4a3-a0be-416d-bd1e-0a16c50cfca3
📒 Files selected for processing (4)
.claude/board/AGENT_LOG.md.claude/board/INTEGRATION_PLANS.md.claude/board/STATUS_BOARD.md.claude/plans/splat-native-ultrasound-v1.md
Comment on lines
+7
to
+20
| | D-SPLAT-1 | `Gaussian3D` carrier (`mu`/`sigma_packed`/`amplitude`/`opacity`/`sh[16]`/`frame_idx`/`class_id`; 80 B/row) | `lance-graph-contract::splat` | 120 | LOW | **Queued — P1 sprint 1-2** | gates on `MailboxSoAHeader` (D-MBX-10) or own feature flag | | ||
| | D-SPLAT-2 | `ndarray::simd::splat` batch ops — `batched_cholesky_3x3` / `batched_mahalanobis` / `batched_opacity_blend` / `batched_sh_eval_l3` / `batched_se3_transform`; all three backends (AVX-512/NEON/scalar) | `ndarray::src/simd_splat.rs` | 600 | MED | **Queued — P1 sprint 1-2** | foundation; none | | ||
| | D-SPLAT-3 | `SplatBatch<N>` SoA carrier (per-column slices for SIMD sweep; inherits MailboxSoAHeader versioning) | `lance-graph-contract::splat` | 150 | LOW | **Queued — P1 sprint 1-2** | gates on D-SPLAT-1 | | ||
| | D-SPLAT-4 | SH-aware palette extension in `crates/bgz17` (256×256×2B compose table; SH-basis-id per centroid) | `bgz17::sh_palette` | 250 | MED | **Queued — P3 sprint 4-5** | gates on D-SPLAT-1 | | ||
| | D-SPLAT-5 | Splat-to-splat registration math — Σ-sandwich Mahalanobis ICP + SE(3) Levenberg-Marquardt | `lance-graph::splat::registration` | 400 | HIGH | **Queued — P4 sprint 6-7** | gates on D-SPLAT-2 + D-SPLAT-3 | | ||
| | D-SPLAT-6 | `crates/splat-fit` engine — RF/IQ → beamformed → local-maxima → PSF estimate → SH projection → emit Gaussian3D batch | `crates/splat-fit` (new standalone, 0-dep, ndarray-hpc feature) | 1500 | HIGH | **Queued — P2 sprint 3** | gates on D-SPLAT-1 + D-SPLAT-2 + OQ-SPLAT-3 | | ||
| | D-SPLAT-7 | Splat actors — `SplatFitActor`/`PoseAccumulatorActor`/`RegistrationActor`, each owns one `MailboxSoA<Gaussian3D>`; consumes bardioc #17 Rubicon kanban verbatim | `crates/splat-actors` (or `ractor_actors`) | 500 | MED | **Queued — P3 sprint 4-5** | gates on D-SPLAT-3 + D-SPLAT-6 + bardioc #17 (shipped) | | ||
| | D-SPLAT-8 | FMA atlas hydrator — TTL → `fma_class.lance` + `fma_relation.lance` + `fma_atlas_splat.lance` (~150M Gaussians full body) | `lance-graph-ontology` + `crates/fma-hydrator` | 800 | HIGH | **Queued — P4 sprint 7-8** | gates on OGAR PR #30 Phase 8 + D-SPLAT-3 + ndarray PR #189 (shipped) | | ||
| | D-SPLAT-9 | `fma_blueprint::style_recipe` D-Atom catalogue (AnatomicalRegion, OrganSystem, Innervation, Vasculature, Joint, Muscle, Bone, OrganParenchyma, Tract); mirrors PR #433 Odoo pattern | `lance-graph-ontology::fma_blueprint` | 400 | LOW | **Queued — P4 sprint 7-8** | gates on D-SPLAT-8 | | ||
| | D-SPLAT-10 | `memory.ultrasound_frame.lance` + `memory.ultrasound_splat.lance` datasets via `soa_mapping.rs`; new `SensitivityReason::UltrasoundRawPHI`/`UltrasoundAnonymized` variants in `column_mask_bridge` | MedCare-rs `crates/medcare-analytics` | 250 | MED | **Queued — P5 sprint 9-10** | gates on D-SPLAT-3 + MedCare PR #162 (shipped) | | ||
| | D-SPLAT-11 | `commit_event` audit chain for splat ingest via `LanceMembrane::commit_event` (callcenter PR #467, sole-writer membrane); `KnowableFromStore::register("ogit-medcare/ultrasound_ingest", Some(ddl_hint))` | MedCare-rs `crates/medcare-analytics` | 100 | LOW | **Queued — P5 sprint 9-10** | gates on D-SPLAT-10 + PR #467 (shipped) + OGAR #25/#31 (shipped) | | ||
| | D-SPLAT-12 | AR splat renderer — HoloLens OpenXR (clinical AR target) + Cesium ion + Three.js (browser fallback) + headless PNG (regression); CPU does math, GPU only paints | `crates/splat-render` (new) | 1200 | HIGH | **Queued — P6 sprint 11-13** | gates on D-SPLAT-2 + D-SPLAT-3 + D-SPLAT-5 | | ||
| | D-SPLAT-13 | IMU/POSE 4D accumulator — VIO against splat features at IMU rate (~200 Hz); splat-corrected pose at frame rate (~30 Hz); Planning-column readiness at t = −550ms | `splat-actors::PoseAccumulatorActor` | 200 | MED | **Queued — P3 sprint 4-5** | gates on D-SPLAT-7 | | ||
| | D-SPLAT-14 | SaMD documentation track — research-tool → clinical-study → Class IIa (IEC 62366 / IEC 80001 / ISO 14971 / IVD-MDR Rule 11). ADR-022 firewall IS the audit-controls evidence base | `q2`/`quarto` or `docs/` | 600 | LOW | **Queued — P7 sprint 14+ (parallel through P4-P6)** | gates on none architecturally; v1/v2/v3 phased | |
There was a problem hiding this comment.
Keep Status values canonical; move sprint timing out of the status cell.
At Line 7 through Line 20, values like **Queued — P1 sprint 1-2** drift from the board’s canonical status enum (Queued, In progress, In PR, Shipped, etc.). This can break any tooling or queries that parse status strictly.
Suggested edit pattern
-| ... | **Queued — P1 sprint 1-2** | gates on ...
+| ... | **Queued** | gates on ... (target: P1 sprint 1-2)🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In @.claude/board/STATUS_BOARD.md around lines 7 - 20, Several table rows (e.g.,
D-SPLAT-1 through D-SPLAT-14) have non-canonical Status cells like "**Queued —
P1 sprint 1-2**"; change each Status cell to the canonical enum value only
(Queued, In progress, In PR, Shipped, etc.) and move the sprint/timing text into
a separate column (e.g., add a "Sprint" or "Timing" column to the board header)
or into the existing Notes column so tooling that parses the Status column still
sees only the canonical value; update the table header to include the new column
and adjust any consumers that expect the original two-column layout if needed.
Comment on lines
+262
to
+263
| - `pose_se3: FixedSizeBinary(16)` — packed SE(3) pose (3 translation + 9 rotation matrix, both `f16`) | ||
| - `splat_batch_handle: Binary` — pointer into the splat-volume storage (NOT the splats themselves; those live in `ultrasound_splat.lance` to keep this table queryable) |
There was a problem hiding this comment.
pose_se3 byte-width is internally inconsistent.
At Line 262, FixedSizeBinary(16) conflicts with the described payload (3 + 9 values in f16), which is 12 × 2 bytes = 24 bytes. This will cause downstream schema mismatch if implemented as written.
Suggested correction
-- `pose_se3: FixedSizeBinary(16)` — packed SE(3) pose (3 translation + 9 rotation matrix, both `f16`)
+- `pose_se3: FixedSizeBinary(24)` — packed SE(3) pose (3 translation + 9 rotation matrix, both `f16`)🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In @.claude/plans/splat-native-ultrasound-v1.md around lines 262 - 263, The
declared column pose_se3 uses FixedSizeBinary(16) but the described payload is
12 f16 values (3 translation + 9 rotation) which is 12×2=24 bytes; update the
schema to use FixedSizeBinary(24) (or otherwise match the described storage
format) so the FixedSizeBinary size matches the 12 f16 elements for pose_se3.
Comment on lines
+268
to
+269
| **Raw RF/IQ stays out of MedCare-rs entirely** — only fitted splats land. PHI is in the splat coordinates + atlas-aligned annotations, not in the raw signal. The `column_mask_bridge` extension adds: | ||
|
|
There was a problem hiding this comment.
Unify PHI classification for splat geometry (currently contradictory).
Line 268 says PHI is in splat coordinates; Line 443 says coordinates are scanner-frame and not patient-identifying. These are mutually inconsistent and can lead to incorrect masking/audit policy decisions.
Please define one normative rule (e.g., “scanner-frame splat geometry is non-identifying unless linked with patient identifiers/landmarks”) and reference that rule in both sections.
Also applies to: 443-444
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In @.claude/plans/splat-native-ultrasound-v1.md around lines 268 - 269, Sections
that describe PHI for splat geometry are contradictory: one asserts "splat
coordinates" contain PHI while another says coordinates are "scanner-frame and
not patient-identifying." Pick a single normative rule (example: "Scanner-frame
splat geometry is non-identifying unless linked with patient identifiers or
patient landmarks") and update both the paragraph that currently states "Raw
RF/IQ stays out of MedCare-rs entirely — only fitted splats land" and the
paragraph that refers to "scanner-frame" coordinates to reference that single
rule; explicitly name the rule in both places (and in the `column_mask_bridge`
extension description) so policy enforcement and masking/audit logic can
unambiguously rely on the same classification.
Comment on lines
+403
to
+418
| ``` | ||
| OGAR #30 Phase 8 (FMA hydrate prep) ─────────┐ | ||
| ▼ | ||
| ndarray D-SPLAT-2 (SIMD splat ops) ──► D-SPLAT-8 (FMA atlas) ──┐ | ||
| │ │ | ||
| ▼ ▼ | ||
| D-SPLAT-1/3 (carriers) ──► D-SPLAT-6 (splat-fit) ──► D-SPLAT-7 (actors) | ||
| │ │ | ||
| ▼ ▼ | ||
| D-SPLAT-4 (SH palette) ────────────────────────────► D-SPLAT-5 (registration) | ||
| │ | ||
| ┌────────────────────────────┼────────────────────────────┐ | ||
| ▼ ▼ ▼ | ||
| D-SPLAT-10/11 D-SPLAT-12 D-SPLAT-14 | ||
| (MedCare HIPAA) (AR renderer) (SaMD regulatory) | ||
| ``` |
There was a problem hiding this comment.
Add language tags to fenced code blocks to satisfy markdown lint.
At Line 403 and Line 659, fenced blocks are missing a language identifier (MD040).
Suggested fix
-```
+```text
...
-```
+```
-```
+```text
...
-```
+```Also applies to: 659-718
🧰 Tools
🪛 markdownlint-cli2 (0.22.1)
[warning] 403-403: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In @.claude/plans/splat-native-ultrasound-v1.md around lines 403 - 418, The
markdown fenced code blocks shown (the ASCII diagram beginning with "OGAR `#30`
Phase 8 (FMA hydrate prep)" and the other multi-line block around lines 659-718)
are missing language identifiers and trigger MD040; update their opening fences
from ``` to ```text (or another appropriate language token) so the blocks are
explicitly tagged, ensuring both fenced blocks are changed consistently.
6 tasks
AdaWorldAPI
added a commit
that referenced
this pull request
Jun 5, 2026
…nd-v1-fixes docs(splat-native): address review feedback on #471 (5 fixes — StepDomain, canonical status, pose_se3, NR-SPLAT-PHI, MD040)
AdaWorldAPI
pushed a commit
that referenced
this pull request
Jun 5, 2026
…ce contract Closes the runtime-side follow-up commitment that **OGAR #39 ADR-024 § Consequences** explicitly names by reference: *"Reports ρ-vs-reference on first per-country PBF run per the runtime session's §11 follow-up commitment"*. Sibling to #474 (the codex P2 D-OSM-2 ownership-boundary fix landed by the other session). This PR is purely additive — appends a new **§11 ADR-024 adoption — palette256 + HHTL codec contract** section at the end of `cesium-osm-substrate-v1.md` without touching the existing §1-§10 or the §11 (NOT covered) section labelling (now §11 ADR-024 + §10 NOT covered before _End of plan_). ## What the new §11 pins 1. **Adoption checklist** (ADR-024's 4-step) mapped onto D-OSM-2: - Prefix = Cesium TMS quadkey `qk:<level>/<x>/<y_tms>` (Q2 ruling). - Palette domain = OSM tag-values per-tile (≤256 at zoom 21 per ADR-024 §256-ceiling escape hatches) + tile-local quantized coords (sub-cm at zoom 21). - ρ-vs-reference target ≥ 0.99 matching the `arm-discovery` aerial-codebook anchor (ρ = 0.9973 vs cosine). - Decode = const-table lookup; zero-allocation. 2. **Falsifiable adoption contract** for D-OSM-2: - Report empirical ρ on first per-country PBF run (default: Liechtenstein per §6 OQ-OSM-4). - Report per-tile palette cardinality distribution (mean / p95 / p99) — escape hatch selected from measurement. - Decode bandwidth target ≥ 10⁸/sec on AVX-512. - If ρ < 0.99 on first run, document gap before multi-country ingest (escalate to per-tile, hierarchical, or palette-64K). 3. **Cross-arc adopters table** — three shipped anchors (`arm-discovery`, `Binary16K` `_effectiveReaders`, `bgz-tensor` `WeightPalette`) + two queued adopters (`D-OSM-2`, `D-SPLAT-4` — both named in ADR-024 § Consequences). 4. **Why §11 not §3**: ADR-024 codec contract is independent of §3 carrier-shape contract (Q1 v1 fallback). The Arrow `List<Struct<key,value>>` column shape holds whether or not the tag value is palette-encoded; palette is a transparent codec underneath the column. Keeping §11 separate preserves §3's "carrier shape" framing while pinning the codec contract. ## Why a separate small PR (not bundled with #474) #474 (other session) landed the codex P2 D-OSM-2 ownership- boundary fix as a 1-line minimal edit. The §11 ADR-024 callout is purely additive (no overlap with #474's diff). Keeping them as two PRs preserves the codex-fix vs proactive-architectural-pin separation — codex reviewers can pattern-match each PR's intent without bundling. ## Companion (separate small PR — also being filed) D-SPLAT-4 in `splat-native-ultrasound-v1.md` deserves the symmetric ADR-024 adoption note (ADR-024 § Consequences names both D-OSM-2 AND D-SPLAT-4 as queued adopters). That edit ships as `claude/splat-native-adr-024-callout` since the splat-native arc has its own branch lineage and its own #471/#472 PR history. ## Test plan - [x] Docs/plan only — no source code; no build/test invoked. - [x] §11 cites ADR-024 by file:line (`OGAR/docs/ARCHITECTURAL- DECISIONS-2026-06-04.md`) + the arm-discovery ρ=0.9973 empirical anchor + bgz-tensor `WeightPalette` reference. - [x] Falsifiable contract is testable at D-OSM-2 implementation time (per-country PBF run; reported ρ + cardinality distribution + decode bandwidth). - [x] No collision with #474 (purely additive section append). - [ ] Codex re-review on this PR.
5 tasks
AdaWorldAPI
pushed a commit
that referenced
this pull request
Jun 11, 2026
Surveyed PRs #471-#487. Three landed that materially affect my outstanding ask list: - #482 (merged): GUID canon + prefix routing knowledge doc — pins TWO-ALGEBRA RULE (sign=XOR, magnitude=bundle, never MergeMode::Xor) + helix CurveRuler stride-4-over-17 as bit-exact integer phase generator. Both are load-bearing receipts for substrate-addressing-v1. - #484 (merged): D-IDENTITY-2 ships entity_type↔NiblePath bijection in lance-graph-ontology registry. RESOLVES the Tier-1 'NiblePath scheme for FMA classes' ask — OGAR Phase 8 calls register_class_path() per FMA Class. - #485 (OPEN): PROBE-MANTISSA-FILL + PROBE-PHASE-1 both GREEN. The golden-mantissa placement leg of the substrate-addressing claim is now measured (not asserted): beats seeded random by ~30% at k=256 + half worst-case pile-up. CurveRuler bit-exactness verified over 20 path/depth pairs. Updated Decision 1 trigger: substrate-addressing-v1.md now files after #485 merges (not after D-HELIX-1 owner ping — they're actively probing). D-CESIUM-1 (mine — extend implicit_tiling.rs to consume helix::bounds) is the file-soonest deliverable. D-JC-1 still needs per-scene-class p calibration timeline.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Cross-workspace integration plan v1 for a CPU-only Gaussian-splat ultrasound SaMD pipeline triggered by user-supplied architecture diagrams (English 6-stage + German business-facing). This is the canonical home of the plan; companion docs live in
ndarray,OGAR, andMedCare-rs(separate PRs from new branches).The pipeline turns certified probes (Clarius / Telemed ArtUs / us4us) into anisotropic 3D Gaussian volumes, accumulates them via IMU/POSE 4D, registers against the FMA anatomical atlas (Σ-sandwich Mahalanobis ICP), and renders patient-aligned AR overlays. Same splat math serves acquisition, registration, rendering. CPU-only by design (no GPU vendor lock; no GPU cart at bedside).
What this PR ships
Docs/board only — no code; cargo not invoked.
.claude/plans/splat-native-ultrasound-v1.md(~930 LOC, 12 sections).claude/board/INTEGRATION_PLANS.md— PREPEND new plan entry..claude/board/STATUS_BOARD.md— new section with 14 D-SPLAT-* rows..claude/board/AGENT_LOG.md— PREPEND this run.Anchored to existing FINDING-grade epiphanies (inherits, no new claims)
E-SOA-IS-THE-ONLY·E-BATON-1·E-RUBICON-RACTOR·I-VSA-IDENTITIES·I-NOISE-FLOOR-JIRAK·I-LEGACY-API-FEATURE-GATEDSplat-native is the medical-imaging incarnation of "one substrate, three operations" — fit / accumulate / render.
14 deliverables across 4 repos + 3 new standalone crates
§10 ownership matrix names: ndarray (D-SPLAT-2 SIMD), lance-graph-contract (D-SPLAT-1/3 carriers), lance-graph (D-SPLAT-4/5/8/9 — SH palette + registration + FMA atlas + style_recipe),
crates/splat-fitnew (D-SPLAT-6),crates/splat-actorsnew (D-SPLAT-7/13),crates/splat-rendernew (D-SPLAT-12), MedCare-rs (D-SPLAT-10/11), OGAR (Phase 8 customer of #30),q2/quarto(D-SPLAT-14 SaMD docs).The §6 FMA litmus is the customer-side gate
OGAR PR #30 §6 ("FMA bones-rendering as the architectural litmus") was previously a demo target. With splat-native as the named downstream, it becomes the load path — the sub-millisecond HHTL traversal claim IS the splat-native frame-rate budget's gating threshold.
Combined acceptance gate: <150ms/frame total — sub-millisecond NiblePath traversal + <10ms atlas-region paging + <100ms Σ-sandwich ICP + <33ms render. CPU-only, no GPU vendor lock at the math layer.
Inherits (no new build)
bardioc PR #17 (Rubicon kanban — splat actors map Planning→Cognitive work→Evaluation→Commit·Plan·Prune) · callcenter PR #467 (
LanceMembrane::commit_eventsole-writer membrane — audit home) · OGAR PR #25/#31 (KnowableFromStore— splat-ingest registration with OGIT-prefixed canonical identity) · lance-graph PR #434 (unified-SoA carrier doctrine) · ndarray PR #189 (OntologySchema::is_ancestor— FMA atlas traversal) · ndarray PR #463 (ndarray-is-mandatory).5 open questions for user ratification (before D-SPLAT-* implementation)
Test plan
Cross-PR coordination
This is one of four coordinated PRs for the splat-native-ultrasound-v1 cross-workspace plan. All four reference each other; lance-graph is canonical.
lance-graphclaude/splat-native-ultrasound-v1ndarrayclaude/splat-native-ultrasound-v1MedCare-rsclaude/splat-native-ultrasound-v1OGARclaude/splat-native-customerTriggered by user-supplied architecture diagrams (English 6-stage technical + German business-facing). No source code in any of the four PRs — design-spec / handover only.
Authored by session
claude/lance-graph-ontology-review-Pyry3.Summary by CodeRabbit