Authorization
Read the status first: authorization is preview in 0.2.0. The boundary is
real and you can watch it work in the tutorial. It is not a finished, supported
feature, and it is not a customer-ready authorization service. Don’t build a
delivery date on it.
What you can do today is run the prepared exercise with known accounts and memberships and watch the wrong person get turned away.
Gate G9 — required implementation. Customer-facing activation and receipts still have to be built and rehearsed. Until then they are not available, in any environment.
The rule that matters: authorization is applied first, before filters, ordering, pagination, counts, facets, cursors, joins, nested reads, and disclosure.
That ordering is what stops the usual leaks. You cannot get at a hidden object by sorting differently, by paging past it, or by reaching it through a nested field — it was removed before any of that ran.
The corollary catches people out: an empty result is a legitimate answer. If you are allowed to ask the question and nothing is visible to you, you get nothing back, and that is a correct, recordable result — not an error and not a bug.
A receipt records a decision and where it came from, in a form safe to keep. Read it alongside the result and the events. An item missing from a UI is not proof that it was denied; the receipt is.
Turning authorization on for a customer is future work, not a command you can run. During this release, use the fixed configuration and the prepared exercise.
For the record, here’s what any future activation has to do before anyone calls it usable: validate an immutable revision, swap it in only if the predecessor is still the one it expects, and write the receipt — all before reporting success. That is the bar, and it isn’t cleared yet.
Next: Fixtures and visibility for the exercise itself, and Audit Evidence for what to keep afterwards.