Railguard

A working local operations workbench for the MarketSphere build-versus-partner case. Compare infrastructure strategies, evaluate partner assumptions, exercise funding-route failures, and retain evidence of every decision.

This is a complete local decision-support and sandbox system. It does not execute real payments, connect to UPI, verify licenses, or trade financial products. All three initial providers and their operating metrics are fictional. The proposed India → US leveraged-product corridor is deliberately blocked.

Run

Requires Node.js 24 or newer. There are no npm dependencies, build steps, API keys, external fonts, or network calls required to run the application.

cd C:\Users\yokri\Desktop\marketsphere
npm.cmd start

Open http://127.0.0.1:4317. On Windows, you can also double-click start.cmd. Keep the terminal open while using the app; Ctrl+C stops the server. Subsequent starts reuse your saved workspace.

If the default port is already in use:

$env:PORT = '4318'
npm.cmd start

The app binds to 127.0.0.1 only. It is a single-operator desktop workbench, not a publicly deployable multi-user financial service. Do not proxy it onto a public network.

What works

Area	Implemented behavior
Overview	Persisted funding totals, rail health, intake capacity, reconciliation and the base-case strategy chart
Partner directory	Editable assumptions, deterministic scoring, sandbox approval states, evidence expiry, mandatory change reasons
Funding lab	Route preview, customer-verification gate, product/corridor gate, atomic capacity reservation, idempotent creation, settlement, cancellation, filtering and CSV export
Strategy studio	Month-by-month build/partner/hybrid costs, growth, launch timing, payback, outage exposure and saved scenarios
Incident room	Offline/degraded rail isolation, fallback for new requests, retained pending requests, documented recovery
Evidence	Hash-linked audit events, per-transfer ledger reconciliation, full JSON export and independent verification

Walk through the project

1. Funding lab: create a $2,500 sandbox request. Atlas wins on eligible score. Click Settle; the ledger records clearing −$2,500, customer balance +$2,478.75 and fees +$21.25.
2. Incident room: open an offline incident on Atlas. Return to the funding lab and create another request. Harbor is selected. Pending Atlas requests remain on Atlas; they are not silently rerouted.
3. Take Harbor offline too. A new request is blocked: the higher-scoring owned rail is still unapproved. Resolve the incidents with recovery notes.
4. Choose India → US leveraged products in the funding form. The product/corridor policy blocks it regardless of partner approval.
5. Strategy studio: change the assumed launch month from 12 to 18 and recalculate. Save the scenario. The model does not assume that hybrid is automatically cheaper.
6. Evidence & audit: verify the chain and export the JSON. The workspace retains your actions after refreshing or restarting.

See the demonstration guide for a concise presentation flow.

Data and backups

The first run creates data/railguard.sqlite. It contains partners, transfers, balanced ledger postings, incidents, scenarios and audit events. There is no reset button that can erase evidence accidentally.

npm.cmd run backup

This uses SQLite's backup API to make a consistent snapshot, including while the server is running. A timestamped file is created under data/backups/; existing backup targets are never overwritten. To use a backup as a separate workspace, stop the app, set RAILGUARD_DB to the backup's absolute path, then start the app. Copy that backup first if you want the original backup to remain immutable.

To start an isolated clean exercise without changing your current database:

$env:RAILGUARD_DB = "$PWD\data\exercise-02.sqlite"
$env:PORT = '4318'
npm.cmd start

Paths set through RAILGUARD_DB can be absolute or relative to the current working directory. The default path is always resolved relative to the project root.

Verify

npm.cmd run check
npm.cmd test
npm.cmd run verify-evidence -- "C:\path\to\railguard-evidence-2026-09-21.json"

Optionally pass a separately retained SHA-256 audit head as a second argument to the verifier. Exit code 0 means the audit chain and ledger reconcile; exit code 1 means a mismatch or invalid input. The JSON verifier checks the full audit chain, not only the 200 events visible in the UI.

Tests create isolated in-memory or temporary databases. They never clear or modify the normal workspace. See validation, architecture, and API contract.

Boundaries that matter

• Sandbox approval is a local setting, not a regulatory finding. This project makes no claim about MochaTrade's actual authorizations or payment arrangements.
• The supplied deck's proposed PA-CB solution is not treated as proof that the underlying leveraged activity is permitted. The source register in the app explains this distinction.
• No customer identity documents, bank credentials, wallets or actual money are needed. Use fictional references only.
• Economic inputs are assumptions. Costs exclude tax, regulatory capital, approval probability, FX, loss of customers and discounting. Build-only sacrifices all prelaunch volume. See the exact formulas in the architecture notes.
• Audit hashing detects inconsistency, but a database administrator could rewrite the entire local chain. Retain exports and audit heads independently; this is not an immutable external audit service.
• A real deployment requires independently validated product legality, provider integrations, authentication and authorization, durable job processing, webhook verification, external reconciliation and operational review. Those capabilities are not represented as complete here.