The Auto Auctions sector in the DecisioQ Decision Catalog is identified by AUTO-AUCT. It supports auction and remarketing workflows where teams compare vehicles, lots, buyers, sellers, reserves, lane choices, and transportation vendors.

DecisioQ integrations should not hard-code old template names. They should load the Decision Catalog, select the Auto Auctions sector, choose a real category, then choose a decision by Decision Name while preserving the decision ID internally.

Recommended first deployment: start with one high-value advisory workflow, such as vehicle acquisition or bid optimization. Compare DecisioQ recommendations against existing buyer or auction manager decisions before automating actions.

Auto Auction client applications should use the same discovery flow as the Business Decision Studio:

1. Call GET /decisioncatalog.
2. Select sector AUTO-AUCT using its sector name and decision count.
3. Populate Category from the selected sector's real categories[] collection.
4. Populate Decision from the selected category's decisions[], or call GET /decisioncatalog/sectors/AUTO-AUCT/categories/{categoryCode}/decisions when decisions are not embedded.
5. Display Decision Name in dropdowns and keep the decision ID as the option value.
6. Call GET /decisioncatalog/decisions/{decisionId} to load full decision metadata, criteria, profiles, scenarios, validation, samples, and overview content.

Decision detail metadata should drive the UI. Criterion summaries, purpose, business meaning, data guidance, and common pitfalls can be shown beside the Business Data entry fields.

For regional deployments, keep DecisioQ technical identifiers stable and localize only user-facing labels and guidance. Unless the selected endpoint and decision schema explicitly support unit-qualified input, convert mileage, distance, pressure, temperature, mass, volume, speed, fuel consumption, and other measurements to the required canonical units before submission. Do not infer units or currency from locale.

Auto Auction integrations should map operational data into decision-specific Business Data. The selected decision detail defines which criteria are required, how values should be measured, and whether lower or higher values are better.

Do not invent criterion IDs or fallback names in client code. Use canonical criterion IDs and display names from /decisioncatalog/decisions/{decisionId}.

Production integrations should keep credentials and bearer tokens on trusted servers or server-side gateways. Browser pages should use same-origin proxy handlers or their own backend service.

1. Trusted backend obtains a JWT token from identity.vinquery.com.
2. Application loads catalog and decision detail metadata.
3. User or system prepares Business Data for candidate cases.
4. Call POST /api/v1/validate to validate and prepare the request before execution.
5. Call POST /api/v1/decide to return the authoritative Decision Result.
6. Display the recommendation, ranked alternatives, warnings, assumptions, and Explanation of Decision Result.
7. Keep execution trace and diagnostics available to integrators, but collapsed or hidden by default for business users.

Use /api/v1/decide for both Prepared Criteria Mode and business-data integrations that submit a businessData object. New public onboarding should prefer Preview Decision and Execute Decision terminology.

The exact fields depend on the selected Auto Auction decision. The example below shows the integration style rather than a guaranteed schema for every decision.

{
  "decisionId": "AUTO-AUCT-008",
  "decisionPreparationModelId": "AUTO-AUCT-PROFILE-STANDARD",
  "scenarioId": "AUTO-AUCT-SCENARIO-MARKET-DEMAND",
  "businessData": {
    "candidates": [
      {
        "optionId": "LOT-10482",
        "name": "2021 Toyota Camry SE",
        "values": {
          "purchasePrice": 16800,
          "estimatedGrossProfit": 2900,
          "conditionScore": 86,
          "marketDemandScore": 78,
          "transportationCost": 425,
          "expectedDaysToSell": 24
        }
      },
      {
        "optionId": "LOT-10491",
        "name": "2020 Honda Accord EX",
        "values": {
          "purchasePrice": 15750,
          "estimatedGrossProfit": 2550,
          "conditionScore": 82,
          "marketDemandScore": 81,
          "transportationCost": 610,
          "expectedDaysToSell": 28
        }
      }
    ]
  },
  "requestContext": {
    "correlationId": "auction-workbench-20260717-001"
  }
}

This pattern belongs in a trusted backend, not directly in browser JavaScript.

async function executeAutoAuctionDecision(decisionInput, jwtToken) {
  const response = await fetch(`${process.env.DECISIOQ_BASE_URL}/api/v1/decide`, {
    method: "POST",
    headers: {
      "Authorization": `Bearer ${jwtToken}`,
      "Content-Type": "application/json"
    },
    body: JSON.stringify(decisionInput)
  });

  if (!response.ok) {
    throw new Error(`DecisioQ execution failed: ${response.status} ${await response.text()}`);
  }

  return await response.json();
}

• Store identity credentials, Decision API base URL, and proxy configuration in trusted server configuration or a secret manager.
• Do not expose bearer tokens or integration credentials in browser code.
• Use catalog metadata rather than hard-coded categories, decisions, criteria, profiles, or scenarios.
• Validate Business Data before execution and show user-friendly validation messages.
• Persist correlation ID, decision ID, profile ID, scenario ID, selected option, score, and explanation for audit.
• Retain the successful decision response requestId with the host business transaction, then call POST /api/v1/decision-outcomes when the action and realized result are known.
• Require an overrideReason for overridden recommendations; never infer acceptance merely because a result was displayed.
• Monitor GET /api/v1/decision-outcomes/summary for acceptance rate, override rate, and realized-value aggregates. Treat outcome feedback as reporting evidence, not automatic model training.
• Redact sensitive buyer, seller, and payment data in logs and diagnostics.
• Monitor catalog load failures, token refresh failures, API latency, validation failures, and unusual exclusion rates.
• Define fallback behavior so auction workflows remain usable when DecisioQ is unavailable.
• Review Decision Preparation Models and scenario assumptions with business owners when market conditions materially change.