Diego Arias’s jev-devtools puts a React inspection drawer beside a Node application using Jev. It captures requests and returned values, then shows the paths an application takes when developers define those paths through its flow API.

Follow the answer into the branch

  • The server adapter wraps the TypeSafe SDK’s systemOne calls and links retries to the original request.
  • Request views expose inputs, questions, probability distributions, errors, and cancellation.
  • Connected flows add developer-written conditions, parallel checks, function steps, bounded collections, and loops.
  • Branch cards show captured values beside the configured thresholds; untaken paths stay visible.

A request trace explains what the model returned. An explicit flow also explains which application rule used it. The inspector only captures calls through its instrumented client; arbitrary application code remains outside that view.

The passage example makes policy inspectable

One cookbook classifies retrieved passages before assembling evidence for an answer. Its code checks for attempted instruction injection first, then contradictory evidence, relevance, and usable answer evidence.

These checks have ordered precedence and exact boundary operators. A score at a threshold can take a different route from one just above it. The accompanying offline tests exercise those boundaries and verify that excluded passages stay out of the final prompt and sample answer.

The responses are synthetic fixtures passed through the real SDK. They demonstrate the routing machinery. They provide no evidence that live Jev correctly identifies malicious or irrelevant passages.

Local checks passed, without live inference

At inspected commit 4ce235dd950b8b2f94e97d268ecbd5ae2b5b96ea, a local run passed 92 repository tests: 64 library, 24 playground, and four release-tooling tests. Type checking, the normal build, development-UI compilation, and packed-package consumer verification also passed.

The tests cover retries, cancellation, scoped histories, response ownership, and flow behavior. Package verification also checked server-rendered output and a disabled endpoint. These are reproduced software checks, separate from model-quality evaluation. Browser interaction and live inference were not exercised in this capture.

Treat captured context as sensitive

  • Capture and display are disabled by default; API keys stay on the server.
  • Credential-named fields are redacted, but secrets embedded in ordinary prose need application-specific handling.
  • Traces live in one Node process’s bounded memory. Restarting loses history; distributed aggregation and durable workflow recovery are outside its scope.
  • Shared environments need application authorization. A local proxy or tunnel can bypass the protection implied by a loopback-only connection.

The README identifies this checkout as the experimental 0.4.1 candidate, with npm publication pending and the install command still resolving 0.4.0. Keep the drawer and server adapter on matching builds.

A valid typed answer can still drive a wrong decision. This tool makes the application’s use of that answer easier to inspect; representative labeled cases still have to establish whether the model and policy work together.

Caveat: this capture ran offline software checks, not a live-model evaluation or security audit.