Gap (2) of #273: rule on the verisimdb-via-SNIF boundary (A / B / C)

[hyperpolymath]

Context

Epic #273 gap (2): "store is local flat files, not a private verisimdb via snif (snif boundary is pure aspiration; freestanding-wasm cannot reach verisimdb -- architectural gap)".

Audit produced a decision-ready memo, committed in-tree as docs/architecture/boundary-design-options.adoc (see open PR -- linked at bottom).

The hard finding (decision driver)

The naive target chain VCL → SNIF → verisimdb cannot be built as stated:

1. SNIFs are wasm32-freestanding with zero imports -- no filesystem, no network, no clock. WASI is listed as unspecified future work in snifs/docs/whitepapers/academic/snif.tex (~639-644).
2. verisimdb has no octad/VCL-native embeddable surface a freestanding guest could use; verisim-nif is currently a placeholder (returns {"status":"nif_placeholder"}).
3. The conformant VCL parser is ReScript + Idris2 (vcl-ut); there is no conformant Elixir or Zig parser anywhere in the estate.

Any viable architecture must either (a) keep the DB hop host-side, (b) upgrade the SNIF to WASI, or (c) drop the SNIF from the data path.

Decision request

Rule on one boundary question:

Does the VCL parse+typecheck stage run inside the SNIF sandbox (A), inside the SNIF with WASI I/O so it can also reach the DB (B), or in-process in Elixir with no SNIF on the data path (C)?

	A -- Split (RECOMMENDED)	B -- WASI SNIF	C -- No SNIF on data path
SNIF used for VCL safety	Yes (pure check)	Yes (+ I/O)	No
Impossible wasm→db hop avoided	Yes (host-side DB)	N/A (WASI grants I/O)	Yes (no SNIF)
verisim-nif prerequisite	Required (M)	HTTP/gRPC real instead (≥M)	Required (M)
Parser work	Idris2-spec → Zig SNIF (M-L)	A's parser + guest DB client (L)	Idris2-spec → Elixir (M-L), non-conformant
Safe-boundary property kept	Yes	Weakened (guest gets I/O)	Lost for VCL
Effort tier	L	L+	M
Time-to-first-store	Medium	Slowest	Fastest

Secondary ruling (only if A or B): confirm parser strategy -- port the Idris2 core to a wasm32-freestanding Zig SNIF, differential-tested against the ReScript reference. (Recommended.)

What ruling unlocks

• A: verisimdb-side verisim-nif real implementation + private-instance lifecycle, then hypatia-side Idris2→Zig SNIF parser port + boundary module + verisim_connector.ex re-target.
• B: all of A's hypatia-side work plus WASI binding spike in wasmex plus in-guest verisimdb client.
• C: verisimdb-side verisim-nif real implementation, then Elixir VCL parser/checker port from the Idris2 spec; no SNIF on the data path.

Out of scope

• The verisim-nif real implementation is verisimdb-side work and should be tracked there once a ruling lands.
• This issue only asks for a ruling, not for an immediate build. Build issues spin off afterwards.

Companion PR

docs(arch): add boundary-design-options.adoc (#273 gap 2, decision-ready) -- adds the full memo to docs/architecture/. (PR link will be posted in this issue once opened.)

Parent: #273.

[hyperpolymath]

Status — 2026-05-25

Decision memo extending docs/architecture/boundary-design-options.adoc is now committed at:

docs/operations/issue-294-boundary-recommendation.adoc (via PR #314, moved into docs/operations/ by PR #315).

Recommendation: Option A — Split (SNIF for VCL parse+typecheck only; host-side NIF for the DB hop).

Three reasons summarised:

1. SNIF moat is worth keeping. wasm32-freestanding with zero imports is the security property; Option B trades it away for I/O capability we already have host-side.
2. verisim-nif real implementation is unavoidable in all three options — Option A/B/C all need it, so the cost is equivalent.
3. Parser port to Zig SNIF is bounded (~2–3 person-weeks, differential-tested against ReScript reference). Option C's "port to Elixir" is the same scale but loses the SNIF moat.

If ruling lands as A, two follow-up milestones get opened:

• M19 — verisim-nif real implementation (verisimdb-side work).
• M20 — Idris2 → Zig SNIF parser port (hypatia-side work).

If B or C, the memo's "If you pick B/C" sections describe the alternate work plan.

Still open — awaiting ruling. Reply on this issue with Decision: A, Decision: B, or Decision: C to commit.

---

Generated by Claude Code

[hyperpolymath]

Decision: A — split. M19 + M20 to be opened.

Per the recommendation memo at docs/operations/issue-294-boundary-recommendation.adoc (committed 2026-05-24) and the design memo at docs/architecture/boundary-design-options.adoc. Owner ruling 2026-05-27.

The SNIF performs VCL parse + typecheck only (pure computation, zero imports kept). The VCL → DB hop runs host-side via verisim-nif. Idris2 reference in vcl-ut stays canonical; the Zig SNIF port differential-tests against it.

Unlocked work:

• M19 — verisim-nif real implementation (verisimdb repo): M19: verisim-nif real implementation (host-side, replaces nif_placeholder) [hypatia#294 unlock] verisimdb#61
• M20 — Idris2 → Zig SNIF parser port (this repo) with verify/ differential-test rig: M20: Idris2 → Zig SNIF parser port + verify/ differential-test rig [hypatia#294 unlock] #367

Closing this issue as ruled. M19 + M20 are the execution trackers.

[hyperpolymath]

Ruled A (split). Tracking unlocked work at hypatia#367 + verisimdb#61. Closing.