Block toolkit

The A-POST-OL platform isn't an empty framework. It's 26 ready-made PostgreSQL modules and 8+ C++ server modules. From these blocks, an information system of any kind can be assembled.

Below — a map of blocks organized by group. Each block links to its detailed page in the db-platform wiki, the source of truth.

Confirmed by independent audit

7 architectural decisions flagged by the audit

An April 2026 external auditor singled out these platform decisions as worth carrying into any new stack. Below — his words and our explanations.

Workflow engine — as data

States, transitions, and events of business processes are stored in DB tables, not in code. Change the workflow without redeploying the service.

«States/transitions/events configurable without deploy. Truly useful.»
wiki ↗

Registry — hierarchical K/V for config

Platform and project configuration are stored in a registry modeled after Windows Registry. Changeable at runtime — no service restart.

«Hierarchical K/V for config, changeable at runtime.»
wiki ↗

Entity file convention

Each business entity is assembled from 8 SQL files: table, view, routine, api, rest, event, init, security. Open the project — instantly know where everything lives.

«Entity file convention — consistent navigation.»
wiki ↗

Audit log taxonomy

Event-code registry 1xxx–9xxx with predictable grouping by subsystem. Debugging and error tracing become a one-line affair.

«Code registry 1xxx-9xxx really simplifies debugging.»
wiki ↗

Three-layer access control (ACU/AMU/AOU)

Access is controlled at three levels: class (ACU), method (AMU), object (AOU). Not just role-based — a fine-grained model for multi-tenant and enterprise.

«Proper access model, not just role-based.»
wiki ↗

Observer via PG NOTIFY

Pub/sub real-time subscriptions to object events: PostgreSQL LISTEN/NOTIFY → WebSocket → frontend. No Kafka, no Redis, no operational overhead.

«Simple and effective real-time subscriptions without Kafka overhead.»
wiki ↗

Role-based DB users

Real security boundaries not at the application layer, but at the PostgreSQL layer: kernel / admin / daemon / apibot — four DB users with different SECURITY DEFINER rights.

«Real security boundaries at the DB layer.»
wiki ↗

— from the independent audit of Apostol CSMS, April 2026.

Auth & Sessions

Built-in authorization, authentication, and session management blocks.

Entities & Objects

Class-oriented data model with inheritance, types, and states.

Workflow & Events

State machine, audit log, real-time subscriptions. Business process — as data.

Files, Config & Data

File storage, multilingual content, hierarchical settings registry.

Access & Security

Three-layer ACL, isolated DB users, area-based document visibility.

Communication & Integrations

Notifications, inbound webhooks, outbound HTTP, reports.