Fifty years of engineering doctrine, applied consistently.

Actionary’s architecture is a coherent stack of principles ranging from 1974 (Dijkstra) to 2024 (MCP). Every foundational principle is fifteen to fifty years old. Every modern principle is production-proven at cloud-scale organisations today.

Every principle has an authoritative citation. Every one traces to concrete evidence in the platform — a repository, a role in the DB model, a merge-time gate, a tool on the MCP surface.

The table below is the citation table behind every architectural claim we make on this site. Read it as a peer.

The sixteen principles

Where each one lives in the platform

Every entry above cashes out as something concrete. Separation of Concerns is the layered backend — routers, application services, repositories — with a merge-time gate that fails the build when the boundary is crossed. Least Privilege is the multiple-role DB model — a dedicated role for tenant traffic, a separate one for platform-admin traffic, and a still more restricted one for the migrator — each scoped to one purpose, none able to bypass row-level security. PoEAA is one repository file per aggregate, with a merge-time budget check that fails any pull request introducing inline SQL in a router.

Hexagonal Architecture is two HTTP adapters over one core: the REST surface for the SPA, and the MCP tool surface for the embedded agent and every external MCP client. Storage swaps between local disk, S3, R2, MinIO, and Backblaze through one adapter with one configuration value. LLM provider swaps between Anthropic, OpenAI, Bedrock, Azure OpenAI, and Gemini through one factory branch.

Row-Level Security lives at the substrate. RLS is enabled on every tenant-scoped table; policies key on a per-connection tenant setting; the request-time role cannot bypass RLS even under a hostile query. Feature-Sliced Design is the SPA’s module layout, with a merge-time isolation gate. MCP is a first-class service alongside the API and the SPA.

One Voice — the Actionary house term for the same discipline Google, Airbnb, Uber, Meta, and the Rust ecosystem run on — lives at the layer of the codebase where a new lead engineer’s first day happens. Every file states its layer on the first line. One Generic Repository handles every entity in the metadata layer. One place for SQL, checked at merge time by a per-file inline-SQL budget. One SPA-to-API contract, verified against the OpenAPI schema on every pull request. One typed SDK, generated. One error-capture path with no endpoint-level silent catches. One authentication contract — a session-kind string with three values, no boolean flag anywhere in the system that flips to elevate. One naming convention. One comment discipline: present state only, no fix history in code. One migration shape, with -- phase: declared and expand/contract sequenced. The rules are stated once, enforced at merge time, and applied uniformly across the tree.

Every claim on the architecture page resolves to a verifiable property of the running platform. That is the point.

The applied stance

Cockburn’s Hexagonal Architecture puts adapters at the boundary and business logic at the core. Wiggins’s Twelve-Factor App says dependencies are explicit and backing services attach through config. Martin’s Chapter 32 warns “Do not marry the framework.” Read together they compose into one stance:

Open standards at the infrastructure boundary. Code we own at the application core.

At every layer where a real open standard exists, Actionary ships a thin adapter. PostgreSQL. S3-API. Redis wire protocol. OpenTelemetry OTLP. MCP. OAuth with DCR and PKCE. HTTP + OpenAPI. Every one has multiple compatible implementations; the substrate is portable by construction.

At every layer where the “ecosystem” is an opinionated framework masquerading as a standard, we own the code. The RAG pipeline is a few hundred lines — extract, chunk, embed, persist — writing against Postgres with the standard vector extension. The workflow engine is durable step execution on Postgres with FOR UPDATE SKIP LOCKED claims. Agent orchestration is propose-then-execute on the MCP tool surface. Permission enforcement is Postgres RLS plus a permissions contract computed server-side on every list response.

Roads not taken

Each alternative gets a reason.

LangChain, LlamaIndex — orchestration middleware. Their patterns fit a specific shape of problem. When the business logic encodes decisions specific to Actionary’s entity model, its per-row visibility gate, and its audit-log integration, imported abstractions get in the way.

Pinecone, Weaviate — hosted vector databases. Adopting one means data leaves Postgres. Backup surface splits in two. Audit surface splits in two. The RLS visibility gate does not apply to the external store; a second implementation would be needed. The standard Postgres vector extension on the same database keeps every one of those a single-surface concern.

Temporal, Airflow — durable-execution frameworks. Adopting one means a second stateful service in the deploy topology when durable step execution on Postgres already delivers the same idempotent-step guarantee.

Kafka, RabbitMQ — dedicated brokers. Redis lists with an orphan sweep against a Postgres state table is enough at our shape. A dedicated broker becomes the right choice once throughput demands it.

Every one of these is a valid architecture for a codebase built around it. The distinction is which layer of the stack imports the framework. Frameworks at the infrastructure boundary are portable. Frameworks at the application core become the coupling Chapter 32 warns about.

The takeaway

Our architecture is borrowed from decades of production practice. Every principle underneath it has been production-proven at Netflix, Uber, AWS, Microsoft, Apple, Google, and every bank for fifteen to fifty years. The modern principles are what leading cloud-native SaaS builds on today.

That is the point. A technical audience recognises the substrate on day one. A security reviewer, a CTO, or an acquirer inspecting the stack finds citations at every layer. The open-standards boundary means the code is portable. The owned application core means the substrate fits the domain. Every layer traces to a paper on the reading list and a codebase you can audit against it.