Know what a policy change does before it decides.
The most expensive authorization incidents are not the denials that should have been permits. They are the permits nobody predicted. Simulation exists so a change can be evaluated against real traffic before it has any effect.
1. What this enforces
Nothing — deliberately. In shadow mode a candidate policy is evaluated alongside the policy in force, and only the policy in force decides. The candidate’s decisions are recorded and compared.
2. Where it enforces
At the same enforcement points as production decisions, so the simulation sees the same caller, the same record, the same purpose and the same aggregate state. A simulation that runs anywhere else is testing a different question.
3. What evidence it produces
A decision difference report: which requests would change outcome, in which direction, for which principals and which records. Replay against a historical window answers the same question about traffic that has already happened.
4. Why you cannot assemble this from what you already own
A staging environment does not have production’s data, principals or aggregates, so it cannot tell you which of your actual users would lose access on Tuesday. An external policy engine can dry-run its own rules but does not see the in-process context B5 enforces on.
5. What Q4 2026 adds
Policy Simulation, Shadow Mode and Historical Replay
Evaluate candidate policies against live or recorded traffic without enforcement and report decision differences, impact and root cause.
6. Acceptance criteria
These are the conditions the capability must satisfy to be considered complete. They are quoted from the specification rather than paraphrased, because an acceptance criterion that has been reworded is no longer the criterion.
- Shadow decisions cannot affect production responses. MF-002
- Replay reports identify false allows, false denies and affected transactions. MF-002
- Candidate policy evaluation is reproducible against a fixed evidence dataset. MF-002
7. What is still open
The following are genuinely undecided rather than merely undocumented, and each one changes what the capability is:
- The retention window for shadow decisions, and whether shadow evidence is held to the same standard as production evidence.
- Whether replay is bounded by the evidence retention period or by a separate simulation store.
- How a difference report is scoped so it is readable — by principal, by resource, or by reason code.
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.
The decision difference, on the pull request
Shadow evaluation answers “what would this policy do?”. Continuous integration answers “is this policy valid?”. Neither answers the question a reviewer actually has, which is “what breaks if I approve this?”
So the difference report goes where the change is reviewed. A pull request that alters authority receives a comment stating how many decisions would change, in which direction, for which principals and which record classes — evaluated against real traffic rather than a staging environment that has none of your data.
A policy review that reads the diff is reading the rules. A policy review that reads the decision difference is reading the consequences.
Status: Q4 2026 Roadmap Extension