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

# Integration Overview

# Integration Overview

## Purpose

This guide explains the customer-side integration model for FoxCommand without redefining runtime architecture.

## Integration Model

FoxCommand integration is evidence production across a bounded runtime surface.

The customer system selects governance material and policy context, calls FoxCommand through the authenticated runtime boundary, receives bounded runtime evidence, and stores that evidence in customer-controlled systems of record.

FoxCommand does not own:

* Customer governance repositories.
* Customer branch policies.
* Customer approval workflows.
* Promotion or rollback decisions.
* Corpus management.
* Experiment interpretation.
* Aggregate reporting.
* Customer CI/CD pipelines.

## Runtime Boundary

The runtime boundary is the protected FoxCommand Runtime Gateway documented in `foxcommand-runtime`.

Within that boundary, FoxCommand may authenticate requests, execute accepted material through current runtime capabilities, invoke FoxCore where current behavior requires execution-semantics verification, and return bounded JSON evidence.

Customer systems should not depend on runtime internals such as filesystem paths, generated contract bodies, logs, caches, tracebacks, or replay storage layout.

## Customer Responsibilities

Customer-owned systems are responsible for:

* Selecting governance artifact versions.
* Selecting setup mapping and policy setup versions.
* Preserving customer traceability context before submission.
* Supplying authorized runtime credentials.
* Keeping secrets out of committed files and shared logs.
* Persisting returned runtime identifiers.
* Deciding how evidence affects review, release, promotion, rollback, reporting, or CI/CD workflows.

## FoxCommand Responsibilities

FoxCommand is responsible for:

* Maintaining the authenticated runtime execution surface.
* Accepting requests through current runtime contracts.
* Producing governed execution output where current runtime behavior supports it.
* Returning replay references, comparison identifiers, and bounded evidence fields where produced by current behavior.
* Keeping runtime evidence distinct from customer governance source truth.

## Standard Integration Sequence

1. Select a customer-owned governance artifact version.
2. Select customer-owned setup mapping and policy setup versions.
3. Record customer-owned traceability context.
4. Submit the material to the authenticated governed execution endpoint.
5. Persist returned `execution_id`, `contract_reference`, and `replay_reference` where returned.
6. Use replay by `replay_reference` when baseline verification is needed.
7. Submit candidate policy setup for simulation when candidate evaluation is needed.
8. Request comparison evidence when structured baseline-versus-candidate evidence is needed.
9. Request Governance RCA when bounded attribution is needed.
10. Make promotion, rollback, release, experiment, reporting, or CI/CD decisions in customer-managed systems.

## Evidence Handling

Treat FoxCommand identifiers as runtime evidence references:

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

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

## Next Documents

* Use [Quick Start](quick-start.md) for a compact implementation checklist.
* Use [Integration Journey](integration-journey.md) for the full lifecycle view.
* Use [Customer Decision Architecture](decision-architecture.md) before preparing configuration and mapping material.
* Use [Runtime Authority](runtime-authority.md) before relying on runtime API or runtime capability details.