Question-first diagramming

Choose the question.
Get the right diagram.

Describe what your audience needs to understand. Archify recommends one bounded visual recipe—plus the evidence it must contain, when not to use it, and a prompt you can copy.

Ten supported diagram types: Architecture, Workflow, Sequence, Dataflow, Lifecycle, ERD, Class, Tree, Timeline, and Waterfall. The recipes below are selected starting points.

13real-world
recipes
6diagram modes
with recipes
0runtime
dependencies

What must the diagram explain?

Write a situation, not a diagram type. Specific system facts produce a stronger recommendation.

⌘ / Ctrl + Enter
Recipe library

13 small, opinionated starting points.

Each recipe answers one technical question. That boundary keeps the result legible, reviewable, and honest about missing evidence.

Read the complete recipes

One question. A clear evidence boundary.

These recipes come directly from this build's CLI source. Follow the source and proof links to inspect what each recommendation means.

architecture · classic

System overview

What exists, who owns it, and how is it connected?

A bounded map of core components, external dependencies, primary paths, and trust boundaries.

Use when
Onboarding, design reviews, repository orientation, or explaining a service landscape.
Avoid when
The audience needs exact call order, state transitions, or row-level data lineage.

Evidence to include

  • 8–12 core components
  • one primary path
  • external dependencies
  • trust boundaries

Copy-ready prompt

Analyze this repository, then use Archify to create a high-level architecture diagram. Show 8–12 core runtime components, one primary request or data path, external dependencies, ownership or trust boundaries, and put supporting detail in cards instead of adding more edges.

architecture · blueprint

Deployment ownership

Where does each workload run, and what crosses a boundary?

A deployment-focused map of regions, networks, clusters, workloads, stores, and cross-boundary mechanisms.

Use when
Cloud reviews, production readiness, multi-region planning, or infrastructure ownership handoffs.
Avoid when
Deployment facts are unknown or the real question is application behavior rather than placement.

Evidence to include

  • regions and networks
  • workload ownership
  • stateful services
  • named boundary crossings

Copy-ready prompt

Use Archify to draw the production deployment topology. Group resources by region, network, cluster, and owner; show workloads and stateful services; label every cross-boundary mechanism. Do not invent deployment facts—mark unknown areas explicitly. If the user wants a fail-closed deployment review, ask before setting meta.engineering_profile to deployment-ownership; otherwise leave the engineering profile unset.

workflow · signal-flow

Agent tool-call loop

How does an agent plan, get permission, act, recover, and report?

A lane-based agent loop with policy gates, tool execution, exception recovery, evidence, and final response.

Use when
Explaining agent runtimes, MCP/tool orchestration, approvals, retries, or observability.
Avoid when
The goal is only to show static agent components or exact API message timing.

Evidence to include

  • request and planning
  • policy or approval gate
  • tool execution
  • exception and evidence paths

Copy-ready prompt

Use Archify workflow mode to explain this agent tool-call loop. Separate user surface, agent runtime, policy boundary, exception handling, tool execution, and observability into lanes. Make the successful path primary and show approval, retry, blocked, and evidence paths explicitly.

workflow · classic

Delivery workflow

How does a change move safely from commit to production?

A delivery flow with build, checks, environments, approvals, smoke tests, rollback, and ownership lanes.

Use when
CI/CD design, release reviews, deployment governance, or onboarding developers to delivery.
Avoid when
The question is where infrastructure runs or what states a deployment object can occupy.

Evidence to include

  • trigger and build
  • blocking checks
  • approval and environments
  • rollback and verification

Copy-ready prompt

Use Archify workflow mode to draw this delivery process from commit to production. Separate developer, CI, approval, environment, and exception lanes; mark blocking checks, smoke tests, ownership, and the rollback path. Keep one unmistakable happy path.

workflow · signal-flow

Incident runbook

How do responders detect, triage, mitigate, verify, and escalate?

An operational workflow that separates signals, responders, mitigation, communications, and recovery proof.

Use when
Incident playbooks, on-call handoffs, reliability reviews, and tabletop exercises.
Avoid when
The audience needs live metrics or a post-incident component topology instead of response actions.

Evidence to include

  • detection signal
  • triage owner
  • mitigation and rollback
  • verification and communication

Copy-ready prompt

Use Archify workflow mode to turn this incident runbook into responder lanes. Show detection, triage, mitigation, escalation, communication, rollback, and recovery verification. Separate decision gates from actions and make missing ownership visible.

sequence · classic

API request chain

Who calls whom, in what order, and what returns?

A time-ordered request path with authentication, cache fallback, persistence, return traffic, and async trace.

Use when
API documentation, debugging request latency, auth reviews, or explaining cache fallback.
Avoid when
Order is unimportant and the audience only needs the stable service topology.

Evidence to include

  • callers and callees
  • request and return messages
  • fallback or error path
  • async side effects

Copy-ready prompt

Use Archify sequence mode to show this request from caller to final response. Include authentication, cache hit or miss, persistence fallback, return messages, and asynchronous trace or event emission. Keep message labels short and order unambiguous.

sequence · signal-flow

Async roundtrip

What happens after the initial request returns?

A sequence view of enqueue, acknowledgement, background work, callbacks, retries, timeout, and final consistency.

Use when
Webhooks, jobs, queues, payment callbacks, eventual consistency, or async API contracts.
Avoid when
The primary question is topic topology and consumer ownership rather than time order.

Evidence to include

  • initial acknowledgement
  • queue or scheduler
  • background work
  • callback, retry, and timeout

Copy-ready prompt

Use Archify sequence mode to explain this asynchronous roundtrip. Show the initial acknowledgement, enqueue or scheduling step, background processing, callback or polling, retry and timeout behavior, and the point where the caller can observe final consistency.

dataflow · classic

Data lineage

Where does data come from, how does it change, and who consumes it?

A governed path from sources through consent, transforms, sensitive stores, warehouse, and consumers.

Use when
Analytics architecture, ETL/ELT review, PII assessment, warehouse design, or model feature lineage.
Avoid when
The audience needs request timing or operational task ownership rather than data assets.

Evidence to include

  • sources and assets
  • transform stages
  • classification or consent
  • stores and consumers

Copy-ready prompt

Use Archify dataflow mode to map this data lineage. Name every data asset and transform, show consent or classification boundaries, distinguish streaming from batch paths, and identify stores plus downstream consumers. Do not use unlabeled flows.

dataflow · signal-flow

Event-stream topology

Which events move through which topics, processors, groups, and failure paths?

A stream map of producers, topics, ordered processors, consumer groups, state, replay, and DLQ.

Use when
Kafka/event-platform design, stream processing reviews, ownership, replay, and failure handling.
Avoid when
Topic names, consumer groups, and delivery semantics are not known—use a generic workflow instead.

Evidence to include

  • producers and event names
  • topics and ordering
  • processors and consumer groups
  • state, replay, and DLQ

Copy-ready prompt

Use Archify dataflow mode to draw this event-stream topology. Name producers, events, topics, ordered processors, consumer groups, state stores, replay paths, and the DLQ. Show ownership and delivery semantics only when supported by evidence.

lifecycle · classic

Object lifecycle

Which states exist, what events move between them, and how does it end?

A state model with active work, waits, retries, cancellation, failure, and explicit terminal outcomes.

Use when
Tasks, orders, tickets, subscriptions, jobs, agent runs, or any durable object with status.
Avoid when
The object has no durable state and the real question is participant interaction over time.

Evidence to include

  • start and active states
  • event-labelled transitions
  • wait and retry states
  • all terminal outcomes

Copy-ready prompt

Use Archify lifecycle mode to model this object. Separate main progress, waiting or interruption states, and terminal outcomes. Label transitions with events, include retry, cancellation, timeout, success, and failure where real, and never hide an ending.

lifecycle · signal-flow

Deployment lifecycle

What state is a release in, and what can happen next?

A deployment state model covering queued, building, verifying, approval, promotion, rollback, and terminal outcomes.

Use when
Release controllers, GitOps reconciliation, environment promotion, or deployment status APIs.
Avoid when
The question is the human/CI sequence of delivery actions rather than the deployment object state.

Evidence to include

  • queued and running states
  • verification and approval
  • promotion and rollback
  • success, failure, cancellation

Copy-ready prompt

Use Archify lifecycle mode to model the deployment object. Show queued, building, verifying, waiting for approval, promoting, rolling back, and every terminal outcome. Label the events and guards that permit each transition.

erd · classic

Database schema

Which tables exist, what columns and keys do they carry, and how do they relate?

An entity-relationship map of tables with their complete column lists, key markers, and the cardinality between them.

Use when
Schema reviews, data-model onboarding, migration planning, or explaining a foreign-key graph.
Avoid when
The question is row-level movement between systems (data flow) or access order at runtime (sequence).

Evidence to include

  • tables with their complete column lists
  • primary, foreign, and unique key markers
  • cardinality and optionality at both ends
  • cards reserved for supplementary notes

Copy-ready prompt

Use Archify ERD mode to model this schema. Show every physical column inside its table — the field list is this diagram's primary content, not a summary — and mark primary, foreign, and unique keys. Draw every foreign-key relationship with its cardinality and optionality at both ends, and group related tables into contiguous domain blocks. Keep cards for supplementary notes instead of moving columns out of the tables.

architecture · classic

Layout repair

Why does the existing diagram overflow, overlap, or route through nodes, and what should be fixed first?

Repair an existing diagram in its current mode using validation diagnostics, explicit waypoint semantics, and a measured desktop viewport budget.

Use when
An existing architecture, workflow, sequence, dataflow, or lifecycle diagram needs layout repair; keep its diagram type and presentation settings.
Avoid when
The task is choosing a new diagram type. Do not change topology, delete meaningful labels, or hide overflow just to pass checks.

Evidence to include

  • repair order: schema → overlap → direction → crossings → labels
  • via contract: absolute [x, y] intermediate points; route = [start, ...via, end]
  • desktop viewport budget for the complete page, including header and necessary cards
  • validate after each edit, then inspect the final HTML in a browser

Copy-ready prompt

Use Archify to repair this existing diagram while preserving its diagram type, topology, meaningful labels, and presentation settings. Follow references/authoring-contract.md in this order: (1) schema and missing/invalid meta.quality_profile; (2) node overlap or out-of-range placement; (3) edge-through-node and endpoint-direction errors; (4) crossings, ambiguous corridors, border runs, excessive detours, and route rhythm; (5) labels: label-to-node, label-to-label, then label-to-route clearance. Run validate after every edit and use diagnostics[] code, subject, evidence, and supportedFixes; apply one diagnosed geometry control at a time. Where the current schema supports via, it is an ordered array of absolute SVG [x, y] intermediate points: the route is [start, ...via, end], with start/end supplied by the node anchors. Explicit via points override automatic routing; they are not offsets or a request for automatic obstacle avoidance. For an orthogonal repair, align adjacent points on the same x or y and make the first/final segment respect fromSide/toSide; use only controls supported by the current diagram mode. Follow references/delivery-contract.md for the viewport budget: check 1440×900, 1600×1000, 1920×1080, and 2048×1320; require document.documentElement.scrollWidth <= window.innerWidth. Prefer document.documentElement.scrollHeight <= window.innerHeight, but preserve a Reader-declared readable vertical page scroll when browser-check explicitly accepts it after reaching the projected-text floor. Budget the entire page, including header, diagram, and necessary cards. Repair every other overflow by removing only redundant content or compacting spacing first; do not hide overflow, clip content, introduce an internal diagram scroller, stretch the SVG, or shrink typography to force a pass. Let finalize run the required browser evidence; run perceptual visual review only when requested or escalated by the delivery contract.