What's shipped, what's next
An honest accounting of the platform's state — including the things we explicitly haven't built yet, and why.
Shipped
1700+ deterministic physics checks across 21 domains
Shippedcore/physics_validator.py — the full engine, live on the deployed site via the self-hosted Python backend.
Honest, reproducible benchmarks
Shipped5-seed, randomized-corruption benchmark with a naive-baseline comparison and a published methodology page — see /benchmark.
Mann-Kendall + sliding-window sensor drift detection
ShippedPushed corruption recall from 55% to 71% on the harder, randomized benchmark.
Multi-phase AI orchestrator
ShippedDataset profiling → physics checks → pattern recognition → targeted follow-up probes → synthesis, via OpenRouter.
Automatic repair layer
ShippedDeterministic, reversible fixes (duplicate rows, IDs, timestamp ordering, wrapped angles, short NaN gaps) with a preview before anything is applied.
Multi-format ingestion
ShippedCSV, JSON, YAML, TOML, TXT, Markdown, VTK, NumPy, and OpenFOAM all normalize into one internal schema.
Pre-flight mesh/setup validation
ShippedPredicts likely output-check failures before a simulation runs, with plain-English explanations and config-specific fixes.
CLI parity across Python and Node
Shippedlogin, validate, watch, doctor, explain, repair, api-key, config, usage — identical behavior in both implementations.
Dashboard: Analytics, Logs, Request Inspector
ShippedAll backed by real captured validation runs from this browser — no seeded or synthetic data.
Hybrid TypeScript/Python engine on the deployed site
ShippedPYTHON_API_URL points the deployed site at the self-hosted Render backend, so the playground and API run the full 1700+ check engine. Falls back to a ~20-check TypeScript engine only if that backend is unreachable. The engine badge in the dashboard tells you which one you're getting.
In progress
One-click Python backend deployment
In progressrailway.json and render.yaml exist; still validating the one-click flow end-to-end on both platforms.
Planned
Durable job storage
PlannedValidation jobs are currently in-memory on the API server. A real queue + persistent store is needed before this can run as a production service with restart safety.
Organizations, projects, and RBAC
PlannedToday's auth model is single-user (a real, password-hashed local browser session). Multi-user orgs need a real backend data model — not on the roadmap until there's a durable store to build it on.
Billing
PlannedNo payment provider is integrated. We won't add a fake pricing/billing UI before there's a real Stripe integration behind it.
Webhooks
PlannedEvent delivery for validation completion, once job storage is durable enough to guarantee at-least-once delivery.
Plugin rule system
PlannedLet users register custom physics checks without forking core/physics_validator.py.