◆ Technical section

Architecture: 4 layers, 30+ BPLs, integrated data

Each BPL compiles, tests and ships independently, with strictly one-directional dependencies. Multiple databases orchestrated by synchronization, with PostgreSQL as the platform hub. Alongside it, MemoryLens, security and integration.

4
Layers
30+
Modular BPLs
340k+
Lines of code (ours)
580+
Pascal units
Package architecture
4 layers, zero coupling

Dependencies are one-directional. Updating a module means replacing one .bpl file, without recompiling the executable.

Layer 0
Framework
SF_CoreSF_Database SF_SyncSF_Tools
Layer 1
Common
DtoMes_Common Auth · Config · Menu · Help · SupportPanel · App_MLHelper · Theme
Layer 2
Modules
ProdottiPrintProdTools MLLaboratorioDocTipoA DocTipoBMLEditorMLSupport PianificazioneProduzioneSBOM
Layer 3
EXE
DtoMesAdmin4.exe Minimal bootstrap — all logic in the BPLs
Data layer
PostgreSQL as the platform hub

The platform stays multi-database — Firebird for the MES, SQL Server/COBOL for the ERP — but the cross-cutting services (identity, permissions, telemetry, documentation, AI) converge on PostgreSQL. The shift is isolated behind interfaces (IAuthProvider, IAuthRepository): changing the data source means changing one implementation and one bootstrap line, without touching the modules.

🔑 Identity & permissions

AUTH_* tables (resources, actions, roles, permission matrix, user roles) and identity provider on PostgreSQL. Real FKs, permissions and identity co-located.

📡 Telemetry & audit

Application and security events consolidated in ml_app_events on PostgreSQL, with an outbox pattern from the SyncEventHub.

🧮 Semantic search

With pgvector, embeddings live next to the data: no second database, semantic search where the information already is.

SF.Auth.Provider.pas — a change of implementation, not of modules
// Identity is abstract: Firebird today, PostgreSQL tomorrow
if HasAuthProvider then
  Result := CurrentAuthProvider.Authenticate(AUser, APwd)
else
  Result := LegacyLogin2(AUser, APwd);  // fallback

// Cutover to PG = one bootstrap line:
SetAuthProvider(TAuthPgProvider.Create(connPG));
Cross-cutting infrastructure · inherited via MCP
The nervous system every module inherits

Dashboard, telemetry, audit, documentation, log and synchronization are not per-module options: they are framework services. A scaffold that follows the MCP server's rules (scaffold_module) wires them in automatically — a generated module is born observable, traced and documented.

SEH · TelemetrySyncEventHub · outbox → PostgreSQL · :8091
DAH · DashboardDtoMesAnalyticsHub · internal web · :8092
Centralized auditml_app_events on PostgreSQL · RBAC vocabulary
MemoryLens3 pillars: DEV · USER · SUPPORT
MLPivotarchive + full-text · via MCP
Logstructured, consistent tracing
Nginxreverse proxy for web dashboards
PostgreSQL syncconsolidates events/docs/embeddings
The point: these capabilities live in the framework, not in the modules. The MCP server encodes the framework's rules, so a generated module inherits the whole nervous system — coherent, observable and conformant from day one. See AI & MCP →
MemoryLens
Documentation, diagnostics, help. Unified.

A cross-cutting system that serves three audiences with one architecture. Every module accesses it via TMLHelper: one uses clause, zero extra dependencies.

DEV · Developer

Captures errors, measures performance, documents architectural decisions. ML browser for cross-module navigation.

USER · End user

Contextual help with a ? button on every frame. Tips, warnings, guides. Late-binding: if ML isn't loaded, graceful fallback.

SUPPORT · Support

Diagnostics panel with event badges. Ticket creation with automatic context. Event viewer with detail.

Security & audit
RBAC, enforcement, traceability

Authentication and authorization done right: centralized permission model, declarative enforcement, audit on PostgreSQL. Internal OWASP ASVS L1 checklist, foundations ready for future reviews.

🔑 Centralized RBAC

Resources, actions and roles in tables. A permission is the (resource, action) pair; a role is a set of permissions; a user gets one or more roles. Complementary to the existing level/entity model.

🚫 Declarative enforcement

Guards configured in JSON on forms, menus and actions. Incremental "one at a time" rollout, with fail-open until enforcement is active on the module.

⚖ Separation of duties (SoD)

Whoever creates does not approve. APPROVE base already separated, dynamic check on sensitive actions with tracked override.

📜 Audit & hash-chain

Security events (login, access denied, override) on PostgreSQL. Append-only hash chain: the "not tampered" property without blockchain.

Synchronization · the heart of integration
Multi-database, multi-profile, zero triggers

This is the central point of the architecture: SyncFramework keeps heterogeneous databases aligned (SQL Server/COBOL of the ERP, Firebird of the MES, PostgreSQL of the platform) with a bidirectional hash-based engine that needs no triggers or timestamps on source tables. Every system stays where it is; the data stays coherent.

SQL Server

ERP / COBOL

SyncFramework

Hash-based engine

Firebird

Local MES

PostgreSQL

Platform · AI

🔒 Shadow Database

Deletion tracking without modifying source tables. Garbage collector for automatic cleanup of stale entries.

⇄ Parallel Executor

Parallel multi-profile execution. Each profile has configurable source, target and transform.

⚠ Conflict Tracker

Failed records tracked with retry. Conflicts handled with a per-profile configurable policy.

▶ Windows Service

Console and service. Heartbeat on the DB for monitoring. Graceful shutdown.

Why it matters: synchronization is what lets ERP, MES and platform coexist without duplicating management. Documentation and embeddings live on PostgreSQL, next to the data. See AI & MCP →

From architecture to AI

PostgreSQL underneath, Ollama alongside, MCP as the bridge to the models.

AI & MCP → Explore the modules ↑ Back to overview