Decisions, engineered.Book a Decision Discovery ↗DecisionOne turns policies, data, analytical models and human expertise into governed decision services that act, explain and learn.
Complete lifecycle
Discover, model, test, simulate, approve and publish.
Execute rules, DMN, models, optimisation and human review.
Measure quality, outcomes, forecasts and business impact.
Monitor performance, drift, overrides, experiments and releases.
Reuse governed packs, policies, connectors and templates.
DecisionOne is the operational layer that lets an organisation design, execute, govern, observe and improve decisions without burying their logic inside every consuming system.
DecisionOne exists because an enterprise can have sound policies and capable data platforms while still struggling to make consistent decisions at the point of action. A pricing policy may be interpreted differently by channels. A funding rule may be copied into several applications. A risk model may be released without a clear record of which authority approved its use. The problem is not the absence of technology; it is the absence of a shared operating layer for decision behaviour.
As an Enterprise Decision Operating System, DecisionOne connects the decision assets described by EDAF™ to the systems, people and events that need them. It can receive a request through an API, event, batch or streaming connection; assemble the relevant context; apply rules, models, optimisation or human review; return an authorised result; and preserve the record needed to explain what happened. The surrounding systems remain systems of record and systems of engagement. DecisionOne supplies the governed decision layer between them.
The platform is designed for change as well as execution. Decision logic is versioned, tested, approved and published through explicit controls. Runtime results are joined to outcomes, overrides, drift, alerts and experiments. That makes improvement a managed activity: a team can compare a new threshold or model against a baseline, understand the effect, and release a change with a known scope instead of silently altering live behaviour.
Decision Studio is where teams discover and model the decision, define its contract, test its logic, simulate scenarios and obtain approval. Decision Runtime is where the approved service executes repeatable rules, analytical mechanisms, optimisation and permitted human review. Decision Intelligence connects the determination to the outcome so that quality, calibration, forecast performance and business impact can be assessed. DecisionOps handles the daily discipline of releases, drift, overrides, experiments, alerts and assurance. The Decision Marketplace makes governed packs, policies, connectors and templates reusable across implementations.
Separating these concerns matters. A runtime should be dependable without becoming the place where policy is edited informally. A dashboard should reveal performance without becoming the authority for changing a rule. A model registry should describe an analytical artefact without pretending that the model alone owns the decision. DecisionOne keeps the operating concerns connected while preserving their boundaries.
DecisionOne does not treat an LLM, a prediction or an optimisation result as the final authority by default. A knowledge agent may extract facts, a predictive model may estimate likelihood, and an optimisation routine may compare feasible alternatives. The decision service applies the approved policy, constraints and authority model. Where the consequences or uncertainty require it, the service routes the case to a person with the evidence, explanation and permitted actions needed for a defensible review.
This is how the platform supports an autonomous enterprise without confusing autonomy with unaccountable automation. The system can act quickly when the decision is repeatable and the authority is bounded. It can abstain, escalate or request more information when the decision is outside its scope. In both cases, the decision record makes the boundary visible and gives the organisation a basis for learning.
Five modelling layers
Where decisions sit across the enterprise.
How decisions depend on sub-decisions and information.
Decision tables, rules, FEEL expressions and calculations.
Machine learning, scoring, forecasting and optimisation.
Inputs, outputs, runtime, explanation and monitoring.
DMN is a precise modelling standard for expressing decision requirements and business logic. It is an important layer of DecisionOne, while EDAF™ defines the wider enterprise architecture around it.
The Decision Model and Notation standard, usually called DMN, gives business analysts, decision owners and technical teams a shared way to describe repeatable decisions. Its purpose is practical: a person who owns the policy should be able to read the decision requirements and logic, while an implementation team should be able to use the same model as a basis for automation. The notation helps close the gap between business intent and executable behaviour.
A DMN model can show a decision requirement diagram, where a top-level decision depends on sub-decisions and information; decision tables, where rows make the applicable rules visible; and expressions written in FEEL, the standard’s expression language, for calculations and conditions. A table makes the boundary of a rule inspectable. It shows which inputs are considered, which combinations are covered, what result is returned and what happens when no row matches.
That clarity changes the conversation. Instead of asking whether a system contains the right code, a team can ask whether the decision question is correctly defined, whether the inputs are authoritative, whether the rules cover the intended population, whether exceptions are explicit and whether the result is connected to an action and an outcome. The model becomes a review surface for policy, engineering and governance.
DMN is well suited to the logic of a repeatable decision, but a decision service also has an owner, an objective, an authority model, a trigger, a version, release controls, an explanation contract, integrations, human review, monitoring and an outcome measure. Those concerns do not disappear because a decision table is correct. EDAF™ describes the enterprise relationships and governance around the decision; DecisionOne operationalises the full lifecycle from discovery through improvement.
This distinction prevents Brillion from presenting DecisionOne as a DMN viewer or DMN-only runtime. A customer can use DMN where its semantics fit and combine it with predictive models, optimisation, simulation, graph analysis or human judgement where those mechanisms are more appropriate. The architecture keeps the decision coherent while allowing the implementation to use the right tool for each part.
A useful model has an explicit input contract, an output that can be acted on, a defined authority and a way to explain the result. It is tested against representative cases, approved by the right owner, published with an effective version and observed in production. When the result is compared with what happened next, the organisation can learn whether the rule was useful, whether a prediction was calibrated, whether reviewers override it often and whether the decision should change.
That is the bridge from modelling to decision engineering. DMN gives the logic a common form. EDAF™ gives the logic an architectural home. DecisionOne gives the organisation a controlled way to run, explain and improve it.
Change the inputs. DecisionOne highlights the approved rule that fires, or explicitly abstains and refers the case when no rule matches.
Capture improving demand without moving outside the market.
| Occupancy | Demand | Competitor | Decision |
|---|---|---|---|
| Low | Low | Below market | Hold or reduce |
| Medium | Rising | At market | Increase moderatelyRule fired |
| High | High | Above market | Optimise upward |
DMN models repeatable decision requirements and logic. EDAF™ models the enterprise architecture around the decision. DecisionOne operationalises the lifecycle.
OMG DMN 1.5 ↗