Sandbox Approval Detail
A detailed sandbox request for one concrete use case, with declared purpose, expected traffic band, and operator checklist.
The detail page should show the actual approval state before the team starts waiting on email threads.
Projected protected usage should remain visible on the request itself.
The operator should know exactly what is still preventing sandbox approval.
That gives reviewers enough context to decide whether the request belongs in sandbox, needs scope changes, or is not ready yet.
That keeps sandbox approval from becoming a black-box queue.
That is what makes sandbox approval feel like part of one smooth operator path.
{
"request_id": "sbx_req_workforce_vetting",
"declared_purpose": "workforce_vetting",
"expected_lookup_band": "2k_to_5k_monthly",
"request_state": "under_review",
"blocking_checks": ["billing_owner_confirmed", "webhook_target_declared"]
}Sandbox detail should keep the request context and blocking checks visible all the way through approval.
The request purpose should stay visible throughout the sandbox approval lane.
Expected protected usage belongs on the request detail page, not hidden in intake notes.
The operator should know exactly what still prevents approval.
Sandbox approval should show the actual use case, why the organization wants protected HRS access, and what the expected lookup band looks like before approval is granted.
That gives reviewers enough context to decide whether the request belongs in sandbox, needs scope changes, or is not ready yet.
The detail page should make the requesting technical owner, billing owner, and reviewing owner visible, along with the exact checklist items still blocking approval.
That keeps sandbox approval from becoming a black-box queue.
Once approved, the workspace should be able to move directly into project setup, key issuance, and the first protected lookup without re-entering the same use-case details.
That is what makes sandbox approval feel like part of one smooth operator path.