Platform Architecture¶
Aurum has four released product surfaces around one strategy application:
.at definitions --Athanor--> generated C++
|
venue packages --> C++23 strategy + SDK --> aurum CLI
| |
local runtime +--SSH--> Forge
|
Terminal <-- REST / WebSocket
Strategy and SDK¶
A strategy is the executable. It derives from sdk::Application, binds
venue or paper devices, reacts to typed topics, and submits typed effects. The
SDK supplies the runtime, scheduling, resource catalog, query model, telemetry,
and live WebSocket surface inside that process.
Athanor is optional and runs before the C++ compile step. Its generated factor plugins execute inside the same strategy process as handwritten code.
CLI and Forge¶
The aurum CLI has two independent roles:
it creates, compiles, and runs an installed SDK project locally;
it delivers immutable project versions to a named Forge target over SSH and invokes lifecycle operations there.
Forge is the public server boundary. Its control plane uses aurumd for
inventory and lifecycle. Its live plane routes to running strategy endpoints.
Its history plane reads durable run data. These are related signals, not one
shared state flag.
Terminal¶
Terminal is an API client. It receives one public Forge API base URL and does not need the CLI’s SSH target, a daemon socket, a strategy port, or a database address. This separation lets browser access, deployment access, and internal service networking use different policies.
Failure boundaries¶
Each boundary can fail independently:
Forge health can be good while
aurumdis unreachable;an operating-system process can run while its runtime endpoint is degraded;
live subscriptions can work while history is unavailable;
a stopped project can retain complete historical runs;
one runtime capability can be absent while the rest of the project is healthy.
Operator interfaces expose these distinctions so clients do not invent state from one convenient signal.