Original implementation guide · Content version: · Sources
Separate AI drafts from authorised actions. Define approval versions, idempotency keys, reconciliation and readback before updating ERP or CRM.
A draft is not an instruction to commit
An AI-prepared quote can contain useful product matches and unresolved conditions. It is still a draft. Define the point at which a responsible person approves a particular version, and what that approval permits. Approval of a document should not automatically authorise an order, a discount or a payment. The business action needs its own destination, fields and permission boundary.
Bind approval to the actual payload
Record the business identifier, source version, proposed field changes and approver. If a quantity or currency changes after approval, review the new payload rather than reusing the old approval. In the local example the approval is only a fixture flag; production identity and approval services are outside its scope. This distinction prevents a demonstration checkbox from being mistaken for a complete enterprise control.
Use a key with a defined business meaning
A retry-safe request needs an identifier that remains the same when the same action is retried. Store that key with a digest or canonical representation of the payload. An identical retry can return the existing result; the same key with changed content should be rejected or reviewed. AWS documents idempotent request handling as a reliability practice. It does not remove the need to define transaction boundaries and retention.
Resolve uncertainty before retrying
A timeout may occur before a write or after the destination has committed it. Treat that as an uncertain outcome, not immediate failure. Query the destination by the request key or business identifier, compare the stored fields, and decide whether a retry is safe. If the system cannot be queried reliably, route the task to an exception owner. Repeatedly clicking submit can create duplicate business records.
Read the result from the business system
A successful HTTP response or visible confirmation is useful process evidence. Acceptance also needs the stored record, status and relevant values read back from the destination. Compare them with the approved payload and record differences. The downloadable SQLite sample writes one draft, verifies its readback and reuses an identical retry. It does not simulate a network timeout or prove distributed exactly-once execution.
Agree the exception handoff
Define who handles a rejected update, a changed source version, a duplicate conflict or an unavailable destination. Recovery may involve correcting data, obtaining a new approval or using a documented compensating action. Do not promise that every business operation can be rolled back. Mokyun AI treats write-back and its evidence as part of the work chain, with the actual controls scoped and tested for the target system.
Downloads and related guides
- Integration preparation worksheet (CSV)
- Field-authority and mapping worksheet (CSV)
- Pilot acceptance checklist (CSV)
- Download the reproducible example and all templates (ZIP)
- Observed execution receipts and file hashes (JSON)
- AI integration for legacy systems without APIs: choose a workable handoff
- ERP and CRM data conflicts: what enterprise AI should verify before preparing a quote
- Enterprise AI integration pilot kit: preparation, field mapping and acceptance evidence
- RAG, RPA and enterprise AI agents: choose by the business outcome you need
Sources
- Mokyun local example: execution receipts and scope
Source published: · Accessed:
- AWS: Make all responses idempotent
Accessed:
Mokyun Editorial · neo@mokyun.com
