Skip to main content
Write-back operations, such as creating purchase orders, updating records, and triggering external systems, pass through a configurable approval model before execution. Every action is logged, and the system enforces separate credentials for write operations.

​
Four-Gate Approval Model

Each write-back action is assigned to one of four approval gates based on risk level:
Gate assignments are configured per action type by administrators. The platform enforces the assigned gate, and it cannot be bypassed at runtime.

​
Approval Workflow

1

User initiates action

A user requests a write-back operation through the platform (e.g., “Create a purchase order for 500 units of part X”).
2

System classifies the action

The platform identifies the action type and its assigned approval gate.
3

Dry-run simulation (optional)

The user can request a dry-run to see exactly what would change without writing any data.
4

Approval gate enforced

Depending on the gate, the action either auto-executes, requires user confirmation, manager approval, or dual-control sign-off.
5

Execution and audit

Once approved, the Action Agent executes the operation. The full lifecycle is recorded in the audit trail.

​
Dry-Run Capability

Any action can be simulated before execution. The dry-run:
  • Shows exactly what data would be created, modified, or deleted
  • Executes against the target system in read-only mode where supported
  • Produces the same output format as a live execution, clearly labeled as a simulation
  • Is logged in the audit trail as a dry-run event
Dry-run results reflect the system state at the time of simulation. If underlying data changes between dry-run and execution, the actual outcome may differ.

​
Rollback Declarations

Every action declares its reversibility before the user confirms execution: The reversibility declaration is displayed to the user and approver before execution. Irreversible actions require explicit acknowledgment.

​
Separate Credentials

Action Agents use write-capable credentials that are entirely separate from read-only data-source agent credentials: Credentials are stored within each agent’s isolated container. No credential sharing occurs between read and write agents.

​
Action Audit Trail

Every action lifecycle event is recorded in the immutable audit trail:

Recorded for every action

  • Who initiated the action
  • What the action would do (parameters, target system)
  • Which approval gate was required
  • Who approved or rejected (and when)
  • Dry-run results (if requested)

Recorded on execution

  • Exact operation executed
  • Target system response
  • Success or failure status
  • Rollback eligibility at time of execution
  • Timestamp for every step
The audit trail is immutable: once written, records cannot be modified or deleted by any user or administrator. See Compliance for retention and export details.