Runtime Capabilities

Overview

FoxCommand runtime capabilities begin after your application has selected the decision material, mapped it into runtime-compatible form, and confirmed it is ready to send.

The runtime workflow moves from one governed evaluation to reusable baseline evidence, candidate evaluation, structured comparison, and bounded attribution. Each step returns evidence your systems can store and interpret outside FoxCommand.

Capability Sequence

The supported customer integration sequence is:

POST /governed-execution
    -> POST /replay
    -> POST /simulate
    -> POST /compare
    -> POST /rca

Each capability builds on evidence from the previous step.

Before Runtime Use

Confirm that your application can identify:

• The governance artifact or governance artifact reference.
• The policy setup and setup mapping versions.
• The decision mapping from your business meaning into runtime-compatible material.
• The customer traceability metadata to retain where supported.
• The runtime credential owner and secret handling path.
• Your storage location for returned evidence identifiers.

FoxCommand evidence can support your decisions. It does not make approval, release, rollback, reporting, or CI/CD decisions.

What FoxCommand Returns

FoxCommand returns runtime evidence. Depending on the capability and current runtime behavior, evidence can include:

• execution_id
• contract_reference
• replay_reference
• comparison_id
• governed outcome evidence
• replay outcome evidence
• simulation baseline and candidate summaries
• structured comparison evidence
• bounded Governance RCA attribution evidence

Store returned identifiers in your systems. Treat them as evidence references, not as approval state, release state, rollback state, or system-of-record truth.

How The Sequence Works

Governed Execution creates initial evidence from the information you submit. A successful response can return execution_id, contract_reference, and replay_reference.

Replay uses the returned replay_reference to verify or reuse baseline material. Replay material depends on current runtime behavior and may not be available across runtime sessions unless the deployment preserves it.

Simulation evaluates candidate policy setup against replay-derived baseline material. Use it before making decisions to promote, reject, revise, or investigate a policy change.

Comparison returns structured evidence between the baseline and candidate evaluation. It may return schema_version: "comparison.v1", comparison_id, replay relationship fields, comparison result fields, and customer correlation metadata where supplied.

Governance RCA returns bounded attribution evidence when an outcome change needs explanation. It is not organizational RCA, clinical RCA, financial RCA, infrastructure diagnosis, lifecycle automation, or a free-form explanation service.

Authentication

Operational runtime POST requests require:

Authorization: Bearer <runtime-gateway-token>
Content-Type: application/json

The runtime bearer token is validated before runtime request processing. Your systems own credential storage, credential access decisions, rotation procedures, and secret handling.

Current Limits

The current runtime API is a bounded validation and evidence surface. It does not define production hosting, OAuth, SDKs, user management, tenancy, billing, quotas, storage retention, backup restore behavior, public internet safety, durable simulation storage, durable RCA storage, or lifecycle automation.

Replay, Simulation, Comparison, and Governance RCA depend on replay material created by successful governed execution.

Exact Request Shapes

Use the Runtime API Reference for endpoint behavior, request sequence, minimal examples, response identifiers, errors, and current limits. Use the OpenAPI specification when importing the Runtime API shape into API tooling.