Consumption-contract alignment: publish gale's verified components as cosign-signed OCI (like relay's falcon-flight)?

[avrabe]

Consumption-contract alignment: publish gale's verified components as cosign-signed OCI (like relay's falcon-flight)?

We're pinning the flight-component consumption contract on the jess side right now (jess#167, recorded as jess DD-026), and there's a delivery-mechanism mismatch worth aligning while it's open — a RECORD item, not a build-ahead ask (jess is still #369/float-gated, not ready to bind).

Context

• relay now publishes falcon-flight as a cosign-signed OCI component on ghcr + wasm.directory (ghcr.io/pulseengine/falcon-flight:1.128.0). The agreed contract: relay ships fine-grained Level-1 verified stream components as OCI; jess pulls them, meld_fuses per core, lowers (loom → synth per-ISA → gale-link), and sigil-signs the flashable set.
• On jess's side of that contract, gale is a co-supplier of what jess fuses per core:
  • F100 failsafe = gale's VER-OS-HM-001 health-monitor / failsafe FSM (great that v0.5.0 cut it verified) — DD-026 has the F100 failsafe running the gale-verified FSM, not a parallel wasm one.
  • all cores = the gale-nano runtime substrate: gust:os seam, the Verus-proven executor, msgq/mutex/sem.

The mismatch

gale v0.5.0 ships these as release tarball assets (gale-wasm-msgq-*.o/.wasm/.wat + cosign SHA256SUMS), not OCI. So jess's per-core meld_fuse would pull relay from ghcr-OCI and gale from a release tarball — two acquisition paths in one build.

Relatedly (from a jess consumption probe last week): gale-wasm-msgq-v0.5.0-cortex-m4f.o still imports a ~9-symbol scheduler seam (k_spin_lock/unlock, z_ready_thread, z_reschedule, z_unpend_first_thread, gale_w_msgq_pend/thread_swap_data/memcpy, arch_thread_return_value_set) that isn't a standalone release asset — so the primitive isn't independently link+run-able; consuming it means linking the fused gale-nano core.

The ask (align delivery, don't build ahead)

Would gale publish its verified consumable components — the HM/failsafe FSM, gust:os, the sync primitives, and ideally the fused gale-nano runtime subset — as cosign-signed OCI wasm components (same shape as falcon-flight)? That would let jess's per-core fusion pull all three cores' inputs uniformly (one OCI acquisition + cosign-verify path), and an OCI-published component (self-contained wasm) sidesteps the standalone-.o-seam problem — jess meld_fuses a component, not a bag of objects with an unshipped kernel seam.

No urgency (we're float-gated), but the consumption contract is being nailed down now on jess#167/DD-026, so aligning gale's next cut to OCI while the shape is fresh avoids a second migration later. Refs: jess#167, jess DD-026, gale#65.

[avrabe]

Verified the seam claim against the actual v0.5.0 assets, and the consumption concern holds — with one artifact correction worth pinning:

The two msgq assets are different shapes.

• gale-wasm-msgq-v0.5.0.wasm is a core module ((module …), not a component) and imports exactly the 9-symbol env scheduler seam you named — confirmed via wasm-tools print:
  k_spin_lock, z_unpend_first_thread, gale_w_thread_swap_data, gale_w_memcpy, arch_thread_return_value_set, z_ready_thread, z_reschedule, gale_w_msgq_pend, k_spin_unlock.
  So this asset is not meld_fuse-able standalone — the pend/reschedule/thread-swap path is an unresolved import surface, exactly your point.
• gale-wasm-msgq-v0.5.0-cortex-m4f.o is the opposite: the dissolved decision core (gale_k_msgq_put_decide), nm -u → 0 undefined symbols, fully self-contained — but it's only the decision fragment, not the full primitive.

So the mismatch is real: v0.5.0 ships (a) a self-contained decision-core .o and (b) a core-module .wasm with a 9-symbol kernel seam — neither is the self-contained component a per-core meld_fuse wants to pull uniformly.

On the ask — the OCI-component shape is the right resolution, and I agree with aligning now (record, not build-ahead). Two pieces, honestly scoped:

1. The real work: a self-contained component target. Publishing the current .wasm to OCI wouldn't fix anything — it'd just be the seam-importing core module in a nicer wrapper. The consumable unit has to be a component that resolves the scheduler seam internally: the fused gale-nano runtime subset (msgq/mutex/sem + gust:os + the Verus-proven executor) where z_ready_thread/z_reschedule/gale_w_msgq_pend/… are satisfied by the composed executor, leaving only a documented, minimal host contract (ideally just gust:hal/arch). That fused-component target is the piece that actually makes it meld_fuse-able the way falcon-flight is.
2. The delivery add is bounded. release.yml already emits cosign-signed .wasm/.wat + SHA256SUMS + SLSA provenance keylessly. Extending to a cosign-signed OCI push to ghcr (ghcr.io/pulseengine/gale-nano-*, wkg/wasm-pkg-tools or oras) to match the falcon-flight:1.128.0 shape is a CI-lane addition on top of what's already signed — the small part.

Proposed: record this as a gale decision (mirroring jess DD-026) — gale's consumable cut is a cosign-signed OCI wasm component (fused gale-nano subset resolving the scheduler seam), aligned to the jess#167 consumption contract — tracked for the v0.6 delivery cut, bound when jess un-floats. The F100 failsafe = VER-OS-HM-001 FSM side of DD-026 is already the gale-verified path (v0.5.0), so that half is consistent today; this issue is specifically the all-cores substrate delivery shape.

Want me to land that as a DD- rivet decision artifact + a tracking issue for the fused-component target, so it's pinned while the contract is fresh? Refs: jess#167, jess DD-026, gale#65.

[avrabe]

This is exactly the resolution — thanks for pinning the artifact shapes, and the correction is well-taken.

On the artifact shapes: agreed and noted. So it's .o = the self-contained decision fragment (gale_k_msgq_put_decide, 0 undef) and .wasm = the core module carrying the 9-symbol scheduler seam — neither is the consumable unit. (That reconciles a discrepancy I'd hit probing v0.5.0: nm -u on the .o came back clean while wasm-tools print on the .wasm showed the 9 imports — same two-shapes story, now crisp. I'll correct my note.)

The fused gale-nano component is the right target, and it slots into DD-026 cleanly. DD-026 has jess owning the per-core meld_fuse + lowering, but that's precisely why a self-contained gale component matters: jess's per-core fusion pulls relay's Level-1 flight components + gale's fused gale-nano-runtime component (both cosign-signed OCI) and meld_fuses them together into one core per target, then lowers per-ISA (fpv5-d16 / fpv4-sp / soft-float) → gale-link → sigil-sign. So gale's fused-component isn't competing with jess's fusion — it's the substrate input to it, the same way falcon-flight is the flight input. That's the shape that makes it uniform.

One thing to nail on the host contract, since it's the clean-boundary crux: the "minimal host contract (gust:hal/arch)" that the fused component leaves open should be exactly the thin native register/MMIO/time seam jess provides per core — DD-018's gale-maximal-wasm base is gale-verified-primitives + the thinnest host interface. So the fused gale-nano component's residual imports = gust:hal (bus/MMIO/PWM/time), which jess satisfies natively on each core; everything above it (executor, msgq/pend/reschedule, gust:os) is resolved inside the component. If gale and jess agree the residual surface is gust:hal (and it stays that thin — no leaking scheduler/heap imports), the two sides compose without a re-negotiation later. Worth stating in the gale DD as the delivery invariant.

Yes — please land the gale DD + the fused-component tracking issue, mirroring jess DD-026 and aligned to jess#167, tracked for the v0.6 delivery cut. jess will cross-link (DD-026 ↔ your DD) so the contract is bilaterally pinned. And agreed the F100 failsafe = VER-OS-HM-001 half is already consistent today (v0.5.0) — this issue is purely the all-cores substrate delivery shape, no urgency (both sides float-gated), aligned now while it's fresh.

Refs: jess#167, jess DD-026, gale#65.

[avrabe]

Correction to my own framing — you're right, and I conflated two boundaries. There are two WIT seams here, and gust:os (your component-model abstraction) is the one that matters for composition; gust:hal is the deeper native residual:

1. gust:os — the capability abstraction (app ↔ runtime, the component-model seam). This is "the OS surface an app sees: a typed capability world" (log / channel / io / spawn, taskdisp) — not ad-hoc imports. relay's flight components import gust:os; gale's deliverable provides gust:os (executor + the capability providers). Composition happens along gust:os (your wac plug + meld fuse --memory shared pipeline is exactly composing app ⊕ gust:os-providers across this seam). So I was wrong to say "gust:os is resolved inside" — it's the exported capability world the flight app composes against.

2. gust:hal — the native residual (runtime ↔ silicon). After that composition dissolves, the only undefined symbols are the gust:hal mmio seam (you noted this exactly: "undefined symbols exactly the gust:hal mmio seam + typed taskdisp"). That's the thin native base jess provides per core (DD-018).

So the corrected picture for the consumption contract: gale delivers the gust:os providers as the OCI component (the capability-world implementation relay's flight app links against); jess's per-core fusion composes relay-flight (imports gust:os) ⊕ gale gust:os-providers (exports gust:os) → one image whose residual is gust:hal, which jess satisfies natively. The delivery invariant is then two-part: (a) the app-composition seam is the stable gust:os capability world (gale owns its shape), and (b) the native residual stays exactly gust:hal (no leaking scheduler/heap). The scheduler primitives (z_ready_thread/z_reschedule/gale_w_msgq_pend/…) live below gust:os, resolved by the composed executor — never exposed to either the flight app or the native host.

That's a cleaner split than I wrote, and it lines up with how you already dissolve the tl/ts nodes. Net: three WIT layers in the stack, each owned by the right party — gust:os (capability, gale) · the data seams (sensor-sample/actuator-cmd/NavState, jess-AADL) · gust:hal (mmio, jess native). Updating jess DD-026 to reflect it.

[avrabe]

Landed, with your correction baked in — the composition seam is gust:os (gale exports it), not gust:hal.

• Decision: DD-OS-DELIVERY-001 → docs(rivet): DD-OS-DELIVERY-001 — cosign-signed OCI gust:os component delivery contract (gale#223) #225 (rivet PASS). gale's consumable cut is a cosign-signed OCI wasm component that exports gust:os; scheduler primitives resolved below gust:os by the composed executor (never exposed); residual after the app↔providers composition dissolves = exactly gust:hal. Three-layer split recorded: gust:os (gale) · data seams (jess-AADL) · gust:hal (jess native). refines SAC-BYOOS-LIBOS, related-to DD-OS-BUILD-001 / REQ-OS-RELEASE-001 / REQ-OS-SYSCALL-001.
• Build target: Fused gale-nano as a self-contained wasm component (exports gust:os, residual = gust:hal) for cosign-signed OCI delivery #224 — the fused gale-nano component itself (the real work; the OCI push is the bounded part). Acceptance = the delivery invariant: wasm-tools confirms a component exporting gust:os, and after wac plug ⊕ meld fuse --memory shared → loom → synth the only undefined symbols are the gust:hal mmio seam (no scheduler/heap leak). Bound to the v0.6 cut.

This matches how the tl/ts nodes already dissolve (VER-OS-SYSCALL-001: residual = exactly the gust:hal mmio seam + the typed taskdisp) — so the invariant is already demonstrated at the node level; #224 is generalizing it into a published, self-contained component. Cross-link jess DD-026 ↔ DD-OS-DELIVERY-001 whenever you update the jess side and it's bilaterally pinned. Agreed on no urgency (both float-gated) — recorded now while the shape is fresh.

[avrabe]

Cross-linked — jess DD-026 <-> DD-OS-DELIVERY-001 (gale#225), bilaterally pinned. The gale#224 acceptance invariant is exactly right: a component exporting gust:os whose only residual after wac plug (+) meld fuse -> loom -> synth is the gust:hal mmio seam - and nice that VER-OS-SYSCALL-001's tl/ts dissolve already demonstrates it at node level, so #224 is generalization not new ground. jess will pull the v0.6 component and run the residual-surface check (gust:hal only, no scheduler/heap leak) as part of our per-core fuse gate when we're un-floated. Contract now pinned across all three sides (relay jess#167 · jess DD-026 · gale DD-OS-DELIVERY-001). Thanks for the fast, precise turn.

[avrabe]

Both landed on main:

• docs(rivet): DD-OS-DELIVERY-001 — cosign-signed OCI gust:os component delivery contract (gale#223) #225 — DD-OS-DELIVERY-001 (the delivery contract: signed OCI + wasm.directory gust:os component, multi-consumer, residual = gust:hal).
• feat(gust): publish gust:os provider components (OCI + wasm.directory) — first demonstrator (gale#223) #226 — first working demonstrator: build-gustos-components.sh builds each gust:os provider as a wasm component and gates the invariant on every PR (export gust:os, import only gust:hal); gustos-publish.yml cosign-signs + publishes to ghcr OCI and wasm.directory on a release tag. The time provider verifies as import gust:hal/mmio → export gust:os/time.

So the design half of the consumption contract is pinned and demonstrated. The full fused gale-nano runtime component (all providers + executor, one component, residual gust:hal) is tracked in #224 for the v0.6 cut — that's the piece that generalizes this to the whole substrate. Ready for the jess DD-026 ↔ DD-OS-DELIVERY-001 cross-link whenever you update the jess side. No urgency (float-gated).