State Times Questions

Frame engineering is the part of building on Jev that decides what a judgment can see and what it is asked. A frame is the state times the questions: the facts sent in one call, multiplied by the typed questions asked of them. Jev answers the frame it is given, with a probability, so most of what an answer can mean is settled when the frame is written, before any call is made.

Our focal point is Omarchy, an open-source Linux desktop that had 1,964 open GitHub issues on the day this was written. We built frames that sort the whole queue into triage piles, read-only, for 47 cents of Jev calls. The work sorted into four problems: shaping the decision a frame serves, pointing questions at the state with backticks, knowing what an answer’s confidence covers, and letting AI agents draft frames without trusting them to finish. Each has a part of this series.

Story explains why a frame says as much about its engineer as about the data. Technical has one real frame, the answer it got, and the four problems in detail.

Point a camera at a busy street and two decisions get made before anything is recorded: where the edges of the picture go, and what the lens focuses on. Whatever falls outside the edges does not exist as far as the photograph is concerned. Whatever falls inside is there, sharp or soft, depending on where the focus landed.

A camera is reliable about exactly that much. It records a crisp picture of whatever it was pointed at, and it has no opinion about whether it was pointed at the right thing.

Jev, the decision model this series is about, works the same way. All it sees are the facts your code sends it in one call (the state), and it answers narrow questions about those facts: is this true, which of these options fits, where does this sit on a scale (the questions). The state is the part of the street inside the edges. The questions are where the focus goes. Together they make the frame, and the frame is the whole world as far as the answer is concerned.

That sounds like a limitation. In practice it is the useful part, because every answer can be traced to choices someone made on purpose: what went into the picture, and what the lens was asked to look at.

We spent a day making those choices against a real, untidy subject. Omarchy is an open-source Linux desktop whose GitHub project had 1,964 open issues that morning: bug reports, feature requests, people asking for help, and a few things that were none of those. The job was triage. For each issue: what kind of thing is it, could someone act on it as written, and should a maintainer look at it now.

Four problems kept coming back, and each became a part of this series.

The first was what the picture is for. Asked as one question, “should a maintainer look at this now?” returns a single confident number and hides every reason behind it. Split into several narrow questions whose answers get combined by plain code, the same decision can be checked, argued with and changed.

The second was a small piece of punctuation. In a Jev question, a pair of backticks points the lens at one exact part of the state. Anyone who writes documentation also uses backticks for anything that looks like code, and the two habits collide.

The third was how sure the camera says it is. Jev reports a confidence with many of its answers, and it describes how crisp the picture came out. It cannot say whether the camera was pointed where the photographer meant. A perfectly focused photograph of the wrong building is still perfectly focused.

The fourth was who holds the camera. Most of our frames were first drafted by AI agents, which are fast, sure of themselves, and inclined to make the same choices every time.

Every photograph says something about the photographer. Some point the camera straight at what is in front of them, level and well lit. Others go looking for the odd angle and the thing at the edge of the scene. Frames carry their engineer the same way, and the rest of this series is about what each kind of frame catches and what it misses.

Jev evaluates exactly the state it is given against exactly the questions it is asked. Everything else about whether an integration decides well follows from how those two were chosen together. I put it in one line while recording a read-through of TypeSafe’s documentation for this work: frame engineering is state times questions.¹

A frame, and the answer it got

The state is a JSON object. The questions are typed (Choice, Score or Noul), and a question points at the part of the state it is about with a backticked path, the convention TypeSafe documents.² Here is one frame from this work. The issue report is synthetic, written for the triage traps described in Triage Map: its reporter has not found a feature that exists.

{
  "model": "jev-latest",
  "state": {
    "project": "Omarchy, an opinionated Linux desktop setup built on Arch Linux and the Hyprland window manager.",
    "issue": {
      "title": "BUG: cannot change wallpaper, feature is broken",
      "body": "The wallpaper feature is broken. I looked everywhere in the settings and there is no way to change the background image. Every Linux desktop has this. Please fix ASAP. Omarchy 3.1, fresh install."
    }
  },
  "questions": {
    "kind": {
      "type": "choice",
      "instructions": "What kind of item is `issue`?",
      "criteria": {
        "bug": "a defect: something behaves wrongly",
        "feature": "a request for new or changed behaviour",
        "support": "someone needs help; nothing is shown to be broken",
        "docs": "the documentation is wrong or missing",
        "other": "not a work item: spam, another project, or discussion"
      }
    }
  }
}

The answer, from a call run against hosted Jev for this series:³

{ "type": "choice", "choice": "bug",
  "probabilities": { "bug": 0.98, "feature": 0.01, "support": 0.01, "docs": 0, "other": 0 },
  "confidence": 0.98 }

155 ms, 482 input tokens. That is the wrong answer, and the report was written to invite it: the handling written down for this trap before any design existed is support, or a person, because nothing is broken. The frame never told Jev the feature exists, and Jev was 98% sure of an answer the frame had no way to make right. Frame Confidence is about that gap.

The focal point

Every frame in this series was built against Omarchy’s GitHub queue, snapshotted on 2026-09-24 with 1,964 open issues. The finished design reads each issue in about three calls and sorts the queue into piles (look now, ready for an agent, the fix belongs upstream, ask the reporter, park). The whole queue cost $0.47 in Jev calls.⁴ It is read-only: nothing was labelled, commented on or closed. Whether it sorts well is being checked against people’s judgment of 80 randomly drawn issues, on a public labelling page.

Four problems

Problem	The question it answers	Covered in
Decision shape	Which narrow questions, combined by what rule in code, make up the decision, and what should each answer look like before the first call?	Triage Map
Pointing	How does a question say which part of the state it means, and what happens when the pointer points at nothing?	Backticks
Confidence	What does Jev’s confidence measure, and who measures whether the frame says what its engineer meant?	Frame Confidence
Drafting	What can an AI agent be trusted to draft, including when to split a call, and what has to be measured instead?	Agent Drafting

The earlier Jev Engineering series covered what surrounds a frame: how calls are shaped and priced, what a state field claims, where Jev sits relative to the code that acts, and what a decision receipt keeps. This series is about the frame itself.

What would falsify this

The four problems are a claim about coverage from one subject in one day. They would be falsified by a frame failure on another issue queue that fits none of the four rows. A second project is chosen for exactly that test, and the set should be read as the map so far rather than a closed list.