What we touch, what we don’t, and who can prove it.
You are being asked to let an AI system read from your systems of record and, once you approve, write back to them. That deserves a straight answer rather than a badge. Here is what ADIP actually accesses, what it cannot do, and what you keep control of.
Read-only by default. Write-back only where you scope it.
What ADIP reads
- Only the fields the agents in your scope actually reason on — not a full database copy
- Through standard governed interfaces: APIs, database views, existing lake or warehouse tables
- No schema changes on your side, no agent installed inside the ERP
- The field list is documented at assessment and reviewed before go-live
What ADIP writes
- Nothing at all until you enable it — first domain runs recommend-only
- Field-level scope agreed in writing, not blanket system access
- Every write carries the decision ID, the approver identity and the timestamp
- Prior state retained and restorable
- Recommend-only mode remains available permanently if that is your policy
Disconnect ADIP and your business keeps running exactly as it did. Your ERP is still the system of record, your data never moved, and no process depends on us to transact. You lose the coordination and the decision memory — you do not lose the operation.
Auditable end to end.
Lineage and permissions
Data lineage, access control and audit run through Unity Catalog on Databricks. Every field an agent reads is traceable to its source system and its permission grant.
Decision logging
Every recommendation and every human response is logged: the trigger, the alternatives considered, the constraint that applied, the expected impact, the approver and the timestamp. Exportable for audit.
Operating limits
Each deployment defines which decisions may be automated, which require approval, and what an agent may never do regardless of confidence. These are enforced in configuration, not stated in a policy.
Model isolation
Your Judgment Layer — your approvals, overrides and the reasoning behind them — is never shared across customers and is never used to train anything another customer touches.
Data residency
ADIP runs in your Databricks environment or a dedicated one, in the cloud and region you specify. Data does not transit to a shared A2go tenancy.
Open formats
Storage in open formats on the lakehouse, versioned. Portable by design — you are not locked into a proprietary store you cannot read without us.
What your security team will ask for.
| Document | Contents |
|---|---|
| Architecture and data flow | Every connection, direction of flow, field-level scope, and where processing occurs. |
| Access control model | Authentication, role definitions, permission inheritance and separation of duties between agent and approver. |
| Audit and retention | What is logged, for how long, in what format, and how it is exported. |
| Write-back scope template | The document you sign before any action reaches a system of record. |
| Subprocessors and hosting | Cloud provider, region, Databricks configuration, and any third party in the path. |
| Incident and continuity | Notification commitments, escalation path, and what happens to your operation if ADIP is unavailable. |
Compliance certifications and their current status are provided on request — ask during a working session and we will send the current pack rather than a claim on a webpage.
Bring your security team to the first call.
It is a better use of the session than a second one later. We will walk the data flow, the write-back scope and the audit model against your actual environment.