Decision evaluation
Compass evaluates a specific operating decision, compares options, simulates impact, and explains why a recommendation is ranked.
- Decision type selection
- Baseline vs proposed options
- Cost, risk, SLA, or outcome impact
Capability
Compass
AI decisioning
Compass is the decision layer inside Yedron. It uses rules, approved models, prediction, optimization, and simulation to propose options without bypassing approvals, controls, or audit.
A decision, not a black box
See the options before anyone acts.
For a delayed shipment, the decision view can compare responses alongside their evidence and constraints. A recommendation stays separate from authority to execute.
- Situation
- Customer delivery is at risk after a carrier delay.
- Options
- Keep the route, reroute, or contact the customer.
- Evidence
- Shipment status, carrier capacity, customer commitment, and cost.
- Next step
- Send the recommended response through policy and approval.
Illustrative workflow view. Controls and integrations depend on deployment.
Model resolution
Decision loops can use rules, approved models, industry patterns, or customer-specific models depending on readiness and control needs.
- Rules fallback
- Global and industry models
- Customer model approval
Controlled execution boundary
AI never executes actions directly. Recommendations move through rules, approvals, Praxis execution, Radar outcomes, and Audit evidence.
- Rule evaluation
- Human approval gates
- Traceable decision records
In practice
Decision support for real operating choices.
Use reasoning where a team must compare responses, understand a tradeoff, or inspect an uncertain recommendation. Define the operating question and the evidence that can answer it.
Recover a commitment
For a shipment delay, compare the existing route with alternative responses. Show timing, cost, capacity, and customer implications so the responsible operator can review the tradeoff.
Prioritize a response
For a production or service exception, compare candidate responses against the accepted operating context. Make constraints and missing evidence visible before a recommendation is handed off.
Explain the choice
Preserve the baseline, options, and rationale in the decision record. The reviewer can inspect why a response was proposed and choose to approve, reject, or escalate it.
How it works
From operating question to explicit recommendation.
The intelligence used depends on the decision. Deterministic logic, approved models, and relevant findings support the comparison within defined boundaries.
- 01
Define the decision
Agree the trigger, candidate responses, success criteria, and required evidence. Use Lattice and Strata to establish the accepted context and eligible inputs.
- 02
Evaluate and explain
Compare the options and preserve the assumptions behind the result. Expose uncertainty or missing inputs so the reviewer can decide whether more evidence is required.
- 03
Apply authority before action
Send the proposal through Policy and Workflow. Praxis executes the authorized response and Radar follows the observed result, with Audit preserving the evidence.
Common questions
Understand the fit.
Can we start with rules instead of a model?
Yes. The operating decision can use deterministic rules. Model signals should be introduced only where they serve the decision and meet the agreed input and approval requirements.
What can a reviewer inspect?
The DecisionCard connects operating context, candidate options, tradeoffs, rationale, policy status, and the authority path. It keeps the reasoning handoff explicit.
Does a recommendation automatically change a system?
No. Recommendation, policy, approval, and execution are separate steps. The permitted action path must be established before a target system is changed.
Start where one workflow needs clearer control.
Adoption starts with one workflow, the systems around it, the approvals it needs, and the outcome your team wants to improve.
Design a decision loop