Introduction

DecisioQ is a catalog-driven decision platform. A client chooses a decision, provides candidate cases, and receives a deterministic recommendation with ranking, scores, validation feedback, and a business-friendly explanation. Profiles and Scenarios are optional configuration tools; begin with the decision's recommended or default configuration and introduce them only when the business requirement calls for a different evaluation emphasis or operating context.

How DecisioQ Supports Your Business

DecisioQ helps your organization turn recurring business questions into consistent, explainable decisions. It brings together the capabilities needed to prepare business data, compare alternatives, apply priorities and eligibility rules, and retain evidence for later review.

Consider a dealership asking, “Which of these vehicles should we acquire?” One vehicle may offer a higher expected margin but require more reconditioning. Another may better fit current inventory. DecisioQ gives your team a structured way to evaluate these tradeoffs using the selected decision definition and the facts you provide.

Compare alternatives using explicit priorities

Business decisions often involve competing objectives such as cost, quality, demand, availability, and risk. DecisioQ evaluates these factors together and returns a ranked comparison of eligible alternatives.

The Weighted Sum Model combines comparable criterion scores according to their relative importance. TOPSIS compares alternatives by their distance from desirable and undesirable combinations of criterion values. The selected decision's recommended configuration provides a starting point; your team can use supported configuration choices when different priorities are needed.

This makes the basis for a recommendation visible. Teams can distinguish a disagreement about the facts from a disagreement about priorities, and apply the same evaluation consistently across applications and locations. The ranking reflects the supplied inputs and configured policy; it does not predict a guaranteed business result.

Prepare business records for a consistent comparison

Your business systems hold purchase prices, inspection estimates, transport charges, demand categories, and other operational facts. A Decision Preparation Model translates supported Business Data into the criterion values required by the selected decision.

Preparation can include required-field and range validation, category lookups, supported measurement conversions, and reusable financial calculations. This gives connected applications a common definition of the values they submit for evaluation.

Reusing the same calculation helps teams avoid different interpretations of a metric across applications. Where a decision supports unit-qualified inputs, measurement conversion can also make miles and kilometres comparable. Scoring normalization then expresses values on comparable evaluation scales. Your organization supplies or sources the business facts and estimates; accurate, current inputs remain essential.

Apply business priorities, boundaries, and operating assumptions

Profiles express a reusable evaluation emphasis, such as giving more importance to cost or quality. Constraints determine eligibility before ranking, so an attractive score cannot compensate for failing an applied mandatory condition. Scenarios represent published operating circumstances or assumptions for the same decision.

For a vehicle-acquisition workflow, these capabilities can support a preferred evaluation emphasis, an approved purchase limit, and a review under changed repair-cost assumptions. The available Profiles, constraints, and Scenario behavior depend on the selected decision definition. Begin with its recommended configuration and select supported alternatives when the business question calls for them.

Your team gains a clear distinction between what it prefers, what it requires, and which assumptions it is evaluating. This makes policy discussions and exception reviews easier to follow.

Understand recommendations and connect them to outcomes

Explanations help users understand the returned ranking, contributing factors, and exclusions. Optional AI wording describes the finalized deterministic result without deciding which option wins. This gives users a basis for reviewing the recommendation and questioning unexpected inputs or tradeoffs.

Decision receipts capture execution evidence such as applied criteria and weights, ranking contributions, exclusions, and version references. Your application can retain the receipt with its business transaction to support later review and investigation.

Outcome feedback lets your application report whether a recommendation was accepted, rejected, or overridden, along with an observed result and an optional realized business value. For example, a dealership can link a completed sale's realized margin to the original acquisition decision. Your business system supplies these observations through the feedback API after the outcome is known.

These records provide evidence for evaluating how decisions are used and where inputs or policies may need attention. Outcome feedback does not automatically change the decision policy. Your team can use it alongside operational measures to assess performance and guide reviewed improvements.

Bring the capabilities into your workflow

Together, these capabilities connect business data, decision policy, recommendation, review evidence, and observed outcome. Applications can reuse a common preparation and evaluation process, while your organization owns the business facts, policy choices, and actions taken.

Start with a recurring decision that has meaningful tradeoffs, accessible data, and a result your team can observe. Choose a suitable catalog decision, review its required inputs, and use a complete example to see how the workflow fits your application.

Decisions

A Decision is a reusable model for answering a specific business question, such as which auction vehicle to purchase, which repair order to prioritize, or which towing request should be dispatched first.

Common mistake: hard-coding decision inputs instead of loading the decision definition from the catalog.

Criteria

Criteria are the measurable factors used to score each candidate case. Examples include title confidence, estimated margin, repair complexity, customer impact, safety risk, and parts availability.

Best practice: show criterion names and overview text to users, but keep criterion IDs in the request payload for stable integration.

Weight Strategy

A criterion weight expresses how much influence that criterion has on the evaluation. A Weight Strategy answers one question: Where do the criterion weights come from?

Three practical weighting paths

How the concepts relate

Choosing an approach

You can begin with DecisioQ Recommended Priorities and adopt a more customized approach later as business evidence and governance requirements develop. These are practical guidelines, not absolute rules.

Measurement Units and Localization

Localize what people see, not the machine-readable API contract. DecisioQ uses stable technical identifiers and the canonical values required by each decision definition so that the same model behaves consistently across regions. Criterion scoring normalization is an algorithm step; it does not convert kilometres to miles or CAD to USD.

Submit unambiguous measurements

Do not send a bare value such as {"annualDistance":25000} unless the selected decision definition explicitly and unambiguously defines its unit. If the endpoint supports unit-qualified values, submit the documented unit structure. Otherwise, convert the user's value to the definition's canonical unit before submitting it.

The following shapes are conceptual only, not production request fields: {"annualDistance":{"value":25000,"unit":"km"}} and {"annualDistance":{"value":15534,"unit":"mi"}}. Use them only if the selected endpoint's published schema supports that exact structure.

Locale and measurement system are separate choices. Do not infer units, currency, or jurisdiction from language or country: a Canadian user may prefer miles, a US user may prefer metric units, and a French-speaking user does not imply a particular currency.

Separate localization settings

A client may independently track locale, measurement system, currency, time zone, and jurisdiction. Conceptually: {"locale":"en-CA","measurementSystem":"metric","currency":"CAD","timeZone":"America/Toronto","jurisdiction":"CA-ON"}. This object explains the concerns; it is not an API request contract unless an endpoint explicitly documents these fields.

Currency is not a measurement conversion

Kilometres-to-miles conversion is deterministic. CAD-to-USD conversion requires an exchange-rate source, an effective date or valuation timestamp, rounding rules, and a defined policy. DecisioQ does not automatically convert currencies unless the selected API and decision definition explicitly document that capability. Where currencies may vary, the consumer must retain or identify the currency and apply its approved conversion policy before evaluation.

Canadian and US presentation example

When both consumers represent the same real-world facts and normalize them correctly, presentation differences should not change decision behavior. Any currency comparison must use the same explicitly defined valuation policy.

Responsibility summary

Decision Execution Contract

Related Concepts

Decision Input Modes

DecisioQ accepts two mutually exclusive ways to supply decision input. The input mode changes who prepares criterion values, but it does not change the ranking, sensitivity, explanation, or response capabilities of the Decision Service.

API considerations

Send businessData for Business Data Mode or options for Prepared Criteria Mode—never both. The shared endpoint is POST /api/v1/decide.

Related Concepts

Platform Components

Related Concepts

Options and Candidate Cases

An Option is a candidate that can be recommended. In the user interface these are often called Candidate Cases. For Auto Auctions, each option may be a vehicle lot. For Auto Towing, each option may be a tow request.

When not to use: if there is only one possible candidate and no meaningful trade-off, a rule or validation endpoint may be more appropriate than a ranked decision.

Profiles and Scenarios

Profiles and Scenarios let you adapt how a decision is evaluated without redefining its business question, canonical criteria, or candidate data. They are related configuration choices, but they are not interchangeable.

Profiles

A Profile is a reusable evaluation configuration for a decision. It answers: How should this decision generally be evaluated? A published Profile supplies a reviewed weight map keyed by the decision's current criterion IDs and can therefore change the relative emphasis placed on cost, quality, risk, customer value, or other criteria.

One decision can publish multiple Profiles for different enduring business priorities. Current catalog examples include balanced, cost_focused, quality_focused, and risk_control; their exact meaning and weights come from the selected decision definition, not from the name alone.

Select a Profile with profileId. If it is omitted, configuration resolution uses the decision's recommended Profile when one is declared, then the supported Balanced fallback when available. The response's configurationUsed.profile reports the effective value and source. A Profile does not change how Business Data is prepared and does not replace the Weight Strategy: with the normal Expert strategy, it is one supported source of effective criterion weights.

Scenarios

A Scenario names the circumstances, assumptions, or operating context under which the same decision is being evaluated. It answers: Under what circumstances is this decision being evaluated? Decisions can publish several Scenario IDs, such as standard, limited_budget, or risk_control, but clients must discover the actual values and descriptions from the selected Decision Catalog definition.

Select a Scenario with scenarioId. The runtime validates and applies only a Scenario published for that decision and records the effective selection in configurationUsed.scenario. What a Scenario changes is definition-specific; do not infer weight overrides, thresholds, or transformations merely from its name. When scenarioId is omitted, the base/no-Scenario execution is used unless the decision's authoritative configuration explicitly recommends one. The platform fallback is no Scenario.

Profiles vs. Scenarios

Using them together

{
  "decisionId": "AUTO-AUCT-006",
  "profileId": "balanced",
  "scenarioId": "standard",
  "businessData": { "...": "decision-specific fields" }
}

Input mode answers how values are supplied; Profiles influence evaluation emphasis; Scenarios identify operating context; TOPSIS or WSM performs ranking; Sensitivity Analysis tests recommendation stability.

Sensitivity Analysis

Sensitivity Analysis tests how stable the recommendation is when weights or model assumptions vary. It helps decision makers understand whether a result is robust or fragile.

Use it when recommendation stability matters, especially for high-value, closely ranked, borderline, or audit-sensitive decisions. It is optional when that additional evidence is not required.

When to use: high-value purchases, borderline rankings, audit-sensitive decisions, or decisions where a small data error could change the outcome.

When not to use: very high-throughput flows where latency matters more and the recommendation is already operationally low risk.

Decision Preparation Models

A Decision Preparation Model is a declarative model that defines how DecisioQ validates, normalizes, transforms, calculates, and maps Business Data into the Prepared Criteria required by a specific decision.

It owns the Input Contract, validation, normalization, Prepared Values, reusable metric references, business rules, criterion mappings, and documentation metadata. Clients normally select a decision; Business Data Mode resolves the appropriate model automatically.

Data Preparation

Common mistake: treating data preparation as the same thing as business preference. Data preparation gets values into the expected decision shape; Profiles express business preference through weights, defaults, and context.

Financial Metrics

Financial Metrics are reusable Prepared Values calculated by a Decision Preparation Model. They centralize definitions such as Total Acquisition Cost and Expected Gross Vehicle Margin while continuing to map into existing decision criteria such as Cost Impact and Business Value.

Decision Algorithm

A Decision Algorithm is the option-ranking algorithm that evaluates the available options using their criterion values and criterion weights, then produces a ranked result. DecisioQ currently supports TOPSIS and WSM (Weighted Sum Model).

Option-Ranking Algorithm choice guide

Four supported combinations

Neither ranking algorithm is universally better. Choose a weighting path and ranking method before reviewing the winner. Changing the effective weight source can change weights; changing TOPSIS to WSM can change rankings even with the same weights.

Decision Results

A Decision Result contains the recommendation, ranking, scores, confidence, validation feedback, warnings, and optional sensitivity output. Present business-facing recommendation information prominently while keeping detailed technical diagnostics available to integrators and support teams when needed.

Interpretation guidance: the top-ranked candidate is recommended because it best satisfies the configured criteria, profile, scenario, and validation rules.

Decision Outputs

The Decision Response separates the recommendation from the evidence needed to interpret and operate it. Output availability is independent of whether input arrived through Business Data Mode or Prepared Criteria Mode.

Related Concepts

Outcome Feedback: Connect Recommendations to Business Results

A recommendation evaluates the information and priorities available at decision time. Outcome feedback records what your team actually did and what happened afterward. Keeping these observations connected helps you assess whether the decision process is useful in everyday operations.

Why your business benefits

• Understand adoption. See whether reported recommendations were accepted, rejected, or overridden. Frequent overrides can prompt a review of missing information, operational constraints, or user needs.
• Connect decisions to observed results. Record an actual result, such as a completed delivery or sale, and optionally a measured value such as delivery delay or gross profit. Review these alongside the original assumptions in your own reporting.
• Make improvements with evidence. Preserve override reasons and business context so your team can investigate recurring problems and decide whether inputs, criteria, or policies need a reviewed change.

Outcome feedback is optional: you can receive and act on recommendations without submitting it. It becomes particularly useful for recurring decisions where your team needs to evaluate adoption, track results, and improve its process over time.

How your application supplies feedback

Your operational system observes the result. DecisioQ provides an API to store that observation and return summary figures. Outcome collection and reporting are currently exposed through the API; your integration supplies the entry screen, business-system connection, or reporting view.

1. Keep the decision reference. Save the successful decision response's requestId with the relevant business record, such as an acquisition, order, or delivery.
2. Capture the action in your application. Record whether the recommendation was accepted, rejected, or overridden, the selected option when applicable, and the reason for an override.
3. Submit after the outcome is known. Send the action and observed result together to POST /api/v1/decision-outcomes, using the saved ID as originalDecisionRequestId. Include the outcome time and, if available, a measured value with its metric and unit or currency.
4. Review the reported outcomes. Use GET /api/v1/decision-outcomes/summary for account-level counts, acceptance and override rates, and measured-value totals and averages over an optional time range.

A dealership example

DecisioQ recommends Vehicle A for acquisition. A buyer discovers damage during inspection, chooses Vehicle B, and records the override reason in the dealership system. When Vehicle B sells 21 days later, that system sends one outcome record linked to the original decision: the recommendation was overridden, Vehicle B was selected, and the sale produced CAD 2,450 in gross profit.

The dealership now has a record connecting the recommendation, the buyer's action, and the eventual result. Reviewing similar cases in its own analytics can help the team decide whether inspection findings should be captured earlier or included in eligibility rules.

Use the measures in context

The summary covers submitted outcomes. Its acceptance rate does not measure all recommendations unless feedback was supplied for all of them, and acceptance alone does not establish a good business result. Measured values are grouped by metric, unit, and currency. Comparisons by decision, policy, or business segment require your own reporting.

A reported profit or saving is an observed result; it does not by itself establish how much value DecisioQ caused. Use a suitable comparison or baseline when assessing improvement. Feedback does not automatically retrain the engine or change weights, Profiles, Scenarios, or catalog rules. Your team reviews the evidence and controls configuration changes.

Frequently Asked Questions

What is the easiest way to use DecisioQ?

Use the fully programmatic workflow in the Quick Start. Your application discovers a decision once—or uses a configured or cached decisionId—then submits businessData, receives the recommendation, and presents it to the user or continues the business process. Software normally performs these steps automatically. Decision Profiles, Weight Strategies, Ranking Algorithms, Constraints, Scenario Analysis, and Sensitivity Analysis are optional advanced capabilities.

When should I use Profiles?

Use them when the same decision needs different business priorities, such as Conservative, Balanced, or Aggressive.

When should I use Scenarios?

Use them when the operating context changes, such as high demand, low inventory, emergency dispatch, or seasonal pressure.

Do Profiles override weights?

A selected Decision Catalog Profile supplies recommended weights for its decision. Explicit client-provided weights or consistent AHP-derived weights override those Profile weights, and configurationUsed.effectiveWeights.source explains the result.

Is AHP an alternative to TOPSIS or WSM?

No. AHP determines criterion weights; TOPSIS or WSM uses the resulting weights to rank options.

Should Sensitivity Analysis always be enabled?

No. Use it where decision stability matters enough to justify extra analysis.

What is the difference between Decision Preparation Models and Profiles?

Decision Preparation Models map business data to criteria. Profiles change decision preference and weighting.

Ready to Use These Concepts?

Continue with the resource that best matches what you want to do next.