System Model: Foundation Layer

Primitive helpers with no internal dependencies: UUID v7 generation, Base64/Base32 encoding, string conversion, datetime helpers, faker utilities, and rfl type reflectors. 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 base classes, a health monitor, and LISTEN/NOTIFY integration. All domain services build on this component to access their isolated tables.

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-location geolocation using MaxMind GeoLite2-City stored in PostgreSQL. Provides country, city, and coordinate lookups that ores.iam uses to annotate login sessions.

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 and by ores.connections for bookmark encryption.

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.