dsh-jev

How we reviewed this: we ran scripts/verify.sh, which is what its CI runs, then built the core and attacked its failure policy from plain JavaScript — the path a TypeScript-only guarantee does not cover. We made no Jev calls.

What it is

The decision layer for DeepSeek Harness: the harness runs the agent, Jev makes the small decisions, and code owns the verdict. Two packages — a provider-agnostic jev-core and the dsh-jev plugin that wires it into DSH’s waterfalls.

The fail-closed rule is a type, and then a check

jev-core’s config declares what may happen when a required assessment produces no usable answer:

/**
 * What happens per function when a required assessment produced no usable
 * result. Tool assessment may only ask or hold — deriving a permission from a
 * failure is rejected at configuration time.
 */
export interface JevFailurePolicy {
  readonly toolSelection: 'fallback'
  readonly toolAssessment: 'ask' | 'hold'
  …
}

A type is a promise to TypeScript users. We are more interested in what happens to everyone else, so we built the package and configured it from plain JavaScript:

  toolAssessment: 'ask'        accepted
  toolAssessment: 'hold'       accepted
  toolAssessment: 'allow'      rejected: onFailure.toolAssessment must be "ask" or "hold":
                                         a missing execution assessment…
  toolAssessment: 'off'        rejected: same
  toolAssessment: undefined    accepted   (defaults to 'ask')

You cannot configure this thing to allow a tool call because the decision failed. Not “it defaults to safe” — the value is refused, in a runtime check, with a message that says why. Of everything we have reviewed in this category, this is the strongest form of the property: Canny proves it with a pure function, JevLoop prevents it by controlling the option set, and this one refuses to build the object.

Its own suite tests the same shape from the other side, and the test names read like a specification:

• falls back to the configured failure action, never to allow
• never softens a denial with a weaker ask
• binds the assessment to the exact arguments
• redacts sensitive argument fields before transmission
• does not apply decisions in shadow mode
• makes no provider call in off mode and stays unapplied
• does not add a second retry loop: tries follow the SDK policy

That last one is a failure we have found elsewhere by hand — a wrapper adding its own retries on top of the SDK’s, quietly multiplying the worst case.

What verify.sh actually does

It is more than a test run, and it all passed:

✓ Lockfile passes supply-chain policies (301 entries in 2.2s)
== unit + integration tests ==   jev-core: 82 passed, 8 files
[packaging] installing tarballs + pinned DSH peers (npm, no registry dependency on @buberlo/*)
[packaging] running the runtime smoke (real DSH services + installed plugin)
smoke: OK (standalone core, real plugin load, fail-closed enforcement, single cordis, client artifact)
[packaging] type-checking a consumer that uses the published types
packaging test PASSED
verify: OK

It packs the tarballs, installs them into a fresh consumer with no registry dependency on its own scope, loads the plugin into real DSH services, and type-checks a consumer against the published types. That is the difference between “the tests pass in the repository” and “the thing you would install works”, and it is the gap we found in patdown the hard way — green CI, unusable package.

Honest about what it has not measured

The config module opens with this:

Thresholds are deliberately uncalibrated defaults: they are a starting point for the target application, not measured operating points. Document any deployment-specific calibration next to the config that carries it.

docs/benchmark.md says its runs “remained fail-closed. No thresholds or completeness checks were weakened”, which is the right thing to record about a benchmark of a gate — the usual temptation is to loosen the gate until the numbers improve.

What to know before you install

It is a DSH plugin. jev-core is provider-agnostic and could be lifted out, but the packaging, the settings section and the client card are all DSH. If you do not run DeepSeek Harness there is nothing here to run, only to read — and config.ts and assessment.ts are worth reading.

Arguments are redacted before transmission against a default key list, and the assessment is bound to a hash of the exact arguments, so an approval does not survive the call being changed underneath it. Both are tested; we did not re-derive them.

MIT by package.json; GitHub detects no licence, which scanners will flag.

Verdict

Small, unshowy, and it gets the one thing right that most of this category gets wrong — and then makes it impossible to get wrong by configuration.

If you run DSH, install it. If you do not, read JevFailurePolicy and the line under it, and ask why your own gate can be configured to allow.

For the same property proved differently, see Canny and JevLoop; for the version that gets it wrong, Jevmind.

See how it compares with other tools in Best Jev tools, tested hands-on.

Review updated Sep 22, 2026. Numbers quoted from the project are its author's own; we don't publish our own measurements of Jev.