Quick Start

Quick Start

Purpose

This quick start is the shortest customer integration path for producing and retaining FoxCommand runtime evidence.

It assumes the customer already has an engineering system that can manage governance artifacts, policy setup, traceability metadata, credentials, and release or approval records.

Before You Call FoxCommand

Prepare the customer-owned side first:

  1. Choose the governance artifact version to evaluate.
  2. Choose the setup mapping and policy setup versions to submit.
  3. Identify where the customer system will store runtime identifiers.
  4. Define any customer correlation metadata needed for traceability.
  5. Confirm the integration actor is allowed to use the required runtime credential.
  6. Keep bearer credentials out of committed files and shared logs.

Runtime Call Sequence

Use the runtime API documentation in foxcommand-runtime for exact request and response shapes.

The standard sequence is:

  1. Call governed execution with selected customer-owned material.
  2. Store returned execution_id, contract_reference, and replay_reference where returned.
  3. Call replay by replay_reference when baseline verification is needed.
  4. Call simulation with replay_reference and candidate policy setup when evaluating a candidate.
  5. Call comparison with the same replay reference and candidate policy setup when structured evidence is needed.
  6. Store comparison_id, schema_version, comparison_result, replay relationship, and customer correlation metadata where returned.
  7. Call Governance RCA when bounded attribution is needed.
  8. Make approval, promotion, rollback, release, experiment, reporting, or CI/CD decisions in customer-owned systems.

What To Store

At minimum, store:

  • Customer governance artifact version.
  • Customer policy setup version.
  • Customer setup mapping version.
  • Runtime execution_id where returned.
  • Runtime contract_reference where returned.
  • Runtime replay_reference where returned.
  • Runtime comparison_id where returned.
  • Customer correlation metadata.
  • Customer release, review, approval, or experiment record that used the evidence.

Boundary Checks

Do not treat FoxCommand evidence as:

  • Customer governance source control.
  • Customer approval state.
  • Customer promotion state.
  • Customer rollback state.
  • Customer experiment assignment.
  • Customer corpus authority.
  • Customer system-of-record truth.

FoxCommand produces bounded runtime evidence. Customer systems decide what that evidence means.

Next Step

Read Integration Overview for the responsibility model, then use Examples and Runtime Capabilities when you are ready to build against the runtime sequence.