Move 1By email
Request a key
At launch, on this page. Until then, email info@admissiblelabs.com with the subject “Sandbox access” and we will contact you when keys open. Keys are individual, rate-limited, and revocable.
Send it an action. Keep the receipt.
The sandbox is an isolated instance of the governance kernel, loaded with synthetic industry packs, driven over an API. You submit a sample action; it answers allow, hold or refuse; the answer comes with a signed receipt you can check without us.
The API
Three moves. At capability level.
The request and response formats publish with the keys. What follows is what the sandbox does, not how to call it.
Move 2Over the API
Submit a sample action
A proposed action — a payment, a message, a data export — addressed to a synthetic industry pack.
The kernel puts it through the same discipline it applies everywhere: every action it governs is checked before it executes, and an action that fails its checks does not execute.
Move 3Yours to keep
Read the verdict, keep the receipt
Allow, hold, or refuse, with the failing checks named on a refusal. Every governed action is sealed in a signed, tamper-evident record.
That record verifies offline, without access to our systems.
Determinism
Run it again. And again. The sandbox exists so you can test the sentence yourself rather than take it from us.
Same input, same verdict, every time. Submit the same action a hundred times and count the distinct verdicts.
An industry is a configuration file, not a codebase: the sandbox's packs are synthetic ones built for evaluation, and at boot the governance layer recomputes each pack's rule digest and refuses to serve if it does not match.
Posture
The boundaries. Built as if it will misbehave.
A demonstration environment earns no benefit of the doubt.
Its own instance
The sandbox is a kernel instance of its own, loaded only with synthetic packs, with no route to any other system.
Underneath, the platform’s isolation is not a courtesy: tenant isolation is enforced in the database itself and attacked by our own adversarial suite in CI.
No personal data
The sandbox accepts no personal data and its packs contain none. Do not send real records, real names, or anything confidential. Synthetic data only — the terms make that a condition of access, not a request.
Rate limits and a kill switch
Every key is rate-limited. We hold a kill switch and will use it without ceremony if the sandbox misbehaves or is abused. Losing a key costs an email; losing the environment’s integrity costs the point of having one.
Fail-closed, here too
When the governance layer cannot decide, the action is refused, not waved through.
The sandbox does not carry a friendlier setting for visitors. There is one failure mode and it is closed.
It will not start unwell
The kernel will not serve at all if its own checks cannot be discharged at start-up.
If the sandbox is down, that may be why. Down is a state we prefer to wrong.
Not a service
The sandbox is for evaluation. It carries no availability commitment, may change without notice, and is not something to build against. It demonstrates behaviour; it is not infrastructure.
Terms
The terms, summarised. A courtesy summary. Where this summary and the terms differ, the terms win.
Use
Evaluation only. No load testing beyond your rate limit, no probing of the environment itself, no resale or sharing of keys.
Data
Synthetic data only. No personal data, no real case records, no confidential material of yours or anyone else’s.
Keys
Individual, rate-limited, revocable at our discretion. The environment may be changed, suspended, or withdrawn at any time.
Verdicts
Sandbox verdicts are demonstrations against synthetic rules. They are not advice, and they say nothing about any real obligation of yours.
Start here
Want a key when they open?
Email us with the subject “Sandbox access”, or watch the kernel decide on the console first.