qmuloA closer look / PODL
Make fewer mistakes
part of the process.
PODL (Portable Operation Definition Language) is a document specification for operations and tools that describes how multiple steps fit together. It builds on the Model Context Protocol (MCP). Its design targets models in the 3–32B range, including deployments that use different specialists for different roles. A runtime executes that description, using models where judgment is needed and deterministic processes where it isn’t.
01 / Define the work
Make a useful workflow repeatable.
An operation includes the tools available at each step, the choices that lead to the next step, and the paths for empty results or failures. PODL makes those relationships explicit in a reusable document. Research is one example:
- FindGather promising sources.
- ReadExamine the relevant material.
- AnswerConnect the response to its sources.
- VerifyReview the answer independently.
The document defines the process; a runtime supplies model integration and executes its steps. Our reference implementation uses constrained generation to enforce the permitted formats and choices at defined boundaries.
In the reference implementation, the final step is a verification operation running as a PODL aside—a subagent with its own defined context. It receives the original question, available tools, gathered sources, and proposed answer, but not the author’s reasoning. That separation keeps the reviewer focused on the evidence and answer instead of the path that produced them.
PODL also supports advisory specialty hints. An operation can identify roles such as retrieval, vision, coding, or review, allowing a runtime to route each role to a model that fits the environment and cost. Routing is formally represented in the specification; our reference runtime does not yet implement it.
Why define operations as documents?
MCP provides the underlying tool interface. PODL extends it with contracts for tools and their results, including source references and handling policies, and a specification for coordinating those tools into whole operations.
A document can be inspected, revised, reused, and composed with other operations. Its meaning should hold across conforming runtimes. Model integration, execution mechanisms, and inspection interfaces belong to the implementation; PODL is not itself a server.
02 / Remove failure modes
Don’t ask a model to copy what a tool can pass exactly.
A model may understand which result it needs and still mistype a long identifier or timestamp. A handle gives it a short reference to select, allowing the runtime to carry the underlying value to the next tool unchanged.
PODL lets tool authors require a particular handle type and operation authors restrict where that type is offered. Our reference runtime uses those definitions to limit the available choices. A step that needs a time reference need not accept a document reference or a model-written date.
Which mistakes does this remove?
In this example, the model no longer has to copy a timestamp or construct one in the right format, and it cannot pass a document reference where a time reference is required. The same principle applies to the flow of work: when the next step is already known, a defined transition removes the need for another model decision.
A correctly typed reference can still point to the wrong time. These constraints eliminate particular failure modes; they don’t make every decision correct. Evaluation still needs to check whether these constraints improve the operation’s results.
03 / Keep the source
Keep answers connected to their sources.
PODL gives tools a way to identify sources, describe their results, and declare how those results may be presented. Source handles are part of the specification; retaining and exposing evidence is work the runtime performs using those contracts.
Our reference implementation retains original source material while presenting selected portions to the model. It restricts citations to collected sources and resolves those references for the reader. Another runtime may provide a different inspection interface, or none at all.
How are citations and reduced views constrained?
In our implementation’s constrained citation output, the model cannot invent a source identifier outside the collected set. Its context reduction selects from source text, so that step cannot introduce newly generated claims.
The model can still misunderstand a source or cite the wrong one. Source traceability makes those errors inspectable; review addresses whether the evidence actually supports the statement.
04 / Define the context
Let the people who know the work decide what matters.
Context management can be formally defined as part of a PODL operation. Tool authors can describe how their results should be retained or reduced; operation authors can define what information each part of the work receives. Authors can use their knowledge of the task to decide what must stay available and what can be reduced.
A search tool may need to preserve promising leads, while a review operation may need the complete source behind a claim. Those needs can be expressed in the documents, giving the runtime explicit policies to execute instead of relying entirely on a general context-management heuristic.
How do subagents and context pressure fit in?
Asides are subagent operations with a defined input and a separate context. An operation author can specify what an aside receives and which decisions it returns, so a focused judgment need not bring all of its working material into the parent’s context.
The same approach makes context pressure an operation-design problem: define what can be reduced or set aside, when a subagent should judge relevance, and how information can be retrieved again. Predictable steps can follow fixed rules, with model judgment reserved for choices that need it.
Our reference runtime implements retention policies and defined inputs for sub-operations. Automatic eviction and recovery under context pressure are still in development.
05 / Check the result
Review the answer against the original sources.
PODL allows one operation to request a review from another. Our reference implementation includes review operations that check statements against original sources, assess citation choices, and judge whether the response addresses the question.
Each review document defines what the reviewer receives. In our implementation, the review runs over the evidence and result without the author’s reasoning, helping it assess the work independently. This small, separate reviewer has already shown a meaningful reduction in hallucinated and misattributed claims, even when the reviewing model is small.
What happens when the work falls short?
Our reference implementation currently applies citation repairs and records flagged statements. Automatically sending an answer back for another attempt is still in development.
When an operation stops without an answer, our runtime can return an account assembled from its actual tool calls. That record helps reveal missing information or a misunderstood request.
06 / Research direction · Not yet implemented
An operation that improves operations.
The longer-term goal is to use feedback on good and bad outcomes to revise the process that produced them. Given a failed request and a successful one, an improvement operation would examine where their paths differed and look for a change that rules out the observed failure.
This is the approach to reinforcement learning we want PODL to facilitate: apply the learning signal to the operation’s definition. The first question is whether a better tool contract, a constrained choice, or a defined transition can make the bad result impossible, before considering model training to make it less likely.
What would the improvement cycle look like?
An operation running on a supporting runtime would compare outcomes and propose a revised PODL document. If a failure came from a copied value, for example, the revision could require a typed handle and remove the free-text path that allowed the error.
The proposed operation would then be evaluated against both failed and successful cases to check whether it removes that failure while preserving useful behavior. Some failures will still require model judgment; the goal is to remove the ones the process can prevent.
People improve their own processes this way: learn from a mistake, change the procedure, and check that the change helps. Portable operation documents give us a concrete place to make and inspect those changes. This improvement cycle is an aspiration, not a capability of the current reference implementation.
07 / Measure what helps
Every added step has to earn its place.
We evaluate changes to our runtime and operation documents using questions with known answers and source attributions, across multiple small models. Review operations are tested separately: a reviewer approving more answers does not establish that those answers are better.
These results guide development; broader testing is needed to establish how well they generalize.
Discuss the details with us.
We can walk through the architecture, evaluation methods, current limitations, and fit for your use case under NDA.
Request more information