Configuring batch triage
The System → Batch Triage screen controls how much of the AI budget triage may use and how each batch is sized — with no release and no restart. It exists because, until September 2026, changing the batch size or the quota slice meant editing the chart and publishing the whole platform; and because a form that only stores numbers would be a crowbar: the screen validates the combination before saving and explains what it rejected.
Who can use it
| Action | Permission |
|---|---|
| See the plan in force, the parameters, and simulate per context | AUDIT_VIEW |
| Save parameters and restore the baseline | AUDIT_CONFIG_EDIT (advanced user profile and administrators) |
Without the write permission the screen opens normally, with the form disabled and a notice naming the missing permission. The real barrier is the service — the screen is only the visual hint.
What the screen shows
Plan in force
What the planner would choose now for a typical case, with the current quota and measurements: batch (rules per call), requested maxTokens, calls in flight, p90 cost per analysis (measured, or the initial one while there is no sample), typical prompt size, p50 latency and the batch-lane quota (RPM/TPM). The reason says which ceiling decided the batch — batch-maximo, output ceiling, generation time or adjustment after an observed failure.
If the configuration in force is inconsistent (for instance a maximum batch that does not fit the output ceiling at the measured cost), it shows up here in red, before any edit.
AI budget slice
The fraction of the model's quota (RPM and TPM) reserved for triage. The rest stays guaranteed for chat, copilot and NER. The slice lives in the AI gateway's distributed limiter — it applies to every replica, and a change reaches the limiter within 15 seconds.
The card next to it shows the active model's quota, the lane quota the slice produces and how many in-flight calls it allows. If the limiter is inactive for the model (unknown quota), the slice has no effect until the gateway knows the quota — the screen says so.
Batch parameters
| Parameter | What it protects |
|---|---|
| Dynamic batch | Off, the static pair from the chart applies (shown right below the form). |
| Maximum batch | Hard ceiling of rules per call. The planner picks the largest batch that fits — raising the ceiling does not force the batch to grow. |
| Output headroom | Margin over batch × cost per analysis when requesting maxTokens. The gateway debits the whole maxTokens from the quota. |
| Initial cost per analysis | Used until there is a real sample; then the measured p90 applies. |
| Model output ceiling | Largest maxTokens requested from the provider. |
| Output speed | Converts the batch cost into generation time — bounds the batch by the timeout. |
| Initial latency | Used until there is a real sample; converts quota into in-flight slots. |
| Maximum concurrency | Ceiling of in-flight calls per case. |
Each parameter carries the origin of the value in force: configuration (saved by this screen) or baseline (the chart value or the service default). The Restore baseline button removes only that override — the others stay.
Only what changed is saved. Saving everything would turn every baseline into "configuration", and the origin would stop telling the truth.
Timeouts
Read-only: the model call timeout and the HTTP response timeout change through the chart and apply on service restart. The screen warns when the transport timeout is not larger than the AI call timeout — the inversion that makes rules vanish from the report without any error.
Simulation per context
Pick a triageable context: the screen counts its active rules and real cases and applies the triage arithmetic to the plan in force — calls per case (batches + report), calls per minute the lane quota allows and which axis binds first (RPM or TPM), time per case and for the whole context. It is a capacity estimate, not a promise: a large case costs more.
Which cases the count includes. The same ones triage would sweep: those with a document of their own in the collection. A case number merely cited inside someone else's document has no text of its own and never enters the queue — so it does not enter this count either. The gap is usually wide: in a real collection, 70 identified cases in the graph against 12 with a document. This card shows the same number as the case dashboard for that context; if the two disagree, one of them is wrong.
When the count cannot be read, no simulation is produced and the screen says why — the context database did not answer (retry in a moment) or it does not exist (then the fix is in the context registration, and retrying will not help). "This context has no case loaded yet" appears only when the count ran and the answer really was zero.
What the screen rejects
Validation runs in the service over the resulting combination (baseline plus what you changed), and the response says what to fix:
- Slice outside 1%–90%. Zero switches triage off; above 90% chat, copilot and NER are left without quota.
- Maximum batch that does not fit the output ceiling:
batch × cost × headroomabove the ceiling. The message says how many rules fit at the current cost. - Headroom outside 1.00–1.50; output ceiling outside 512–65,536; initial cost outside 16–4,096; concurrency outside 1–64; speed outside 5–5,000 tokens/s; latency outside 1–300 s.
Warnings do not block and come back with the confirmation: output ceiling more than 2.5× above what is needed (quota reserved and never used), dynamic batch off, inverted timeouts.
When the change applies
From the next triaged case — a batch in progress finishes with the plan it started with. No service restarts.
Every save and every restore goes to the platform audit trail (TRIAGEM.CONFIG_ALTERADA and TRIAGEM.CONFIG_RESTAURADA), with who changed it and the values before and after.
Relationship with the chart
The chart remains the baseline: what applies when nothing was saved by the screen, and what comes back when you restore a parameter. The order is configuration → chart (env) → service default. Changing the chart does not erase what the screen saved — to go back to the chart, restore the parameter.
See also: Batch triage (user guide) and, under Architecture, Triage: dynamic batch by AI budget slice.