Platform architecture

The architecture overview explains NomOS’s logical system boundary: request path, core services, data stores and honest enforcement language.

What the overview shows

It is a read-only orientation surface for architecture, development and review. It describes the platform logically, not as an infrastructure plan with concrete production data.

The hand-drawn system map reads from left to right: people and agents enter the NomOS boundary, identity and policy checks govern the request, brain-core uses approved context and external targets, and Evidence records the controlled path. The dashed route marks a possible bypass, not a supported enforcement claim.

Reading the request path

A governed request passes four guardrails before knowledge or models are used in production:

1. The client or agent sends the request with user, room or service context.
2. Identity, roles and consent determine the allowed context.
3. OPA checks access. brain-core checks rules and risky actions.
4. brain-core uses approved knowledge and models, then creates evidence or slim audit events.

Connected, Guarded, Enforced

BDR-023 separates three claims so the UI does not promise more security than the architecture actually enforces.

Connected

An external client is attached, but is not necessarily fully mediated by policy and evidence.

Guarded

Policies, roles, kill switches and approvals constrain actions. This is stronger than a plain connection, but not automatically complete enforcement.

Enforced

All relevant actions run through the controlled path and leave the expected evidence. Only then is this level named.

What is deliberately omitted

The page does not show live endpoints, credentials, cluster names, network rules or customer-specific topology. Those details belong in operations documentation with suitable access control.

This keeps the architecture useful for orientation and review without turning a help or admin page into an infrastructure map.