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 for a compact implementation checklist.
• Use Integration Journey for the full lifecycle view.
• Use Customer Decision Architecture before preparing configuration and mapping material.
• Use Runtime Authority before relying on runtime API or runtime capability details.