Jev as a pre-install and pre-merge gate

01What makes a question gate-shaped

A gate sits in a pipeline and has to produce a verdict the pipeline can branch on. That constraint rules out most of what a language model is good at. An explanation cannot be branched on. A paragraph of reasoning about a package cannot be branched on. What the pipeline needs is a value from a closed set, plus enough signal to know whether to trust it.

The builds in this category converge on the same decomposition: ask several independent typed questions over the same state rather than one compound question. Intent, severity and exfiltration risk are different judgements, and splitting them means each can be logged, thresholded and audited separately. When a gate later turns out to be wrong, having three separate answers is the difference between knowing which judgement failed and knowing only that the whole thing did.

questions = {
  intent:      { type: 'choice', criteria: { install, postinstall, telemetry, build } },
  severity:    { type: 'score' },                      // 0..1
  exfiltration:{ type: 'choice', criteria: { yes, no } },
  curl_pipe:   { type: 'choice', criteria: { yes, no } },
}
// four typed primitives over one state; each is separately loggable

02Why prose is the wrong output shape here

Nothing downstream of a gate reads prose. The caller is an if statement. This is worth stating because the instinct when adding safety to a pipeline is to ask for an explanation — so a human can review it — and an explanation is exactly the thing that makes the gate too slow to run on every install.

The budget is the other half of the argument. A pre-install gate that takes seconds will be turned off by the people it is supposed to protect, because it fires on every package in every CI run. The reported figures for these gates are in the low hundreds of milliseconds, which is roughly the same order as the package manager’s own overhead — that is the range where a gate survives contact with a real workflow.

03The value is entirely in what happens on a refuse

An allow-by-default gate changes nothing. It has all the cost of a check and none of the benefit, and it creates the comfortable impression that something is being enforced. The whole design question is what the pipeline does when the verdict is refuse, and there are only three credible answers: block the install, quarantine it for a human, or allow it and record that it was flagged.

Which one is right depends on whether the pipeline is interactive. Blocking is correct in a CI job where a person can look at the failure. Quarantining is correct when the developer is mid-task and a hard failure would just train them to pass `--force`. Recording-as-flagged is correct when the package is already in production and blocking is not available. Picking one deliberately, and writing down why, matters more than the threshold.

04Failure modes, in the order they bite

A gate that never refuses is indistinguishable from a gate that works, and it feels identical to having no gate at all except for the latency. This is why a gate needs a set of inputs that *should* be rejected, run on every change to the criteria map. Without that, the only observable behaviour of the component is the time it costs and the bill it generates.

Obvious-looking questions get answered by pattern rather than by reading. A package with a `postinstall` script that happens to do something benign will be flagged; a package that obfuscates the same behaviour in a build step may not be. The failure is not random, it is correlated with how the code looks, which means measuring aggregate accuracy hides it. Look at the false positives and the false negatives separately.

The refusing verdict is fast, the reviewing human is not. A gate that fires on one install in fifty is fine; one that fires on one in three becomes a queue, and the queue becomes an approval rubber-stamp. The threshold should be set from the observed rate, not from a desire to be careful.

And the last one: the criteria map is the policy. Two descriptions that sound alike will be confused, and the fix is in the wording, not the model. Treat that map as the document a future auditor will read, because it is the only place the policy actually exists in executable form.

Gating an install and gating a diff are not the same problem, and it is worth keeping them separate. An install gate sees unfamiliar code arriving from outside and has almost no context about intent; its job is to be suspicious by default. A diff gate sees a change to code the team already owns, alongside the issue it claims to fix, and its job is closer to review than to security — “does this change match what it says it does” is answerable from the state in a way that “is this package safe” is not. The same decision model can serve both, but a shared threshold will be wrong for one of them.

05How to read the case list below

These are small tools, not products, and the figures are the authors’ own. What travels is the shape: four typed questions over the state, a pre-flight budget in the low hundreds of milliseconds, and a deliberate decision about what a refuse does. If you take one thing from this page, take the last one — the rest is configuration.