Review Queue

Human approval workflow for proposed writes to external clinical systems, with explicit decisions, delivery status, and audit history.

External write approvals are currently in private preview and available only in enabled workspaces and environments. Contact your Amigo representative before designing a production workflow around this capability.

The Review Queue governs eligible connector write-back events for destinations configured to require human approval. Instead of sending the write immediately, the platform stages an external write proposal with the target, proposed change, and origin context. The preview does not intercept every integration tool call or every world-model event.

This workflow is separate from world-model confidence scoring. Source and destination eligibility apply before a proposal is staged, but an eligible event can be staged at any confidence. Reviewers decide whether that specific external mutation may proceed; they do not edit event confidence or rewrite the underlying world-model history.

How It Works

1. A source-eligible outbound event targets a connector destination configured to require review.
2. The platform stages a proposal instead of calling the target system.
3. An authorized reviewer inspects the proposal and approves or rejects it.
4. Approved proposals enter the delivery path. Rejected proposals remain closed with the reviewer's reason.
5. The proposal records the final delivery outcome for audit and follow-up.

What Reviewers See

A proposal gives the reviewer enough context to make a decision:

• The target connector and clinical resource type
• The proposed payload and affected entity
• The originating world event and, when populated, run context
• Confidence and provenance information supplied by the originating workflow
• Current review and delivery status
• Prior decision, delivery attempts, or failure details

Proposed payloads may contain protected health information. Access is workspace-scoped and permission-gated.

Proposal Lifecycle

Status	Meaning
Proposed	Awaiting a reviewer decision.
Approved	Approved and waiting for delivery.
Rejected	Rejected by a reviewer and never delivered.
Pushing	Delivery is currently in progress.
Pushed	Delivered successfully to the target system.
Failed	Delivery did not succeed within the permitted attempt policy.
Superseded	Retired or replaced before completion and no longer eligible for a decision or delivery.

Only a proposal in Proposed status can be approved or rejected. If two reviewers act at the same time, the first valid decision wins and the other reviewer is asked to reload the current state.

Review Decisions

Reviewers have two actions:

• Approve - Authorize the proposed payload for delivery.
• Reject - Block delivery and record a required reason.

The current proposal workflow does not provide a Correct action. If the payload needs to change, reject the current proposal and have the originating workflow create a new one so the audit trail preserves both records.

Delivery Safety

Approved proposals use a delivery policy matched to the connector type:

• The active FHIR sink (fhir_store) use idempotent write behavior and can retry up to the proposal's attempt limit.
• Other sinks receive at most one automatic vendor call. After an ambiguous failure or a crash during delivery, the proposal fails visibly rather than risking a duplicate booking, cancellation, or creation.

This favors a visible, recoverable under-delivery over a silent duplicate clinical mutation. Failed proposals retain their error state for investigation.

Pushed means the destination handler completed without reporting an error and the proposal was marked delivered. A read-back is operation-specific, not universal; verify destination state when the workflow requires end-to-end confirmation.

Audit and Access Control

Approval and rejection use the authenticated reviewer's identity. Each decision is audit-logged with the proposal, target type, action, and reviewer attribution. The proposed payload is not copied into audit log entries.

Read and decision permissions are separate, allowing organizations to give some users queue visibility without authority to approve clinical writes.

For endpoint details and permissions, see Review Queue in the developer guide. For the surrounding data flow, see Connectors and EHR.