Platform overview

This overview maps Ethen by responsibility rather than by menu order. Use it when you need to decide which surface owns a question, which services are shared, and where a handoff changes the meaning of the evidence. The repository confirms several direct routes and platform concepts, but it also states that individual surfaces can be live, preview, mock, or setup-required. Treat the map as an operating model, not a promise of uniform availability.

Platform map

At the highest level, Ethen combines a workspace shell, model research surfaces, a model catalog, an access-oriented gateway, and product-specific work areas. They are connected by common ideas—context, routing, approvals, evidence, and artifacts—but they do not all perform the same job.

A reader should be able to move across these layers without losing the distinction between what is described, what is configured, and what can run now.

The platform can be understood as a set of user-facing surfaces connected by shared model, context, review, and evidence concepts. The current shell recognizes many product and operational paths, but recognition alone is not proof of full implementation.

Use the console as the orientation point, Model Library and Model Intelligence as model surfaces, AI Gateway as the configured access layer, and approval or evidence concepts as cross-cutting controls. Mark any route that has not been directly verified as conceptual rather than a guaranteed destination.

Core surfaces

Console

The console is the general Ethen entry point. Its metadata presents an agent console for chat, coding, research, media, and design. It is best understood as the shared workspace surface, not as the source of truth for every model or provider attribute. When the console sends a reader to a specialized surface, the destination owns the detailed status.

Model Library

Model Library loads gateway catalog models and provider rollups. The inspected table wrapper calls it a read-only catalog of gateway models and provider overlays. Search, capability tabs, provider filters, status filters, sorting, selectable columns, selected-model inspection, model ID copying, and links toward Gateway are implemented in the explorer.

Model Intelligence

Model Intelligence lists normalized profiles and provides dynamic model pages. Profiles can contain benchmarks, specifications, pricing, context, comparisons, charts, summary cards, FAQs, quality flags, provider information, and SEO data when present. Because fields are data-driven, missing information should remain unavailable rather than being filled with assumptions.

AI Gateway

The Gateway surface is oriented toward model and provider access. The current page labels the Managed Gateway as beta and exposes approved links to its playground, documentation, API keys, and model-related areas. Gateway readiness still depends on the catalog status, provider configuration, credentials, and supported modality for the selected model.

Verified direct routes include the console, Model Library, Model Intelligence model index, and AI Gateway. Each has a different job and a different evidence base.

The console hosts the application shell and composer. Model Library is a read-only gateway catalog with runtime overlays. Model Intelligence presents normalized profiles and comparisons. AI Gateway exposes model access, provider status, keys, logs, usage, and a playground, but its page identifies the product as beta.

Shared services

The approved platform copy describes several services that connect product surfaces:

• Model routing records or communicates the lane selected for a request where the implementation supports it.
• Workspace context keeps relevant prompts, files, artifacts, decisions, evidence, or review notes associated with work.
• Approval paths allow sensitive or state-changing work to pause before execution.
• Evidence and receipts preserve inspectable information such as request history, referenced context, route decisions, logs, tool outputs, or verification notes.
• Workflow support gives repeated work a structure that can be reviewed.
• Local lanes provide a private or local-oriented option only where the corresponding product supports it.

These are platform patterns, not proof that one centralized service implements every behavior identically. A later product-specific guide should override this overview when it provides more precise implementation evidence.

Approved copy describes shared structures for routing requests, moving permitted context, reviewing proposed actions, attaching evidence, and supporting workflows.

Treat these as platform-level services or patterns rather than a promise that every surface implements them identically. Shared language should remain stable even when the concrete UI, status, or configuration differs by product.

Data and execution flow

A safe way to reason about an Ethen task is to follow the information through five checkpoints:

1. Intent and context. The reader identifies the outcome and supplies only the context permitted for that surface.
2. Selection. A model, provider, or product path is chosen using catalog status and research evidence appropriate to the task.
3. Proposal or request. The surface prepares work, sends a supported model request, or produces a reviewable proposal.
4. Approval and execution. State-changing work proceeds only through the approval boundary supported by the owning product. Research or catalog inspection may end before this stage.
5. Evidence and output. The result may be represented as a response, artifact, receipt, route decision, tool output, or verification note, depending on the surface.

This flow prevents a common category error: reading evidence from an earlier checkpoint as proof that a later checkpoint succeeded. A profile does not certify runtime access; a configured provider does not prove a modality is supported; an approved proposal does not by itself prove execution completed.

A safe mental model begins with authorized context, continues through model selection or routing, produces visible work, attaches evidence, and pauses at an approval boundary before sensitive movement.

This is an explanatory flow, not a universal runtime trace. The current product surfaces do not define every request schema, storage layer, retry rule, or execution engine, so those details must be documented in later product-specific batches.

A handoff record

When work crosses products, keep a small handoff record with the task, selected model or profile, provider, visible status, date, and unresolved questions. For example, a researcher may shortlist a model in Model Intelligence, then discover in Model Library that the provider is only configured or that a key is missing. The handoff record preserves both findings instead of allowing the research conclusion to overwrite the operational one.

This practice is also useful in reverse. A successful Gateway test proves that one route handled one request; it does not replace the broader research needed to compare quality, benchmark coverage, cost, or context. Each product contributes evidence within its responsibility.

Product boundaries

Product boundaries keep documentation honest and make troubleshooting faster.

Research versus access. Model Intelligence explains and compares normalized model data. Model Library shows gateway catalog and status information. AI Gateway is the access-oriented surface. A finding in one product must be rechecked in the next.

Visibility versus readiness. A recognized route, navigation item, or catalog record confirms visibility. Readiness requires the supporting implementation, provider state, credentials, and capability match.

Proposal versus execution. Ethen’s control language separates reading, proposing, approving, and executing. Documentation should name the stage that actually occurred rather than using “completed” for every intermediate result.

Stable guidance versus dynamic values. Product responsibilities can be documented as durable concepts. Model counts, prices, benchmark values, limits, latency, throughput, and provider availability are dynamic and should be read from the current surface.

Platform concept versus policy commitment. Workspace context, evidence, and approvals are product concepts. Retention, legal rights, security guarantees, compliance, and contractual commitments belong to their verified policy sources.

Model research, catalog status, configured access, and workflow execution are separate concerns. Keeping them separate prevents a research record from being mistaken for a runnable model or a proposal from being mistaken for an executed action.

Document the owner of each decision: Model Intelligence for evidence presentation, Model Library for catalog and status inspection, AI Gateway for access configuration, and approval paths for state-changing boundaries where supported.

Where to go next

Use the following sequence when you are new to the platform:

1. Read What is Ethen? for the product definition and major boundaries.
2. Open Choose your first product to match a task with the correct surface.
3. Follow Quickstart for a first conservative workflow.
4. Use the Platform Concepts section when you need precise distinctions among workspaces, sessions, models, providers, agents, tools, runs, receipts, and artifacts.
5. Move into the Models section for catalog search, detail pages, selection criteria, modalities, provider status, and Model Intelligence interpretation.

When a route or control is not approved in the current route map, treat it as a concept rather than a clickable instruction. That keeps the overview useful without turning navigation evidence into an unsupported product claim.

Choose the next page based on the question you need to answer: platform concepts, first-use steps, model discovery, model comparison, or provider availability.

Follow the related documentation links rather than guessing at shell routes. Product links in this page are limited to routes verified and approved for this documentation set.