[Learning]: Add policy simulation and change-impact lab

[cdcavell]

Requested content type

Hands-on lab

Learning problem

Learners now have material explaining how to test current policy behavior, but they also need to understand how to simulate a candidate policy against representative historical or synthetic contexts before rollout.

Create a hands-on lab tentatively titled:

Policy Simulation and Change-Impact Analysis

The lab should give learners an existing policy, a proposed replacement, and a set of representative policy contexts.

The learner should run both policy versions against the same contexts and compare the resulting decisions.

For example:

Recorded / synthetic contexts
 │
 ┌────┴────┐
 ▼ ▼
 Policy v1 Policy v2
 │ │
 ▼ ▼
 Decisions Decisions
 └────┬────┘
 ▼
 Difference report

The central lesson should be:

Policy simulation asks what would change before the new policy becomes authoritative.

Simulation must not itself execute real-world side effects.

Why this would be useful

Milestone 8 lists Policy simulation as an unfinished subject.

The repository recently established a strong policy-testing foundation, including decision tables, boundary testing, regression behavior, policy-version evidence, and execution-boundary invariants.

Simulation is the natural next step.

Testing asks:

Does this policy behave as specified?

Simulation additionally asks:

If we deploy this candidate policy, which decisions would change?

That distinction matters for policy changes involving:

• New deny rules
• New escalation requirements
• Changed acknowledgment thresholds
• Regional overlays
• Tenant overrides
• Changed risk thresholds
• New precedence rules
• Rollback decisions

A lab can make those differences observable without turning Learning into a full policy-management product.

Suggested difficulty

Intermediate

Concepts or architectural boundaries to cover

The lab should teach learners to:

• Define a baseline policy version.
• Define a candidate policy version.
• Build representative deterministic policy contexts.
• Replay identical contexts against both policies.
• Capture structured decisions.
• Compare outcome differences.
• Compare reason-code differences.
• Compare contributing policy identities.
• Detect newly denied operations.
• Detect newly allowed operations.
• Detect new acknowledgment requirements.
• Detect new escalation requirements.
• Identify unchanged cases.
• Summarize change impact.
• Distinguish expected changes from regressions.
• Include boundary contexts, not only happy paths.
• Model regional or tenant overlays where practical.
• Preserve deterministic test inputs.
• Avoid invoking protected executors during simulation.
• Treat simulation data as potentially sensitive.
• Explain historical-data versus synthetic-data tradeoffs.
• Avoid assuming historical traffic represents every future case.
• Explain that simulation does not prove production safety.
• Record candidate policy identity/version.
• Connect simulation results to rollout and rollback reasoning.

A required architectural invariant should be:

Simulation mode
 ↓
Policy evaluation occurs
 ↓
Decision evidence produced
 ↓
Protected executor invocation count = 0

The lab should ideally include at least one initially surprising result.

For example:

Policy v1:
Protected resources require acknowledgment.

Policy v2:
Protected resources require escalation.

Simulation should expose that a meaningful percentage of representative requests change from:

AcknowledgmentRequired

to:

EscalationRecommended

before the candidate policy is deployed.

The lab should conclude by having the learner decide whether to:

Roll forward
Revise candidate policy
Run additional simulation
Stage rollout
Abandon change

without implying that the simulation engine itself makes the deployment decision.

Related Learning or implementation material

• ROADMAP.md — Milestone 8 / Governance and Policy Architecture
• docs/governance/constraint-composition-and-policy-precedence.md
• docs/governance/policy-versioning-and-decision-provenance.md
• docs/governance/practical-policy-testing-and-decision-table-strategies.md
• docs/advanced/regional-and-tenant-policy-overlays.md
• docs/tutorials/policy-context-and-explicit-decision-outcomes.md
• Existing governance-oriented labs under docs/labs/
• Existing invariant tests under samples/
• Relevant AsiBackbone/AsiBackbone policy evaluation abstractions where useful as working references.

Once added:

• Include the lab in docs/labs/toc.yml.
• Add it to the labs index.
• Cross-link it from Practical Policy Testing and Policy Versioning.
• Update ROADMAP.md to mark Policy Simulation complete when the acceptance scope is satisfied.

Pattern classification

General learning material

Submission checks

• I searched existing Issues and current Learning material for this topic.
• This request is concrete enough to track as work rather than only an open-ended architecture question.