Start Here
Copy page
Sandbox Walkthrough
The intended first-value path for a new Parametrig operator workspace.
Parametrig should be approached as a sandbox-first system.
The first operator goal is not to switch to live immediately. It is to prove the end-to-end lifecycle in rehearsal conditions first.
First-Value Sequence
create sandbox key
-> connect or inspect sandbox webhook delivery
-> run and save a simulation artifact
-> verify event -> claim -> payout proof
-> cross the live boundary explicitly
Step 1: Create A Sandbox Key
Issue an operator-scoped key for sandbox first.
That keeps early integration work, event replay, and delivery verification out of the live operating path.
See:
Step 2: Prove Delivery In The Sandbox Inbox
Before you wire a live endpoint, use the first-party sandbox inbox to confirm what Parametrig would actually deliver.
That means:
- the payload shape is visible
- retries and failures are inspectable
- event semantics stay aligned with the public contract
See:
Step 3: Save A Simulation Artifact
The simulation surface is part of onboarding, not just later commercial analysis.
Use it to:
- size the initial program shape
- save the first scenario artifact
- create a shared reference point for the workspace before moving toward live activation
See:
Step 4: Verify The Lifecycle Story
The onboarding proof should cover the whole contract story in non-final terms:
- event arrives
- policy context is understood
- claim posture is visible
- payout behavior is explainable
The sandbox walkthrough is successful when the workspace can explain that lifecycle clearly before any live dependency is introduced.
Step 5: Cross To Live Deliberately
live is an explicit operating boundary.
Do not treat it as the default just because the integration exists.
The expected posture is:
- sandbox first for a new or still-pending workspace
- explicit activation later
- once a workspace is already active in live operation, it should not be forced to start from sandbox again on every new session or browser