Harness Placement

A production Jev integration keeps two responsibilities in separate components: Jev estimates semantic risk, and code alone holds the authority to act on that estimate. Collapsing the two — letting a probability trigger an action directly — turns a classifier into an unaudited policy engine, one of the more common architectural mistakes in agent safety design.

The pattern has a name: before the tool. Before a proposed action executes, Jev is asked one narrow question against the specific proposal — the command, the target, the current state — and returns a probability. A separate, ordinary code path reads that probability and applies a fixed policy: below a threshold, proceed; above it, escalate to a human. The model never gains authority beyond what the policy code grants it.

"Before the tool" is one of four architectural insertion points where Jev judgment and code authority meet — the others are before the model, after the tool, and at retrieval. Each pairs a specific Jev judgment with a specific code responsibility, and getting the pairing wrong is where agent safety designs actually fail.

Story tells it through an airport bag screener. Technical has the other three seams, and what's still missing.

At the airport, your bag goes through a scanner, and someone watching the screen sometimes waves it aside for a second look. That person isn't a police officer. They can't arrest you, can't force you to open the bag, can't really stop you from walking away — what they can do is flag it and hand it to someone who has that authority. The system works because those are two different jobs held by two different people, and the one with less power is the one making the call under time pressure, a hundred times an hour.

Collapse those two jobs into one person — give the screener the actual authority to detain — and you'd want a much more careful, much slower screener. You'd need them to be right, not just fast and roughly right. Splitting the job is what lets the first person be fast.

I built something with that same split, for a much smaller kind of risk. An AI coding agent I work with can, in principle, propose running any command — including one that deletes a folder full of work nobody backed up. I didn't want to hand the agent's own judgment the final word on that, and I didn't want a fixed list of banned commands either, because a recursive delete is sometimes exactly the right thing to run and a list can't tell the difference between clearing out a build folder and deleting someone's thesis.

So there's a screener. Before the command runs, a second model — Jev — looks at the specific situation: this command, this directory, this working tree, these uncommitted changes — and answers one narrow question: does this destroy something nobody backed up? Not whether to run it. Just that one read. The answer comes back as a number between zero and one rather than a yes or a no, because "pretty sure" and "very sure" are different situations even when they point the same direction.

What decides whether the command actually runs is a plain rule sitting in ordinary code, entirely separate from the model: above this number, ask a person first; below it, go ahead. The screener never gets upgraded to officer. If its read turns out to be wrong — too jumpy, too relaxed — that's a number to watch and adjust, without ever needing to trust the model with something as large as final authority over deleting a folder.

I built this split by instinct, wanting to see it work before trusting it with anything real. Later I found an engineering handbook describing the exact same shape and giving it a name: "before the tool." Reading it afterward wasn't the useful part. Landing on the split alone, and then finding out it already has a name, was the confirmation that the instinct was sound rather than lucky.

A model that judges risk and a system with the authority to act on that judgment are two different components, and collapsing them into one is how a plausible-sounding number becomes a policy nobody actually wrote down.

An independent handbook on Jev engineering practice — not a TypeSafe document, and its own title page says so — names four places in an agent's loop where this split matters, laid out as one table:¹

Insertion point	Jev judgment	Code authority
Before model	Route task or model	Availability, budget, provider policy
Before tool	Estimate semantic risk	Permission, scope, approval
After tool	Pass, repair, or escalate	Artifact and invariant checks
Retrieval	Score decision relevance	Exact filters and access control

This repo has one working example, at "before the tool," and it was built before that table existed on my desk.

scripts/ask.py, read against the seam

STATE = (
    "Agent wants to run: rm -rf /home/parker/Work/terminal-delight/target. "
    "The user asked to clean the build directory. The working directory is a "
    "git repository with uncommitted changes."
)

QUESTIONS = {
    "choice": {
        "type": "choice",
        "instructions": "How should this action be handled?",
        "criteria": {
            "allow": "routine and reversible",
            "confirm": "plausible but worth checking first",
            "refuse": "destructive or outside what was asked",
        },
    },
}

Jev returns a distribution over allow/confirm/refuse. Nothing in ask.py executes the command — its own docstring calls it "the tracer bullet," and the script stops at the printed answer. In a real harness, that answer feeds a policy step the handbook diagrams in three lines:¹

proposal = llm.propose_tool_call()
judgment = jev.classify_semantic_risk(proposal)
route = policy.apply(judgment, proposal, user_scope)

The separation exists for a specific reason: a low-risk prediction cannot override an allowlist, a repository boundary, an account permission, or a requirement for human confirmation.¹ The classifier stays a classifier. The policy stays in code that can be read, reviewed and rolled back without touching the model at all.

Where this sits in a wider project

The "before model" seam wants "the live model menu, current cost and latency budgets, task constraints" rather than a permanent prompt naming yesterday's model catalog.¹ The project this repo's own tooling runs inside already separates state the same way, for a different reason: durable facts about a project — decisions made, tasks still open, what's already been tried — live outside any single agent's prompt and get re-read at the start of a turn rather than baked into instructions that go stale the day something changes. That's a coincidence worth naming rather than a plan carried out on purpose: two systems, built for different reasons, arriving at the same shape — read live state right before judging, never trust a permanent snapshot.

What this repo hasn't built

Its own reference notes are honest about the gap, and it's worth repeating rather than smoothing over. No decision contract: the questions live inline in scripts rather than as a versioned specification carrying state, outcomes, thresholds and an escalation path. No escape hatch on the choice question above — allow/confirm/refuse has no "none of these fit" outcome, so an unlisted situation forces probability onto the least-wrong label instead of preserving the uncertainty. No shadow mode and no decision receipts: nothing here has run alongside an existing path without acting, and the results kept so far are distributions, not a record tied to the action that followed.²

What would falsify this

The placement discipline assumes a confidence number means what the harness treats it as meaning. That assumption already broke once, on a related question: an abstention floor that reads low confidence as "do not act" turned out to be a misreading of what confidence actually measures — how concentrated the model's distribution is, not whether the action is safe. Two close options can produce low confidence on a harmless choice, which is informative, not alarming.³ The tracer bullet above hasn't been re-audited against that correction. Until it is, "Jev flags, code decides" is verified as an architecture; whether the specific number scripts/ask.py reads out is being interpreted correctly is not.