Coroid uses a dedicated Decision engine for questions with a known set of answers. The initial model is Jev 1.13, served via OpenRouter. It sits alongside the architect, developer, QA and reviewer models in your AI profile; it is not another agent that writes code or calls tools.
How a decision works
Coroid sends the relevant state and a versioned question contract. Rather than asking a chat model to create and format a JSON response, it provides the permitted choices. Jev returns a structured answer and probability information.
- Choice selects a supplied option, along with a probability distribution and confidence level.
- Score evaluates the supplied ordered criteria, with associated probabilities and confidence levels.
- Noul expresses a yes/no judgement as a probability between zero and one.
Coroid validates the answer against the exact contract, checks confidence and workflow rules, and only then uses it. If the answer is uncertain, invalid or unavailable, the existing workflow evaluator handles the decision.
Where it is used
| Workflow | Decision | What stays unchanged |
|---|---|---|
| Acceptance evidence | Classify a criterion as visual, command, static or unverifiable | The check must still run and produce evidence. |
| QA preflight | Classify a failure, assess fixability and identify relevant paths from the supplied logs. | Fixes, tests and QA approval remain separate. |
| Work qualification | Assess current-release relevance, duplicates, reproducibility and routing. | A duplicate must reference a supplied candidate; already-fixed issues require supplied evidence. |
| Task routing | Classify work type and complexity, and select from compatible skills. | Explicit work type, model overrides, budgets and profile selection are preserved. |
The engine does not generate implementation plans, patches, arbitrary evidence, new file paths or reviewer explanations. Qualification nodes with an explicit model selection keep that selection instead of using Jev.
Set up your profile
- Open Settings → AI profile and choose an appropriate profile for new work.
- Budget, Smartest, Quick and Ludicrous profiles include a Jev Decision engine assignment.
- In an editable custom profile, assign Jev 1.13 to Decision engine. Chat models are excluded from this role, and Jev is excluded from chat-agent roles.
- Ensure OpenRouter is enabled and an eligible platform or organisation provider key is available. Organisation and project model policies still apply.
There are no temperature, reasoning or chat-fallback controls for this role. Fallback means reverting to the workflow's existing evaluator, not sending a decision request to an arbitrary chat model.
Free and residency-constrained profiles are not automatically assigned a paid OpenRouter model. Existing custom profiles are not silently changed. Execution snapshots retain their original assignments, so start new work after changing a profile to test the new assignment. See AI profiles.
Enablement and safe fallback
Runtime enablement is controlled at deployment level, separately for each workflow. In local development, all four workflows are enabled for real decisions by default after migrations. Other environments retain their rollout settings until an operator approves the relevant contract versions.
Even when enabled, Coroid falls back if the profile has no eligible decision model, missing credentials or policy blocks access, the request exceeds the supported size, the provider times out, or an answer fails validation or confidence checks. An unsupported or ambiguous decision must not silently become a successful check.
Operators can use off, shadow or enforced modes. Shadow records a comparison but keeps the existing evaluator's result; enforced uses a validated decision from an approved contract. These runtime controls do not hide this guide or the public product description.
Usage and audit records
Calls use the same provider-key selection, organisation policy checks and usage accounting as other model tasks, attributed to the Decision engine role. Billed responses are recorded even if their answers are rejected. BYOK follows the provider's billing terms; no separate Typesafe key is needed.
The operational decision record includes the workflow, contract version, actual model revision, probabilities, whether the result was applied, fallback reason, decision latency and usage correlation. It stores a digest of the input state, not the raw prompt or credentials. Retention follows the organisation's agent-log policy. This audit record is distinct from a generated explanation or test report.
Test locally
Use a new task with a profile that includes Jev. Exercise acceptance planning, QA preflight with a known failure, work qualification and normal task routing. Check the decision audit for an enforced mode and an applied result. A fallback entry explains why Jev did not control that particular decision; it is not proof that the workflow failed. Existing tasks may have a profile snapshot without Jev.