Your AI agents are ready. Don't let your data hold them back.

Technical Platform Specifications & Operational Contracts

Semantius keeps the records your agents work on correct by construction, not by instruction. The rules live in the database, next to the data, and every change passes through them. This section explains how the architecture achieves that, and what it guarantees.

How the architecture keeps records correct

Eliminating semantic drift

One active data dictionary defines your business.

• The model: every entity, every field, every relationship with its cardinality, subtypes and extensions, each with its description, dimensions and measures.
• The business rules: extended JSONLogic, stored and evaluated inside PostgreSQL, for validation, computed fields and attribute-based access.
• One source for everything: the same definition drives the API, the app your team uses and what your agent reads. No generated code restates it, so there's no second copy to drift away from it.

A rule in a system prompt is read again in every session and followed most of the time. A rule in the database is evaluated on every write.

Real-time actions on live records

Agents act on the live system of record, not on an export or a copy kept in sync.

• Queues: changes that matter are put into queues with event and rule triggers: a new record, a status change, an approval waiting. An always-on agent picks them up on its next check.
• Incoming webhooks (Pro): they bring events from your other tools as they happen, authenticated and mapped to your entities and fields.

Unified context ingestion

• Getting data in: existing data comes in through CSV import and JSON modules. Continuous events arrive through incoming webhooks (Pro).
• One model: support tickets, product usage events and CRM records land in one model whose relationships are enforced by foreign keys.
• What the agent does with it: it follows a ticket to the customer's usage and the open deal by reference, instead of matching names across tools.
• Search: full-text search runs across all of it.

Agents as accountable actors

People and agents are both actors.

• Login and role: every agent signs in with its own token and works under its own role.
• Enforcement: role-based and attribute-based access control is enforced inside the database, with row-level security, for every caller.
• Refusals: a refused change returns the reason, the missing permission, and the agent can query the dictionary to see who holds it.
• The model: changing the model itself requires its own permission.

Who does the work, who approves it

State machines define the steps a record can go through, and enforce that it moves only along them.

• Permission gates: each step has a gate, so only a role allowed to take it can take it.
• Doing and approving: where you define who does the work and who approves it, the database enforces both.

A model your agent can read

• Readable at runtime: the dictionary's descriptions, relationships, dimensions and measures can be read at any time through the same API the agent uses.
• No manual needed: every agent session starts from the same understanding of your business, without out-of-band instructions.

Operational contracts

These hold for every app, API and agent login:

• Every write is checked against the rules defined for it.
• The same change, from the same role, against the same record, always gets the same answer.
• A refused change leaves the record as it was and returns the reason.
• A record moves only along the steps defined for it, and only by a role allowed to take the step.
• A reference can't point to a record that doesn't exist.
• Changing the model requires its own permission.
• Every change to data and to the model is logged, with who made it, person or agent, and when.

Outside these contracts

• Whether an agent chose the right action
• Whether a value that passes your rules is the right one
• A database superuser or table owner, who can bypass row-level security