> ## 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.

# Runtime API Reference

# Runtime API Reference

## Purpose

This customer edition summarizes the runtime capability API surface used by customer integration systems.

The authoritative API contract is `foxcommand-runtime/docs/FOXCOMMAND_RUNTIME_API_v2.md`. Use that runtime document for exact request bodies, response bodies, status concepts, error details, authentication requirements, and current limits.

The publication/import OpenAPI derivative is [`customer-reference/openapi/foxcommand-runtime-api.openapi.json`](https://github.com/joelliptondesign/foxcommand-adapter-kit/blob/main/customer-reference/openapi/foxcommand-runtime-api.openapi.json). That artifact is derived from runtime-authoritative implementation and engineering documentation and does not replace runtime authority.

## Authenticated Runtime Surface

Current customer runtime capability paths:

```text
POST /governed-execution
POST /replay
POST /simulate
POST /compare
POST /rca
```

Operational runtime POST requests require bearer authentication through the runtime authority boundary.

## Standard Request Sequence

Use this sequence:

1. Submit selected governance material to `POST /governed-execution`.
2. Store returned `execution_id`, `contract_reference`, and `replay_reference` where returned.
3. Use `POST /replay` by `replay_reference` when baseline replay verification is needed.
4. Use `POST /simulate` with `replay_reference` and `candidate_policy_setup` when candidate evaluation is needed.
5. Use `POST /compare` with the same replay reference and candidate policy setup when canonical structured evidence is needed.
6. Use `POST /rca` when bounded Governance RCA attribution is needed.

## Evidence References

Treat runtime identifiers as evidence references:

* `execution_id` identifies runtime execution evidence.
* `contract_reference` identifies runtime contract material where returned.
* `replay_reference` identifies replay lookup material through the replay boundary.
* `comparison_id` identifies deterministic Comparison evidence.

These identifiers are not customer governance versions, approval records, release records, branch names, experiment assignments, corpus authority, or rollback targets.

## Error Model

Runtime responses return bounded customer-facing errors when submitted material is missing, malformed, unsupported, unknown, non-admissible, or cannot be validated.

Errors should help customer systems correct boundary issues without exposing stack traces, filesystem paths, runtime module names, generated execution bodies, replay internals, simulation internals, logs, telemetry, cached outputs, FoxCore internals, or customer-specific integration logic.

## Customer Non-Dependencies

Customer integrations should not depend on:

* Runtime internals.
* FoxCore internals.
* Generated contract bodies.
* Stored replay material.
* Filesystem paths.
* Logs.
* Telemetry.
* Caches.
* Tracebacks.
* Replay portability beyond runtime-authoritative limits.
* Hosted, SDK, tenancy, billing, quota, production, or external authorization behavior not defined by runtime authority.

## Boundary

This page is a customer orientation reference. It does not replace the runtime API authority and does not define independent runtime behavior.

## Next Step

Return to [Customer Reference Documentation](customer-reference-home.md) or verify source-of-truth boundaries in [Runtime Authority](runtime-authority.md).