Simulation

Purpose

Simulation evaluates candidate policy setup against replay-derived baseline material.

Use Simulation when a customer wants to compare a candidate policy change against a known baseline execution before making customer-owned lifecycle decisions.

When To Use It

Use Simulation when:

• A valid replay_reference is available.
• The customer has candidate policy setup to evaluate.
• The customer needs baseline and candidate outputs before deciding whether to promote, reject, revise, or investigate a candidate change.

Request Boundary

Simulation requires:

• replay_reference.
• candidate_policy_setup.

Candidate policy setup uses the same policy setup shape and rule syntax as Governed Execution. Customer systems own the meaning, versioning, and lifecycle status of the candidate policy.

Response Evidence

A successful simulation response may include:

• Status.
• replay_reference.
• Baseline outcome.
• Simulated outcome.
• Comparison summary.
• Candidate policy identity.
• Bounded errors.

Simulation evidence is runtime output. It is not approval, promotion, rollback, release, or experiment assignment state.

Customer Responsibilities

Customers should:

• Store simulation outputs or references in customer-controlled systems where needed.
• Preserve the candidate policy identity and version.
• Decide how candidate output affects review, release, experiment, reporting, or CI/CD workflows.

Boundary

Simulation does not expose baseline or candidate internal execution material, replay internals, filesystem paths, logs, tracebacks, module names, or FoxCore internals.

Next Step

Use Comparison when structured baseline-versus-candidate evidence is needed.