DecisioQ Documentation

DecisioQ is a decision intelligence platform for business applications that need to choose, rank, justify, and audit operational decisions. The current platform combines a secured Decision Catalog, governed Decision Preparation Models, deterministic Decision Execution, catalog-defined validation and constraints, and a business-friendly explanation layer.

The current user and integration workflow is:

1. Load the Decision Catalog.
2. Select Sector, Category, Decision, Profile, and Scenario.
3. Review the Selection Overview and criterion guidance.
4. Enter Business Data for the candidate cases.
5. Preview Decision input for validation and preparation when needed.
6. Execute Decision and review the deterministic recommendation.
7. Read the Explanation of Decision Result and, when needed, developer diagnostics.

Many applications frequently need to answer questions such as:

• Which supplier should we select?
• Which vehicle should be purchased?
• Which claim should be prioritized?
• Which carrier provides the best value?
• Which customer application should be approved?
• Which inventory item should be replenished first?

While these decisions appear straightforward, they usually involve competing criteria such as cost, risk, quality, availability, compliance, customer impact, and long-term value.

By externalizing decision logic into DecisioQ, organizations can keep decisions consistent and auditable across multiple products without embedding custom scoring rules, validation rules, or eligibility constraints in every application.

The DecisioQ Decision Catalog is the authoritative discovery source for available business decisions. It is secured by JWT authentication and organized around business language rather than internal engine concepts.

The current discovery flow is:

1. Sector - the automotive business area, such as Auto Auctions or Auto Insurance.
2. Category - a real catalog category within the selected sector.
3. Decision - a named decision type returned by the catalog; the dropdown displays the Decision Name while retaining the decision ID internally.
4. Profile - a governed Decision Preparation Model that supplies decision-specific weights, defaults, and business context.
5. Scenario - a named operating situation used to load realistic sample Business Data and assumptions.

Decision detail responses include overview metadata for decisions, criteria, profiles, scenarios, validation rules, and catalog-defined hard constraints. This allows the Business Decision Studio and client applications to explain the selected sector, category, decision, and individual data fields without hard-coded page text.

Current catalog endpoints include:

• GET https://dks.vinquery.com/decisioncatalog - lightweight sector and category discovery.
• GET https://dks.vinquery.com/decisioncatalog/sectors/{sectorCode}/categories/{categoryCode}/decisions - decision list for a category when decisions are not embedded.
• GET https://dks.vinquery.com/decisioncatalog/decisions/AUTO-AUCT-006 - complete decision metadata, criteria, profiles, scenarios, validation, constraints, and overview content.

Profiles and Scenarios let you adapt a decision's evaluation emphasis and operating context without redefining the decision. They are related, distinct concepts, and the available choices are specific to each Decision Catalog definition.

Learn about Profiles and Scenarios →

Decision execution is deterministic. The engine validates Business Data, enforces catalog-defined validation rules, applies hard constraints, normalizes criteria, applies weights, scores eligible candidate cases, ranks them, and returns the recommendation.

The current public integration language is:

• Decision Preparation Model - the business configuration selected for the decision.
• Business Data - the customer or application payload being evaluated.
• Prepared Criteria Mode - the validated and normalized request ready for execution.
• Decision Preview - validation and preparation without final execution.
• Decision Execution - the final deterministic decision run.
• Decision Result - the ranked result, recommendation, scores, confidence, and supporting details.

A typical result contains:

• Recommended option
• Ranked candidate cases
• Eligible and excluded candidate outcomes when hard constraints apply
• Scores and confidence
• Key drivers and criterion contributions
• Warnings, assumptions, and validation messages
• Execution trace metadata for authorized technical users

Explanation of Decision Result is rendered after the deterministic result. It helps business users understand the outcome but does not overwrite rankings, scores, eligibility decisions, or recommendations.

When the host workflow later knows what action was taken and what happened, it can link accepted, rejected, or overridden feedback to the original decision requestId. This supports adoption and realized-value reporting while preserving deterministic, governed configuration.

Applications submit business data or already prepared decision criteria. DecisioQ prepares and validates the input when applicable, evaluates it against the authoritative definition in the Decision Catalog, and returns a deterministic recommendation with ranking and explanation context.

You can begin with business facts in Business Data Mode or use Prepared Criteria Mode when your integration already supplies decision-ready values. In both cases, the catalog definition governs validation and execution.

Explore the Architecture →

Server-side applications can authenticate, discover decisions, validate input, execute decisions, and report realized outcomes through the DecisioQ APIs. The API Guide is the canonical reference for routes, methods, authentication, request and response contracts, and endpoint-specific behavior.

Use POST /api/v1/decision-outcomes after the business result is known and GET /api/v1/decision-outcomes/summary for account-scoped adoption and realized-value reporting.

View the API Guide →

Preview Decision

Preview validates the selected decision input without completing the final recommendation workflow. Use it before execution when users are editing Business Data, building integrations, or checking that Prepared Criteria Mode matches the selected catalog decision.

POST https://dde.vinquery.com/api/v1/validate

Execute Decision

Execution validates the same input and runs the selected decision once. The deterministic Decision Result is authoritative.

POST https://dde.vinquery.com/api/v1/decide

The response can include:

• Recommended option
• Ranked options
• Constraint outcomes for eligible and excluded candidates
• Confidence score
• Decision summary and result metrics
• Explanation of Decision Result
• Warnings and validation messages
• Execution trace metadata for technical review

Business Decision Studio

The Business Decision Studio demonstrates the same workflow in a business-facing UI: choose the decision, understand it, enter case information, evaluate candidate cases, run the decision, and review the recommendation and explanation.

Production integrations should distinguish authentication, authorization, quota, validation, missing-resource, dependency, and unexpected-service failures. Preserve request and correlation identifiers so an error can be traced across services.

Review HTTP Status Codes and Error Handling →

DecisioQ keeps API identifiers stable and uses American-English technical names for decision IDs, criterion IDs, JSON fields, and endpoints. User-facing labels may be localized separately for Canada, the United States, and future markets.

Decision calculations use canonical metric values internally. Client applications may submit metric or US customary measurements when the unit is explicit. The Integration Platform normalizes supported units before the Decision Execution service scores the request.

These unit pairs are illustrative, not a list of universally accepted API inputs. Unless an endpoint explicitly documents unit-bearing values and conversion, consumers must submit the canonical unit required by the decision definition and keep their own conversion trace where needed.

Locale, measurement system, currency, time zone, and jurisdiction are independent presentation or policy concerns. Do not add them to requestContext unless the selected endpoint schema explicitly supports them. Localize what people see, not the stable API contract.

To maximize decision quality and integration reliability:

• Load decisions from the Decision Catalog instead of hard-coding IDs in user interfaces.
• Display Decision Name to users while retaining decision ID internally for integration.
• Use the selected Decision Preparation Model and Scenario to prepare realistic Business Data.
• Always include explicit units when submitting measurements that may be metric or US customary.
• Preview Decision input before execution when users are editing or importing data.
• Treat the deterministic Decision Result as authoritative.
• Use Explanation of Decision Result to help users understand the recommendation.
• Keep credentials and bearer tokens on trusted servers or server-side proxies.
• Collapse execution trace and diagnostics by default in business-facing screens.
• Include the required token audience when requesting access tokens.
• Link API Consumers to DecisioQ accounts before executing decisions.
• Respect catalog validation ranges, including percentage and score fields that must remain within 0 to 100.
• Treat hard constraints as eligibility rules; excluded candidates do not participate in ranking.
• Store correlation IDs and decision IDs needed for audit and support.

By following these practices, applications can leverage DecisioQ as a reliable, transparent, and scalable decision intelligence platform.