Problem
Phase 5 of the C-LEARN residual work wired simlin-cli to resolve Vensim GET DIRECT * external-data references via a FilesystemDataProvider rooted at the model file's parent directory (commit 99b8e5c4). That fix is filesystem-based and therefore native-only.
WASM and the default libsimlin/JS open paths remain on the null DataProvider (open_vensim / simlin_project_open_vensim), so a browser/WASM caller importing a model with GET DIRECT DATA/CONSTANTS/LOOKUPS/SUBSCRIPT still gets the hard external data file '...' referenced but no DataProvider configured error -- there is no way for such a caller to supply the external CSV/data bytes.
libsimlin already exposes simlin_project_open_vensim_with_data (src/libsimlin/src/project.rs:577), but it builds a FilesystemDataProvider from a data_dir, which is unavailable in a sandboxed WASM/browser context.
Why it matters
No browser/WASM consumer can supply external data for a GET DIRECT * model, so importing such models in the browser/WASM build fails outright. This is a forward-looking feature gap, not a regression: the native CLI now works via the filesystem provider.
Proposed work
Design and add a data-supply surface for non-filesystem callers: a way to pass in named data blobs (e.g. a caller-provided map of filename -> bytes, or a callback DataProvider the FFI/JS layer can implement) so WASM/browser consumers can resolve GET DIRECT * references without a real filesystem.
The right shape of this API (in-memory provider vs. host callback; FFI vs. JS-side) is its own design question and was explicitly out of scope for Phase 5. Keep the FFI surface small and orthogonal per the libsimlin API-design guidance (no bulk/batch variants).
Components affected
src/libsimlin (src/project.rs -- the open_vensim / open_vensim_with_data FFI surface)- WASM / JS open paths (
@simlin/engine)
Out of scope (tracked separately)
Other native callers still on the plain open_vensim are out of scope here:
- pysimlin
- simlin-serve (
parse.rs:59)
- simlin-mcp-core (
open.rs:129)
Context
Identified as the AC5.4 follow-up from Phase 5 of the C-LEARN residual work, which delivered the filesystem-based provider for simlin-cli (commit 99b8e5c4). Distinct from #555, which tracks supplying external data for one specific test model (metasd COVID) to make it simulation-tier-eligible in the macro corpus harness; that issue does not cover the WASM/FFI data-supply API gap.
Problem
Phase 5 of the C-LEARN residual work wired
simlin-clito resolve VensimGET DIRECT *external-data references via aFilesystemDataProviderrooted at the model file's parent directory (commit99b8e5c4). That fix is filesystem-based and therefore native-only.WASM and the default libsimlin/JS open paths remain on the null
DataProvider(open_vensim/simlin_project_open_vensim), so a browser/WASM caller importing a model withGET DIRECT DATA/CONSTANTS/LOOKUPS/SUBSCRIPTstill gets the hardexternal data file '...' referenced but no DataProvider configurederror -- there is no way for such a caller to supply the external CSV/data bytes.libsimlin already exposes
simlin_project_open_vensim_with_data(src/libsimlin/src/project.rs:577), but it builds aFilesystemDataProviderfrom adata_dir, which is unavailable in a sandboxed WASM/browser context.Why it matters
No browser/WASM consumer can supply external data for a
GET DIRECT *model, so importing such models in the browser/WASM build fails outright. This is a forward-looking feature gap, not a regression: the native CLI now works via the filesystem provider.Proposed work
Design and add a data-supply surface for non-filesystem callers: a way to pass in named data blobs (e.g. a caller-provided map of
filename -> bytes, or a callbackDataProviderthe FFI/JS layer can implement) so WASM/browser consumers can resolveGET DIRECT *references without a real filesystem.The right shape of this API (in-memory provider vs. host callback; FFI vs. JS-side) is its own design question and was explicitly out of scope for Phase 5. Keep the FFI surface small and orthogonal per the libsimlin API-design guidance (no bulk/batch variants).
Components affected
src/libsimlin(src/project.rs-- theopen_vensim/open_vensim_with_dataFFI surface)@simlin/engine)Out of scope (tracked separately)
Other native callers still on the plain
open_vensimare out of scope here:parse.rs:59)open.rs:129)Context
Identified as the AC5.4 follow-up from Phase 5 of the C-LEARN residual work, which delivered the filesystem-based provider for
simlin-cli(commit99b8e5c4). Distinct from #555, which tracks supplying external data for one specific test model (metasd COVID) to make it simulation-tier-eligible in the macro corpus harness; that issue does not cover the WASM/FFI data-supply API gap.