> ## Documentation Index
> Fetch the complete documentation index at: https://developers.foxcommand.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Simulation

# 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](comparison.md) when structured baseline-versus-candidate evidence is needed.