Quick checks

While a workflow runs, Cerevisor makes a few small judgments about the work in front of it:

• Is this connection's condition met? — so it knows whether the next agent should run.
• Should this loop stop now? — the same question, asked at the end of each round.
• Did this agent do what it was asked, and did it finish? — so a half-finished result can be sent back for another try.
• Did this run go well? — the label Cerevisor uses to learn which models work for you.

Those are quick checks. They have always happened; now you can see them, and you can make them faster.

What you see

A conditional connection that has been checked carries a small chip on the line:

yes · 94% · 88 ms

• yes or no — what was decided. yes means the condition held and the next agent runs.
• 94% — how sure the model said it was. This appears only when the model gives a number.
• 88 ms — how long the check really took. It is measured, not estimated.

The run window shows one line beside the run's cost:

23 quick checks · 2.1 s · $0.0003 on your TypeSafe account

Reopen a finished run later and the chips and the line are still there. They come from the run's own recording, not from anything held in memory while the app is open.

A run that made no checks shows no line at all.

What the percentage means

The percentage is the model's own estimate.

That sentence is the hover hint on the chip, and it is meant literally. It is the model saying how sure it is. Nobody has proved that a 90% is right nine times out of ten — treat it as a hint about how clear-cut the text was, not as a guarantee.

When a check is not confident, Cerevisor does not just guess:

• On a connection, it asks a second model. If the two agree, that settles it. If they disagree — and you are running with Oversight approvals, so somebody is there — Cerevisor asks you, in the same card an approval gate uses. If nobody is there to ask, it treats the condition as not met, which is the cautious answer.
• On a loop, nobody is ever asked: a check that cannot tell ends the loop rather than spinning another round.

If no model can answer at all — a provider outage, say — the next agent is skipped rather than run on a guess, and the run's history says so.

Making them faster: connecting TypeSafe

By default a quick check runs on the models your workflow already uses, preferring the model that produced the text being checked. That costs a little and takes about as long as a short chat reply.

You can instead connect a TypeSafe account — a service that answers exactly this kind of small question, typically in a fraction of a second. Open Provider Hub → Quick checks, paste your key and press Connect. The key is checked with one real question before it is saved, so a wrong key is refused in one sentence and nothing is stored. Try it runs one sample check and prints how long it actually took.

You do not need a TypeSafe account. Everything above works without one.

What is sent, and what is not

Before the key field, Cerevisor states plainly what connecting means:

Cerevisor will send agent results and a short summary of finished runs to TypeSafe to be checked. Your memory is never sent.

In detail:

• Sent: the piece of text being judged — an agent's output for a connection or a result check, and for the finished-run rating only the two lines the run log holds about what worked and what did not. Secrets are stripped out first, and long text is shortened before it leaves your machine.
• Not sent: your memory, your profile, your prompts, your files, your tool output, or anything about a workflow that was not part of the check.
• Not recorded either: the text that was judged is never written into the run's history. The history keeps the question, the answer, how sure it was, how long it took and what it cost.

Cerevisor also states TypeSafe's own terms rather than a flattering version of them:

TypeSafe says it does not train on your data. On a standard account it keeps what it is sent.

Connecting is the consent. There is no second "are you sure" afterwards, and the connect, every switch you change and the disconnect are all written into your consent history in Settings → Memory, where you can read them back or export them.

Before a run

Whenever a run will reach TypeSafe, the pre-run summary says so in one line:

Quick checks in this run are sent to TypeSafe, the decision model you connected.

You will see it whether the in-run checks or the finished-run rating is what reaches them.

Turning a purpose off

Once connected, two switches sit under the key, both on:

• Check edges and agent results with TypeSafe. — the checks made while a workflow runs.
• Rate how each finished run went with TypeSafe. — the label on a run once it is over.

Turn either off and that kind of check stops going to TypeSafe immediately. It does not stop happening: it goes back to running on the models you already use, exactly as it does for someone who never connected an account.

Disconnect removes the key from your machine and turns both off. Your consent history keeps both lines — that you connected, and that you disconnected.

What a quick check can and cannot do

A quick check is information, never permission. It can send a workflow down one branch instead of another, ask an agent to try again, or write a label on a finished run. It can never give an agent a power it did not have, open a folder, or lift anything you said no to. Nothing that decides what an agent is allowed to do ever reads one.

Known limits

• The percentage is not calibrated yet. It is the model's estimate and is labelled as one.
• When a check is unsure, the text is shown to a second model as well, so it may reach a provider that would not otherwise have seen it.
• Loop-exit checks never ask you, by design.
• There is no quick-check display on the phone companion.
• When a check is unsure and a second model was asked, the cost shown for it covers both answers.

Evidence-backed decisions

Ask the Chat Builder to prepare source evidence, make bounded decisions, and send unresolved questions to a regular-model agent. Jev is optional: ordinary-model workflows remain the default without a connected decision model.

Decision nodes now show model confidence as a percentage. This describes certainty about the supplied text, not verified accuracy. For yes/no answers it measures distance from an even split; it is not the probability that the real-world claim is correct. A handoff keeps the preliminary Jev confidence visible and does not invent a percentage for the regular model.

In the decision editor, use Decision rubric to define what each outcome means. Enable Require source-matched evidence when the decision depends on documents. An upstream evidence-preparation agent supplies a source file and verbatim excerpt for each observation. Cerevisor checks that the excerpt occurs in that file before asking the model. It sends the selected excerpts, not the rest of those source files. Missing or changed evidence follows Unsure with Needs evidence, without a speculative model call.

A source match establishes text provenance only. It does not certify the source's truth, originality, or completeness. Avoid treating earlier generated reports as original policies. Connect Unsure to a regular agent that gathers the missing facts or explains what cannot be concluded.

Existing nodes keep their supplied-input behavior until source matching is enabled; their cards say that sources were not checked. Regular models handle strategic interpretation and substantive completion review. When quick checks previously invoked Jev for broad output completion, Cerevisor now uses the selected regular model under the existing review budget and opt-out. That review can consume regular-model quota or incur its usual cost. No different paid credential is selected for this handoff.

Evidence packet for advanced users

An evidence-preparation agent can return this as its final response or save it to a declared JSON output file:

{"type":"cerevisor-evidence","items":[{"source":"policy.txt","quote":"Approval is required before sending."}],"missing":[]}

Use up to 12 excerpts, at most 4,000 characters each and 18,000 characters total. Source files must be supported text files inside the workflow folder and fit the bounded reader. Put unresolved prerequisites in missing; they produce Needs evidence rather than a guessed answer.

Click a decision node to edit its question, rubric and evidence requirements, or inspect its latest result. Inspect supporting excerpts shows the exact source passages matched at evaluation time. Opening this view makes no model call. Finished nodes and chosen paths retain an outcome color; amber means unsure or missing evidence, and red means an execution error. Color identifies the outcome and never replaces its text label.

Progressive mode rechecks Jev availability at each increment. Operator also sees its current availability when choosing work and drafting workflows. Both can combine Jev decisions with regular-model agents according to the task: bounded checks and routing for Jev; planning, interpretation, research, execution and responses for regular models. They build ordinary-model workflows when Jev is disabled.

Inspecting decision inputs

Each decision card has an Inputs button. Open it to read the connected sources, the exact prepared model context, and any preparation problem. A long received-input preview is labelled as a preview; the model context is shown in full. File buttons open the current file, which may differ from the input captured during evaluation. Jev context uses the same secret redaction as the request sent to Jev.

Source documents and model context have separate limits: a short verified excerpt can come from a longer text source (up to one million characters/four MB). The complete decision context still must fit 22,000 characters. Oversized or missing input is not silently cut down; the node explains what to prepare and makes no speculative model call. Unrelated inherited files no longer invalidate an otherwise valid source evidence packet.

A wave contains only decision nodes or only regular-model agents. Prepare evidence in an earlier regular-model wave, evaluate it in a decision wave, then put follow-up reasoning or execution in a later regular-model wave. Parallel decisions should each connect to the relevant evidence producer. The builder rejects mixed-wave edits; existing mixed workflows must be separated before running.