DecisioQ is deployed as a small set of cooperating services. Client applications authenticate, discover governed decision metadata, submit options, and receive a deterministic result without needing to manage catalog content or scoring infrastructure.

Component	Primary responsibility	Public production host
Client App	Business UI, integration workflow, token storage, catalog selection, option entry, and result display.	Customer application or hosted demo site.
Identity Service	Authenticates DecisioQ API consumers and issues bearer tokens for secured calls.	https://identity.vinquery.com
Knowledge Service	Serves the decision catalog, sectors, categories, decisions, criteria, profiles, scenarios, and examples.	https://dks.vinquery.com
Decision Execution Service	Validates and executes decision requests, applies scoring, and returns results.	https://dde.vinquery.com

The Identity service issues access tokens for DecisioQ API consumers. Client applications request a bearer token from Identity and attach that token to catalog and decision calls.

• Production: https://identity.vinquery.com/connect/token
• Boundary: DecisioQ catalog and execution services validate incoming tokens but do not issue tokens.

The Knowledge Service is the source for catalog metadata. It answers questions such as which sectors exist, which categories belong to a sector, which decisions belong to a category, and which criteria, profiles, scenarios, and examples belong to a decision.

• Catalog: https://dks.vinquery.com/decisioncatalog
• Decision detail: https://dks.vinquery.com/decisioncatalog/decisions/{decisionId}
• Boundary: the Knowledge Service stores decision metadata. It does not run the recommendation.

The Decision Execution Service receives validation and execution requests. When it needs catalog metadata, it calls the Knowledge Service using the propagated bearer token, then runs the deterministic decision model.

• Validation: https://dde.vinquery.com/api/v1/validate
• Catalog execution: https://dde.vinquery.com/api/v1/decide
• Business-data execution: https://dde.vinquery.com/api/v1/decide
• Boundary: the Decision Execution Service computes recommendations. It does not own the public catalog metadata.

The same bearer token follows the request across service boundaries so authorization, traceability, and account context remain tied to the original API consumer.

1. The client requests a token from Identity.
2. The client sends the token to the Decision Execution Service for validation or execution.
3. When decision metadata is needed, the Decision Execution Service forwards the bearer token to the Knowledge Service.
4. The Knowledge Service validates the token and associates catalog activity with the same account context.
5. The Decision Execution Service completes execution and returns the recommendation to the client.

Step	Caller	Service	Outcome
1	Client app	Identity	Bearer token is issued.
2	Client app	Knowledge Service	Catalog, sectors, categories, and decision metadata are loaded.
3	Client app	Decision Execution Service	Decision request is submitted for validation or execution.
4	Decision Execution Service	Knowledge Service	Decision definition is retrieved using token propagation.
5	Decision Execution Service	Decision Execution Service	Options are validated and scored.
6	Decision Execution Service	Client app	Recommendation, ranking, explanation context, warnings, and diagnostics are returned.

Service	Production endpoint	Primary use
Identity	https://identity.vinquery.com	Token issuance.
Knowledge Service	https://dks.vinquery.com	Catalog and decision metadata.
Decision Execution Service	https://dde.vinquery.com	Validation and decision execution.
Client site	Hosted website or customer application	User workflow and integration experience.

• Token issuance boundary: only Identity issues tokens.
• Catalog boundary: the Knowledge Service owns catalog and decision metadata.
• Execution boundary: the Decision Execution Service owns validation, scoring, execution, and result generation.
• Client boundary: browser pages should not expose secrets. Server-side integration layers may be used to keep credentials and private settings off the public page.
• Diagnostics boundary: business pages should keep diagnostics collapsed or hidden by default; developer pages may expose request summaries, correlation IDs, execution traces, and service messages.

Localization and measurement normalization sit at the integration boundary. Client applications may collect values in a user's local language and preferred measurement system, but DecisioQ keeps technical identifiers stable and evaluates normalized canonical values.

Client application	Displays localized labels, collects user-entered units, and passes locale, measurement system, currency, time zone, and jurisdiction in request context when needed.
Integration Platform	Maps Business Data into decision criteria and normalizes supported metric or US customary measurements before execution.
Decision Execution service	Scores canonical values deterministically. Presentation choices do not alter ranking or recommendation.
Trace and diagnostics	Preserve source value/unit, canonical value/unit, conversion identifier, request ID, and correlation ID where available.

Canadian and US deployments can use different presentation defaults, but the same submitted business situation should produce the same deterministic decision after normalization.

Use Decision Concepts for modeling terminology. Use the Developer Center and API Guide for implementation details. Use the Business Decision Studio or Interactive Playground to exercise the live flow.

Decision Concepts Developer Guide Business Decision Studio Playground