How to Explore Ethen Research Lab: Programs, Evidence Labels and Reading Paths

The fastest way to read Ethen Research Lab well is to check two labels before reading anything else: the publication type (position paper, research note, proposal, technical report, methods paper, protocol, benchmark design, survey or system card) and the evidence status (measured result, synthesis, proposal, protocol, or external survey). Together they tell you what kind of claim the paper can make. Then filter the archive by research program to find papers on your topic, and use a reading path to follow a question from concept to benchmark to experiment. This guide explains each label, the programs, how related papers fit together, and where to start for your role.

Key takeaways

• Read the labels first. Type tells you what a paper is trying to do; evidence status tells you how much it has shown. None of the first 40 papers reports a new measured Ethen result.
• Programs group topics. Filter by program to see every paper on routing, recovery, context, trust, data or enterprise privacy.
• Topics come in families. Many subjects have a concept paper, a benchmark design and a protocol. Each answers a different question.
• Use a reading path. The flagship path and the role-based paths below give you a sensible order.
• Cite with the label. If you quote an Ethen paper, quote its evidence status too.

How is the Ethen Research Lab archive organized?

The Ethen Research Lab archive currently lists 41 publications: the 40 papers of the first library and the AgentTrustBench system card. You can filter the archive by research program and by publication type, and sort it newest first, oldest first, or with featured publications first.

The research programs are the durable areas of work:

• Adaptive Intelligence — whether AI systems can improve from verified experience, and how to measure transfer.
• Trust & Accountable AI Work — authority, records of work, data rights, and unknown outcomes.
• Evaluation & Verification — benchmark designs and how to check the checkers.
• Model Intelligence / Faros — routing, model change, and the economics of model choice.
• Data & Learning Systems — data defensibility, outcome data, skills and failure taxonomies.
• Context / Skills / Transfer — memory, context compaction and whether skills survive model upgrades.
• Enterprise / Sovereign AI — private evaluation, private improvement and cost per verified outcome.
• AI Security — a program the archive uses for security-focused work.

A paper can belong to more than one series. That is deliberate: a paper on data rights matters both to trust and to learning.

What do the publication types mean?

The publication type tells you what a paper is trying to do, and therefore what it cannot tell you. A position paper argues for a claim. A research note sharpens one idea. A proposal describes a mechanism and how it would be evaluated. A technical report specifies a design at the level of fields and invariants. A methods paper defines a way to measure something. A protocol pre-specifies an experiment. A benchmark design pre-specifies a benchmark. A survey organizes other people's work. A system card reports evidence about one specific build.

The most common misreading is treating a protocol or benchmark design as if it reported results. It does not. Thirteen papers in the first library are protocols or benchmark designs, and their pages say that no result may be claimed until the study is run. Where a working title implied results that did not exist, the Lab replaced it with a protocol title.

What do the evidence labels mean?

Evidence status is the strength of the evidence behind a paper's central claim. Ethen Research Lab uses five classes for its library:

• A — Measured Ethen result. Ethen ran an experiment or measurement on a stated build and published the method. No paper in the first library is in this class.
• B — Ethen research synthesis. An argument built from internal synthesis and external literature.
• C — Technical or architecture proposal. A proposed mechanism or design that has not been tested.
• D — Research protocol or benchmark design. A pre-specified study or benchmark that has not yet been run.
• E — External literature survey. Primarily a survey of other researchers' published work.

Inside a paper, individual numbers carry their own inline labels: a measured Ethen result, an external primary-source result, an illustrative example, a proposed target, a hypothesis, or an unknown. When a paper says "≥15% lower cost" it will also tell you whether that is a target we intend to test against or something someone measured. That distinction is easy to lose in a quotation, which is why we ask anyone citing our work to keep the label.

The one measured result in the archive — the AgentTrustBench system card — is a different kind of document. It reports what happened when a fixed set of boundary conditions was run against one pinned build. It explicitly supports no claim about other builds, populations or live traffic.

How are papers on the same topic related?

Many topics in the archive appear as a family of papers, each answering a different question. Recognizing the family saves time and prevents a common mistake: reading a concept paper as if it were the test of that concept.

The pattern usually has three members. A concept paper asks what is this and why does it matter? A benchmark design asks how would we compare systems on it? A protocol asks how would we test whether a specific claim about it is true?

A few families, as examples:

• Recovery. Recovery Atlas is the concept: when should an agent retry, reconcile, escalate or stop? VerifiedWork Recovery is the benchmark design that injects failures. Toward a Failure Genome of Software Agents proposes a taxonomy of failures. Testing Whether Recovery Knowledge Transfers Across Tools is the protocol.
• Model routing. Faros: Researching How Intelligence Should Choose Intelligence sets out the research agenda. Why Learned AI Model Routing Must Beat Good Rules surveys the literature. How to Test Whether Learned AI Routing Beats Strong Rules is the protocol, and Why AI Routers Should Log Propensities From Day One covers the data the protocol needs.
• Context and memory. Evidence-Preserving Context proposes how to compress context without losing obligations. VerifiedWork Context is the benchmark design and How Should We Measure How Much Context an AI Agent Actually Needs? is the protocol.
• Model change. Model Change Assurance is the concept: test an upgrade on your own past work before it reaches live work. A separate protocol asks whether such assurance actually predicts live outcomes, and another asks whether individual skills survive a frontier-model upgrade.

Each paper's "Related research" section names its family members with one line on why they are related, so you can move sideways without returning to the archive.

What is inside a typical paper?

Every paper follows the same broad structure, which makes papers faster to skim once you know it. At the top, under the title, is a one-sentence thesis in italics. Then comes an abstract of roughly 120 to 200 words that states what the paper does and does not show. The body is organized for the paper's type: a protocol has hypotheses, design, analysis plan and decision rules; a proposal has the problem, the mechanism, the evaluation plan and the risks. Every paper has a Limitations section, and most have a short FAQ for the questions readers actually ask. Figures carry an evidence badge — conceptual diagram, qualitative matrix, proposed architecture, experiment design, taxonomy, or an explicit "illustrative, not measured" label — and none of them plots numbers as if they were Ethen data.

A practical reading order for a single paper: thesis line, abstract, evidence status, Limitations, then the body. If the limitations section would change whether you rely on the paper, you have learned that before investing in the details.

Where should I start?

There are two good starting points: the flagship path, which follows the program's central argument, and role-based paths.

The flagship path walks through the program's main argument in order. It begins with Verified Adaptive Intelligence, the thesis that AI systems should learn only from work that is verified, rights-cleared and shown to transfer. It continues to From AI Traces to Verified Experience, which explains why logs are not yet learning data; Work Receipts, a proposed per-task record of authority, actions, effects, verification, cost and rights; and Commitment Graphs, which defines false completion. It then moves through recovery, the VerifiedWork benchmark designs, Faros, capability transfer, model change assurance, tenant replay and private improvement, ending with the sovereign improvement protocol.

If you build agents that act, start with Unknown Effects in Autonomous AI Systems (why a timeout is not permission to retry), then Recovery Atlas, Mandates (how human intent becomes bounded authority) and Evidence-Preserving Context.

If you choose or change models, start with Faros, then the routing survey, Model Change Assurance and Cost Per Verified Outcome, which argues that cheaper tokens do not always mean cheaper finished work.

If you evaluate or buy AI systems, start with Ethen VerifiedWork, then Evaluating the Evaluators: Reward Integrity for AI Agents, Tenant Replay (evaluation inside an organization's own boundary) and Private AI Improvement Without Raw Data Export.

How do I read a protocol or benchmark design?

Protocols and benchmark designs are the least familiar type for most readers, and they reward a specific reading order. Five questions will get you most of the value.

What exactly is being compared? Look for the arms or conditions. A good protocol compares a new method not only against doing nothing, but against the strongest simple alternative — for example, a learned router against carefully written rules rather than against "always use the most expensive model". If the comparator is weak, a positive result will mean little.

What counts as success, and who decides? Find the primary outcome and the verifier that judges it. Our designs prefer deterministic checks of the resulting state where they exist, and they ask that graders' error rates be measured. A result is only as good as the judgment behind it.

What would count against the hypothesis? Every protocol in the library states a falsifier or a decision rule fixed before the study. If you can find that sentence, you know what the authors have committed to accept.

What is held out? Generalization is the hard part. Look for splits by task family, tool version or failure mechanism rather than random rows, and for a sealed set managed by someone other than the authors.

What does it explicitly not prove? Benchmark designs in the VerifiedWork series each include a statement of what their scores cannot prove — for example, that a good score on control tests does not certify compliance. Read that section before quoting any future score.

These questions also work for anyone else's agent research. They are a compact way to tell a test that could fail from a demonstration that could not.

How should I cite an Ethen Research Lab paper?

Cite the canonical URL under /resources/research/, the title, "Ethen Research Lab" as the author, the year, and — most importantly — the publication type and evidence status. For example: Ethen Research Lab (2026). Commitment Graphs: Why AI Agents Need to Know What Is Still Unfinished. Research proposal; untested. If you quote a number, include its inline label. A proposed target quoted without its label reads like a result, and that is the misreading the labels exist to prevent.

Our Blog follows the same rule when it draws on research: it links the canonical paper and repeats its evidence status. Why we keep research and product claims apart is explained in Why Ethen Keeps Research Separate From Product Claims.

Common misreadings to avoid

• "Ethen has a benchmark, so it has benchmark scores." VerifiedWork and its four tracks are benchmark designs. They have not been run and report no scores.
• "The paper describes a system, so Ethen has built it." Proposals and technical reports describe designs. They do not establish implementation.
• "A survey's numbers are Ethen's numbers." Surveys and syntheses report external results, labeled as external primary-source results.
• "The system card shows Ethen is safe." It reports one enumerated condition set on one pinned build and supports no population or live-traffic claim.
• "A threshold in a protocol is a promise about performance." It is a bar a future result must clear.

Limitations of this guide

This guide describes the archive as it stands in October 2026. Programs, types and filters may change as the archive grows, and reading paths reflect editorial judgment rather than any measure of which papers are most important. Every paper listed here is research, not a product description.

Frequently asked questions

Does Ethen Research Lab publish measured results? The archive's only measured Ethen result so far is the AgentTrustBench system card for one pinned build. The 40 papers of the first library are syntheses, proposals, protocols, benchmark designs and surveys.

What is the difference between a research proposal and a research protocol? A proposal describes a mechanism and how it might be evaluated. A protocol pre-specifies a particular experiment — hypotheses, design, metrics, analysis and decision rules — so that its result can be judged against a plan fixed in advance.

Why are some topics covered by three or four papers? Because the concept, the benchmark and the experiment answer different questions. Families let each paper stay focused.

Related reading

• Why Ethen Research Lab Publishes Its Work in Public
• What We Learned Publishing 40 Research Papers at Once
• Agent Verification and Evaluation — hub page with research listed by evidence status.

References

1. Ethen Research Lab (2026). Research Publications V1 and AgentTrustBench system card. Archive. https://upcube.ai/resources/research
2. Ethen Research Lab (2026). Verified Adaptive Intelligence: Learning From Work That Can Be Proven. Position paper; research synthesis. https://upcube.ai/resources/research/verified-adaptive-intelligence
3. Ethen Research Lab (2026). Recovery Atlas: Teaching AI Agents When to Retry, Reconcile, Escalate, or Stop. Research proposal; untested. https://upcube.ai/resources/research/recovery-atlas
4. Ethen Research Lab (2026). Ethen VerifiedWork: A Benchmark Framework for AI Systems That Take Action. Benchmark design; not yet run. https://upcube.ai/resources/research/verifiedwork-benchmark