> For the complete documentation index, see [llms.txt](https://docs.amigo.ai/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.amigo.ai/data/review-queue.md).

# Review Queue

{% hint style="warning" %}
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.
{% endhint %}

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

```mermaid
flowchart LR
    A["Eligible connector\nwrite-back event"] --> P["Proposal staged\nwith provenance"]
    P --> R{"Human review"}
    R -->|Approve| D["Deliver to\ntarget system"]
    R -->|Reject| X["Record decision\nwithout delivery"]
    D --> S["Record delivery\noutcome"]
```

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:

* **FHIR sinks** (`fhir_store` and `smart_fhir`) 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.

{% hint style="info" %}
For endpoint details and permissions, see [Review Queue](https://docs.amigo.ai/developer-guide/platform-api/integrations/review-queue) in the developer guide. For the surrounding data flow, see [Connectors and EHR](/data/connectors-and-ehr.md).
{% endhint %}


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.amigo.ai/data/review-queue.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.