System Model: Foundation Layer

Primitive helpers with no internal dependencies: UUID v7 generation, Base64/Base32 encoding, string conversion, datetime helpers, faker utilities, and the wire codecs. The lowest point in the dependency graph — nothing in Foundation depends on anything below it.

Filesystem utilities, environment variables, network info (hostname, MAC, machine ID), and cross-platform time utilities. Wraps OS-specific behaviour so every component above it can target the same API.

Core Boost.Log infrastructure — the make_logger() factory, severity levels, and a lifecycle manager for console and file sinks. Extracted from ores.telemetry to break the circular dependency that would otherwise form between logging and ores.database.

Extends logging with distributed tracing (trace_id, span_id), OpenTelemetry integration, JSON Lines log export, and service identity. The split into three sub-components reflects the layered dependency: .core extends the logger, .database persists spans to PostgreSQL, .service manages identity and lifecycle initialisation.

PostgreSQL access layer — connection pool, tenant/party context, bitemporal CRUD helpers, repository mapper helpers, a health monitor, and LISTEN/NOTIFY integration. All domain services build on this component to access their isolated tables. A simple component with no sub-parts. It is hand-written infrastructure with no codegen entity model, and it owns the bootstrap table ores_database_info_tbl that records the checkout which built the database.

Feature flags and runtime configuration management, published via the variability.v1. ores.nats namespace. Consumers read flags without polling the database; the service propagates changes so flag updates are visible system-wide without a restart.

IP-to-country lookup using ip2country ranges stored in PostgreSQL. Answers a country code only; city and coordinate data are not available. ores.http calls it from its login route.

PostgreSQL schema, migration scripts, role provisioning, and database lifecycle management for the entire system. Each service role holds DML only on its own ores_<service>_* tables — cross-service reads inside triggers use SECURITY DEFINER; cross-service writes go through ores.nats.

Related documents:

• SQL entity schema patterns — how service-isolated tables are structured and cross-service access is controlled.
• PlantUML ER diagram conventions — conventions used to diagram the database schema.
• Tooling Layer — ores.sql in its developer-tooling context.

Shared cryptographic primitives — scrypt password hashing, AES-256-GCM encryption, JWT parsing and validation, OWASP password and email validators. Used by ores.iam for credential handling.

Parses the subset of org-mode this project's docs use — frontmatter keywords, property drawers, headings, paragraphs, lists, tables, and id: links — into a C++ document structure, and resolves those links against the org-roam SQLite index that compass builds. A pure C++ library, consumed by ores.shell.

Code generation utility for domain types and documentation — driven by ores.codegen.json stencil files to produce boilerplate C++ and org-mode scaffolding. Also the engine behind the compass CLI tool.

• Tooling Layer — ores.codegen and ores.compass in their developer-tooling context.