Panel Decisions

Use Decisions to prepare typed questions, inspect calibrated decision probabilities, and review experimental launch strategies. The served Engine exposes /v1/decide for compatible loaded backends, while the Panel uses its own registered /v1/decisions profile owner; these endpoints are distinct and the Panel does not fabricate a proxy. All controls run through the same authenticated Panel route owners as API requests; the pages do not create a second decision engine or independent approval system.

Where to work

1. Open Decisions at /rust/decisions to create a profile, fit or prepare a private artifact, validate it against held-out examples, then activate only a validated artifact. A profile binds the question type, options, managed instance, minimum level and action threshold. Use Run a typed decision after activation.
2. Open Decision D3 at /rust/inference/d3 to train a captured-feature head. Train new unqualified candidate, Re-evaluate stored candidate, and Select a qualified-by-policy experimental candidate are separate actions. Selection requires the exact artifact SHA-256, a current Engine revision and typing PROMOTE. Infer with the live selected artifact uses CPU-reference inference only. Revoke Engine D3 selection uses REVOKE.
3. Open Decision-mode service at /rust/decisions/service. Start with Inspect decision capabilities, Inspect model compatibility, and List calibration profiles. Fit a calibration profile requires labeled records with stable, disjoint training and holdout example IDs. Record full-text comparison gathers real evidence from a matching served instance. Evaluate deployment quality persists a profile-bound pass or failure. Read the quality gate checks it. Only then use a named profile ID for calibrated yes/no, pick-one, routing or score requests.
4. Open Experimental launch strategies at /rust/decisions/strategies. Check training job feasibility reports readiness but queues no job. Propose a measured strategy needs paired real per-case quality and speed evidence, plus exact runtime bindings. Approve verified strategy requires a different administrator and independent signed receipt verification. Activate approved strategy requires explicit confirmation and a connected launch owner. End the experiment with Deactivate active strategy and use Inspect active strategy to verify.
5. Open Diffusion studio at /rust/dlm for read-only opted-in canvas events, starting presets, staging policy and paired comparisons. Loading presets or staging a policy does not run an engine.

The guided sequences are Train, verify, select and use a D3 yes/no head, Calibrate decision mode and check the quality gate, and Review, approve, activate and deactivate a strategy. Each consequential action still passes the real owner's permission and evidence checks. Some stages require manual data entry or a second administrator; no guide manufactures a capture, approval or successful quality gate.

Safety and outcomes

• Fitting a profile is not deploying it. A usable calibrated live request requires the exact model/runtime/instance/mode/ordered-option binding and a current passing gate; the screen displays errors rather than silently downgrading.
• Validation uses labeled held-out examples distinct in stable identity from fit examples. Four rows is the minimum for each of fitting and supplied validation; the default deployment gate asks for at least 32 held-out observations and 20 full-text comparison observations. Example payloads must be replaced with evidence from the actual run.
• D3 status and selected binding are reported by the managed Engine. Training, evaluation, selection and CPU-reference inference do not prove device-level qualification.
• A staged strategy is not an active strategy. Proposal, receipt review and activation are independent transitions. Review cancellation and activation cancellation are cooperative requests; verify the owner status afterward.
• API route permissions apply within each form. The Panel hides administrator controls from lower roles, including profile creation, artifact mutation and D3 candidate changes. An administrator using a scoped key sees only decision-service controls authorized for that exact route. Submission checks the required role and token scope again, validates the JSON envelope, and requires a separate authorization checkbox for proposals, approval, activation, deactivation and cancellation. An authenticated user without the required role or scope receives a refusal.

Service and strategy controls

Every row below names the exact button and owner route. Read operations take the indicated profile ID, instance ID or local model path; write operations take an editable JSON object, not raw shell commands.

Control help text

Each help marker uses the following exact text. A marker alongside a form explains the action without authorizing it.

Related guides

See Typed decision API, Panel API, and Guided tasks for request envelopes and the broader operator workflow.