Glossary

1. Overview

The Glossary provides short, canonical definitions for terms that appear across concepts, DSL references, architecture, and examples — for example Bundle, Horizon, Voyage, System Design Model, Ocean Repository, Perspective, Control Structure, Service, Component, Broker, Vault, and FSM.

It is a terminology layer, not a duplicate of the pages it links to. Each entry gives a reader — or a search and retrieval system — enough to disambiguate a term at a glance, then sends them to the page that owns the full meaning.

This matters most for search and retrieval-augmented generation: glossary entries normalize terminology and disambiguation, so a query for “FSM”, “finite state machine”, or “Voyage” resolves to one specific Ocean meaning instead of a generic industry one.

2. How the Glossary Differs from Other Knowledge

Knowledge type	Purpose
Glossary entry	Quick, authoritative definition of a term — one or two sentences, plus aliases and disambiguation.
Concept page	Deeper explanation: relationships, rationale, and examples.
DSL reference	Precise language syntax and semantics.
Architecture page	How major components and layers relate, and where to continue.

When a term needs more than a short definition, the glossary entry links out rather than growing to cover that ground itself.

3. Editorial Rules

This page follows a fixed set of rules so it stays a reliable terminology layer rather than a second copy of other pages:

One canonical meaning per term. Every Ocean-specific term has exactly one preferred definition on this page.
Short definitions. Usually one or two sentences. Detailed explanation belongs on the linked concept or reference page.
Canonical links. Every entry points to the page that owns the full meaning; the glossary summarizes, it does not redefine.
Explicit, unambiguous aliases. Synonyms, abbreviations, and former names are recorded only when they can safely resolve to one Ocean term. Generic search phrases are not aliases.
Disambiguation. Terms that also have a common software meaning — component, service, context, bundle, repository, config — state their Ocean-specific meaning under “Not to be confused with.”
Related terms. Entries link to related terms so a reader can navigate the terminology graph, not just one definition.
Stable anchors. Every term has a stable heading anchor (for example /glossary/#system-design-model) that search results and citations can target directly.
Alphabetical and domain navigation. Section 4 groups terms by domain; Section 6 lists every term alphabetically.
Search normalization. Recorded aliases such as “FSM” / “finite state machine” are meant to resolve to the same entry regardless of which form is searched.
Status synchronization. An entry’s status mirrors its canonical reference and must be updated whenever that reference changes status.

An additional rule — automated validation of duplicate terms, duplicate aliases, ambiguous alias mappings, and broken canonical links — is intended for the builder pipeline once the glossary grows past one hand-maintained page. That validation, a structured per-term data model, and generated alphabetical and domain views are roadmap work, not current behavior; see Section 7.

4. Browse by Domain

Platform — Generator · Ocean · Ocean App · Ocean-Atlas · Ocean DSL · Ocean-Lab · Ocean Repository

Architecture — Bundle · Control Structure · System Design Model

Learning Model — Example · Horizon · Implementation · Voyage

DSL — API · Artifact · Asset · Broker · Component · Config · Context · Dashboard · Database · Datatype · Definition · Deploy · Engine · Expression · FSM · Import · Include · Info · Integration · Metadata · Perspective · Predefined Widget Types · Section · Service · Tag · UI · Vault · Widget

5. Entry Format

Each entry below follows the same shape:

### Term

- **Domain:** ...
- **Aliases:** ... (only when aliases exist)
- **Definition:** One or two sentences — the Ocean-specific meaning.
- **Not to be confused with:** ... (only when disambiguation is needed)
- **Related:** other glossary terms
- **Canonical reference:** the page that owns the full meaning
- **Status:** the current status of the canonical reference

Sections that do not apply to a given term (typically Aliases or “Not to be confused with”) are omitted rather than left empty.

6. Glossary A-Z

API

Domain: DSL
Definition: The technology-independent @api section defining a service’s public operations, payload representations, and transport configuration.
Related: Service, Integration, UI
Canonical reference: API DSL Reference
Status: Accepted

Artifact

Domain: DSL
Definition: The @artifact directive for resolving, interpreting, transforming, and materializing an external semantic file as part of a generated project.
Not to be confused with: Asset, which attaches a file verbatim without interpretation or transformation.
Related: Asset, Service, UI
Canonical reference: Artifact Directive Reference
Status: Approved

Asset

Domain: DSL
Definition: The @asset directive for attaching an external file to a DSL element, copied verbatim into the generated project without interpretation.
Not to be confused with: Artifact, which is interpreted and transformed rather than copied verbatim.
Related: Artifact, Service, UI
Canonical reference: Asset DSL Reference
Status: WIP

Broker

Domain: DSL
Definition: The @broker section defining message brokers, topics, message payloads, messaging patterns, and delivery semantics.
Related: Service, Integration
Canonical reference: Broker DSL Reference
Status: Accepted

Bundle

Domain: Architecture
Aliases: Ocean DSL project
Definition: The complete, identifiable Ocean DSL project — the full set of local and reused DSL definitions that together describe one system, identified by its @info section.
Not to be confused with: a bundler or packaging build output in general software tooling; an Ocean Bundle is the DSL project itself, not a build artifact.
Related: System Design Model, Ocean Repository, Import, Include, Service
Canonical reference: Ocean Bundle
Status: Approved

Component

Domain: DSL
Definition: The @component section for composing FSMs, expressions, and nested components through typed inputs, outputs, and explicit connections.
Not to be confused with: a UI/frontend component; an Ocean Component composes behavioral logic, not presentation.
Related: FSM, Expression, Service, Control Structure
Canonical reference: Component DSL Reference
Status: Draft

Config

Domain: DSL
Aliases: Configuration
Definition: The @config section for declaring named, reusable, typed configuration schemas used by deployable services.
Related: Vault, Service
Canonical reference: Config DSL Reference
Status: Approved

Context

Domain: DSL
Definition: The @context section for service-local volatile shared state used by service logic and orchestration.
Not to be confused with: “context” in general programming (request context, dependency-injection context); Ocean Context is a declared, typed, service-local state section.
Related: Service, Config
Canonical reference: Context DSL Reference
Status: Accepted

Control Structure

Domain: Architecture
Definition: How Ocean services, components, FSMs, and expressions form a layered behavioral composition model.
Not to be confused with: control-flow statements (if/loop) in general programming; Ocean’s Control Structure is the layering of behavioral building blocks, not statement-level flow control.
Related: Service, Component, FSM, Expression
Canonical reference: Control Structure
Status: Approved

Dashboard

Domain: DSL
Definition: The @dashboard section for composing widgets into reusable, backend-agnostic pages or screens.
Not to be confused with: UI, which owns application-level integration and composes dashboards into a deployable user-interface service.
Related: Widget, Predefined Widget Types, UI
Canonical reference: Dashboard DSL Reference
Status: Approved

Database

Domain: DSL
Definition: The @database section defining persistent entities, relationships, keys, indexes, encryption, queries, and commands.
Related: Service, Context, Integration
Canonical reference: Database DSL Reference
Status: Accepted

Datatype

Domain: DSL
Aliases: Data type
Definition: The @datatype section defining reusable, technology-independent data contracts used across Ocean APIs, services, brokers, expressions, databases, and other constructs.
Related: API, Service, Database, Import, Include
Canonical reference: Datatype DSL Reference
Status: Accepted

Definition

Domain: DSL
Definition: One named item declared inside a top-level DSL section — for example one Service, one Datatype, or one FSM — as opposed to the section itself.
Not to be confused with: Section, the top-level block (@service, @datatype) that contains one or more definitions.
Related: Section, Bundle
Canonical reference: Ocean DSL
Status: Accepted

Deploy

Domain: DSL
Aliases: Deployment
Definition: The @deploy section defining how Ocean services, UIs, and brokers are materialized for a runtime environment, including replicas, configuration, ports, volumes, dependencies, and runtime connections.
Related: Service, UI, Broker, Config
Canonical reference: Deploy DSL Reference
Status: Approved

Engine

Domain: DSL
Definition: The concrete technology selected to implement a construct, declared through an engine attribute — for example engine = postgres on a database, or engine = nats on a broker.
Not to be confused with: Generator, the tool that produces implementation code; an engine is the selected target technology a generator produces code for.
Related: Generator, Database, Broker
Canonical reference: Ocean System Design Model
Status: Approved

Example

Domain: Learning Model
Definition: A validated, runnable Ocean project that demonstrates specific DSL capabilities end-to-end, cataloged with a Horizon and a Voyage.
Related: Horizon, Voyage, Bundle
Canonical reference: Examples
Status: Accepted

Expression

Domain: DSL
Definition: Ocean’s stateless, side-effect-free reusable logic model — named or inline expressions with typed inputs and outputs.
Not to be confused with: a math or regular expression; an Ocean Expression is a typed, reusable logic unit that may wrap built-in functions or external implementations.
Related: Component, FSM, Control Structure
Canonical reference: Expression DSL Reference
Status: Accepted

FSM

Domain: DSL
Aliases: Finite State Machine, finite-state machine
Definition: The @fsm section for modeling stateful domain behavior through states, events, triggers, transitions, and actions.
Not to be confused with: a generic finite-state-machine library or pattern; Ocean’s FSM is a specific DSL section with entity-controlled and in-memory modes.
Related: Component, Control Structure, Expression
Canonical reference: FSM DSL Reference
Status: Accepted

Generator

Domain: Platform
Definition: A tool that translates a validated, technology-independent Ocean model into a concrete implementation for a selected engine or target technology.
Not to be confused with: Engine, the selected target technology; a generator is the tool, an engine is what it targets.
Related: Engine, System Design Model
Canonical reference: Ocean System Design Model
Status: Approved

Horizon

Domain: Learning Model
Definition: The concise orientation view of an Ocean example — its scenario, architecture, demonstrated Ocean concepts, and expected result — described independently of implementation technology.
Not to be confused with: Voyage, which teaches the step-by-step construction of the same example.
Related: Voyage, Example, Implementation
Canonical reference: Examples
Status: Accepted

Implementation

Domain: Learning Model
Definition: The source-inspection facet of an Ocean example, preserving its original folders and files so readers can inspect the complete executable model and its supporting artifacts.
Not to be confused with: Voyage, which explains the construction process and decisions rather than presenting the source itself.
Related: Voyage, Horizon, Example, Bundle
Canonical reference: Examples
Status: Accepted

Import

Domain: DSL
Definition: The @import directive for resolving a selected reusable definition and exposing it through a local alias.
Not to be confused with: Include, which statically composes a same-section definition rather than exposing it through an alias.
Related: Include, Ocean Repository, Bundle
Canonical reference: Import DSL Reference
Status: Draft

Include

Domain: DSL
Definition: The @include directive for statically composing a same-section DSL definition from the Ocean Repository or local Pre-baked Registry.
Not to be confused with: Import, which resolves a reusable definition into a local alias rather than statically composing it into the current file.
Related: Import, Ocean Repository, Bundle
Canonical reference: Include DSL Reference
Status: Draft

Info

Domain: DSL
Aliases: Project information
Definition: The @info section declaring the identity, version, and descriptive metadata of the complete Ocean DSL project.
Not to be confused with: Metadata, which classifies individual DSL definitions and files rather than identifying the complete project.
Related: Bundle, Metadata
Canonical reference: Info DSL Reference
Status: Approved

Integration

Domain: DSL
Definition: The @integration section defining typed, directional flows between implemented contracts and used APIs, brokers, databases, files, and other supported resources.
Related: Service, API, Broker, Database
Canonical reference: Integration
Status: Accepted

Metadata

Domain: DSL
Definition: Generic classification attached to Ocean DSL definitions or files through item-level @tags and @perspectives and the optional file-level group.
Not to be confused with: Info, which identifies and describes the complete Ocean DSL project.
Related: Tag, Perspective, Info
Canonical reference: DSL Metadata Reference
Status: Accepted

Ocean

Domain: Platform
Definition: The overall Ocean platform and ecosystem name for DSL-first, technology-independent system modeling, reuse, and generation.
Not to be confused with: Ocean DSL, which names the language specifically rather than the platform as a whole.
Related: Ocean DSL, Ocean-Atlas, Ocean-Lab, Ocean Repository
Canonical reference: Architecture
Status: Accepted

Ocean App

Domain: Platform
Definition: The Ocean-Lab application used to work with Ocean projects directly.
Related: Ocean-Lab, Ocean-Atlas
Canonical reference: Ocean App
Status: External — no dedicated Ocean-Atlas page; described on the Ocean-Atlas home page.

Ocean DSL

Domain: Platform
Aliases: Ocean language
Definition: Ocean’s case-sensitive domain-specific language for modeling systems through typed, declarative, technology-independent definitions.
Not to be confused with: Ocean, the platform name that also encompasses the Ocean Repository, generators and engine, Ocean-Atlas, and Ocean-Lab.
Related: Ocean, System Design Model, Bundle
Canonical reference: Ocean DSL
Status: Accepted

Ocean Repository

Domain: Architecture
Definition: The versioned source of reusable Ocean definitions, referenced through the canonical O. (Ocean Repository) and P. (local Pre-baked Registry) formats.
Not to be confused with: a source-code repository (for example a Git repository); the Ocean Repository specifically holds versioned, reusable DSL definitions.
Related: Bundle, Import, Include
Canonical reference: Ocean Repository
Status: Approved

Ocean-Atlas

Domain: Platform
Definition: The canonical knowledge base for the Ocean platform and its domain-specific language.
Not to be confused with: Ocean-Lab, the broader Ocean application and ecosystem that Ocean-Atlas documents but does not implement.
Related: Ocean, Ocean-Lab
Canonical reference: Ocean-Atlas
Status: Approved

Ocean-Lab

Domain: Platform
Aliases: Ocean Lab
Definition: The broader Ocean application and ecosystem in which generated systems and services are built and run.
Not to be confused with: Ocean-Atlas, which documents Ocean but is a separate knowledge platform.
Related: Ocean, Ocean-Atlas, Ocean App
Canonical reference: Ocean-Lab
Status: External — no dedicated Ocean-Atlas page; described on the Ocean-Atlas home page.

Perspective

Domain: DSL
Definition: Context-dependent, key-value metadata (@perspectives) attached to a DSL item, such as version, lifecycle stage, or region.
Not to be confused with: Tag, which attaches free-form labels rather than key-value pairs; the legacy singular perspective keyword is not canonical syntax.
Related: Tag
Canonical reference: Perspective DSL Reference
Status: Accepted

Domain: DSL
Aliases: Widget types
Definition: The canonical catalog of built-in Ocean widget types and their implemented properties, defaults, and generated functions.
Related: Widget, Dashboard, UI
Canonical reference: Predefined Widget Types
Status: Approved

Section

Domain: DSL
Definition: One top-level DSL block — @datatype, @api, @service, and so on — that a source file declares exactly one of, containing one or more definitions.
Not to be confused with: Definition, one named item declared inside a section.
Related: Definition, Ocean DSL
Canonical reference: Ocean DSL
Status: Accepted

Service

Domain: DSL
Definition: The @service section composing domain behavior, external contracts, infrastructure, configuration, secrets, and typed connections into one deployable unit.
Not to be confused with: a microservice in general architecture; an Ocean Service is a DSL composition unit that may or may not map one-to-one to a deployed microservice.
Related: Component, Bundle, Control Structure
Canonical reference: Service DSL Reference
Status: Approved

System Design Model

Domain: Architecture
Definition: How Ocean DSL constructs for data, behavior, interfaces, persistence, messaging, orchestration, configuration, and deployment combine to model one technology-independent system.
Related: Bundle, Control Structure, Ocean DSL
Canonical reference: Ocean System Design Model
Status: Approved

UI

Domain: DSL
Aliases: User Interface
Definition: The @ui section composing dashboards into deployable user-interface services connected to APIs and brokers.
Related: Widget, API, Broker
Canonical reference: UI DSL Reference
Status: Approved

Vault

Domain: DSL
Aliases: Secret Vault
Definition: The @vault section for modeling logical secret stores, typed secret schemas, and physical secret-backend generation.
Not to be confused with: a specific secret-backend product (for example HashiCorp Vault); Ocean’s Vault is a technology-independent logical model that generates to a chosen backend.
Related: Config, Service, Perspective, Tag
Canonical reference: Vault DSL Reference
Status: Approved

Voyage

Domain: Learning Model
Definition: The step-by-step learning facet of an Ocean example, explaining how the system is constructed and why each implementation decision is made.
Not to be confused with: Horizon, which explains the completed system without teaching its construction sequence.
Related: Horizon, Implementation, Example
Canonical reference: Examples
Status: Accepted

Domain: DSL
Definition: A declared element inside an Ocean dashboard, with a predefined type, scalar/list/map properties, datatype binding, and generated functions.
Related: UI
Canonical reference: Widget DSL Reference
Status: Approved

7. Roadmap

The current page completes the first two stages of a three-stage plan:

Schema and editorial rules (this page) — the term shape, disambiguation, alias, and cross-link conventions defined in Section 3 and Section 5.
Foundational term set (this page) — an initial term set spanning the platform, architecture, DSL, and learning-model domains.
Builder validation and generated views (not yet built) — a structured per-term data model, builder-level validation (duplicate terms, duplicate or ambiguous aliases, missing definitions, broken canonical links), and generated alphabetical/domain views, feeding future search, APIs, and RAG output.

Until stage three exists, this single page is the authoritative glossary, and new terms should be added here as additional ### Term entries rather than as separate files.