# Architecture diagram review checklist

Use this with an engineering review, whether the diagram lives in Arialine or another tool.

## Establish the reference

- Name the system boundary and level of detail.
- List the components and relationships you are actually reviewing.
- Check the source against the intended design; AI output is not implementation evidence.
- Identify the reviewer and the owner of the accepted design.

## Review the failure path

- What happens if a downstream operation fails after the upstream operation succeeds?
- Are retries bounded? Who owns exhaustion and recovery?
- Which assumptions require evidence or a separate design decision?
- Which relationships are still unknown or proposed?

## Record an accepted change

1. Keep the proposed change separate from ordinary discussion.
2. Review the plain-language proposal; edit or dismiss it if the request is wrong.
3. Apply the accepted request, then inspect the generated Mermaid and rendered result before treating the version as a design reference.
4. Keep the resulting version and its source request accessible.
5. Write context, alternatives, consequences, ownership and status in the formal design record.

## Example addressed request

```text
@Arialine add a retry queue before the fulfillment worker because fulfillment may fail after payment succeeds
```

In Arialine, invite the app to the working channel, create a board, and address edits in its thread. Proposal mode requires review/application. The example is illustrative; it is not a complete reliability design.

Website workflow: https://arialine.app/use-cases/architecture-reviews
Setup: https://arialine.app/getting-started
Data handling: https://arialine.app/privacy