Coroid uses a dedicated Decision engine for questions with a known set of answers. The initial model is Jev 1.13, served through 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. Instead of asking a chat model to invent and format a JSON response, it supplies the allowed choices. Jev returns a structured answer and probability information.
- Choice selects a supplied option, with a probability distribution and confidence.
- Score evaluates supplied ordered criteria, with probabilities and confidence.
- Noul expresses a yes/no judgment 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.
Question contract
Relevant state plus the allowed answers
How can this acceptance criterion be verified?
Structured answer
A probability for each allowed choice
Validation
Contract, confidence and workflow rules
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 requires 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 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 organization provider key is available. Organization and project model policies still apply.
There are no temperature, reasoning or chat-fallback controls for this role. Fallback means returning 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 database-controlled, separately for each workflow. Acceptance classification, QA preflight, qualification, and task routing use Jev decisions by default. The seven current version-1 contracts are approved.
Even when enabled, Coroid falls back if the profile has no eligible decision model, credentials or policy block 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. A new contract version still requires approval before it can control a workflow. These runtime controls do not hide this guide or the public product description.
Usage and audit records
Calls use the same provider-key selection, organization policy checks and usage accounting as other model work, 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 organization'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.