Customer Integration Reference Architecture

Purpose

This reference architecture shows how customer-owned systems integrate with FoxCommand without transferring customer governance ownership to FoxCommand.

Architecture

Customer systems of record
    -> Customer Configuration
    -> Business Semantics
    -> Decision Mapping Layer
    -> FoxCommand Runtime Gateway
    -> Governed Execution
    -> Replay
    -> Simulation
    -> Comparison
    -> Governance RCA
    -> Customer governance, release, review, audit, or CI/CD records

Customer-Owned Components

Customer systems own:

• Governance artifact source records.
• Policy setup and setup mapping versions.
• Customer Profile and durable configuration references.
• Business Semantics.
• Decision Mapping Layer.
• Credential handling controls.
• Evidence retention locations.
• Approval, promotion, rollback, release, experiment, reporting, and CI/CD decisions.

FoxCommand Boundary

FoxCommand owns bounded runtime evidence production through runtime-authoritative contracts.

The customer integration should treat runtime identifiers as evidence references:

• execution_id
• contract_reference
• replay_reference
• comparison_id

These are not customer governance versions, approval states, release records, or rollback targets.

Implementation Sequence

1. Define Customer Configuration.
2. Capture Business Semantics.
3. Build Decision Mapping.
4. Form a governed execution request.
5. Persist returned runtime identifiers.
6. Replay baseline evidence when needed.
7. Simulate candidate policy setup when evaluating a candidate.
8. Compare baseline and candidate evidence.
9. Request Governance RCA when bounded attribution is needed.
10. Store evidence and make lifecycle decisions in customer systems.

Runtime Authority

Use foxcommand-runtime for exact runtime API contracts, authentication requirements, runtime behavior, and operational limits.