Decision Mapping

Overview

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

Use this guide after you know what the customer decision means. Mapping should not invent meaning. It should turn resolved customer meaning into the material your integration can submit through a FoxCommand Decision Surface.

Start With A Practical Mapping

Example: a customer wants to evaluate a candidate policy setup for prior authorization.

The customer-owned meaning might be:

• "Prior authorization request" comes from the intake system.
• "Policy version 2026.07" is the Governance Artifact to evaluate.
• "Current setup" is the baseline policy setup.
• "Candidate setup" is the policy setup under review.
• "Case ID" and "release ID" should be retained as traceability metadata.

The Decision Mapping turns that meaning into:

• The selected Decision Surface.
• The Governance Artifact and policy setup material selected for evaluation.
• The setup mapping needed by the integration.
• The candidate policy setup for Simulation or Comparison.
• The replay reference from a prior governed execution where needed.
• Customer correlation metadata such as case ID and release ID where current runtime contracts support it.

FoxCommand evaluates submitted material and returns bounded runtime evidence. Customer systems keep the original meaning and decide how to use the evidence.

Another Example

A support organization wants to review escalation decisions.

The customer-owned meaning might be:

• "Escalated" means the ticket moved from standard support to specialist review.
• "Escalation policy" is the customer-owned Governance Artifact.
• "Tier 2 rules" are represented by a policy setup version.
• "Experiment cohort" identifies the customer population being evaluated.
• "Review record" identifies the customer-owned approval workflow.

The Decision Mapping connects those terms to the Governance Artifact, policy setup, setup mapping, candidate policy setup, replay references, and traceability fields that the integration can submit or retain.

General Model

After the practical examples, the general model is:

Customer workflow
    -> Business Semantics
    -> Decision Mapping
    -> FoxCommand Decision Surface
    -> runtime evidence
    -> customer lifecycle decision

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

Runtime evidence is the bounded output FoxCommand returns, such as execution, Replay, Simulation, Comparison, or Governance RCA evidence where current runtime behavior supports it.

Mapping Inputs

Decision Mapping starts with customer-owned inputs:

• Customer workflow context.
• Business Semantics.
• Customer Profile references.
• Governance Artifact references.
• Policy setup and setup mapping references.
• Candidate policy setup references where needed.
• Evidence and lineage references.
• Customer traceability metadata such as case, corpus, experiment, release, review, or approval identifiers.
• Data handling constraints.

Mapping Outputs

A customer-owned mapping should produce enough material for the integration system to select and submit runtime-compatible inputs.

Expected outputs may include:

• Selected Decision Surface.
• Governance Artifact and policy setup material selected for evaluation.
• Setup mapping references or material.
• Candidate policy setup for evaluation workflows.
• Replay references retained from prior execution where applicable.
• Customer correlation metadata for traceability where current runtime contracts support it.
• Evidence and lineage references retained in customer systems.

Mapping Workflow

1. Select the customer workflow or decision to evaluate.
2. Confirm the customer-owned Business Semantics.
3. Select the Customer Profile references needed for this workflow.
4. Select Governance Artifact, policy setup, and setup mapping versions.
5. Choose the Decision Surface targeted by the mapped material.
6. Attach evidence, lineage, and customer traceability metadata.
7. Review ambiguous terms or values with the customer owner before runtime submission.
8. Submit only through current runtime request contracts.
9. Store returned runtime identifiers in customer systems.
10. Update mappings through customer-owned change controls when business language or governance material changes.

Mapping Rules

• Preserve customer ownership of source facts and Business Semantics.
• Map customer meaning before runtime submission.
• Treat customer correlation metadata as opaque customer-owned traceability context.
• Keep runtime evidence distinct from customer governance source truth.
• Do not infer missing business meaning inside FoxCommand.
• Do not treat runtime identifiers as customer governance versions, release versions, approval records, or rollback targets.

Runtime Source of Truth

Use FoxCommand runtime documentation for exact request and response contracts, authentication requirements, capability behavior, and operational limits.

Decision Mapping selects and prepares material for runtime evaluation. It does not change runtime behavior, add runtime endpoints, or make FoxCommand the owner of customer meaning.

Next Steps

Review Decision Surfaces, inspect Decision Mapping examples, then use Runtime Capabilities when mapped material is ready for runtime evaluation.