Guides
  1. runtime-capabilities

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

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 or verify source-of-truth boundaries in Runtime Authority.