TinyDecider

Rules that can be versioned, called and explained.

Keep the rules that decide things (a price band, an eligibility check, a routing choice) out of application code. Publish them once, call them from anywhere, and know afterwards which version answered.

1 · Model

Write the rules in DMN

Decision tables and decision models in the DMN standard, with FEEL expressions. Check a document before you publish it: the service compiles it and shows the decisions and the requirements between them.

Documents are bounded in size, depth and element count

2 · Deploy

Publish an immutable version

Deploying a document creates a new numbered version; deploying unchanged content returns the version you already have. A version never changes afterwards, and you can stop new selection of one by deactivating it.

Version numbers are never given out twice

3 · Evaluate

Ask for a decision

Send your inputs and get the result: by decision key, or by name with a version or the latest. You can also invoke a DMN decision service directly. Repeating a request with the same idempotency key returns the original answer.

A failed decision is recorded and answered with the reason

4 · Review

Read the history

Every answer is kept with the exact model version, the evaluator version and the instant it was given, plus the inputs and a trace of how the result came about. History is kept for 30 days by default, as one configurable window.

Inputs and trace are shown only to people allowed to see them

DMN decision tablesFEEL expressionsDecision servicesImmutable versionsIdempotent requestsEvaluation trace

For the people who own the rules, and the systems that ask.

Rights keep deploying, evaluating and reading the history apart.

Rule authorsDeploy DMN documents from the console, optionally editing them in the built-in DMN editor, check them first and publish a new version when the rules change.

DevelopersCall the HTTP API from your own systems: evaluate by key or by name and version, or invoke a decision service. The service serves an OpenAPI description.

Analysts and reviewersOpen the evaluation history in the console to see what was decided, with which version, and how, if your role allows seeing the inputs and trace.

AdministratorsChoose one tenant or many for the installation, decide who may deploy, evaluate and read history, and sign people in through your OpenID Connect provider.

OperatorsRun it on PostgreSQL with a Helm chart and a container image. Settings are environment variables, and metrics are served on their own port.

Everything the console does, over HTTP.

Your systems send the inputs; the service returns the decision. Models, evaluations and history all belong to the signed-in tenant.

curl --fail-with-body --header @auth.headers \
  --header "Idempotency-Key: order-1042" \
  --json '{
    "namespace": "https://example.com/pricing",
    "decisionId": "discount",
    "variables": { "customerTier": "gold", "orderTotal": 1200 }
  }' \
  "$DECIDER_URL/v1/evaluations"

Names, values and the address are illustrative. Without a version the latest active one is used, and the answer states which.

Deploy a document with POST /v1/deployments, or check it first with POST /v1/models/validate, which stores nothing.
Evaluate with POST /v1/evaluations by decision key, or by name and version. Run a decision service with POST /v1/decision-services/{key}/evaluations.
Read history with GET /v1/evaluations, filtered by decision, outcome or time.
Errors are problem documents with a stable code, and requests with unknown fields are refused.
The service describes its own API at /openapi.json. Automation signs in with an access token from your identity provider.

Rights, tenants and limits.

Who may do what, and how tenants are kept apart.

Answers follow the caller's rightsOne route serves every caller, and the answer is shaped by what that caller may see. Without the right to read detail, an evaluation shows the root result only; without the right to read models, decisions show no model.

Separate rights for separate jobsReading models, deploying, evaluating, reading all history and reading inputs and trace are distinct rights, plus an administrator right that holds them all. Anything you may not see is reported as not found.

One tenant or manyChosen once for the installation. Single-tenant (the default) serves one company; multi-tenant binds each sign-in issuer to one tenant, and a caller cannot reach another tenant by naming it.

Bounded and recordedRequest, document, result and trace sizes are limited, evaluations wait for a worker only so long, and each expression has its own step and memory budget. PostgreSQL is the only database.

What is in the private beta.

What the service does today. It supports a subset of DMN and FEEL.

In the beta

Deploy DMN documents as immutable versions, with a check before publishing
Evaluate by key or by name and version, with idempotent retries
Direct invocation of decision services
Evaluation history with exact model and evaluator version and instant, kept 30 days by default
Console: decisions, deploy, evaluate and history
Rights-shaped answers, single or multi-tenant operation
Export, import and purge per tenant
Container image and Helm chart

How to try it.

There is no public image yet. The private beta is by invitation, and it is free: ask, and we send you registry credentials.

tinydecider config check     # validate the settings, no network
tinydecider migrate          # as the database owner login
tinydecider serve            # API on 8080, metrics on 9090

The commands the service image runs, once its database and sign-in settings are filled in. The Helm chart runs them for you.

Ask for access. Write to hello@tinyfactory.ai. We send registry credentials.
Bring PostgreSQL and a sign-in provider. A TLS-enabled database with a runtime login and a separate owner login for migrations, and an OpenID Connect issuer.
Run the image. Install the Helm chart or run the image, with settings as environment variables.
Open the console at /console/, sign in, deploy a DMN document and evaluate it.

Business rules as versioned decisions, answered the same way every time.