Onboarding presets
The eleven presets, their configuration schema, the detector set each puts in play, and the perimeter each declares.
Preview is a separate capability
/v1/onboarding/preview answers exactly what apply would do and changes nothing, behind a lower capability. An operator can explore the whole configuration surface without being able to commit it.
- GET /v1/onboarding/catalogue
- POST /v1/onboarding/preview
- POST /v1/onboarding/apply
Every preset declares a perimeter
The output is three lists: what was configured, which detectors are in play, and where the boundary sits. The third is not a caveat. It is the contract term your auditor will ask for, and it is produced by the preset itself rather than written by marketing.
Some defaults are refusals
A bridge asset declared with a destination side and no source side is rejected at onboarding. Left configured, every legitimate mint looks unbacked, the rule fires continuously, and somebody mutes it. A rollup asking for pre-inclusion screening already armed to exclude is refused the same way, and so is a wallet declaring a protected domain on a shared host, where the label that would be protected belongs to the platform. A configuration that predictably ends in a disabled control is not conservative, it is broken.
Where the boundary sits.
In the same type as everything above it, and paired with the control that covers it. This is the part your auditor reads first.
Put Onboarding presets on your perimeter.
Engine-level detail and the full catalogue are provisioned with your engagement, alongside the console your team works in.