Core concepts overview

The concepts section provides the vocabulary needed to reason about Ethen without blending product surfaces or execution stages. Use it before designing a workflow, evaluating a model route, or reviewing an output that crosses workspace, provider, agent, tool, and evidence boundaries. The concepts are grounded at platform level; product-specific runtime details and administrative behavior remain subject to later documentation and current implementation status.

How to use this section

Read the concepts in the order that matches your question rather than treating them as a single architecture specification.

• Start with Organizations, workspaces, and projects when you need to understand where work is grouped and which hierarchy details are still unknown.
• Use Sessions and context to separate a bounded interaction from the broader material associated with a workspace.
• Read Models and providers when catalog presence, provider configuration, runtime status, routing, or fallback is involved.
• Continue to Agents and capabilities and Tools and integrations when work may involve bounded action rather than a direct model response.
• Use Runs, receipts, and artifacts to identify the record of an attempt and the outputs preserved from it.
• Finish with Read, Propose, Approve, Execute when the task can change state or requires explicit review.

Each page owns a distinction. Refer back to the owning page instead of repeating a shortened definition until it loses its boundary.

The concepts section explains the stable mental models that connect Ethen products. It is not a substitute for product-specific setup or API documentation.

Read the hierarchy pages to understand where work is organized, the model pages to understand provider and status truth, and the control pages to understand how visible proposals, approvals, and evidence should relate. Follow task guides when you need an exact procedure.

Platform hierarchy

Ethen’s shell recognizes workspace-oriented concepts, projects, sessions, artifacts, approvals, audit logs, policies, observability, MCP, models, and agent runs. That navigation evidence shows the intended vocabulary but does not fully establish containment, tenancy, inheritance, or permissions.

A conservative hierarchy model is:

Use this model for orientation only. When access or isolation matters, the current product and policy sources must supply the definitive answer.

The current shell recognizes workspaces, projects, sessions, artifacts, and several operational destinations, while approved copy describes workspace context as the connection between prompts, files, outputs, decisions, and evidence.

The inspected sources do not establish the exact organization hierarchy, ownership model, inheritance, or isolation boundaries. Use the terms for orientation and never treat route recognition as proof of tenancy or permissions.

Execution model

Ethen work can range from read-only research to a state-changing external action. The execution model therefore begins by identifying the stage that actually occurred.

A Model Intelligence comparison is research. A Model Library filter is catalog inspection. A Gateway request may produce a model response if configuration supports it. An agent or workflow may prepare a proposal, but Batch 01 does not establish the detailed runtime that would execute tools or integrations.

The stages can be viewed as a progression:

1. Observe: inspect catalog, profile, context, or current state.
2. Select: choose a product, model, provider, or route using available evidence.
3. Request or propose: ask for an output or prepare a candidate action.
4. Review: evaluate quality, status, evidence, and the intended effect.
5. Approve and execute: proceed through the owning product’s control boundary when a state change is supported.
6. Record: preserve the result as a response, receipt, artifact, route decision, tool output, or verification note where available.

Not every task reaches every stage. Research can end after review; a blocked Gateway request may end with a status; a proposal can remain intentionally unexecuted.

A supported task can begin with context, move through model selection, produce visible work, and reach an approval boundary before a sensitive action.

This execution model is deliberately conceptual. It does not define a universal state machine, retry policy, tool protocol, or guarantee that every surface can execute actions. Product-specific batches own those contracts.

Control model

The canonical control phrase is Read → Propose → Approve → Execute. It prevents a request for analysis from being treated as permission to act.

Read gathers or inspects permitted information. Propose produces a candidate change or plan. Approve authorizes the candidate through the control supported by the product. Execute performs the approved action. Evidence should make it possible to tell which stage occurred.

This separation is especially important when an agent has access to tools, credentials, or external systems. Capability answers “can this type of work be represented?” Permission answers “may this actor use it?” Configuration answers “is the connection ready?” Approval answers “has this specific action been authorized?” Execution evidence answers “did it actually happen?”

Batch 01 does not define role names, universal approval controls, or every execution state. Use the pattern as a platform boundary and defer exact mechanics to the relevant product guide.

The approved control language separates reading, proposing, approval, and execution. This separation helps a reader distinguish analysis from an action that changes external or persistent state.

Approval must not be implied by silence or by a prior unrelated action. When implementation evidence is absent, documentation should describe the boundary rather than claim a specific approval card, role, timeout, or escalation flow.

Evidence model

Ethen’s approved language emphasizes visible work, evidence, and receipts. Evidence can include request history, referenced context, route decisions, logs, tool outputs, source files, extraction confidence, notes, and verification results, depending on the surface.

Different evidence answers different questions:

• A source file supports where catalog or profile data came from.
• A status communicates current catalog or configuration state.
• A route decision explains which model lane or processing path was selected when exposed.
• A receipt summarizes a request, route, action, or outcome.
• An artifact preserves a useful output from the work.
• A quality flag warns that profile data is missing, limited, or uncertain.

Evidence should be read together with time and scope. A current status can change. A benchmark applies to a defined test. A receipt describes one attempt. A normalized profile may omit fields that were not available in its source.

Evidence and receipts are intended to keep the path from request to result inspectable. Relevant material may include referenced context, model or route choices, logs, tool outputs, and verification notes where the surface exposes them.

Evidence supports review; it does not make the result automatically correct. Retention, immutability, export, and legal effect are not defined by this batch and must not be inferred.

Related concepts

Several pairs are easy to confuse:

Workspace context and model context window. Workspace context is the material associated with work. A context window is a model capacity field. The workspace may hold more material than one request can use.

Model and provider. The model identifies the system being requested; the provider identifies the configured access source. One does not replace the other.

Capability and availability. A model can have a capability family while remaining catalog-only, missing a key, or unsupported for the requested modality.

Run and artifact. A run is an attempt; an artifact is an output preserved from work. One run may produce no artifact, and an artifact may be reviewed after the run ends.

Receipt and benchmark. A receipt records an event or request; a benchmark records measured model performance under a test.

Research recommendation and routing decision. Model Intelligence can present a derived verdict or routing suggestion. That presentation logic is not the same as a runtime route and must not be treated as guaranteed truth.

Use these distinctions consistently across the documentation set. They allow a reader to trace a claim back to the layer that can actually support it.

Organizations, workspaces, projects, sessions, models, providers, agents, tools, runs, receipts, artifacts, and approvals form the vocabulary used across later documentation.

Use the glossary for concise definitions and the dedicated concept pages for boundaries. When a term has limited evidence, keep the limitation visible rather than filling it with a familiar industry meaning.