Sandbox — pre-deploy validation
Rules are tested before they reach the ledger.
Mistakes never become audit records.
When Orchestrator rules change, Sandbox runs them against synthesized events that mirror production patterns. If a rule misbehaves — releases too aggressively, fails too conservatively, fires under wrong conditions — Sandbox catches it before the rule reaches production. Mistakes never become Confidential Ledger entries.
What it does
Rules tested before activation
Every Cascade rule update flows through Sandbox first. Synthesized events that mirror production patterns get evaluated against the new rules. If outcomes look wrong, the change is blocked.
Simulates production patterns
Sandbox uses anonymized historical event traces + edge cases. Tests cover the long tail: weird waiver counts, boundary G702 math, COI lapses, mixed-state sub-stacks.
Errors don't reach prod
If Sandbox detects a regression — releases firing when they shouldn't, or stalling when they should fire — the deployment halts. The ledger never receives the bad release.
How it works
Compares old vs new
Sandbox runs the same synthetic events against the OLD rule and the NEW rule, producing a side-by-side outcome diff. Operators see exactly what changes.
Builds up over time
Every production incident becomes a Sandbox test case. Once a class of failure is caught, it can never happen again — the test runs every deploy.
Tests within Cascade limits
Sandbox respects the same authority limits as production. A Council-restricted rule can't be tested by an operator without Council approval.
Tests land on the ledger too
Sandbox runs are themselves audit-recorded. You can prove later that a rule was tested before deployment.
Related
Council
Council is the governance layer that authorizes rule changes. Sandbox is the safety net that validates them.
See Council →Diagram
Talk to us about Trust Spine.
Wave 1 design partners get pricing certainty + product shaping + first-mover position on the network.