jevreduce

Event forecasting against an evidence bundle

Mon, 21 Sep 2026 00:00:00 +0000

Why this shape

The bundle is the state. Every item read together, once.
The criterion is the question. Verbatim, date included.
The price stays out of the request. Joined for the reviewer only.
Disagreement is the queue. p(yes) next to price, sorted.

How it gets scored

Run weekly on fresh snapshots.
Add resolutions as markets settle. Join on market_id.
Bucket by p(yes). Read the resolved share per bucket.
Replay with another model or wording. Compare the tables.

Nothing here trades.

Grading model outputs, and comparing models by replay

Mon, 21 Sep 2026 00:00:00 +0000

Why this shape

Grade alone, prefer together. Independent grades, then A against B in one view.
Typed, not parsed. A probability, a rubric position, a failure name, a preference split.
Swap the judge. One field in the manifest. Same snapshot. Two columns.
Disagreements are the labelling queue. Both judges’ raw responses are in the trace.

Interview transcripts scored against a rubric

Mon, 21 Sep 2026 00:00:00 +0000

Why this shape

One rubric, frozen. Every candidate scored against the same words.
Ordinal scores. 2.7 means between two levels, and you can see how sure.
The evidence turn. Read one answer, not the transcript.
Must-haves only above the bar. The other 81 keep their scores.

What it replaces

Six people remembering what was said.
A 3 that means a 4 to someone else.
Not the interviewer. People decide.

Reasons for customer churn

Mon, 21 Sep 2026 00:00:00 +0000

Why this shape

Unit: the customer, not the ticket. Two angry tickets are one relationship.
One request, three questions. 1,284 tickets, 412 requests. One question at a time: 1,236.
Filter before you read more. History is read for 38 customers, not 412.
Distributions, not labels. Close calls look like close calls.
The receipt. Why is Northstar on the list? Two clicks, not a re-run.

When the questions change

Edit a question. A new version is saved.
Old runs keep the old version.
Replay to apply the new wording to old data. New run, parent kept.

Ticket triage and routing

Mon, 21 Sep 2026 00:00:00 +0000

Why this shape

Four decisions per ticket, one request. Category, priority, engineering, sensitive data.
Your priority scale. P3 to P0, in your words, inside the state.
Incidents are a snapshot. Matched against what was open at 09:00. The trace shows which.
Routing in your code. Decision traced here, action audited there.

Which deals are most likely to close

Mon, 21 Sep 2026 00:00:00 +0000

Why this shape

Per call first. Next step, objection, stage. One call is the natural unit.
Per deal second. All its calls plus the record. A true dependency, so a second stage.
Between them, no model calls. Group, then join.

Make the probability earn its threshold

Run the same definition on last quarter’s snapshots.
Join closed-won and closed-lost on opportunity_id.
Bucket by p(close). Count won and lost per bucket.
Read the table. That is what 0.8 means for your team.

p(close)	deals	won	share
0.90 and up	your number	your number	your number
0.70 to 0.89	your number	your number	your number
0.50 to 0.69	your number	your number	your number
below 0.50	your number	your number	your number

A question is not a stage

Sun, 20 Sep 2026 00:00:00 +0000

Five questions about a customer do not make five model calls. In jevreduce they make one, unless one of them cannot be asked until another is answered.

The packing rule

The compiler groups questions that can be answered from the same state with compatible model settings into a single request. Their answers do not become hidden context for each other. TypeSafe’s documentation is explicit that sibling answers stay separate, and the trace keeps one recorded judgment per question either way.

Every judgment keeps its request

Sun, 20 Sep 2026 00:00:00 +0000

A model answer you cannot reproduce is an opinion. jevreduce stores, for every judgment, the request body that was sent, the response body that came back, and the attempt that carried both. Everything the app shows in the right panel is read from those stored facts. Nothing is reconstructed from logs or chat history.

The chain

Every answer has a pathEach connection is a stored reference.

RecordSource snapshot
UnitGrouped evidence
AttemptModel request
ResponseProvider output
JudgmentTyped answer

Filtered out?

The record stays in the trace with the rule that excluded it.

Plugging Pylon, Fireflies and Attio into a reducer

Sun, 20 Sep 2026 00:00:00 +0000

A reducer never calls Pylon. It reads a snapshot that a Pylon connector published. That one boundary is what lets the same question run over support tickets on Monday and call transcripts on Tuesday without touching the workflow.

One contract for every source

New data, a new snapshotEarlier runs keep their original inputs.

SOURCE DATA

Import records

Raw evidence
Structured fields
Source references

→

VALIDATE

Check the contract

Schema
Coverage
Provenance

→

PIN INPUTS

Versioned snapshots

Run A → snapshot 1
Run B → snapshot 2

What a reducer is, and what it is not

Sun, 20 Sep 2026 00:00:00 +0000

A reducer is the evaluate stage in a jevreduce workflow. It takes one unit, a record or a group of records, binds it into a single request, asks Jev a fixed set of typed questions, and writes the answers back as data. The name is a nod to MapReduce. The nod stops there.

What goes in

The unit. You choose it: one ticket, one customer with all of their tickets, one call transcript, one candidate pair. “Per customer” means grouping by the customer key and declaring which tickets go into the state. It does not mean renaming per-ticket scores as customer risk.
The state. The fields from that unit the model is allowed to see, bound explicitly. Jev fetches nothing. A dataset reference in the instructions is not content.
The questions. Each has a type with a fixed answer shape. Each is written to name the fields it is about, because the model never sees your question IDs.

One customer, one shared stateGroup the evidence before asking the model.

INPUT

Northstar

Ticket T01
Ticket T02

About us

Mon, 01 Jan 0001 00:00:00 +0000

Investors

Mon, 01 Jan 0001 00:00:00 +0000

A focused approach to useful AI

jevreduce brings structured model questions, repeatable workflows, and record-level traces into one place. It is a HeyMilo product, built by Redsnack Technologies Inc.

Investor inquiries

For information about the company and investor conversations, visit HeyMilo to contact the team.

Explore the product

Start with the product resources and blog to understand how the product works. Our Trust Center outlines product transparency and questions to cover in a review.

Leadership

Mon, 01 Jan 0001 00:00:00 +0000

The company behind the product

jevreduce is a HeyMilo product, built by Redsnack Technologies Inc.

44 Montgomery Street, San Francisco, CA.

Start a conversation

For leadership introductions, company questions, or partnership conversations, visit HeyMilo to contact the team.

How we think about the work

Make the inputs visible. Keep model outputs open to review. Give people the information they need to decide how to use the results.

Read our product guides or visit the Trust Center for practical details.

Resources

Mon, 01 Jan 0001 00:00:00 +0000

Keep learning

Visit the blog for practical guides and explanations from the product team.

Trust Center

Mon, 01 Jan 0001 00:00:00 +0000

See the evidence behind an answer

A trace lets you inspect a record’s input, questions, typed result, and provider request and response. Records excluded by a filter remain visible in the workflow path. Read what a judgment keeps.

Keep the original run

Runs retain their input snapshot and workflow definition. Replay creates a new run; model answers can change. The earlier run remains available for comparison.

Understand where model calls go

The model selected at each stage determines which provider handles that request. Hosted Jev and supported self-hosted models follow different deployment paths. Confirm the provider and data handling requirements for your setup before uploading sensitive information.