A bounded task is the unit of work
An invoice extraction response is a candidate interpretation. A draft bill in the correct ERP workspace is a business action. The Outcomes API architecture connects those two stages through an explicit task contract: permitted inputs, required output fields, checks, an authorized destination and a definition of completion. This gives applications a way to reason about progress and evidence without treating generated text as confirmation.
The architecture centers on narrow, reviewable operations such as preparing an invoice draft. It does not assume that every business process should become autonomous. A task may stop for missing information, conflicting evidence, unavailable credentials or an uncertain write. Those results need to remain useful to the calling application.
Separate interpretation from execution
This separation gives developers places to attach controls. A budget policy belongs before model selection. A supplier-match rule belongs before bill creation. A record identifier and observed version belong in confirmation evidence. Combining all three inside an opaque prompt makes retries, permissions and failure diagnosis harder to reason about.
- Validate the requested operation against a versioned contract and authorized workspace.
- Produce a candidate result using a suitable permitted model or deterministic transformation.
- Run structural and business checks against the candidate and relevant source records.
- Perform only the action authorized by the contract, then read back the resulting state.
- Return an evidence record that distinguishes passed checks, action acknowledgment and confirmed persistence.
Fit the API around the system of record
Outcomatic is an independent product endorsed by ERP.AI. The integration architecture centers on scoped record and workflow interfaces, with permissions, mappings and confirmation rules defined for each destination. Evaluate an adapter against the exact operation you need, including its behavior when a write times out or a record changes during execution.
Evaluate a first integration by choosing one operation, a representative fixture set and an observable success condition. Establish who can authorize a write, how duplicate submissions are identified and what the application should display when confirmation is incomplete. The demo illustrates this decision structure without connecting to a live ERP account.
| Application responsibility | Outcomes API design responsibility |
|---|---|
| Choose the business operation and grant access | Enforce the accepted task boundary |
| Provide source data and review policy | Generate and check a candidate result |
| Decide how exceptions enter the work queue | Expose evidence and an explicit unresolved state |
Missing a detail or found a problem?
Send a documentation question →