How We Build Predictiv

A platform that scales with catalogue depth, not with engineering headcount.

Most ERP vendors are bolting AI onto closed stacks. Predictiv has built a different substrate — four catalogues that describe what the product is, generators that produce code from those catalogues, and an open-standard interaction layer that humans, integrations, and AI all consume the same way.

The result: new customer functionality and new AI capability share one build pipeline. Capability scales with catalogue depth, not with engineering headcount.

Catalogues are the substrate

Four catalogues are the source of truth for the platform. They are not documentation by-products — generators read them as input, AI tools resolve entities through them, and pre-commit gates enforce them.

Data Catalogue. A thousand-plus tables across fifteen domains, with foreign-key relationships and entity definitions kept current with the database.

Business Rules Catalogue. Five hundred-plus documented rules across eighteen domains: posting logic, document lifecycle, validation invariants, anti-patterns. The rules the AI relies on are the same rules the ERP enforces.

Codebase Catalogue. Six hundred-plus patterns across the Predictiv stack — Java, JavaScript, application-dictionary metadata, SQL — each documented with where the pattern lives and how to extend it.

Services Catalogue. Active companion services and the embedded interaction layer, including the open-standard MCP Server that exposes ERP data and processes to AI clients.

These are continuously maintained. The data and business-rules catalogues update automatically when the underlying schema or rule definitions change.

Generators produce the artefacts

A registered toolkit produces every platform artefact from spec or catalogue input. Tables, windows, callouts, event handlers, JasperReports, dashboards — every metadata file, every SQL file, every Java class follows from a spec, not from a manual edit.

Manual edits to generated artefacts are blocked at pre-commit by hard gates. The wrapper does not allow `--no-verify` to bypass them.

This is what makes the marginal cost of capability decline. A new module is generated end-to-end from spec — table, window, role access, AI tools, documentation. A new business rule is added to the catalogue and enforced everywhere it applies. Adding capability is a configuration change against the platform, not authoring against a blank canvas.

The interaction layer is what we are

The MCP Server exposes the same data-access layer the ERP's user interface uses, through a JSON-RPC 2.0 interface that is the emerging open standard for AI tool access. Authentication maps to the same role, organisation, and client context the user has. Every call is logged. Rate-limited per user. Six to fifteen disciplined tools, not forty — chosen deliberately for router accuracy.

The same code path that serves human users serves AI clients. No second source of truth. No drift. The interaction layer is what we are; AI is one client among many.

This pattern matters because it means the AI's understanding of the business is the same as the ERP's. When business rules change, the AI follows automatically. There is no separate AI knowledge graph to maintain, no parallel embeddings of business logic to keep in sync.

What this means for unit economics

Capability scales with catalogue depth, not with engineering headcount. New customer functionality is configured against the platform, not authored line-by-line. New AI capability is registered against the same data layer, not built on a separate stack. The platform is the asset; new work configures that asset.

Four catalogues

Data, Business Rules, Codebase, Services — the substrate that drives generators and AI alike.

Generators not authors

Every artefact follows from a spec. Manual edits blocked at pre-commit.

Open-standard interaction

MCP server, JSON-RPC 2.0, with the same role enforcement and audit trail as your ERP UI.

One code path

Humans, integrations, and AI all use the same data-access layer. No drift, no second source of truth.

Want to see this from the inside?

We share architecture deep-dives and live walkthroughs under NDA with serious customers, investors, and design partners.