Trust and control
Built for a live ERP
An AI that can change your finance and supply chain records has to be bounded, checked and visible. These are the controls that do that, and the limits we are open about.
Controls
What keeps it safe
Identity and access
JD Edwards security still decides
The platform acts as the signed-in person's own JD Edwards user, so application, row and column security apply. If you cannot do it in JD Edwards, neither can the platform on your behalf.
Every person is mapped, never substituted
Microsoft sign-in leads to the person's JD Edwards user. If a person cannot be resolved, the request fails and does not fall back to someone else's account.
Your enterprise application controls access
Microsoft issues a sign-in only to people you assign. JD Edwards must also recognise them, and the check repeats every 12 hours.
One read only system user
A single read only JD Edwards user handles connection tests and health checks where no person is involved. It cannot sign in and has no write access.
Verified actions
A trust badge on every run
Each run shows read only, change made, or change not verified, worked out from what actually happened.
Writes are re-read
After a create, update or delete, the platform queries the table by key and confirms the value. A mismatch is shown as a failed write, with expected and actual values.
Write discipline by default
Any agent that can write is told never to invent a key and never to retry blindly.
Read only is a switch
Schedules, email assistants and any assistant or agent can be set to read only, which removes every write tool. It is strongly recommended for anything triggered by email.
Skipped work is not success
A batch step that never made its required call is failed, and its reply is replaced, so a confident but empty answer cannot pass.
Safety limits
Kill switch
An administrator can stop every model call and scheduled run on the instance at once.
Spend budgets
Optional daily limits per person and a monthly limit for the instance. They are off until you set them.
Rate limits
Per-person limits on requests that start a model turn, set well above normal use.
Circuit breaker and step cap
The platform backs off when the AI provider keeps failing, and caps the number of tool steps in a single turn.
Separation and data
One customer, one subscription
Each customer runs in their own separate Azure subscription, operated by Fusion5.
No copy of your ERP
The platform keeps no replica or warehouse of your JD Edwards data. Records are read when needed, under the asker's security.
Your AI account
You create and hold the AI model credential and set its spending limits. Fusion5 does not supply it.
Safe documents
Generated files cannot carry macros, links or model-written formulas, and each file is owned by its creator.
Retention you control
An optional daily job deletes logs older than the period you choose. It never touches agents, skills, pipelines or generated files.
Visibility and audit
One trace identifier
Each request carries a single identifier from question to answer, recorded in the audit trail.
An activity log
Sign-ins, refused sign-ins and settings changes are recorded.
AI disclosure
The sign-in page names the AI provider, every chat says answers are written by AI and can be wrong, and every generated file says so too.
Structure-only monitoring export
Optional streaming to your monitoring tools carries the shape of activity, never JD Edwards business data.
Quality over time
A daily health check
The platform checks itself daily against a baseline that moves only when an administrator resets it.
Your own tests and drift view
Turn real questions into tests and watch recent runs against a pinned baseline. Off by default.
Skills change by proposal
Suggested rule changes arrive as drafts, and an administrator promotes them. Nothing applies itself.
Releases are gated
Releases pass automated tests, security scans and an evaluation set before approval, and deployment is a separate manual decision.
How a question flows
From a question to a checked answer
The person signs in
They use their corporate Microsoft account. Your enterprise application decides who may enter.
They are known by email
The platform identifies them by their email address.
They ask in plain words
For example, which vendors are on hold, put to an expert or to their own assistant.
The right tools and rules are chosen
The platform picks the expert's tools and skills, and the documentation if that switch is on.
JD Edwards is asked who they are
The platform looks the person up to find their JD Edwards user and signs in to JD Edwards as them.
JD Edwards runs it
The query or change runs under that person's own security.
The answer comes back with evidence
It shows the queries used, a trust badge, and a note that AI wrote it.
Changes are confirmed
If anything changed, the platform reads the record back before saying it worked.
Data separation
Your data stays yours
Your subscription
Fusion5 provisions a dedicated Azure subscription for your organisation and runs the platform in it, including hosting, monitoring and updates.
Your JD Edwards stays the system of record
Nothing is copied out to a data warehouse, and no JD Edwards objects are changed to make the platform work.
Your AI model, your choice
You choose where AI processing happens, for example Anthropic directly or AWS Bedrock in your own AWS account, and you hold the credential. Data you ask about does go to the provider you choose.
Honest limits
What to know before you start
- Assistants and agents can write to JD Edwards. That is by design, bounded by the person's own security. Read only is a switch you set, not a blanket default.
- You choose and own the AI model account and its spending limits. Fusion5 does not supply it.
- AI answers can be wrong. The platform reads live data, shows its queries and verifies writes, and still tells people to check key figures.
- Kill switch, spend budgets, retention and evaluation tests are off until an administrator turns them on.
- Your JD Edwards administrator has to map each person and create the read only system user. That session is usually the critical path.
- Two to four weeks to go live is typical. Your own approvals set the pace, not the technical work.