System Model: Application Layer
Table of Contents
This page is part of the System Model. Application is where the system surfaces — the layer that composes everything below it into user-facing executables. The shell REPL is a client of the same domain services over ores.nats; the compute engine is a long-running service. To generate component diagrams, use the PlantUML Class Modeler skill.
1. Detail
1.1. ores.http
Boost.Beast/Asio async HTTP server exposing a REST API for domain services. ores.http.api defines the route handler contract; ores.http.core provides the async infrastructure; ores.http.server wires all handlers and runs the event loop.
| Sub-component | Role | Dependencies |
|---|---|---|
| ores.http.api | Route handler contract, WSGI-style registry | Foundation |
| ores.http.core | Boost.Beast/Asio async infrastructure | ores.http.api, Domain |
| ores.http.server | Wires all route handlers, runs event loop | ores.http.core |
1.2. ores.compute
Distributed compute grid for ORE Engine risk runs. ores.compute.core manages the cluster: it keeps the app and app-version registry, assigns batch jobs to registered hosts, tracks execution state, and collects results. ores.compute.service is the NATS entrypoint for that orchestrator; ores.compute.wrapper executes each assigned run as a child process on a worker node; ores.compute.client uploads engine packages with hash verification for the shell.
| Sub-component | Role | Dependencies |
|---|---|---|
| ores.compute.api | Shared compute types and ores.nats protocol | — |
| ores.compute.client | Engine package upload, hash-verified | ores.compute.api, ores.storage |
| ores.compute.core | Cluster manager: app registry, batch dispatch, result collection | ores.compute.api, ores.database, ores.ore.api |
| ores.compute.wrapper | ORE Engine process spawner and result reader | ores.compute.api |
| ores.compute.service | Thin ores.nats entrypoint | ores.compute.core, ores.compute.wrapper, ores.nats |
Related documents:
- Compute Engine — compute architecture, run lifecycle, and chunking design.
1.3. ores.shell
Interactive REPL for connecting to ORE Studio over NATS. It parses command-line arguments and a configuration file, auto-connects and auto-logs-in from that configuration, and exposes commands for querying and provisioning a running system from a terminal. It is the surface the system tests drive, and the Emacs dashboard launches it.
| Sub-component | Role | Dependencies |
|---|---|---|
| ores.shell | Composite: the REPL adapter, adds its parts | — |
| ores.shell.application | REPL host, config parsing, script runner, command units; builds ores.shell.exe | ores.shell.api |
| ores.shell.api | Shared plumbing: argument parsing, feedback, pagination, request helpers | — |
Related documents:
- Shell recipes — usage recipes, and the single source of truth for the
.oresscript library.
1.4. ores.lisp
Emacs Lisp developer tooling — per-checkout dashboard (transient menu), database browser, shell integration, and org-roam export pipeline. Not part of the production system; it automates the developer workflow inside Emacs.
| Sub-component | Role | Dependencies |
|---|---|---|
| ores.lisp | Emacs Lisp dashboard and developer tooling | — |
2. See also
- System Model — the index page with the four-layer architecture overview.
- System Model: Domain Layer — the layer below.
- Compute Engine — compute architecture, run lifecycle, and chunking design.