# Archify Diagram Types Comparison and Selection: Complete Guide to Choosing the Right Visual Model

> Compare Archify diagram types dataflow sequence deployment and architecture to select the right visual model for your needs. This guide helps you choose effectively.

- Repository: [tt-a1i/archify](https://github.com/tt-a1i/archify)
- Tags: comparison-guide
- Published: 2026-09-13

---

**Archify renders zero-runtime-dependency diagrams in four distinct types—dataflow, sequence, deployment, and architecture—where the `diagramType` metadata field determines the layout algorithm, visual preset, and export behavior.**

Understanding **Archify diagram types comparison and selection** ensures your architecture documentation matches the communication goal, whether tracing data propagation, illustrating infrastructure topology, or sequencing service calls. The choice is encoded in the architecture JSON’s `meta.diagramType` field and interpreted by the viewer’s renderer contract defined in [`docs/research-visual-evolution-round-43.md`](https://github.com/tt-a1i/archify/blob/main/docs/research-visual-evolution-round-43.md).

## Available Archify Diagram Types

Archify implements four semantic diagram types, each invoking a specific layout algorithm and UI control set.

### Dataflow Diagrams

**Dataflow** diagrams emphasize service-to-service data pipelines and event streams. This type applies the `standard` rendering preset by default and preserves edge direction to highlight reachability and flow tokens. Use dataflow when the primary concern is tracing how information propagates through distributed components.

### Sequence Diagrams

**Sequence** diagrams render call-order and message-passing scenarios using a lane-based layout that orders messages temporally. According to the metadata table in `docs/research-visual-evolution-round-43.md#L284`, setting `"diagramType": "sequence"` activates timeline-specific UI controls distinct from the dataflow legend.

### Deployment Diagrams

**Deployment** diagrams visualize physical or cloud infrastructure topology, representing nodes as compute resources and edges as network links. This type requires the `deployment` diagram type identifier and is optimized for infrastructure operations documentation.

### Architecture Diagrams

**Architecture** diagrams provide high-level component overviews that focus on component groups while suppressing fine-grained edges. This type supports both the `standard` preset and custom visual presets for strategic stakeholder presentations.

## Selection Criteria for Archify Diagram Types

The selection process follows four practical criteria documented in the visual-evolution research notes.

### Audience and Communication Goals

Choose **sequence** when illustrating the ordering of calls or message chronology. Select **dataflow** for tracing data propagation paths and event streaming. Opt for **deployment** when communicating with infrastructure operations teams about physical resource topology. Use **architecture** for executive summaries and strategic overviews that require grouping abstraction.

### Complexity Constraints (8-12 Node Boundary)

For diagrams exceeding approximately twelve core components, Archify advises maintaining the **bounded range** of 8-12 nodes to preserve visual layout readability. The design discussion in `docs/research-visual-evolution-round-8.md#L21-L30` explicitly outlines how diagram size impacts UI clarity, recommending decomposition for larger systems.

### Visual Style and Preset Compatibility

Archify ships with multiple **visual presets** (`standard`, `dark`, `light`) configured via `meta.visual_preset` in the architecture JSON. Critically, switching presets does not affect diagram geometry or semantic IDs, as documented in `docs/research-visual-evolution-round-6.md#L24-L30`. The preset controls color schemes while the `diagramType` controls layout algorithms.

### External Tooling Export Requirements

When exporting to external tools like Mermaid, D2, or Structurizr, ensure the selected diagram type aligns with the target language’s native capabilities. The style-to-diagram matrix referenced in [`docs/research-visual-evolution-round-47.md`](https://github.com/tt-a1i/archify/blob/main/docs/research-visual-evolution-round-47.md) provides the official mapping table for cross-tool compatibility.

## Implementing Diagram Types in Code

Configure diagram types through the architecture JSON metadata or runtime API calls.

To set the diagram type in an architecture definition:

```json
{
  "meta": {
    "visual_preset": "standard",
    "diagramType": "dataflow"
  },
  "nodes": [ ],
  "edges": [ ]
}

```

To dynamically switch presets and types at runtime:

```javascript
// Swap color scheme without altering geometry
Archify.setVisualPreset('dark');

// Re-initialize layout for sequence visualization
Archify.setDiagramType('sequence');

```

To force a specific renderer during export:

```javascript
await Archify.exportMenu.run({
  format: 'png',
  diagramType: 'deployment'
});

```

## Core Renderer Contract and Metadata

The viewer’s renderer contract is defined in the documentation table at `docs/research-visual-evolution-round-43.md#L284`. This contract specifies that the viewer inspects the `diagramType` field to determine which layout algorithm to invoke and which UI controls to expose. For example, dataflow diagrams display reachability legends, while sequence diagrams expose timeline navigation controls.

Key implementation files include:
- [`viewer/README.md`](https://github.com/tt-a1i/archify/blob/main/viewer/README.md) – Documents the export contract and diagram-type handling responsibilities
- [`examples/rag-pipeline.architecture.json`](https://github.com/tt-a1i/archify/blob/main/examples/rag-pipeline.architecture.json) – Reference implementation showing proper `diagramType` metadata structure
- [`docs/research-visual-evolution-round-6.md`](https://github.com/tt-a1i/archify/blob/main/docs/research-visual-evolution-round-6.md) – Guarantees preset switching preserves node IDs and geometry

## Summary

- **Four diagram types**—dataflow, sequence, deployment, and architecture—serve distinct communication purposes within Archify’s zero-dependency rendering engine.
- **Selection depends** on audience goals, the 8-12 node complexity boundary, visual preset preferences, and target export tooling.
- **Configuration** occurs via `meta.diagramType` in JSON files or runtime API calls like `Archify.setDiagramType()`.
- **Visual presets** (`standard`, `dark`, `light`) operate independently of diagram types and do not alter semantic IDs or geometry.
- **Renderer contracts** are documented in [`research-visual-evolution-round-43.md`](https://github.com/tt-a1i/archify/blob/main/research-visual-evolution-round-43.md), ensuring predictable layout algorithm selection based on metadata.

## Frequently Asked Questions

### What is the default diagram type in Archify?

Archify defaults to the **dataflow** diagram type when the `meta.diagramType` field is omitted from the architecture JSON. This default applies the `standard` visual preset and emphasizes edge direction and reachability analysis suitable for service-to-service data pipelines.

### How do I switch between diagram types without losing node IDs?

Changing the `diagramType` value or calling `Archify.setDiagramType()` re-initializes the layout algorithm but preserves the underlying node and edge identifiers. As documented in `docs/research-visual-evolution-round-6.md#L24-L30`, only the visual representation and UI controls change; the semantic graph structure remains constant.

### Can I export Archify diagrams to Mermaid or D2 formats?

Yes, provided the selected diagram type aligns with the target tool’s capabilities. The style-to-diagram matrix in [`docs/research-visual-evolution-round-47.md`](https://github.com/tt-a1i/archify/blob/main/docs/research-visual-evolution-round-47.md) maps Archify diagram types to compatible external formats. Use `Archify.exportMenu.run()` with the `diagramType` parameter to force the appropriate renderer for the target platform.

### What is the recommended maximum number of nodes for readable diagrams?

Archify recommends maintaining **8 to 12 core components** per diagram for optimal readability. Research in `docs/research-visual-evolution-round-8.md#L21-L30` indicates that layouts exceeding this bounded range degrade UI clarity and user comprehension, suggesting decomposition into multiple linked diagrams for larger systems.