TeXposit has moved Jev beyond a demo and into three bounded decisions inside its research-writing assistant: preload the right context, check an answer against explicit requirements, and choose a model tier for the next turn.

The useful part is not a sweeping benchmark—TeXposit explicitly says it has not run one. It is the architecture: Jev recommends resources and flags failures, while ordinary code caps the work and the main model retains responsibility for the answer.

Preflight turns serial discovery into one batch

  • TeXposit sends a task description plus yes/no questions about candidate skills, files, and tools in one Jev call.
  • In the illustrated request, Jev considered 42 questions covering 23 skills, 14 deferred tools, and five files.
  • It selected the same TikZ skill and two files the assistant later needed, plus one unused skill, one extra file, and one unused tool.
  • TeXposit measured the replayed Jev call at 0.38–0.60 seconds. The original assistant spent 59.4 seconds discovering context before a 13.8-second answer, but that is one deliberately extreme example—not an aggregate speed benchmark.
  • Hard caps limit the first turn to three files and four newly unlocked tools, so a permissive classifier wastes some context rather than opening an unbounded fan-out.

Judge Jev trades a cheap correction loop for false positives

  • Rigour Mode checks each active requirement against the conversation and proposed answer in parallel.
  • A failure returns targeted feedback to the main model before the user sees the answer or an edit reaches approval.
  • Across five hand-built examples, TeXposit says its old LLM judge took about 28 seconds, while Jev took 2.4 seconds.
  • Jev agreed with the old judge on four examples and incorrectly rejected one clean answer for failing to disclose limitations.
  • The loop stops after three failed revisions and warns the user instead of letting a strict or impossible criterion block forever.

These are TeXposit’s measurements, and I did not reproduce them. Five examples establish a failure mode, not an error rate; agreement with the old judge also does not prove either judge was correct.

Routing fails upward rather than downward

  • Jev chooses among fast, general, and smart model tiers for each turn.
  • Mechanical requests can go to the fast tier; complex instructions or important claims can move upward.
  • Uncertain routing defaults to the smart model, making the failure policy explicit and conservative.
  • The same yes/no mechanism replaces TeXposit’s old phrase-list skill discovery.
  • Bring-your-own OpenRouter users are excluded because silently changing their chosen model would violate the product contract.

The pattern is bounded advice, not delegated authority

  • Jev does not edit a project, approve its own judgment, or decide what tools may run without limits.
  • The main model still chooses the work, and edits still pass through normal validation and approval.
  • Typed output only guarantees that Jev returns a legal answer. The clean-answer rejection shows that a valid answer can still be wrong.
  • TeXposit has not measured aggregate latency, quality, false-positive rate, or routing accuracy, so the production case remains an informed pilot rather than a validated system.

“After three failed attempts, the task proceeds while giving the user an explicit warning that the answer may not be rigorous enough.”

The design lesson is stronger than the numbers: put a cheap decision model where mistakes have bounded consequences, cap its reach, escalate uncertainty, and preserve an escape hatch when the judge itself is wrong.