Patterns: judging, search, documents, real-time and markets

TL;DR Eight decision shapes people published for evaluation and moderation, retrieval and corpus labelling, document and transcript processing, device control, and market signals. Scan the Decision lines, then follow Map into the official pages for the real contract.

How to read this

One pattern = one narrow judgment. Fit is our verdict against Jev 1.13 jaggedness: known failure modes and System One Models: strong = bounded options, semantic judgment, code owns the rest; workable = real, caveat named; poor = leans on arithmetic, dates, indirection, generation or huge state. Pattern IDs are permanent and never renumbered; the index of all patterns is Decision patterns from the community (with fit verdicts). Posted numbers are attributed and unverified.

Moderation, guardrails & judging

P15 Jev-as-a-judge for agent evals

• Decision did this captured agent run pass, and how good was it
• State the frozen trace: question, tool calls, evidence, final answer
• Ask Noul for does_pass, Score on an ordered quality rubric
• Code replay the same fixed runs; keep a human-labelled oracle to check the judge
• Fit strong — @LangChain reports 0.44s, $0.00035/call and per-case variance 92–913x below three LLM judges (five-example set)
• Map Cookbook: Self-consistency — nouls
• Seen @LangChain, danielgshea/jev-as-a-judge

P16 Screening what goes in and what comes out

• Decision does this input steer the agent or break rules; does this draft follow policy
• State one untrusted message, or the draft plus the rules or source passage
• Ask Nouls where true means something is wrong; add an uncertain Choice option
• Code aggregate with max; only failures and the uncertain band reach a person
• Fit workable — the docs say jev-1.13 is not hardened against adversarial text
• Map Cookbook: Double-checking citations
• Seen @LeoTava8 (110ms interception), @shannholmberg, brainstormity/Jev-Moderation-Bot, jkudish/jev-mcp (a screen tool returns injection, substance and relevance probabilities for a fetched page and recommends pass/review/block/skip — advisory only, the caller enforces)

Search, ranking & data at scale

P17 Per-candidate relevance: rerank, SQL predicate, graph edge

• Decision does this candidate answer the query, match the condition, or lead somewhere
• State the query plus one candidate, one row, or a node with its neighbour edges
• Ask Noul per pair for relevance; Choice over neighbour ids for traversal
• Code shortlist with ordinary search or SQL first; Jev re-ranks. Never ask for counts
• Fit strong per pair — the shipped recipe raised top-10 from 38% to 62% on legal queries
• Map Cookbook: Re-ranking, Cookbook: Line-by-line search
• Seen @mvanhorn, realZachi/pg-jev, superagents-lab/jev-search, ellipsis-dev/blink (the traversal variant: Jev scores file and folder names, many independent walkers are allocated by those probabilities, and the answer is the share of walkers that landed on each file — no index, no embeddings), jkudish/jev-mcp (find = one Choice over up to 250 candidate ids plus a separate existence check, because a Choice always returns a winner; rerank = one relevance question per candidate so the whole ordering survives)

P18 Map-reduce labelling over a corpus or a timeline

• Decision every semantic label you want per record, page element or transcript span
• State one record, or one segment with its neighbours — only the needed fields
• Ask every independent Noul/Choice/Score in a single request per item
• Code parallel workers; stitch adjacent positives into ranges, aggregate rates in code. Store answers keyed by record id so a new question later costs one pass, not a redo; let a reasoning model propose 5-8 narrow questions, approve them, run a 50-record sample first (Nate B. Jones, placement 2). A pattern across labels is a lead, not a cause
• Fit strong per item — the cheapest thing free output tokens unlock; boundary maths stays in code
• Map Cookbook: Parallel questions
• Seen @0xMovez (100k posts × 14 questions, 20.4s, $0.67), @iannuttall (3,282 of his posts × 8 questions, 4.25M tokens, $0.1282, 8m34s, then joined to likes in code — author-reported; arithmetic verified against $0.042/Mtok), @mvanhorn (777 judgments in <0.7s), kitze/unclutter, AkashPriyadarshii/jev-curate (the training-data variant: stream Parquet/JSONL rows, ask a fixed rubric per row — circular logic, step validity, sycophancy, unclosed fences — and write clean/rejected splits verbatim; author reports 1,500+ rows/sec with host-side pre-filtering and an adaptive token bucket for 429s)

Documents & transcripts

P26 Document classification and packet splitting

• Decision what is this document; does a new document start on this page
• State normalized page text from a local parse/OCR stage, plus the category rules verbatim
• Ask Choice over stable category ids with a one-line purpose description each (keep an other id); splitting is page-level, so the per-page category decision is the question and boundaries fall out of it (inferred — the repo averages page scores per segment)
• Code OCR is a separate, fallible stage; page ranges, coverage checks and export are assembled in code. Long packets must be chunked: 64k per request, 32k for state plus the longest question (State: what you send Jev), and the repo says oversized single pages fail explicitly rather than truncating
• Fit strong — bounded id set, semantic "what is this for" judgment, no arithmetic
• Map Cookbook: Hierarchical classification, Choice questions
• Seen @nedwize, kyotofin/tax-doc-classifier (one request per page: a 7-option page-kind Choice plus a 230-option form Choice with not_in_this_list, a second small Choice only for five parent forms; gate at 0.95 on the minimum confidence; 0 wrong on 1,067 pages, 38 below the gate; $0.00115 vs $0.039 per page and ~0.5 s vs ~3.3 s against its Claude Sonnet predecessor — author-measured; option count verified under the 255 limit, Choice questions). @jerryjliu0, jerryjliu/docjev (OCR backends: local liteparse by default, LlamaParse tiers for hard scans). Its 40-document pilot: both engines classified 40/40 correctly; Jev split 7/8 packets exactly against GPT-5.6 Luna's 8/8, with Jev's one extra boundary inside a Fed statement's attachment. The author claims it is "6x faster than gpt-5.6-luna" at equivalent accuracy; the repo's own medians are 138.6ms vs 794.3ms (classify) and 209.6ms vs 1,352.3ms (split), on a small convenience sample with uncontrolled provider caching

P27 Moment finding over a transcript

• Decision is this span of transcript a strong, self-contained moment
• State one chunk — a window of transcript text with a little of its neighbours; code keeps the chunk → timestamp map
• Ask Score on an ordered rubric per chunk (hook, self-contained, payoff); optionally a Noul for "does a new moment start here?"
• Code you chunk, you hold the times, you sort and take the top N; merge adjacent winners in code
• Fit workable — strong per chunk (it is P18 over a timeline), poor as "read this transcript and return the timestamps of the best 17 moments": time arithmetic and counting are documented weaknesses (Jev 1.13 jaggedness: known failure modes)
• Map Composite scoring, Cookbook: Parallel questions
• Seen @startupideaspod — Ryan Vogel reports a clip finder built in ~10 minutes that scored ~17 strong moments in about 3 seconds (author-reported, no accuracy check)

Real-time, games, robotics & IoT

P24 Action selection from simulator or device state

• Decision which legal move this tick; does this sensor picture need action
• State the sim or home state as compact JSON, plus the legal move list
• Ask Choice over move ids; Noul per automation condition in plain words
• Code fast model reacts, slow model plans; code owns the tick budget and safety cutout
• Fit workable — text-only and network-bound, so budget 70–500ms; numeric thresholds stay in code
• Map Smart home assistant demo walkthrough
• Seen fhshaik/typesafe-mario, RomanSlack/jev-drone, AboveColin/HA-Jev, @jpschroeder (10Hz needs ~10x lower price)

Markets & trading

Nothing here is investment advice and none of it is a recommendation to trade. jev-1.13 is documented to be unreliable at arithmetic, numeric representations and date/time comparison — most of what a market decision rests on.

P25 Per-block buy/sell decision

• Decision buy, sell or hold given a state your code already computed
• State pre-computed indicators as named English buckets — never raw price arrays
• Ask Choice over buy | sell | hold with criteria describing each regime
• Code sizing, limits, risk caps and kill switches are code; the public repo defaults to dry-run
• Fit poor as usually posted — the judgment is numeric, and calibration is a population property, not a per-trade guarantee
• Map Confidence vs probability
• Seen @oragnes, jarrodwatts/jev-trader (author states profitability is unverified), @startupideaspod — Ryan Vogel wired Jev to a per-minute Bitcoin buy/hold/sell signal and reports it "performed poorly"; he keeps Jev on routing-style decisions and away from portfolios and crypto, which matches the verdict above

Related

• Decision patterns from the community (with fit verdicts) — the index of every Pxx, routing and anti-patterns
• Consult guide: could Jev help this project? — running the "could Jev help this project?" conversation
• Patterns: agent internals, context and coding agents — agent loops, context, coding agents; Patterns: browser, computer use, voice and product UI — browser, computer use, UI
• Patterns: marketing, sales, GTM, content, support and ops — marketing, sales, support and ops (P19-P23, P28-P33)
• Field reports: independent evaluations, critiques, open replicas — independent measurements behind the numbers quoted here
• Community repos: what people built and how they use Jev — the repos named in Seen

Sources

Post and repo links are inline in each pattern's Seen line. The captured posts and repo READMEs behind them are listed in this page's frontmatter sources: (files under raw/x/ and raw/x-repos/ in the private repo; indexes raw/x/INDEX.json and raw/x-repos/INDEX.json).