Setting assurance levels and entitlements on a capability
Every capability declares a floor: how sure the platform must be of who's asking, how sensitive the data is, and any extra entitlement check beyond identity alone.
Two policy fields on every capability decide who may ever reach it, independent of whatever a rule engine or a flow later adds on top: required assurance and sensitivity.
Required assurance: how sure the platform has to be
The five levels — A0 through A4 — run from anonymous up through progressively stronger proof of identity. A capability declares its own floor, and a tenant's binding of that capability may raise the requirement further, but it can never lower it. That direction only ever moves one way, and it's enforced structurally rather than left to a reviewer to notice a binding trying to relax it.
Assurance is resolved from the session and its token — it is never something a message's own text can supply. There's no code path anywhere in this platform where an identity or an assurance level arrives from the caller and is trusted; if the form here has no field for it, that's the point, not an omission.
Sensitivity: what happens to the data around this capability
Seven classes, from Public up to SpecialCategory, cover retention, whether the value may ever reach a language model's context, and whether a staff member's view of it gets logged. A field left unclassified always resolves to the strictest handling available, not the loosest — so declaring this honestly, even conservatively, never makes anything less safe than leaving it unset would.
Entitlement: a check beyond "who are you"
Assurance answers "how sure are we this is really them." Entitlement answers a separate question: "are they specifically allowed this." Leave it blank for a capability with no additional check beyond identity; name it when there's a real, named permission a resident or a binding needs beyond simply being who they say they are.
Write capabilities are stricter by construction, not by choice
For a Write capability, requires confirmation isn't a switch you set — the aggregate forces it on regardless of what the toggle shows, and the form states the rule rather than pretending it's a preference. Every write in this platform runs through a confirmation turn and an idempotency window for exactly the same reason: nothing here ever acts on a model's say-so alone, and nothing ever runs twice by accident.
When you're unsure which assurance level a new capability needs, start from what it returns rather than what it's called: a capability that returns a resident's own financial balance needs meaningfully more assurance than one that returns a public opening-hours schedule, whatever the two capabilities happen to be named.