---
title: "Mermaid architecture diagrams"
description: "Inspect the system boundary, immutable dispatch lifecycle and document pipeline as readable, downloadable Mermaid diagrams."
---

> Documentation Index
> Fetch the complete documentation index at: https://engineering.guteneo.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Mermaid architecture diagrams

These Mermaid diagrams show logical relationships and state transitions. Each
includes an enlarged SVG, an editable `.mmd` source and an equivalent text
explanation. The isometric walkthroughs remain on the corresponding topic pages.

## System and provider boundaries

Use this view to trace durable work through Cloudflare and identify the explicit
handoff to external fax, postal and email providers.


**Mermaid · System and provider boundaries**

![System and provider boundaries](/illustrations/system-architecture-mermaid.svg)

Workers orchestrate the shared domain service. Durable commitments, private bytes and queued work stay on the application side of an explicit handoff to external delivery providers.

- Clients reach Workers through the browser, native application, REST API or MCP. D1 records commitments, private R2 stores document bytes, and private services handle configured document checks.
- An outbox publisher feeds queues. A consumer claims one attempt before the provider adapter submits it.
- Telnyx fax, Pingen printing and post, and Resend email are external to Cloudflare. Verified callbacks and reconciliation return facts to the domain service; this architecture does not claim live qualification or processing residency.

[Open full-size SVG](/illustrations/system-architecture-mermaid.svg) · [Download SVG](/illustrations/system-architecture-mermaid.svg) · [Mermaid source](/illustrations/system-architecture.mmd)

Read the [system architecture](/architecture/system/) for component responsibilities
and the distinction between implementation and live qualification.

## Approval and dispatch lifecycle

Use this view to separate the immutable approval record from dispatch state, and
to see where atomic acceptance ends and uncertain provider outcomes must stop.


**Mermaid · Approval, acceptance and uncertainty**

![Approval, acceptance and uncertainty](/illustrations/dispatch-lifecycle-mermaid.svg)

Approval is a separate immutable record. The atomic D1 commitment leads to queued work and one claimed provider attempt; an unknown outcome stops automatic resubmission.

- A prepared dispatch identifies exact content, recipient, options and quote. A separate approval record binds that commitment and current authenticated authority.
- One D1 acceptance transaction verifies approval, reserves quota and writes the outbox before the dispatch becomes queued. A conditional claim moves an eligible attempt to submitting.
- Known provider responses can establish accepted or failed. An uncertain response or expired lease leads to submission_unknown and provider-specific reconciliation, never automatic resubmission. Later channel events describe delivery separately from acceptance.

[Open full-size SVG](/illustrations/dispatch-lifecycle-mermaid.svg) · [Download SVG](/illustrations/dispatch-lifecycle-mermaid.svg) · [Mermaid source](/illustrations/dispatch-lifecycle.mmd)

Read the [dispatch lifecycle](/architecture/dispatch-lifecycle/) for cancellation,
delivery facts, reconciliation and financial settlement boundaries.

## Data, templates and derived documents

Use this view to compare generation from mapped data and versioned templates with
postal-address-page derivation from an uploaded original.


**Mermaid · Data, templates and derived documents**

![Data, templates and derived documents](/illustrations/document-pipeline-mermaid.svg)

Mapped data and a concrete Studio template version feed generation. Adding a postal address page is a separate derivation from an uploaded original; both paths produce a new private document.

- Parsed source data passes through an explicit mapping profile. A concrete template version and settings join those mapped inputs in a generation job, which records artifacts and provenance.
- Uploaded originals retain their identity and exact stored bytes under the applicable access and retention rules. Adding a postal address page creates a separate derived PDF; the original PDF is not an imported Studio template input.
- Derived documents still need applicable scan, validation and preview checks before later immutable approval and separate dispatch acceptance. Generation itself grants no delivery authority.

[Open full-size SVG](/illustrations/document-pipeline-mermaid.svg) · [Download SVG](/illustrations/document-pipeline-mermaid.svg) · [Mermaid source](/illustrations/document-pipeline.mmd)

Read [document workflows](/workflows/documents/) and
[Studio and data pipelines](/workflows/studio-and-data/) for provenance, validation
and the separate authority required for dispatch.

For the persisted records behind these flows, see the separate
[data model and entity relationships](/architecture/data-model/).

Source: https://engineering.guteneo.com/architecture/diagrams/index.mdx