Find every check you already have.
Nobody adopts an enforcement layer on a greenfield service. They adopt it on a system with fifteen years of role checks, authorization handlers and hand-rolled conditionals — most of which nobody can currently enumerate.
1. What this enforces
Nothing during migration, and that is the point: discovery is read-only. The tooling inventories what authority the codebase currently asserts and where, then proposes an equivalent expressed in B5’s model.
2. Where it enforces
Across the codebase, not the running system. The output is a map of existing checks — roles, handlers, policy attributes and custom conditionals — and the protected operations that have none.
3. What evidence it produces
A before-and-after coverage report. The valuable artefact is not the converted code; it is the list of operations that were never protected at all, which is usually longer than anyone expects.
4. Why you cannot assemble this from what you already own
A migration done by hand converts the checks that are easy to find and silently omits the ones that matter. There is no way to be sure you found them all by reading, which is exactly the argument for the analyzers.
5. What Q4 2026 adds
Migration Discovery and Conversion Tooling
Inventory legacy authorization and generate B5 migration mappings, risks and remediation tasks.
6. Acceptance criteria
The specification defines this capability against the three baseline criteria that apply to every Q4 2026 extension — documentation with failure modes and a runbook, automated coverage of primary and abuse cases, and telemetry that emits evidence without exposing prohibited data. Capability-specific criteria have not been written yet, and this page will state them when they are rather than inventing them now.
- The capability is documented with configuration, failure modes, security implications and an operational runbook.
- Automated unit, integration, negative and regression tests cover the primary and abuse cases.
- Telemetry and audit evidence are emitted without exposing prohibited sensitive data.
7. What is still open
The following are genuinely undecided rather than merely undocumented, and each one changes what the capability is:
- Whether conversion is applied automatically or always proposed for review. Automatic rewriting of authorization logic is a category of risk that needs an explicit decision.
- How semantic equivalence is demonstrated for a converted check — a test, a shadow evaluation, or both.
- How a partially migrated system behaves while both mechanisms are live.
Every Q4 2026 extension is also held to four platform-wide requirements, six test classes and four release gates. They are published once, on the Q4 2026 roadmap, rather than repeated on every page.
Talk to a human.
Get architecture guidance, Test Mode access, integration review, or help choosing the right B5 identity and authorization pattern.