Ethen terminology and glossary

This glossary defines the terms used throughout Batch 01. Use it when two pages appear to use similar language for different layers, especially around models, providers, context, status, approvals, and evidence. Definitions are intentionally narrow: they reflect the supplied platform copy, model-catalog types, Model Intelligence implementation, and shell concepts rather than general industry usage.

Platform terms

Upcube The company that produces Ethen.

Ethen Upcube’s model workspace for builders working across flagship, open, and local model lanes. Ethen includes connected product surfaces rather than one universal chat interface.

Model workspace The product category used for Ethen. It describes an environment where model selection, permitted context, reviewable work, approvals, evidence, and outputs can be organized.

Surface A product area or interface with its own responsibility and availability state. A surface may be live, preview, mock, or setup-required.

Workspace A context for organizing work. The current sources support workspace-level prompts, files, artifacts, decisions, evidence, and review notes where implemented, but do not define the complete hierarchy or permission model.

Project A recognized shell concept for grouping work. Exact containment, lifecycle, and isolation behavior are not verified in this batch.

Session A bounded unit of interaction or work context. Persistence duration and retention are not defined here.

Workspace context The permitted information associated with work in a workspace, which may include prompts, files, artifacts, decisions, evidence, and review notes.

Use platform terms consistently in headings, interface copy, and cross-references. Stable wording allows readers to compare the console, model surfaces, Gateway, and later product documentation without confusing their responsibilities.

Use the platform terms definitions consistently across pages. Do not add permissions, retention, security, availability, or execution meaning unless the owning implementation or policy source supplies it.

Model terms

Model A named model record or normalized profile. A model may be represented differently in the Gateway catalog and Model Intelligence.

Provider The organization or configured source associated with access to a model. Provider presence does not by itself prove that a model is runnable.

Model ID The identifier exposed by the catalog for a model record. It can be copied from Model Library when present.

Model alias A name that may refer to another model identifier or route. Alias resolution behavior must be verified by the owning implementation.

Capability family The catalog’s broad classification for supported work. Verified values are text, code, image, video, embedding, rerank, realtime, speech, transcription, reasoning, long-context, and unknown.

Modality The type of input, output, or interaction a model can handle. A capability-family label is a useful signal but not proof of universal modality support.

Context window A catalog or profile field representing model context capacity when available. Missing values remain unknown.

Maximum output tokens A represented output-limit field when supplied by the underlying data. It can change and requires current verification.

Catalog-only The model appears in the catalog without a verified configured execution path.

Provider-configured A provider relationship is configured, but the intended request still requires confirmation.

Runnable The strongest verified catalog status for current execution readiness. It does not guarantee every account, region, modality, or workload.

Unsupported-modality The selected access path does not support the requested modality.

Missing-key A required provider credential is absent from the current configuration.

When a model term has a broader industry meaning, use the Ethen definition here for this documentation set. Add product-specific detail only when the owning implementation provides the necessary evidence.

Agent and workflow terms

Agent A platform-level actor that can be described through a goal, available capabilities, context, tools, permissions, and boundaries. Detailed runtime semantics belong to the Agents batch.

Capability A type of work a model or agent can support. Capability does not imply permission or configured availability.

Tool A callable operation available to an agent or workflow where implemented. The exact contract, inputs, outputs, and failure behavior must come from the owning product.

Integration A connection between Ethen and another system or service. A recognized integration concept is not proof of configured access.

MCP A shell-recognized integration concept. Batch 01 does not define server support, transport, credential handling, or tool contracts.

Workflow A structured sequence of work that can preserve stages, review points, and evidence. It should not be assumed to execute live unless the product verifies that behavior.

Run One attempt to perform a supported task or workflow. Exact run states are not established in this batch.

A proposal is visible planned work. Approval is the explicit boundary before supported state-changing execution. A workflow is a named sequence or pattern of work. Detailed run states, tool schemas, and retry behavior are deferred to later batches.

Agent and workflow definitions control documentation language only. They do not create guarantees about availability, retention, authorization, security, execution, or legal obligations.

Use the agent and workflow terms definitions consistently across pages. Do not add permissions, retention, security, availability, or execution meaning unless the owning implementation or policy source supplies it.

Security terms

Read Inspect context or current state without proposing or completing a change.

Propose Prepare a candidate action, plan, or change for review.

Approve Authorize a proposed sensitive or state-changing action through the control provided by the owning product.

Execute Carry out an approved action. A proposal or approval is not execution evidence.

Approval path The review boundary that can pause sensitive or state-changing work before execution.

Credential A secret or configuration item required for provider or integration access. Credentials must not be included in prompts or examples.

Privacy or local lane A product path oriented toward local or private operation where supported. The term does not establish a universal privacy guarantee.

Read → Propose → Approve → Execute is the canonical control sequence for sensitive or state-changing work. Evidence is inspectable material that supports review. A receipt is a record intended to keep request history, route decisions, logs, tool outputs, or verification notes connected to work.

Do not turn these terms into guarantees of immutability, retention, or compliance. Privacy, Terms, security commitments, data handling, and retention remain governed by verified product and legal sources.

Use control and security terms consistently wherever a task can cross an approval or execution boundary. Consistent wording helps readers identify the stage that actually occurred across different products.

Operations terms

Evidence Inspectable material that supports an understanding of what happened, such as source files, request history, referenced context, route decisions, logs, tool outputs, or verification notes.

Receipt A record intended to summarize or preserve information about a request, route, action, or result. Exact receipt fields vary by implementation.

Artifact A durable output or work product associated with a task, such as generated content or another saved result where supported.

Route decision The recorded or visible choice of a model lane or processing path when the surface exposes it.

Benchmark A measured result used in a normalized model profile or comparison. A benchmark represents a particular test, not universal quality.

Composite score A derived value combining multiple signals. Its usefulness depends on the included metrics and method.

Normalized profile The Model Intelligence representation used to build reusable model pages and comparisons from structured data.

Derived verdict Presentation logic that summarizes available evidence or suggests a route. It is guidance, not guaranteed truth.

Quality flag A profile signal indicating a limitation, missing field, or concern in normalized data.

Dynamic value A value such as price, count, benchmark result, latency, throughput, context, output limit, or provider availability that should be read from the current product rather than frozen into evergreen prose.

Runnable means the current catalog overlay indicates that the model is wired for use. Provider-configured means provider setup exists but does not by itself prove the model is runnable. Catalog-only means the record is visible for discovery without confirmed execution.

Unsupported-modality and missing-key are explicit status categories. Preview, mock, setup-required, beta, and GA describe different release or environment states and must not be collapsed into available. Missing metrics mean unavailable, not zero.

When an operations term also has a broader industry meaning, keep the Ethen definition for this documentation set. Extend it only when a product-specific implementation or policy supplies stronger detail.

Use the operations terms definitions consistently across pages. Do not add permissions, retention, security, availability, or execution meaning unless the owning implementation or policy source supplies it.