Customer Integration Reference Architecture

Overview

Your systems integrate with FoxCommand while your governance decisions remain under your control.

In a customer architecture, FoxCommand sits between prepared decision material and the systems that use returned evidence. Your application sends mapped material through the authenticated runtime boundary, then stores returned identifiers for review, audit, release, rollback, reporting, or CI/CD workflows.

Architecture Flow

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

How The Parts Fit Together

Your systems start with governance artifact versions, policy setup versions, business facts, credentials, traceability context, and lifecycle records.

The integration then prepares that material in three steps:

1. Customer Configuration records durable references such as Customer Profile context, credential relationships, and evidence retention locations. The Customer Profile is the customer-specific identity and ownership context within Customer Configuration.
2. Business Semantics defines your vocabulary, source facts, and lifecycle meaning for the decision.
3. The Decision Mapping Layer translates your business meaning into a FoxCommand-compatible request shape.

FoxCommand receives mapped material through the authenticated runtime boundary. It produces runtime evidence for governed execution, replay, simulation, comparison, and attribution workflows where supported by current runtime behavior.

Your systems store returned identifiers and decide what the evidence means for review, audit, release, rollback, experiment, reporting, or CI/CD workflows.

Your Responsibilities

Your 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 Runtime Boundary

FoxCommand owns runtime evidence production through Runtime API contracts.

Treat returned identifiers as evidence references:

• execution_id
• contract_reference
• replay_reference
• comparison_id

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

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

Implementation Sequence

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

Runtime Contract Boundary

Runtime API contracts define authentication requirements, runtime behavior, operational limits, exact request bodies, and exact response bodies.

This integration model does not change runtime behavior, runtime APIs, runtime execution semantics, authentication, or lifecycle automation.

Next Steps

Prepare one Governed Execution request using Customer Configuration, Business Semantics, Decision Mapping, and the exact request shape in the Runtime API Reference.