How We Decide Whether Something Belongs in Blog, Docs, or Research
We decide between blog, documentation and research by asking what the reader came to do. If they want to use something — set it up, call an API, complete a task — it belongs in Docs. If they want structured facts about a model, it belongs in the Model Library. If they want to know what was found or proposed, it belongs in the Research Lab, typed and labeled with its evidence status. If they want to understand what Ethen is building and how it works, it belongs on the Blog. And if they want to know who Ethen is and why it makes the choices it does, it belongs in Company publishing. Each surface has its own evidence standard and freshness rule, and one topic can appear on several surfaces as long as each page owns one question. This article explains the rules and why they matter.
We decide between blog, documentation and research by asking what the reader came to do. If they want to use something — set it up, call an API, complete a task — it belongs in Docs. If they want structured facts about a model, it belongs in the Model Library. If they want to know what was found or proposed, it belongs in the Research Lab, typed and labeled with its evidence status. If they want to understand what Ethen is building and how it works, it belongs on the Blog. And if they want to know who Ethen is and why it makes the choices it does, it belongs in Company publishing. Each surface has its own evidence standard and freshness rule, and one topic can appear on several surfaces as long as each page owns one question. This article explains the rules and why they matter.
Key takeaways
- Route by the reader's question. Not by the writer's team or the topic.
- Five surfaces, five promises. Docs, Model Library, Research Lab, Blog and Company each promise something different.
- Each surface has its own evidence standard. Docs must match current behavior; research must state evidence status.
- Each surface has its own freshness rule. Some pages update constantly; others are dated records.
- One topic, several pages, one question each. Pages link to each other instead of competing.
Why routing matters
Where a piece of writing is published changes how it is read. The same sentence means something different in documentation, where readers assume it describes how the product works today; in a research publication, where they assume it reflects evidence; and in a blog post, where they understand it as explanation or direction.
When content ends up on the wrong surface, readers are misled even if every sentence is accurate. A research proposal published as a blog post reads like a product announcement. A product direction published in documentation reads like a feature that exists. An engineering explanation buried in a research paper is hard for practitioners to find.
There is also a practical cost. When several pages on different surfaces try to answer the same question, they compete with each other in search, and readers — and AI assistants summarizing the site — cannot tell which one is authoritative.
The five surfaces
Ethen publishes across five surfaces. Figure 1 shows how a piece of writing is routed by the reader's question.
Docs: "How do I do this?"
Documentation helps people operate Ethen: getting started, using workspaces, calling the gateway, understanding models, configuring security and enterprise settings. Its readers are trying to complete a task, often under time pressure.
A widely used framework for documentation, Diátaxis, distinguishes four kinds of documentation by user need: tutorials for learning by doing, how-to guides for completing a specific task, reference for looking up facts, and explanation for understanding why. The first three are firmly Docs territory. Explanation is the interesting case: short explanations that help someone use a feature belong in Docs, while longer explanations of design decisions and trade-offs often belong on the Blog.
Model Library: "What is this model?"
The Model Library holds structured pages about models and model families: what they do, which tasks they support, what is known about them and what is not. Its readers want facts they can compare. Its standard is sourcing: each fact has an owner and a source, and unknown values are shown as unknown rather than filled in. We describe how model families are grouped in From Provider Endpoints to Ethen Model Families.
Research Lab: "What was found or proposed?"
The Research Lab holds original research: position papers, research notes, proposals, protocols, benchmark designs, methods papers, technical reports, surveys and system cards. Every publication states its type and evidence status at the top. The rule is firm: original research — a benchmark, an experiment, a measured result, a protocol, a proposal, a system card — does not get published as an ordinary blog post. We explain the format in Why We Made Ethen Research Look More Like a Journal Than a Blog.
Blog: "What are you building, and how does it work?"
The Blog explains what Ethen builds and how: product direction, engineering mechanisms, models, infrastructure, security, developer workflows, practical guides and category education. Its readers want to understand. Its standard is that public facts are stated as facts, direction is labeled as direction, and research is cited with its evidence status rather than restated as a finding.
Company: "Who is Ethen, and why?"
Company publishing explains what Ethen and Upcube are, why Ethen exists, its product philosophy, major decisions, milestones and long-term direction. Its readers want to understand the organization behind the products. Its standard is that philosophy is labeled as philosophy and milestones are dated.
Each surface has its own standards
Because each surface promises the reader something different, each needs its own evidence standard and freshness rule. Figure 2 summarizes them.
Docs must match current product behavior. A docs page that describes a feature that has changed is a bug, and it should be updated with the product.
Model Library facts must be sourced, with unknowns shown honestly, and refreshed as sources change.
Research Lab publications must state type and evidence status on every page, and must change visibly — with dated notes and version history — rather than silently.
Blog posts state public facts and label direction. They are dated, and each has a freshness class that decides how often it is reviewed: some are evergreen guides, some are evolving product explanations that need regular review, and some are dated records — like a release-day explanation — that should not be silently rewritten.
Company pages hold stable principles and dated milestones.
One topic, several surfaces
Most important topics deserve coverage on more than one surface. The trick is to make each page answer a different question about the topic and link to the others. Figure 3 shows a real example: what an AI system should do when it does not know whether an action succeeded.
In the Research Lab, a research note — Unknown Effects in Autonomous AI Systems — argues the general principle that a timeout is not permission to retry.
On the Blog, an engineering post — When an Agent Action's Outcome Is Unknown — explains how a specific Ethen mechanism keeps an uncertain effect and resolves it only with evidence.
Also on the Blog, a guide — What Makes an AI Agent Job Verifiable — includes honest unknown-outcome recovery as one item in a practical checklist.
In Docs, a page would describe what a user sees when an outcome is unknown and what to do about it, once that behavior is part of the product.
None of these pages competes with the others. Each owns a distinct question, and each links to the rest. A reader can enter at any point — the principle, the mechanism, the checklist or the task — and find the others.
A second example: the AgentTrustBench system card reports a measured result in the Research Lab, while a Blog article, Why Ethen Uses System Cards and Research Notes Differently, explains how to read it. The Blog article never restates the result as anything broader than the card does.
Three routing decisions, walked through
The rules are easiest to understand in use. Here are three decisions of the kind we make regularly.
How a voice session starts. The engineering explanation — which server checks run before a voice session begins, what the browser receives and why long-lived keys stay on the server — was published on the Blog as How Ethen Chat Starts a Voice Session. It is an explanation of a mechanism for technically curious readers, so it is Blog. If a user needs to know how to enable their microphone or what to do when voice is unavailable, that is a task, and it belongs in Docs. Neither belongs in the Research Lab: nothing was measured or proposed as research.
How many models the catalog contains. Counts of provider endpoints, model families and indexable pages, and the reasoning behind grouping them, are an explanation of how the catalog works, so they were published on the Blog in From Provider Endpoints to Ethen Model Families. The facts about each individual model family live in the Model Library. The Blog post links to the Library rather than repeating model facts that will change.
A new benchmark. If Ethen designs a benchmark, the design itself is research: it goes to the Research Lab as a benchmark design, labeled as not yet run. A Blog post can then explain why the benchmark matters and how to read it, citing the design with its status. When the benchmark is run, the results are research too, and they get their own publication with method, scope and limits. The Blog can explain them afterwards, but never as more than the results support.
In each case the deciding question was the same: what will the reader do with this page? Understand a mechanism, look up a fact, complete a task, or weigh evidence.
Routing rules we apply
A few rules settle most routing decisions.
Original research goes to the Research Lab. If the main contribution is a benchmark, an experiment, a measured result, a protocol, a proposal or a system card, it is research, regardless of who wrote it or how short it is.
Task instructions go to Docs. If the reader will follow steps, it is documentation.
Structured model facts go to the Model Library. Model comparisons and explanations of how to choose can go on the Blog, linking to the Library for the facts.
"Why we chose this" usually goes to Company or the Blog. Company for organization-level choices; Blog for product and engineering choices.
Direction is labeled wherever it appears. A product direction can be explained on the Blog or in Company publishing, but never in Docs as if it were available.
When in doubt, ask what would mislead. If placing a piece on a surface would make a reader believe something stronger than the evidence supports, it is on the wrong surface.
How routing helps search and AI assistants
Search engines and AI assistants increasingly answer questions by drawing on one or two pages. Clear routing helps them pick the right one. Documentation pages answer how-to questions, research pages answer evidence questions, and blog pages answer explanation questions. Because each page owns one question, the site is less likely to compete with itself, and the page an assistant quotes is more likely to carry the right qualifiers — a research page's evidence status, a docs page's current behavior, a blog page's "this is direction".
Search guidance from Google has long emphasized content created to help people rather than to rank. Routing by the reader's question is one practical way to apply that: the page exists because a reader has that question, and it lives where readers with that question expect to find it.
Edge cases
Some content does not route cleanly.
Engineering write-ups with measurements. If an engineering post reports a measured result, the measurement may deserve its own research publication, with the post linking to it.
Release notes. Dated records of what changed in a release are closest to documentation but carry company-level significance for major releases. They are dated and not rewritten.
Guides that compare products. A practical guide comparing approaches belongs on the Blog, even when it mentions Ethen products, as long as it is useful to readers who do not choose Ethen.
Philosophy that becomes policy. When a stated principle becomes a commitment users rely on — for example, how data is used — it needs a home in documentation or legal pages, not only in a blog post.
Tradeoffs and limitations
Some topics are split across pages. Readers sometimes have to follow a link to get the full picture. Clear links mitigate this.
Routing takes judgment. The rules settle most cases; edge cases need editorial decisions.
Surfaces evolve. As Ethen grows, the boundaries between surfaces may shift, and the rules will be updated.
Rules do not guarantee accuracy. Correct routing helps readers interpret a page; it does not make the page correct.
FAQ
What's the difference between a company blog and documentation? Documentation helps people use a product and must match current behavior. A blog explains what a company is building, how and why, and labels direction as direction.
Where should a company publish research? In a dedicated research section where each publication states its type and evidence status, not as ordinary blog posts.
How do you decide where content goes? Ask what the reader came to do: use something (Docs), look up a model (Model Library), learn what was found (Research), understand what is being built (Blog), or understand the organization (Company).
Can one topic appear in several places? Yes, if each page answers a different question about it and links to the others.
What is Diátaxis? A documentation framework that separates tutorials, how-to guides, reference and explanation according to what the user needs at the time.
Related reading
- Why Ethen Keeps Research Separate From Product Claims
- Why We Made Ethen Research Look More Like a Journal Than a Blog
- Why Ethen Uses System Cards and Research Notes Differently
- Inside the Redesign of Ethen's Research Publications
- Ethen Docs
References
- Procida, D. Diátaxis: a systematic approach to technical documentation authoring. https://diataxis.fr/
- Google Search Central. Creating helpful, reliable, people-first content. https://developers.google.com/search/docs/fundamentals/creating-helpful-content
- Ethen Research Lab (2026). Unknown Effects in Autonomous AI Systems: Why Timeouts Are Not Permission to Retry. Research note. https://upcube.ai/resources/research/unknown-effects
- Ethen Blog. When an Agent Action's Outcome Is Unknown. https://upcube.ai/blog/when-an-agent-actions-outcome-is-unknown
- Ethen Research Lab (2026). AgentTrustBench system card. https://upcube.ai/resources/research/agent-trust-boundaries