Platform capability
AI you can let into the operation.
Before AI is allowed near orders, inventory and money, a team needs six answers: what can it see, what can it change, who approves it, what gets recorded, how do we trace what happened, and how do we know the change took. In mPorts the AI reads the same records your team does, changes nothing until a person with permission confirms, and every run, decision and change is kept on the record it touched — under the same roles, permissions and tenant boundaries that apply to people.
Six questions, answered from the product
What can the AI see?
The operational information mPorts OMS already holds: orders, products, inventory balances, fulfillment, shipments, what was promised and what the warehouse billed — through a reviewed set of capabilities rather than the whole interface, acting with the permissions of the person using it. It does not read your documents, policies or standard operating procedures.
What can it change?
Only fulfillment steps, and only after a person confirms: change the warehouse, the routing objective or the label owner; refresh the plan and submit to the warehouse; requote the shipment; resend the order to the retailer. Each runs through the same path a person’s change takes.
Who approves?
A person with permission, in an approval queue. The requester cannot approve their own action, exactly the payload that was reviewed is what runs, and an approval is used once.
What gets recorded?
Who made a change, what changed and what it was before, on the record itself; every AI run with the question, the records it read, the recommendation, the decision and the change; each approval decision in the audit log; and, when the AI proposed and a person executed, a record that says exactly that.
How do we trace what happened?
An audit log of who did what and when, a timeline per record, the raw messages exchanged with connected systems, an audit trail and decision log on every order, and a page your team can open to see what the AI proposed and what was executed.
How do we know the change took?
mPorts goes back to the connected system’s own record — does the warehouse hold the order, did the retailer receive the update — and marks each verified, stale or unknown. Unknown is never shown as success, and the assistant’s change-warehouse and change-objective playbooks end by re-running the diagnosis.
What the AI works from, what governs it, what it does
- Products
- Orders
- Inventory
- Fulfillment
- Shipments
- Warehouse billing
- Roles & permissions
- Approval queue
- Tenant boundary
- Audit log
- Investigate
- Explain
- Recommend
- Act after confirmation
- Verify
- Record
A change reaches a connected system only through the steps a person would have used, under the rules that already apply to that person.
-
Roles and permissions
Each role is granted permissions separately for orders, inventory, shipments, returns, invoices, reports, mappings, users and cost data — seeing invoices does not imply seeing margin — and a user can be limited to particular warehouses or sellers.
-
Approval queue
A change waits until a person with permission approves or rejects it; the requester cannot approve their own; what was reviewed is what runs; used once; written to the run and the audit log.
-
Audit trail
Who did what and when, a timeline per record, raw messages with connected systems, an audit trail and decision log on every order, and a tenant-visible page of what the AI proposed and executed.
-
Tenant boundary
Each customer’s data is held under its own tenant and every tenant-scoped query is filtered to it; an automated check in the codebase fails any change that reads tenant data without that filter.
-
Credentials
Credentials for connected carriers and channels are stored encrypted; for systems reached through the mPorts integration gateway, the OMS keeps only the connection reference and the secret stays in the gateway.
-
Your systems stay yours
mPorts operates alongside the systems you already run, connecting to them rather than replacing them; what it may change in each is what the connection is built to send.
-
Verification
After acting on a warehouse or retailer, mPorts confirms the result from that system’s own record and marks it verified, stale or unknown; an unverified state is never shown as success.
-
Attribution
When the AI proposed and a person carried it out, the audit record links the action to the proposal and keeps the person as the actor.
Things to ask us about directly
Hosting and data location, backup and retention, authentication options, security documentation and any certification you require. We answer those in the conversation, with the evidence.
Questions buyers ask
Does the AI ever change an order on its own?
A step that changes an order waits in the approval queue for a person with permission, and the agent’s policy fixes in advance which tools it may use at all. There is no default under which a write runs unreviewed.
Can we see what the AI did last week?
Yes. Every run is kept with the question, the records it read, the recommendation, the decision and the change, and a page visible to your team shows what the assistant proposed and what was executed.
How is our data separated from other customers’?
Each customer’s data is held under its own tenant, every tenant-scoped query is filtered to that tenant, and an automated check in the codebase fails any change that reads tenant data without the filter.
Ask us the questions your security review will ask.
We will answer with the product open and the evidence beside it.