Integration Journey

Purpose

This document presents the customer onboarding and integration journey.

It describes the customer-facing path from onboarding through governance evolution while preserving the runtime authority boundary. It does not define runtime API behavior, customer configuration architecture, Decision Mapping architecture, runtime capability behavior, or customer lifecycle automation.

Journey Overview

The integration journey has nine stages:

1. Onboarding.
2. Customer Configuration.
3. Decision Mapping.
4. Governed Execution.
5. Replay.
6. Simulation.
7. Comparison.
8. Governance RCA.
9. Governance Evolution.

This guide focuses on the onboarding and integration journey. Detailed Customer Configuration, Decision Mapping, Business Semantics, and runtime capability references are covered in the linked customer guides.

1. Onboarding

Customer goal: establish the authorized relationship between customer-owned integration systems and the FoxCommand runtime boundary.

Customer responsibilities:

• Identify customer-owned systems of record.
• Assign integration and operational owners.
• Define internal access controls for integration actors.
• Decide which actors may use authorized runtime credentials.
• Keep credential secrets outside committed files and shared logs.

FoxCommand responsibilities:

• Preserve Customer Authority credential behavior.
• Preserve Runtime Gateway authentication-before-dispatch behavior.
• Provide current runtime API documentation from foxcommand-runtime.

Onboarding does not transfer customer governance lifecycle ownership to FoxCommand.

2. Customer Configuration

Customer goal: establish durable customer-owned context for repeated execution.

Customer responsibilities:

• Maintain Customer Profile references.
• Maintain governance, execution, mapping, credential relationship, and evidence retention references.
• Decide when customer configuration changes are required.

FoxCommand responsibilities:

• Accept submitted material through current runtime contracts.
• Preserve deterministic runtime execution over accepted material.
• Avoid owning customer configuration semantics.

For details, read Customer Configuration.

3. Decision Mapping

Customer goal: translate customer workflow and business language into FoxCommand-compatible execution inputs.

Customer responsibilities:

• Own the mapping from business language to governance artifacts, policy setup, setup mappings, candidate policy setup, replay references, and traceability metadata.
• Maintain that mapping as customer business language evolves.

FoxCommand responsibilities:

• Preserve the Decision Surface as a stable normalized execution surface.
• Avoid semantic inference over customer business language.

For details, read Business Semantics and Decision Mapping.

4. Governed Execution

Customer goal: submit eligible governance and policy material through authenticated runtime access.

Customer responsibilities:

• Select eligible governance and policy material.
• Submit authorized requests through current runtime contracts.
• Retain returned runtime identifiers in customer systems.

FoxCommand responsibilities:

• Authenticate protected requests.
• Execute governed execution through current runtime behavior.
• Invoke FoxCore where current behavior requires execution-semantics verification.
• Return bounded runtime evidence.

Runtime request and response details remain authoritative in foxcommand-runtime.

5. Replay

Customer goal: verify or reuse baseline runtime material by replay reference.

Customer responsibilities:

• Preserve replay references needed for later evaluation.
• Decide when replay evidence supports customer lifecycle workflows.

FoxCommand responsibilities:

• Execute replay-by-reference through current runtime behavior.
• Preserve replay-derived material according to current replay behavior.

Replay evidence does not become customer governance source truth.

6. Simulation

Customer goal: evaluate candidate policy setup against replay-derived material.

Customer responsibilities:

• Select candidate policy setup.
• Decide why the candidate is being evaluated and how results will be used.

FoxCommand responsibilities:

• Execute simulation through current runtime behavior.
• Return bounded simulation output.

Simulation output is runtime evidence, not approval, release, or rollback state.

7. Comparison

Customer goal: obtain structured baseline-versus-candidate evidence.

Customer responsibilities:

• Request comparison evidence when needed.
• Store and interpret comparison evidence in customer systems.
• Preserve customer correlation metadata for customer-owned traceability.

FoxCommand responsibilities:

• Produce canonical structured comparison evidence where current runtime behavior supports it.
• Preserve Replay Records as the atomic evidence object.
• Preserve deterministic comparison identifiers where current behavior supports them.

Comparison evidence supports customer decisions but does not make them.

8. Governance RCA

Customer goal: request bounded attribution evidence when comparison outcomes require explanation.

Customer responsibilities:

• Decide when RCA evidence is needed.
• Decide remediation, approval, promotion, rollback, or governance evolution outcomes.

FoxCommand responsibilities:

• Produce bounded Governance RCA output through current runtime behavior.

Governance RCA does not make FoxCommand the customer governance lifecycle authority.

9. Governance Evolution

Customer goal: update customer-owned governance, policy, mapping, release, approval, rollback, reporting, or CI/CD records after reviewing runtime evidence.

Customer responsibilities:

• Update customer governance artifacts, policies, mappings, Customer Profiles, release records, approval records, rollback decisions, corpus, experiments, reporting, or CI/CD workflows as needed.
• Preserve customer systems of record as authoritative.

FoxCommand responsibilities:

• Preserve bounded runtime evidence production and authority boundaries.

Governance evolution remains customer-owned.

Authority Summary

• foxcommand-runtime owns runtime engineering authority.
• Customer systems own customer semantics and lifecycle decisions.
• FoxCore owns execution semantics where invoked.
• Runtime Gateway owns the protected HTTP execution boundary.
• Customer Authority owns customer trust behavior.
• Evaluation evidence documents own evidence semantics.

This customer journey is a derived guide. It does not replace the runtime engineering authorities.

Next Step

Read Customer Decision Architecture to connect configuration, semantics, mapping, and runtime evidence.