How should an AI-native ERP turn answers into controlled action?

Adding a chat box to business software does not by itself create an AI-native ERP. The useful distinction is whether AI works inside the operational context and controls of the application.

A person should be able to ask a real business question, inspect the records behind the response, review any proposed next step, and act through the same permissions and rules that govern ordinary work.

A practical test for AI-native

Ask the assistant why a project cost changed, which shortages affect upcoming work, or what contributes to an account balance. Then ask it to prepare an appropriate supported next step.

Look for continuity. Does the answer reflect current authorized records? Can the user inspect the evidence? Are important calculations defined by the application? Does the proposal identify what would change? Does execution still require the relevant permission and confirmation?

Five stages from question to action

1. Understand the question. Identify the business context without assuming facts that are not present.
2. Retrieve permitted records. Apply the user's company and access context before information reaches the model.
3. Explain with evidence. Show the records and assumptions behind the answer, including uncertainty.
4. Prepare supported work. Present the proposed values or document for review rather than hiding them in a conversation.
5. Apply normal controls. Require the applicable permission, confirmation, approval, business rules, and history.

Keep calculations inside business rules

Language models are useful for interpreting a question and explaining a result. They should not become the authority for inventory availability, currency treatment, account balances, project cost, or another defined business calculation.

The application should calculate using its recorded data and controlled rules. The assistant can bring the result into context, compare it, and explain it in plain language. This separation improves consistency and gives users something they can verify.

Do not expand the user’s authority

An assistant should not reveal a record the user cannot access or perform an action the user is not permitted to perform. It should also respect approvals and confirmation requirements. Conversational convenience is not a reason to create a second, weaker route around business controls.

Record the resulting action through its owning workflow. The history should identify the responsible person and retain the operational evidence required by that workflow.

Questions to use in a demonstration

• Show the records that support this answer.
• Ask the same question as users with different access.
• Ask a question the records cannot answer.
• Show which calculation produced the number.
• Prepare a supported action and show every value before confirmation.
• Try the action as someone without permission.
• Show the business history after the confirmed action.

These tests expose the difference between a fluent interface and an assistant that belongs inside an operational system.

How Dot works within Datum

Dot is the intelligence layer inside Datum. It works from authorized business context to answer questions, investigate changes, build analyses, and prepare supported work. Records and evidence remain available so the user can inspect the basis of a finding.

Datum retains authority over company context, permissions, controlled calculations, business rules, confirmation, and supported actions. Dot does not turn a user's question into unrestricted access or replace the controlled business services that govern the work.