Why REM is choosing decision models for engineering memory

Engineering memory has an efficiency problem of its own. A system built to spare a team repeated investigation can spend so much processing each finding that it gives some of the saving back. Decision models are part of how we plan to address that in REM.

We have selected TypeSafe's Jev as the default for bounded language judgments: questions where the relevant material is available and the possible answers can be defined in advance. Generative models still have a job wherever the work calls for new text, synthesis, or deeper reasoning.

This is a design choice. REM is at the design stage, and we have no production cost or latency results to report. What we can explain now is why the choice fits engineering memory, and what would have to hold for it to be useful.

Many memory decisions have a small answer

A useful engineering memory system needs to distinguish a new finding from a restatement, relevant context from a distraction, and a supported statement from an inference that goes beyond its evidence. Those are language problems, but they do not all require a written explanation.

Consider a fictional pair of findings:

The importer rejects files with an empty header row.

A blank first row causes the file import to fail.

The wording differs. The findings may describe the same condition. A third finding, "The importer rejects files with an unknown column name," shares most of the vocabulary but concerns a different condition. Combining all three would erase a distinction that could matter to the next engineer.

The useful question is specific: do these findings describe the same condition, different conditions, or is there not enough information to tell? An application can define those answers before making the request.

TypeSafe describes Jev as a model that reads natural-language input and returns typed decisions and probabilities. It supports choices, scores, and yes/no judgments. It does not generate prose or explanations of its reasoning.

A generative model can also produce structured output. The reason to choose a decision model is the fit between the work and the model, not the discovery that software can read JSON. We still have to establish that it makes the decisions well.

Where that fits REM

REM, Reconciled Engineering Memory, is being built to preserve what a team learns and make that knowledge useful to the next engineer or coding agent. As we explain in agent memory is not retrieval over your codebase, finding a passage and knowing what to conclude from it are different jobs.

Three kinds of judgment make the case for decision models concrete:

• Comparing findings. Recognising that two accounts express the same lesson, while preserving a meaningful difference or exception.
• Assessing evidence. Judging whether supplied material supports a particular statement, contradicts it, or leaves the question open.
• Selecting context. Judging which available findings are relevant to the task an engineer or agent is working on.

These are intended uses, not a list of shipped features. They also have boundaries. A model can assess the meaning of a test report; it cannot make an unexecuted test pass. It can judge whether a finding is relevant; that does not establish who is allowed to read it. Exact comparisons, permissions, and other facts software can establish directly belong in code.

Writing a new account of an investigation is a different task again. It needs synthesis. So does explaining a subtle exception that cannot be captured by the available choices. That is where generative models remain useful.

The saving has to survive the whole task

Our efficiency argument has two parts.

First, repeated narrow judgments should not automatically incur the work of generating an answer in prose. The input should contain what the decision needs, and the output should serve the next action. Where several independent questions concern the same material, Jev supports evaluating them together. Questions that depend on earlier answers still need to happen in order.

Second, better selection could reduce what the downstream coding agent has to read. A useful finding with its evidence and relevant exceptions can be more valuable than another large collection of loosely related text. The purpose is to help the agent avoid investigating something the team already learned.

Neither saving follows merely from choosing Jev. A cheap first call that sends almost every case to an expensive second call may increase the bill. A filter that removes useful findings can make a prompt shorter while making the task harder. Losing the exception that would have prevented a mistake is a poor trade for fewer tokens.

We therefore plan to measure the complete task: processing cost, response time, how often another model or a person has to step in, useful knowledge missed, and whether the resulting context helps the coding agent complete its work correctly. The comparison must include simpler rules and generative models asked the same questions.

Confidence is a routing signal, not evidence

A narrow output is easy for software to handle. It can still be wrong.

TypeSafe's confidence documentation distinguishes the probability distribution over answers from the confidence summary returned for choices and scores. A confident selection does not prove a statement about a codebase. It describes the model's assessment of the question it was given.

For REM, that distinction is essential. Two findings agreeing with each other does not prove either one is true. A model recognising agreement does not add another independent source. The basis for trusting a finding still has to be available for inspection.

Uncertainty also needs an explicit place to go. If the available evidence cannot settle a question, gathering more evidence or leaving it unresolved is a valid outcome. Choosing the closest available answer is not always useful. We will need examples with known outcomes to establish which judgments can proceed reliably and which need further review.

What we are trying to make cheaper

The goal is to make useful team knowledge affordable to maintain and consult as engineering work accumulates. Model selection matters because that work contains many small judgments, repeated over time, alongside a smaller number of problems that deserve substantial reasoning.

Jev is our chosen tool for the bounded judgments in that design. Its value to REM will depend on the quality of those judgments and their effect on the complete workflow. We will report savings when we have measured them.

If your team is already using coding agents and keeps paying to rediscover its own findings, join the REM private beta.