Customer Decision Architecture

Overview

Use this guide to build the mental model for a FoxCommand integration before you make runtime API calls.

The goal is simple: your system selects customer-owned decision material, explains what that material means, maps it into FoxCommand-compatible inputs, calls FoxCommand, and stores returned evidence for customer-owned decisions.

The Workflow First

Think about the integration as a workflow:

Prepare customer context
    -> define customer meaning
    -> map that meaning into FoxCommand inputs
    -> call a FoxCommand Decision Surface
    -> store returned runtime evidence
    -> apply evidence in customer-owned lifecycle systems

Each step answers a different question:

Example

Suppose a customer wants to evaluate whether a policy change affects prior authorization decisions.

The customer system prepares durable references for the customer, credential relationship, policy setup, mapping material, and evidence storage. Those references belong in Customer Configuration.

The customer then defines what "prior authorization," "denial," "medical necessity," and "review state" mean in its own systems. That meaning belongs in Business Semantics.

Next, the customer maps that meaning to the Governance Artifact, policy setup, setup mapping, candidate policy setup, and traceability metadata that FoxCommand can evaluate. That translation is Decision Mapping.

FoxCommand receives the mapped material through a Decision Surface, returns bounded runtime evidence, and the customer system decides whether that evidence affects review, release, rollback, reporting, or CI/CD records.

Core Concepts

Customer Configuration is the durable customer-owned context used to call FoxCommand consistently. It includes references such as a Customer Profile, credential relationship context, source record references, and evidence retention locations.

Business Semantics are the customer-owned meanings behind terms, facts, workflow states, cases, policies, reviews, approvals, and releases.

Decision Mapping is the customer-owned translation from Business Semantics into FoxCommand-compatible inputs.

A Decision Surface is the FoxCommand runtime entry point targeted by mapped material.

Runtime evidence is the bounded output FoxCommand returns, including identifiers such as execution_id, contract_reference, replay_reference, or comparison_id where current runtime behavior supports them.

Ownership Model

Customer systems own:

• Source facts and systems of record.
• Customer Configuration and Customer Profile references.
• Business Semantics.
• Decision Mapping.
• Credential handling decisions.
• Evidence retention locations.
• Review, release, rollback, reporting, and CI/CD decisions.

FoxCommand returns bounded runtime evidence through its authenticated runtime surface. It does not become the customer system of record, approval workflow, release manager, rollback controller, or semantic owner.

Working Sequence

1. Prepare Customer Configuration for the integration.
2. Define Business Semantics for the decision.
3. Build Decision Mapping from customer meaning to FoxCommand inputs.
4. Target the appropriate Decision Surface.
5. Submit mapped material through the authenticated runtime surface.
6. Store returned runtime identifiers in customer systems.
7. Apply evidence to customer-owned lifecycle decisions.