◆ DTO AI Framework

Not just a MES. A platform.

DtoMES is the manufacturing face of a broader business platform: the DTO AI Framework. A production-proven framework plus an MCP server that lets AI build whole vertical modules on safe rails. A shared central nervous system — identity, telemetry, documentation — on which the verticals plug in. Data on PostgreSQL, local intelligence with Ollama, AI integration via MCP.

An AI-native software factory
A framework + an MCP server that guides the AI

Generic AI starts from scratch. Here it operates on an engine already proven in production: the framework provides the shared core (data, sync, telemetry) and the architectural rules the AI must respect; the MCP server exposes the tools to generate, validate and document whole modules — on safe rails.

Framework / Core

Data · sync · telemetry · rules

MCP server

Scaffolding · validation · registration

Vertical module

Coherent, tested, documented

The central nervous system
Shared services, under every module

Every vertical inherits the same base services — dashboard, telemetry, audit, documentation, log, synchronization. They are not rewritten for each project: a module generated according to the MCP server's rules wires them in automatically. This is what holds the platform together and makes every module coherent.

🔐 Authentication & permissions

Centralized RBAC, declarative enforcement on forms, menus and actions, identity-provider abstraction (AD/SSO/PostgreSQL hook). Separation of duties.

📡 SEH · Telemetry

SyncEventHub: collects events with an outbox pattern and forwards them asynchronously to PostgreSQL. If the network drops, the local queue holds them — no event lost, no operation blocked.

📄 Centralized audit

Security events (login, access denied, permission change, SoD override) on PostgreSQL (ml_app_events), with the same vocabulary as RBAC. Never a password in the logs.

📊 DAH · Dashboard

DtoMesAnalyticsHub: dashboards and analytics exposed as internal web pages. Real-time view (what's happening now) and queryable history.

📚 Three-pillar documentation

MemoryLens: one architecture for developer, user and support. Contextual help, diagnostics and tickets with automatic context, via TMLHelper.

🔍 MLPivot

Knowledge archive: documents with full-text search, fed and queried via MCP (archive_document, search_documents). Versioned history, no deletion.

🧾 Log

Structured application logging, consistent with telemetry and audit: the same tracing discipline at every level of the system.

🌐 Nginx

Reverse proxy serving the internal web dashboards (Dashboard, MLPivot Web) as services. A single entry point for the platform's web interfaces.

🐘 PostgreSQL synchronization

Events, telemetry, documentation and embeddings consolidated on PostgreSQL. It's also the migration path to PG, without rewriting the modules.

Inherited, not rewritten: the rules encoded in the MCP server ensure every new module wires in dashboard, telemetry, audit, documentation, log and synchronization following the framework — on rails, not by hand. How it works with MCP →
How it reaches the market
Three layers on the same engine
01

Communication

The showcase and the portals (e.g. the WordPress channel esperanto.sbs for the Esperanto network): where the public and decision-makers meet the project. Complementary to the platform, not the same stack.

02

Administration

The core: members, fees, production, accounting, banking, compliance, multi-level consolidation. This is the platform product (Delphi + PostgreSQL) where data becomes management.

03

Distribution

Catalogue, orders, inventory, fulfilment, labels — modules already present from the MES line, reused for commercial scenarios (e.g. book distribution in a federated network).

Multi-country
Common management, local accounting

Operations are identical everywhere; only accounting differs. That is why adding a country is configuration, not rewriting: a neutral accounting contract, a per-country profile that declares the additional data, and a per-country tax connector (SdI, CFDI, DTE…).

1 · Common management

The vertical modules are identical everywhere. The module does not know "which country" it works for: it only knows the active profile requires certain extra fields.

2 · Journal-entry engine

The accounting engine, isolated behind an interface and parameterized per country, translates the neutral event into the right parameters. First implementation: Italy.

3 · Tax connector

One plug per country for e-invoicing and compliance. One site per language area (e.g. ES), but distinct accounting profiles for each country.

Honest framing: this is a designed capability, with Italy as the first implementation. Other markets are on the roadmap, not declared as already in production.

From framework to product

The same platform, two sections: grasp the value, then dive into the technical side.

Why DtoMES → Technical architecture