Legacy modernisation / Architecture guide
A governed path between
legacy data and AI agents.
How Inistate turns stored data into permitted business activities, and what your integration needs to do to keep synchronisation reliable.
01 / The contract
Expose business activities with explicit rules.
Map a legacy record into an Inistate module: named and typed fields, states, activities and the flows between states. For example, STS_CD = P3 becomes Approved, with an Issue to vendor activity and a form defining the information it needs.
Legacy systems
Your integration reads changes and translates them into records and permitted activities. It owns the legacy credentials and mapping.
Inistate workflow
Holds the state, permitted next steps, form requirements, access and history of the business record.
People, AI, automation
Act through web and mobile, MCP, or the API and integrations. Business rules stay with the workflow.
The agent reads meaning and context at runtime. It requests an activity on a record; the integration translates accepted workflow changes back into the legacy representation.
02 / The write path
Validate the activity before changing the state.
- 1
Actor and access
The MCP actor gate handles human-only activities and hybrid confirmation. API checks enforce access to the module, record and activity, plus field restrictions and required values.
- 2
Current state
The transition engine checks whether the requested activity is available from the record’s current state.
- 3
AI confidence
Where configured, a confidence threshold holds below-threshold AI attempts as intentions for review. The state stays unchanged.
- 4
History and triggers
An accepted activity changes the record, writes history and fires the configured triggers. Your integration handles external write-back.
Use dedicated agent connections. An agent using a person’s API token can appear as that person. Reported confidence is a routing signal, not proof that a model’s answer is correct; retain human review for consequential decisions.
03 / The MCP interface
Let the schema grow without multiplying tools.
Schema-driven tools discover modules, read their fields and flows, fetch records and forms, and submit activities. A new module can reuse the same interface. Its mapping, permissions and workflow still need validation.
| Approach | 10 tables | 100 tables |
|---|---|---|
| One generic SQL tool | 1 | 1 |
| List, get, create, update per table | 40 | 400 |
| Inistate runtime tool set* | 15 | 15 |
*The engineering notes describe 15 runtime tools. Tool availability can vary with mode and version. The architectural advantage is the shared interface; a small tool count alone does not establish governance. SQL permissions and custom wrappers may have their own controls.
04 / Synchronisation and recovery
A state guard stops an invalid replay.
The integration handles delivery.
Suppose an order moves from Pending approval to Approved. The write-back sets the ERP status to P3. If the next sync interprets this as a new approval, Inistate rejects Approve because that activity is no longer available from Approved.
1. Accepted transition
Pending approval → Approve → Approved. A state-change trigger requests write-back.
2. Legacy echo
The integration writes P3. A later poll sees P3 and repeats the approval request.
3. State guard
Approve is unavailable from Approved. The replay does not advance the workflow.
This protects that transition. It does not make the entire distributed integration exactly-once. Design and validate the following for each connection:
- Stable identity and duplicate protection. Map legacy row IDs consistently. Use idempotency keys or equivalent deduplication for same-state edits, repeatable activities and external side effects.
- Field ownership and conflicts. Decide which system owns each field and how simultaneous changes are resolved. Avoid two systems overwriting one another.
- Failure recovery. Monitor failed write-backs, use bounded retries, preserve enough context to replay safely, and reconcile the two systems after recovery.
- Freshness. A polling integration can be out of date by its sync interval, plus processing time. Display or account for that delay in time-sensitive decisions.
- Cutover. Agree reconciliation checks, backups, acceptance criteria and rollback before transferring ownership or retiring a legacy component.
Use a warehouse or analytics platform for large historical aggregations. Keep this layer focused on operational records and their lifecycle.
05 / The deployment boundary
Review the full data path for on-premise AI.
The On-Premise plan runs Inistate Enterprise on your own servers, keeping records, files and change history on your premises. AI and outside connections are optional.
For an entirely internal deployment, review where each component runs: Inistate, the legacy connection, automation workers, the MCP client, the model endpoint, file handling and operational logs. Confirm the supported architecture and network dependencies during deployment scoping.
Connecting an external model or SaaS automation can send data outside that boundary. Enable only the connections your organisation approves; on-premise hosting alone does not change an external service’s data path.
06 / Pilot acceptance
Prove the controls on your own process.
- Reconcile a representative sample of imported records against the source.
- Test allowed and denied actions with separate person and agent identities.
- Verify human confirmation and below-threshold AI intentions.
- Replay an event and a same-state edit; inspect both workflow history and external effects.
- Interrupt the connection, recover it, and reconcile missed or conflicting updates.
- Check network destinations against the agreed deployment boundary.