Simulation

Overview

Want to evaluate a policy change before deploying it? Use Simulation.

Simulation evaluates candidate policy setup against replay-derived baseline material. It lets customer systems inspect candidate behavior before making customer-owned lifecycle decisions.

When To Use It

Use Simulation when:

A valid replay_reference is available.
You have candidate policy setup to evaluate.
You need baseline and candidate outputs before deciding whether to promote, reject, revise, or investigate a candidate change.

Candidate policy setup is customer-owned policy material submitted for evaluation. Customer systems own its meaning, versioning, and lifecycle state.

What You Provide

Provide:

replay_reference
candidate_policy_setup

Candidate policy setup uses the policy setup shape and rule syntax accepted by current runtime behavior. Use the runtime source of truth for exact request contracts.

What FoxCommand Returns

A successful Simulation response may include:

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

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

What To Do Next

Store simulation outputs or references in customer-controlled systems where needed. Preserve the candidate policy identity and version.

Use Comparison when you need structured baseline-versus-candidate evidence. Use customer-owned systems to decide how candidate output affects review, release, experiment, reporting, or CI/CD workflows.

Runtime Source of Truth

Use FoxCommand runtime documentation and the OpenAPI specification for exact request bodies, response bodies, authentication requirements, errors, and operational limits.

Simulation does not expose baseline or candidate internal execution material, replay internals, logs, traces, module names, or execution implementation details.

Next Steps

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