xaligo

xaligo is a diagram-as-code engine for architecture, network, and UML diagrams. It renders the Vue-style .xal XML DSL to SVG and PPTX and embeds SVG output in Markdown.

The renderer is designed around a single shared pipeline:

.xal
  -> parser
  -> layout
  -> generic layout and routing
  -> renderer-neutral document plan
  -> SVG | PPTX

Core features:

• Vuetify-style layout primitives such as frames, rows, columns, spacing, and alignment.
• AWS architecture group components and catalog-backed service icons.
• Orthogonal connector routing with route and traffic layers.
• Manual bend points in frame coordinates.
• Group, rectangle, port, and item endpoints.
• Frame-oriented SVG and PPTX output, with one frame mapped to one file or slide by default.
• Markdown rendering that embeds those same SVG artifacts.
• SVG and PPTX output with line jumps, legends, and export-focused routing.

Use this documentation when authoring .xal files, rendering output, or working on the xaligo codebase.

See Planned Work for upcoming and exploratory features.

Installation

npm CLI

Install the native CLI package:

npm install -g @xaligo/xaligo
xaligo version

The package installs the xaligo launcher and runtime icon catalogs. Its postinstall step downloads the native CLI binary and verifies its SHA-256 checksum. The Rust V2 engine and PPTX exporter are already linked into that binary; no runtime WASM or dynamic-library artifact is installed.

Go Build

Building the native CLI requires Go 1.26, Rust 1.85 or newer, and a C compiler for cgo:

git clone https://github.com/xaligo/xaligo
cd xaligo
make build
.bin/xaligo version

make build compiles the Rust engine and PPTX exporter into one static library and links it into .bin/xaligo through cgo. The Rust code is part of the executable; no engine process, dynamic library, or WASM artifact is installed alongside it.

Native Exporter Development

Build and test the standalone Rust PPTX exporter workspace when changing that adapter:

make build-exporter
cargo test --manifest-path test/unit/external/exporter/Cargo.toml --locked

The npm package exposes the native xaligo command, not a TypeScript/WASM rendering API. The repository still contains cmd/wasm as a source-only legacy V1 compatibility adapter, but it cannot execute the native V2 engine and is not part of the npm or release artifact set.

Package layout:

Getting Started

Install

Install the CLI from npm:

npm install -g @xaligo/xaligo
xaligo version

Or build from source:

git clone https://github.com/xaligo/xaligo
cd xaligo
go mod tidy
make build
.bin/xaligo version

Render A Diagram

Create a .xal file:

<xaligo version="1">
  <frames>
    <frame id="getting-started" title="Getting Started" version="2026.07"
           width="1122" height="794" class="pa-4" margin-top="48">
      <metadata align="right" width="156" key-width="56" font-size="12" />

      <aws-cloud id="cloud" title="AWS Cloud">
        <region id="region-apne1" title="ap-northeast-1">
          <vpc id="prod-vpc" title="Production VPC">
            <public-subnet id="public" title="Public Subnet">
              <item id="1178" name="web" />
            </public-subnet>
            <private-subnet id="app" title="Application Subnet">
              <item id="27" name="app-server" />
            </private-subnet>
          </vpc>
        </region>
      </aws-cloud>

      <connections kind="traffic" color="#2563eb">
        <connection src="web" dst="app-server" />
      </connections>
    </frame>
  </frames>
</xaligo>

Render it:

xaligo render diagram.xal --format svg -o diagram.svg

SVG is the default, so this is equivalent:

xaligo render diagram.xal -o diagram.svg

PPTX export uses the Rust exporter linked into the native CLI:

xaligo render diagram.xal --format pptx -o diagram.pptx \
  --paper A3 --orientation landscape \
  --paper-margin-top 0.75 --paper-margin-bottom 0.75

Render Multiple Frames

An identified child frame is one physical output page. A multi-frame document therefore creates one SVG file per frame or one PPTX slide per frame. With overview and detail frames, this SVG command:

xaligo render diagram.xal --format svg -o diagram.svg

writes diagram-overview.svg and diagram-detail.svg. A one-frame document still writes the exact -o path. Use the compatibility form when a single canvas is required:

xaligo render diagram.xal --format svg -o diagram.svg --combine-frames

See Cross-Frame Page Links for a complete multi-frame source and the matching to ... / from ... page-link labels.

Render Markdown

Fenced xal blocks can be replaced with generated SVG image references:

xaligo render markdown guide.md

See Markdown rendering for output-location options.

Validate

Run validation before rendering large diagrams:

xaligo validate diagram.xal

Validation catches malformed XML, invalid layout references, duplicate connection references, nested connection tags, and unresolved endpoints.

Command Line

Render

xaligo render <file.xal> --format <format> -o <output>

Supported formats:

The default is svg. Terminal output requires a V2 document. Retired format names are rejected as unknown formats. Markdown is handled by xaligo render markdown; it embeds SVG artifacts and is not a separate --format value.

Frames and physical pages

Identified child frames are physical pages for SVG and PPTX. They are emitted in source order.

Live SVG preview uses the combined canvas so every frame remains visible in one browser view. Markdown follows the SVG artifact mapping.

For a one-frame SVG document, -o is the exact output filename. For several frames, -o output/diagram.svg produces names such as output/diagram-overview.svg and output/diagram-detail.svg. Safe frame IDs retain ASCII letters, digits, _, and -; other character runs become -. Leading and trailing - are removed, an empty result falls back to the frame’s source order, and a filename collision is an error. SVG output is not wrapped in an implicit ZIP archive.

Common render flags:

Terminal flags:

Any mode, format, theme, orientation, paper size, arrow-style option, or SVG legend-position value outside its documented enum returns an error.

--arrow-style belongs to the shared physical plan used by SVG and PPTX.

Physical-page and PPTX flags:

--title sets package-level PPTX metadata. It is unrelated to the visible title attribute on a page <frame> and never creates a frame tag.

Structural Diff

xaligo diff before.xal after.xal -o output/architecture

The command compares parsed .xal data structures rather than source lines and writes two SVG images:

• output/architecture-removed.svg renders the old document and highlights removed elements plus the old side of modified or moved elements in pale red.
• output/architecture-added.svg renders the new document and highlights added elements plus the new side of modified or moved elements in pale green.

XML formatting, comments, attribute order, parser-private attributes, and the equivalent V1 forms with an omitted version or version="1" do not create a diff when that version is on the document root. A version on an identified child frame is visible page content and is compared normally, including the literal value 1. Matching prefers unique name, ref, and id values, then exact subtrees, followed by deterministic order-aware structural matching. Give elements an explicit id, name, or ref when moves must remain identifiable across different parents.

-o is an output prefix, not a single output filename. A trailing .svg is removed before -removed.svg and -added.svg are appended. The default prefix is output. --theme, --mode, and --px-per-inch are applied identically to both images. No difference is a successful result and still produces two unhighlighted SVGs.

See the structural diff sample for a complete before/after pair and the generated images.

Generate

Generate a starter .xal hierarchy:

xaligo generate xal -o generated.xal --paper A4 --orientation landscape

Useful generation flags:

Only --output is required. The generated file uses the canonical <xaligo version="1"><frames>...</frames></xaligo> document envelope.

SVG Icon Registry

The native CLI manages namespaced SVGs in the local xaligo-assets.db SQLite registry. The first icon operation installs 13 domain-neutral icons in the builtin namespace. Registrations are size-limited, safety-checked, and normalized by the in-process Rust engine before SQLite indexes their name, description, tags, and aliases with FTS5.

xaligo icon list --namespace builtin
xaligo icon search 'database OR storage'
xaligo icon get builtin:database -o database.svg
xaligo icon add router.svg --name network:router \
  --description 'Generic network router' --tag network --tag routing \
  --alias gateway --license MIT --source local
xaligo icon remove network:router
xaligo icon namespaces

Stable identities use namespace:name. icon add updates an existing identity atomically, including its tags, aliases, and search row. icon get writes SVG to standard output unless -o names a file. icon search accepts an FTS5 query and all list/search commands accept --limit up to 100. Configure the database path with paths.assets_db in etc/resources/aws/app.yaml.

Local RAG Index

The RAG command family builds a local SQLite/FTS5 knowledge index. Its initial corpus is intentionally restricted to Markdown files below docs/; .xal samples, the root README.md, source code, and generated documentation are not registered implicitly.

xaligo rag index
xaligo rag search 'database AND table'
xaligo rag search routing --limit 10 --json
xaligo rag symbols file:///path/to/diagram.xal
xaligo rag watch --interval 2s

rag index hashes each Markdown source and skips unchanged documents. It removes stale rows for deleted documentation files. rag watch runs the same incremental pass repeatedly. The shared project service can analyze an explicit .xal document into generic Frame, Group, Capture, Item, Port, Line, Text, and Spacer concepts for editor or agent requests, but that explicit path does not broaden the initial RAG corpus.

Language Server

xaligo lsp runs the in-process Language Server Protocol 3.18 adapter over standard input and output. It uses Content-Length framed JSON-RPC and keeps all ordinary logs on standard error so protocol output remains clean.

xaligo lsp

The server provides full-document synchronization, push and pull diagnostics, hierarchical document symbols, project-backed workspace symbols, semantic tokens, completion snippets, definition and reference navigation, and hover details over tags and semantic identifiers. It reuses the same parser and generic concept analysis as the project service rather than maintaining an editor-only parser. Saving an open .xal file is an explicit editor operation and updates that document’s concept rows; it does not make .xal part of rag index, whose initial corpus remains only docs/**/*.md and docs/**/*.markdown.

Other Commands

Services and Legends

--services <csv> provides label overrides and legend metadata.

The CSV format is:

id,OfficialName,Abbreviation,Summary,Usage,Notes

Rules:

• Blank lines and lines beginning with # are ignored.
• id must be a positive numeric service catalog ID.
• OfficialName is required.
• Abbreviation is optional. When present, it is used for item labels and legend abbreviations.
• Duplicate IDs are rejected.

Example:

id,OfficialName,Abbreviation,Summary,Usage,Notes
1178,Amazon CloudFront,CF,CDN,Edge delivery,
27,Amazon EC2,EC2,Compute,Application servers,
117,Amazon RDS,RDS,Database,Relational database,

SVG output draws a service legend when --services is supplied. PPTX output adds separate legend slide(s) after all frame/diagram slides.

Beautiful Diagram Guidelines

A good architecture diagram should be understandable before it is examined in detail. The reader should be able to identify the system boundary, major components, and primary flow within a few seconds. This guide describes a repeatable way to achieve that result with Xaligo.

Start with the message

Decide what the diagram must explain before adding elements. A diagram should normally answer one main question, such as:

• Where does a request enter, and which components process it?
• Which resources belong to each network or security boundary?
• How is data replicated, stored, or delivered?
• Which components are global, regional, VPC-level, or AZ-specific?

If one page must answer several unrelated questions, split it into an overview and one or more detail frames. Identified child frames naturally become separate SVG artifacts or PowerPoint slides.

Build a clear visual hierarchy

Arrange the diagram from large concepts to small details:

1. Put the system or cloud boundary at the outside.
2. Nest regions, networks, zones, and logical groups inside it.
3. Place services and components inside the smallest truthful boundary.
4. Add connections only after the component layout is stable.

Use AWS-specific group tags only for their actual meaning. For example, <public-subnet> represents an internet-routable subnet; it is not a generic blue box. Use <generic-group> for application tiers, security services, observability, CI/CD, or other logical collections.

AWS service placement should reflect its real scope:

See AWS Groups for the available containers and their semantics.

Prefer a simple reading direction

Choose one dominant flow direction and keep it consistent. Left-to-right works well for request and data flows; top-to-bottom works well for layered systems. Avoid making the reader alternate between both directions.

• Put entry points near the top or left edge.
• Put processing components in the middle.
• Put databases, queues, and external destinations near the bottom or right.
• Align siblings and give repeated structures the same size.
• Keep similar gaps between peers; larger gaps should indicate a change of boundary or responsibility.
• Prefer whitespace over decorative elements. Empty space makes grouping and flow easier to perceive.

Use fixed layouts for small, predictable groups and grid or flex layouts for repeated structures. Use absolute positioning only when the intended geometry cannot be expressed structurally; extensive manual coordinates are difficult to maintain and tend to produce uneven diagrams. See Layout for the supported layout models.

Keep labels concise and consistent

Labels should describe the reader-facing role of an element, not repeat every implementation detail.

• Use short nouns for components: API, Worker, Orders DB.
• Use verb phrases for important flows: Publish event, Read replica.
• Use one capitalization style throughout the diagram.
• Avoid unexplained abbreviations. If an abbreviation is necessary, define it in the legend or surrounding text.
• Keep group titles distinct from child labels.
• Put long explanations in frame metadata, a Markdown caption, or adjacent documentation instead of shrinking text to fit a box.

When AWS icons are used, supply services.csv so labels and legends use the official service names consistently. See Services and Legends.

Use color with restraint

Color should encode meaning, not fill empty space. Start with the selected light or dark theme, then add accent colors only for information the reader must distinguish.

A practical palette uses:

• one neutral treatment for normal structure;
• one primary accent for the main path;
• one secondary accent for an alternate or asynchronous path;
• red, orange, or yellow only for risk, failure, warning, or trust boundaries.

Do not rely on color alone. Pair color with labels, line styles, arrowheads, or group boundaries so the diagram remains understandable when printed in grayscale or viewed by readers with color-vision differences. Reuse exactly the same color for the same meaning on every frame.

Make connections easy to follow

Connections should explain relationships without becoming the dominant visual feature.

• Connect the nearest sensible sides of components.
• Prefer short orthogonal routes with few bends.
• Avoid diagonal lines crossing labels or icons.
• Keep parallel flows aligned and separated.
• Place heavily connected components near the center of their neighbors.
• Use explicit ports when several relationships meet one component.
• Label only relationships whose purpose is not obvious.

Use kind="route" for structural network paths and kind="traffic" for directional communication. Do not use an arrowhead on a route. When several lines cross, first improve component placement; use line jumps only after the layout itself is clear. Detailed controls are documented under Connections and the Arrow Reference.

Keep detail proportional to the output

Design for the final viewing size. A diagram that looks comfortable when zoomed in may be unreadable on an A4 page or presentation slide.

• Use one frame per page or slide for normal documents.
• Prefer landscape orientation for wide request flows and multi-column network diagrams.
• Prefer portrait orientation for layered or sequential flows.
• Use paper margins to keep content away from slide and print edges.
• Avoid using --combine-frames for unrelated pages.
• Check that text remains readable at 100% zoom and in a slide-show view.

SVG and PPTX share resolved geometry, but both outputs must still be reviewed. PowerPoint fonts and editable shapes can expose spacing issues that are less obvious in SVG.

A practical authoring workflow

Work from structure toward presentation:

1. Write the diagram’s question and intended audience.
2. List the essential components; remove anything that does not support the question.
3. Create truthful boundaries and place components at the correct scope.
4. Establish a single reading direction and align sibling groups.
5. Add the main flow, then secondary connections.
6. Apply concise labels and a restrained semantic palette.
7. Validate and render both required output formats.
8. Review at the final viewing size and simplify again.

Useful commands:

xaligo validate architecture.xal
xaligo render architecture.xal --format svg -o architecture.svg
xaligo render architecture.xal --format pptx -o architecture.pptx \
  --paper A3 --orientation landscape
xaligo serve architecture.xal

For AWS diagrams, include the service catalog:

xaligo render architecture.xal --format svg -o architecture.svg \
  --services services.csv --svg-legend-position right

Use live preview while adjusting hierarchy and spacing, but make the final decision from the exported SVG and PPTX rather than the editor source alone.

Common problems

Final review checklist

Before publishing, verify:

• The title or surrounding text states the diagram’s purpose.
• The main boundary and primary flow are recognizable at a glance.
• Every component is inside the correct semantic and infrastructure scope.
• Siblings are aligned, evenly spaced, and free from overlap.
• Labels are concise, consistent, and readable at the final size.
• Icons, labels, and services.csv entries agree.
• Connections avoid components, labels, group headers, and unnecessary crossings.
• Color meanings are consistent and are not the only distinguishing cue.
• xaligo validate succeeds without unexplained warnings.
• SVG and PPTX outputs have both been inspected.
• The .xal source is committed with any generated documentation asset.

For complete examples, see Samples, Examples, and the XAL DSL overview.

Samples

Canonical V1 Envelope

The canonical V1 envelope example shows the current document hierarchy, document-wide <data>, identified frames, and default per-frame SVG output.

Cross-Frame Page Links

The cross-frame page-link example demonstrates local page stubs, to <frame ID> / from <frame ID> labels, and multi-page render commands. Detailed anchor rules live in the Arrow Reference.

Frame Metadata Tags

The frame metadata example shows built-in id/title/content-version tags, custom entries, top/bottom placement, and page links that route around metadata reservations. Detailed metadata rules live in the Frame Reference.

Hybrid Enterprise Architecture

This sample combines the larger network-routing showcase with canonical V1 page metadata. Its frame declares a stable id, visible title, and content version, so the built-in metadata band reserves its edge strip while the existing route/traffic lanes, line jumps, junctions, and manual bends continue to use the shared routing pipeline.

Source: docs/src/examples/samples/complex-hybrid-architecture.xal

xaligo render docs/src/examples/samples/complex-hybrid-architecture.xal \
  --format svg \
  --mode network \
  -o output/complex-hybrid-architecture.svg

Structural Diff

This pair demonstrates a title update, an element moved between groups, a removed legacy store, an added cache, and changed connections. The comparison uses parsed .xal structure rather than text lines.

Removed and previous values

Added and current values

Sources:

• diff-before.xal
• diff-after.xal

xaligo diff \
  docs/src/examples/samples/diff-before.xal \
  docs/src/examples/samples/diff-after.xal \
  -o docs/src/images/diff-sample

The command reports +2 -2 ~3: two added branches, two removed branches, and three modified or moved elements. The old SVG uses pale red and the new SVG uses pale green; unchanged elements retain their normal styling.

Route and Traffic Separation

Use kind="route" for structural paths without arrowheads, then add kind="traffic" connections over the same endpoints for directional flows. Traffic lines are drawn beside the matching route lane when possible.

Source: docs/src/examples/samples/route-traffic.xal

xaligo render docs/src/examples/samples/route-traffic.xal \
  --format svg \
  --mode network \
  -o output/route-traffic.svg

Generated AWS Hierarchy

Generate a starter AWS hierarchy and render it:

xaligo generate xal --clouds 1 --accounts 1 --regions 2 --azs 2 \
  --az-layout staggered --subnets 2 --spacing both --start top \
  --paper A4 --orientation landscape -o output/infra.xal

xaligo render output/infra.xal \
  --format svg \
  -o output/infra.svg \
  --services docs/src/examples/samples/services.csv

Examples

These examples show rendered SVG output and link to complete sample sources. Keep syntax details in the reference and .xal DSL pages so this section stays compact.

• Line Variants
• Route and Traffic Separation
• Automatic Route Junctions
• Canonical V1 Envelope
• Cross-Frame Page Links
• Frame Metadata Tags
• Tables
• Relational Database
• UML Diagrams

Line Variants

This example combines structural routes, traffic lanes, and per-line style overrides in one compact diagram.

Route and Traffic Separation

Routes describe the structural path. Traffic lines can then use the same endpoints and render on nearby lanes with independent colors and arrow styles.

Automatic Route Junctions

When several route connectors share the same endpoint side, xaligo can route them through a shared trunk and draw the fan-out junction.

Canonical V1 Envelope

This sample uses the canonical V1 document hierarchy:

xaligo
├─ data
└─ frames
   ├─ overview
   └─ database-detail

The two identified frames share one document. The qualified endpoint database-detail.database-in creates a page link from the overview DB port to the detail frame’s SQL port. Page-oriented output draws one source stub to the inset line parallel to the nearest overview border, labeled to <database-detail>, and one destination stub from the selected database-detail inset line to the SQL port, labeled from <overview>. These metadata-free frames use the default 4-layout-pixel terminal inset. <data> is the document-wide definition registry used by reusable table, database, and UML definitions.

The checked-in image is the combined compatibility view. Default SVG output creates one artifact for overview and one for database-detail.

Source: samples/canonical-v1-envelope.xal.

Validate and render it with:

xaligo validate docs/src/examples/samples/canonical-v1-envelope.xal
xaligo render docs/src/examples/samples/canonical-v1-envelope.xal \
  --format svg \
  -o output/canonical-v1-envelope.svg

The render command writes:

output/canonical-v1-envelope-overview.svg
output/canonical-v1-envelope-database-detail.svg

To reproduce the combined image shown above:

xaligo render docs/src/examples/samples/canonical-v1-envelope.xal \
  --format svg \
  --combine-frames \
  -o output/canonical-v1-envelope.svg

Cross-Frame Page Links

This example shows how a V1 connection becomes a page link when its endpoints belong to different frames. The source endpoint is local to the declaring frame; the destination uses frame-id.endpoint-id.

Default SVG export creates one file for each identified frame:

overview

service-detail

database-detail

The combined compatibility view uses the same source with --combine-frames:

Source: samples/page-links.xal.

See Anchors and Bends and Frame and Containers for page-edge terminal, anchor, and metadata-reservation rules.

xaligo validate docs/src/examples/samples/page-links.xal
xaligo render docs/src/examples/samples/page-links.xal --format svg -o output/page-links.svg
xaligo render docs/src/examples/samples/page-links.xal --format svg --combine-frames -o output/page-links.svg

PPTX uses the same frame order as slides:

xaligo render docs/src/examples/samples/page-links.xal --format pptx -o output/page-links.pptx

Frame Metadata Tags

This two-page example adds visible page metadata without drawing a frame outline. It demonstrates automatic tag sizing, wrapped metadata rows, bottom metadata, and page-link routing around metadata reservation strips.

aws-architecture

release-notes

Source: samples/frame-metadata.xal.

See Frame and Containers and Frame Attributes for metadata defaults, wrapping, row-gap behavior, and page-link safety rules.

xaligo validate docs/src/examples/samples/frame-metadata.xal
xaligo render docs/src/examples/samples/frame-metadata.xal --format svg -o output/frame-metadata.svg

PPTX preserves the same source order as slides:

xaligo render docs/src/examples/samples/frame-metadata.xal --format pptx -o output/frame-metadata.pptx

Tables

This example combines concise pipe rows with an explicit tagged row. Both are normalized into the same V1 table model and rendered through the shared output pipeline.

Source: samples/tables.xal. See .xal Tables for the detailed table model.

xaligo validate docs/src/examples/samples/tables.xal
xaligo render docs/src/examples/samples/tables.xal \
  --format svg \
  -o output/tables.svg

Imported Tables

This canonical V1 example declares a CSV source inside <data> and renders it through a reusable <table data="..."> reference.

Sources: samples/table-imports.xal and samples/table-imports.csv. See .xal Tables for reusable table data syntax.

xaligo validate docs/src/examples/samples/table-imports.xal
xaligo render docs/src/examples/samples/table-imports.xal \
  --format svg \
  -o output/table-imports.svg

Relational Database

This example imports one reusable PostgreSQL-compatible schema in <data>, projects it through a <database> component, and generates a relation from the composite foreign key.

Sources: samples/databases.xal and samples/databases.sql. See .xal Relational Databases for database and SQL import syntax.

xaligo validate docs/src/examples/samples/databases.xal
xaligo render docs/src/examples/samples/databases.xal \
  --format svg \
  -o output/databases.svg

UML Diagrams

These examples use the supported core UML strict V1 tags. Each source is validated and rendered through the same pipeline used by the CLI.

Class diagram

Classes, interfaces, enumerations, typed compartments, realization, and multiplicity-bearing associations.

<xaligo version="1">
  <data></data>
  <frames gap="56">
    <frame id="class" title="Ordering Domain" version="2026.07" width="1440" height="760" class="pa-3" margin-top="48">
      <metadata align="right" width="156" key-width="56" font-size="12" />
      <uml id="domain-model">
        <class-diagram direction="right" grid="3">
          <interface id="repository" title="OrderRepository" stereotype="repository">
            <operation>+ save(order: Order)</operation>
            <operation>+ find(id: UUID): Order</operation>
          </interface>
          <class id="sql-repository" title="SqlOrderRepository">
            <attribute>- dataSource: DataSource</attribute>
            <operation>+ save(order: Order)</operation>
            <operation>+ find(id: UUID): Order</operation>
          </class>
          <class id="customer" title="Customer">
            <attribute>- id: UUID</attribute>
            <attribute>- name: String</attribute>
            <operation>+ placeOrder(): Order</operation>
          </class>
          <class id="premium-customer" title="PremiumCustomer" abstract="true">
            <attribute>- discountRate: Decimal</attribute>
            <operation>+ calculateDiscount(): Money</operation>
          </class>
          <class id="order" title="Order" stereotype="aggregate-root">
            <attribute>- id: UUID</attribute>
            <attribute>- status: OrderStatus</attribute>
            <operation>+ confirm()</operation>
            <operation>+ total(): Money</operation>
          </class>
          <class id="order-line" title="OrderLine">
            <attribute>- productId: UUID</attribute>
            <attribute>- quantity: Integer</attribute>
            <operation>+ subtotal(): Money</operation>
          </class>
          <enumeration id="status" title="OrderStatus" static="true">
            <literal>Draft</literal>
            <literal>Confirmed</literal>
            <literal>Cancelled</literal>
          </enumeration>

          <realization src="sql-repository" dst="repository" title="implements" />
          <generalization src="premium-customer" dst="customer" title="specializes" />
          <association src="customer" dst="order" title="places" src-multiplicity="1" dst-multiplicity="0..*" />
          <composition src="order" dst="order-line" title="contains" src-multiplicity="1" dst-multiplicity="1..*" />
          <dependency src="order" dst="status" title="uses type" />
          <dependency src="order" dst="repository" title="persists through" />
        </class-diagram>
      </uml>

      <connections>
        <connection src="domain-model/repository" dst="repository-detail.repository-in" title="repository details" color="#052d6e" />
      </connections>
    </frame>

    <frame id="repository-detail" title="Repository Contract" version="2026.07" width="720" height="420" class="pa-3" margin-top="48">
      <metadata align="right" width="156" key-width="56" font-size="12" />
      <rectangle id="repository-card" title="OrderRepository responsibilities" width="560" height="220">
        <port id="repository-in" side="left" title="details" />
      </rectangle>
    </frame>
  </frames>
</xaligo>

Component diagram

Components, artifacts, provided interfaces, associations, dependencies, and automatic interface/fan-out-based component heights. Diagram-level component-width and component-height provide defaults; per-component width and height override them. The Order Workflow component also shows interface-width, which gives every interface name in that component one shared width while descriptions use the remaining space.

<xaligo version="1">
  <data></data>
  <frames>
    <frame id="component" title="Ordering Platform Components" version="2026.07" width="1920" height="1180" class="pa-3" margin-top="48">
      <metadata align="right" width="156" key-width="56" font-size="12" />
      <uml id="service-components">
        <component-diagram direction="right" grid="4" component-width="280">
          <component id="web" title="Web UI">
            <interface description="Checkout commands">Ordering API</interface>
          </component>
          <component id="mobile" title="Mobile App">
            <interface description="Customer checkout">Ordering API</interface>
          </component>
          <component id="kiosk" title="Store Kiosk">
            <interface description="In-store ordering">Ordering API</interface>
          </component>
          <component id="admin" title="Admin Console">
            <interface description="Operational commands">Operations API</interface>
          </component>
          <component id="partner" title="Partner Portal">
            <interface description="Partner order intake">Partner API</interface>
          </component>
          <component id="api" title="API Gateway" width="320">
            <interface description="Public ordering boundary">Ordering API</interface>
            <interface description="Back-office boundary">Operations API</interface>
            <interface description="Partner integration boundary">Partner API</interface>
            <interface description="Workflow command boundary">Workflow Commands</interface>
          </component>
          <component id="workflow" title="Order Workflow" width="340" interface-width="88">
            <interface description="Workflow command handler">Workflow Commands</interface>
            <interface description="Inventory reservation">Inventory API</interface>
            <interface description="Payment authorization">Payment Gateway</interface>
            <interface description="Shipment booking">Shipping API</interface>
            <interface description="Persistence boundary">Order Store</interface>
            <interface description="Domain event stream">Order Events</interface>
            <interface description="Compliance event stream">Audit Events</interface>
          </component>
          <component id="inventory" title="Inventory Service">
            <interface description="Stock reservation">Inventory API</interface>
          </component>
          <component id="payment" title="Payment Service">
            <interface description="Authorization provider">Payment Gateway</interface>
          </component>
          <component id="shipping" title="Shipping Service">
            <interface description="Carrier booking">Shipping API</interface>
          </component>
          <component id="repository-adapter" title="PostgreSQL Adapter">
            <interface description="Order records">Order Store</interface>
          </component>
          <component id="event-bus" title="Event Bus Adapter">
            <interface description="Order domain events">Order Events</interface>
            <interface description="Notification dispatch events">Notification Events</interface>
          </component>
          <component id="notification" title="Notification Service">
            <interface description="Email and push delivery">Notification Events</interface>
          </component>
          <component id="audit" title="Audit Service">
            <interface description="Immutable compliance trail">Audit Events</interface>
          </component>
          <artifact id="schema" title="order-schema.sql">
            <property>version = 12</property>
          </artifact>
          <artifact id="event-schema" title="order-events.avsc">
            <property>compatibility = backward</property>
          </artifact>
          <artifact id="template" title="message-template.md">
            <property>locale = ja-JP</property>
          </artifact>

          <association src="web" dst="api" />
          <association src="mobile" dst="api" />
          <association src="kiosk" dst="api" />
          <association src="admin" dst="api" />
          <association src="partner" dst="api" />
          <association src="api" dst="workflow" />
          <association src="workflow" dst="inventory" />
          <association src="workflow" dst="payment" />
          <association src="workflow" dst="shipping" />
          <association src="workflow" dst="repository-adapter" />
          <association src="workflow" dst="event-bus" />
          <association src="workflow" dst="audit" />
          <association src="event-bus" dst="notification" />
          <dependency src="repository-adapter" dst="schema" />
          <dependency src="event-bus" dst="event-schema" />
          <dependency src="notification" dst="template" />
        </component-diagram>
      </uml>
    </frame>
  </frames>
</xaligo>

Activity diagram

ATM withdrawal swimlanes with supported activity partitions, decisions, guards, loop routes, and the xaligo activity theme.

<xaligo version="1">
  <data></data>
  <frames>
    <frame id="activity" title="ATM Withdrawal Activity" version="2026.07" width="960" height="1160" class="pa-3" margin-top="48">
      <metadata align="right" width="156" key-width="56" font-size="12" />
      <uml id="atm-withdrawal" title="ATM Withdrawal Process">
        <activity-diagram direction="down" theme="xaligo" lanes="vertical">
          <partition id="customer" title="Customer">
            <initial id="start" />
            <action id="start-session" title="Start session" tone="primary" />
            <action id="enter-pin" title="Enter PIN" />
            <action id="enter-amount" title="Enter amount" />
            <action id="take-cash" title="Take cash" tone="primary" />
            <final id="done" />
          </partition>

          <partition id="atm" title="ATM">
            <action id="request-pin" title="Request PIN" tone="primary" />
            <decision id="pin-valid" title="PIN valid?" />
            <action id="process-pin" title="Process PIN" />
            <action id="request-amount" title="Request withdrawal amount" tone="primary" />
            <decision id="amount-valid" title="Amount valid?" />
            <action id="process-withdrawal" title="Process withdrawal" />
          </partition>

          <partition id="bank" title="Bank">
            <action id="approve-card" title="Approve card" />
            <action id="approve-withdrawal" title="Approve withdrawal" />
          </partition>

          <control-flow src="start" dst="start-session" />
          <control-flow src="start-session" dst="request-pin" />
          <control-flow src="request-pin" dst="enter-pin" />
          <control-flow src="enter-pin" dst="process-pin" guard="PIN entered" />
          <control-flow src="process-pin" dst="pin-valid" />
          <control-flow src="pin-valid" dst="request-pin" guard="invalid PIN" route="loop" />
          <control-flow src="pin-valid" dst="approve-card" guard="valid PIN" />
          <control-flow src="approve-card" dst="request-amount" />
          <control-flow src="request-amount" dst="enter-amount" />
          <control-flow src="enter-amount" dst="amount-valid" guard="amount entered" />
          <control-flow src="amount-valid" dst="request-amount" guard="invalid amount" route="loop" />
          <control-flow src="amount-valid" dst="approve-withdrawal" guard="valid amount" />
          <control-flow src="approve-withdrawal" dst="process-withdrawal" />
          <control-flow src="process-withdrawal" dst="take-cash" />
          <control-flow src="take-cash" dst="done" />
        </activity-diagram>
      </uml>
    </frame>
  </frames>
</xaligo>

Activity diagram - horizontal swimlanes

The same ATM withdrawal flow arranged as horizontal swimlanes for wide process views.

<xaligo version="1">
  <data></data>
  <frames>
    <frame id="activity-horizontal" title="ATM Withdrawal Activity - Horizontal" version="2026.07" width="1480" height="720" class="pa-3" margin-top="48">
      <metadata align="right" width="156" key-width="56" font-size="12" />
      <uml id="atm-withdrawal-horizontal" title="ATM Withdrawal Process">
        <activity-diagram direction="right" theme="xaligo" lanes="horizontal">
          <partition id="customer" title="Customer">
            <initial id="start" />
            <action id="insert-card" title="Insert card" tone="primary" />
            <action id="enter-pin" title="Enter PIN" />
            <action id="enter-amount" title="Enter amount" />
            <action id="take-cash" title="Take cash" tone="primary" />
            <final id="done" />
          </partition>

          <partition id="atm" title="ATM">
            <action id="read-card" title="Read card" />
            <action id="request-pin" title="Request PIN" tone="primary" />
            <decision id="pin-valid" title="PIN valid?" />
            <action id="request-amount" title="Request amount" tone="primary" />
            <decision id="amount-valid" title="Amount valid?" />
            <action id="dispense-cash" title="Dispense cash" />
          </partition>

          <partition id="bank" title="Bank">
            <action id="authorize-card" title="Authorize card" />
            <action id="authorize-withdrawal" title="Authorize withdrawal" />
          </partition>

          <control-flow src="start" dst="insert-card" />
          <control-flow src="insert-card" dst="read-card" />
          <control-flow src="read-card" dst="request-pin" />
          <control-flow src="request-pin" dst="enter-pin" />
          <control-flow src="enter-pin" dst="pin-valid" guard="PIN entered" />
          <control-flow src="pin-valid" dst="request-pin" guard="invalid PIN" route="loop" />
          <control-flow src="pin-valid" dst="authorize-card" guard="valid PIN" />
          <control-flow src="authorize-card" dst="request-amount" />
          <control-flow src="request-amount" dst="enter-amount" />
          <control-flow src="enter-amount" dst="amount-valid" guard="amount entered" />
          <control-flow src="amount-valid" dst="request-amount" guard="invalid amount" route="loop" />
          <control-flow src="amount-valid" dst="authorize-withdrawal" guard="valid amount" />
          <control-flow src="authorize-withdrawal" dst="dispense-cash" />
          <control-flow src="dispense-cash" dst="take-cash" />
          <control-flow src="take-cash" dst="done" />
        </activity-diagram>
      </uml>
    </frame>
  </frames>
</xaligo>

State-machine diagram

States, initial/final pseudostates, transitions, guards, and state compartments.

<xaligo version="1">
  <data></data>
  <frames>
    <frame id="state-machine" title="E-Commerce Order State Machine" version="2026.07" width="1680" height="900" class="pa-3" margin-top="48">
      <metadata align="right" width="156" key-width="56" font-size="12" />
      <uml id="order-state">
        <state-machine-diagram direction="right">
          <initial id="start" row="1" col="1" />
          <state id="created" title="Order Created" row="1" col="2">
            <entry>Assign order number</entry>
            <do>Wait for payment</do>
            <exit>Record result</exit>
          </state>
          <state id="awaiting-shipment" title="Awaiting Shipment" row="1" col="3">
            <entry>Reserve inventory</entry>
            <do>Request shipment</do>
          </state>
          <choice id="stock-check" title="Stock Check" row="1" col="4" />
          <state id="shipped" title="Shipped" row="1" col="5">
            <entry>Register tracking number</entry>
            <do>Track delivery status</do>
          </state>
          <state id="delivering" title="In Transit" row="1" col="6">
            <note>Monitor delivery events</note>
          </state>
          <state id="completed" title="Completed" row="1" col="7">
            <note>Revenue has been finalized</note>
          </state>
          <final id="closed" row="1" col="8" />

          <state id="refund-requested" title="Refund Requested" row="2" col="3">
            <entry>Create refund ticket</entry>
            <do>Request refund</do>
            <exit>Store refund result</exit>
          </state>
          <choice id="refund-result" title="Refund Result" row="2" col="4" />
          <state id="refund-failed" title="Refund Failed" row="2" col="5">
            <note>Operator retries or contacts buyer</note>
          </state>
          <state id="return-requested" title="Return Requested" row="2" col="6">
            <entry>Assign return request number</entry>
            <do>Wait for returned item</do>
          </state>
          <choice id="return-result" title="Return Result" row="2" col="7" />
          <state id="return-failed" title="Return Failed" row="2" col="8">
            <note>Inspection failed or window expired</note>
          </state>

          <state id="buyer-cancelled" title="Buyer Cancelled" row="3" col="2">
            <note>Cancelled by buyer request</note>
          </state>
          <state id="refund-succeeded" title="Refund Succeeded" row="3" col="4">
            <note>Refunded event has been emitted</note>
          </state>
          <history id="order-history" title="H" row="3" col="5" />
          <state id="return-succeeded" title="Return Succeeded" row="3" col="7">
            <entry>Return item to inventory</entry>
            <exit>Mark order as cancelled</exit>
          </state>
          <state id="system-cancelled" title="System Cancelled" row="3" col="8">
            <region>Exceptional close</region>
            <note>Out of stock or return completed</note>
          </state>

          <transition src="start" dst="created" event="Create order" />
          <transition src="created" dst="awaiting-shipment" event="Payment succeeded" guard="Payment approved" action="Reserve inventory" />
          <transition src="awaiting-shipment" dst="stock-check" event="Prepare shipment" />
          <transition src="stock-check" dst="shipped" guard="In stock" action="Issue shipment" />
          <transition src="shipped" dst="delivering" event="Start delivery" />
          <transition src="delivering" dst="completed" event="Delivered" effect="Finalize revenue" />
          <transition src="completed" dst="closed" event="Close" />

          <transition src="created" dst="buyer-cancelled" event="Buyer cancels" guard="Not shipped" action="Cancel order">
            <bend x="120" y="650" />
          </transition>
          <transition src="awaiting-shipment" dst="refund-requested" event="Refund requested" guard="Paid" action="Start refund">
            <bend x="540" y="360" />
          </transition>
          <transition src="refund-requested" dst="refund-result" event="Refund result" />
          <transition src="refund-result" dst="refund-failed" guard="Failed" action="Request retry" />
          <transition src="refund-result" dst="refund-succeeded" guard="Succeeded" action="Mark refunded" />
          <transition src="refund-succeeded" dst="buyer-cancelled" event="Refund completed" />

          <transition src="shipped" dst="return-requested" event="Return requested" guard="Within return window" action="Accept return" />
          <transition src="return-requested" dst="return-result" event="Inspection complete" />
          <transition src="return-result" dst="return-failed" guard="Failed" action="Contact buyer" />
          <transition src="return-result" dst="return-succeeded" guard="Succeeded" action="Refund and restock" />
          <transition src="return-succeeded" dst="system-cancelled" event="Return completed" />
          <transition src="return-requested" dst="order-history" event="Return cancelled" action="Resume previous state" />
          <transition src="order-history" dst="shipped" event="Resume" />
          <transition src="stock-check" dst="system-cancelled" guard="Out of stock" action="Close order">
            <bend x="1560" y="196" />
            <bend x="1560" y="760" />
          </transition>

          <transition src="buyer-cancelled" dst="closed" event="Close">
            <bend x="1660" y="820" />
            <bend x="1660" y="252" />
          </transition>
          <transition src="system-cancelled" dst="closed" event="Close" />
        </state-machine-diagram>
      </uml>
    </frame>
  </frames>
</xaligo>

Sequence diagram

Participants/lifelines and ordered call, self, create, return, and destroy messages.

<xaligo version="1">
  <data></data>
  <frames>
    <frame id="sequence" title="Checkout Sequence" version="2026.07" width="1360" height="760" class="pa-3" margin-top="48">
      <metadata align="right" width="156" key-width="56" font-size="12" />
      <uml id="checkout-sequence">
        <sequence-diagram>
          <participant id="customer" title="Customer" />
          <lifeline id="api" title="Ordering API" />
          <lifeline id="session" title="CheckoutSession" />
          <lifeline id="payment" title="Payment Gateway" />

          <message src="customer" dst="api" order="1" title="checkout(cart)" />
          <create-message src="api" dst="session" order="1.1" title="create(cart)" />
          <message src="session" dst="session" order="1.2" title="validateCart()" />
          <message src="session" dst="payment" order="1.3" title="authorize(total)" mode="async" />
          <return-message src="payment" dst="session" order="1.4" title="authorization" />
          <return-message src="session" dst="api" order="1.5" title="receipt" />
          <message src="api" dst="session" order="1.6" title="release()" />
          <return-message src="api" dst="customer" order="2" title="orderConfirmed" />
        </sequence-diagram>
      </uml>
    </frame>
  </frames>
</xaligo>

AI Agent Guide

This page is the compact entry point for AI assistants, coding agents, and other generated-code tools working with xaligo.

Read First

Use this order when collecting context:

1. Introduction
2. Getting Started
3. .xal DSL Overview
4. Layout
5. Connections
6. Examples
7. Development

For repository work, also read the applicable files under .github/instructions/ before planning or editing. Those files are the source of truth for implementation constraints.

Core Model

xaligo has one source DSL: .xal. Keep every renderer on the same pipeline:

.xal -> parser -> layout -> shared scene/plan -> encoder

Do not add format-specific parsers or hidden alternate layout paths. SVG and PPTX consume the shared parser, layout, and document plan; Markdown embeds SVG artifacts. Other outputs are outside the current product contract.

Important Paths

Generated outputs belong in output/ or another temporary directory, not in the documentation source tree unless they are intentional documentation assets such as SVG previews.

Useful Examples

• Line Variants shows route, traffic, and style overrides.
• Route and Traffic Separation shows structural routes plus directional traffic lanes.
• Automatic Route Junctions shows shared route trunks and fan-out junctions.

The corresponding source files live in docs/src/examples/samples/.

Common Commands

go test ./...
go build ./...
mdbook build docs
git diff --check

Render a documentation example:

.bin/xaligo render docs/src/examples/samples/route-traffic.xal \
  --format svg \
  --mode network \
  -o output/route-traffic.svg

Editing Rules

• Preserve the shared .xal pipeline.
• Keep mode and output format independent.
• Keep render geometry and routing in shared use-case layers.
• Keep generated binaries, package artifacts, and ad hoc renders out of the repository.
• Update documentation links when moving examples or changing CLI paths.
• Prefer focused tests or render checks for behavior changes.

Planned Work

xaligo is being developed as a diagram-as-code platform for architecture, network, and operational visualization workflows. The items below are planned or under consideration and may change as the core renderer evolves.

Rendering and Scale

• Performance improvements for large diagrams.
• Rendering support for larger architecture maps.
• Tiling one oversized frame across several physical pages.

Frame pagination status

Identified child frames are now physical page boundaries. The full scene is resolved first and then projected in source order:

--combine-frames requests one SVG canvas or PPTX slide. Default SVG uses the exact frame rectangle as its canvas and clip boundary, while combined SVG keeps marker-safe bounds. Markdown embeds the same SVG artifacts.

Page frames can also add a top/bottom metadata band for built-in id, title, content version, and arbitrary key/value tags. The resolved row-gap (4 pixels by default) supplies both the inter-row spacing and the metadata page-edge inset at the selected vertical edge and both horizontal edges; rows use frame width - 2 * row-gap. A full-width reservation strip still starts at the outer logical frame edge, extends to the final content-box boundary, remains at least row-gap + complete band height + 8 pixels deep, and excludes normal items, text, connector geometry and labels, and page links. Auto/fixed widths, typography, colors, ordered greedy row wrapping, explicit row breaks, per-row alignment, page ownership, and safe page-link edge selection are resolved before the physical formats project one frame per page. Cross-frame links can select item and logical page-edge anchors independently, preserve the frame anchor’s tangent coordinate, and place the drawable terminal on a parallel inward line. That inset is the resolved metadata row-gap, or 4 pixels when metadata is absent; zero retains the outer edge and the value is never clamped. Links reject unsafe explicit geometry. Without an explicit frame terminal, unsafe candidates are filtered and rendering chooses the nearest safe side from actual visual geometry; only an empty candidate set is an error. Labels remain 4 layout pixels from the final inset terminal.

This frame pagination is separate from generic tiling. Remaining scale work is to split one oversized frame into multiple tiles, add large-diagram regression samples and benchmarks, and optimize the slowest measured shared stages.

Rendering Correctness Foundation

The shared renderer now rejects non-finite and invalid layout numbers, resolves fixed children before flex ratios, records content boxes and explicit overflow, detects parent and port overlap violations, and gives SVG/PPTX a common text layout and PPI transform. CLI format dispatch also goes through one use-case entry point. See Internal Architecture and Algorithms.

The next structural steps are:

1. Store a typed normalized layout specification instead of repeatedly reading numeric strings from the syntax tree.
2. Extend the V2 resolved adaptive item grid beyond all-item groups to mixed item/rectangle occupancy; minimum-cell and item-offset preflight already run during V1 Build.
3. Move catalog-derived intrinsic label measurement and final connector geometry into the same validation pass used by render.
4. Replace the remaining internal Excalidraw-shaped V1 compatibility scene and presentation-shaped plan schema with genuinely format-neutral models.
5. Extend SVG/PPTX/Markdown regression coverage for text behavior, item offsets, connector values, and non-default PPI/paper fitting.

V1 Compatibility and V2

<xaligo version="1"> is the canonical V1 envelope. Historical root <frame> and <frames> documents remain compatible but emit a migration warning. V2 uses <xaligo version="2">; a V1 reader rejects the unsupported document version before interpreting nested syntax.

The V2-owned frontend can normalize both language versions, while the public V1 render path remains frozen. V2 preserves the concise V1 authoring profile and lowers it, together with explicit generic V2 extensions, directly to the same typed, renderer-neutral model. Each source is parsed once. The design avoids XML rewriting, parser retry, serialized intermediate round-trips, and running the full V1 renderer inside V2. V1 itself remains independent of V2.

The embedded Rust calculation core, C ABI v2, authoring-profile frontend, and SVG/PPTX projection are implemented for the generic Frame, Group, Capture, Item, Port, Line, Text, and Spacer concepts. It supports nested fixed/flex, fixed-column and adaptive item grids, absolute placement, ports, generic routing, deterministic SVG projection, V1-style frame metadata and AWS/catalog defaults, and shared icon placement. Remaining work includes multi-page V2 documents and broader profile coverage. See V2 Generic Engine.

Golden compatibility tests will cover roots and defaults, unknown nested tags, strict versus fallback enum behavior, connection inheritance and anchors, signed-32-bit catalog IDs, item-size render contexts, and equivalent resolved geometry across native and embedded targets.

Input and Output Formats

SVG and PPTX are the cross-version engine-output set. V2 additionally exposes terminal text; Markdown embeds SVG artifacts. Import from existing diagram formats may be considered separately, but it must normalize into .xal/the generic model and cannot add a hidden render path.

The V1 structured-diagram profile includes a document-wide data registry, general tables, relational schema/ER views, and the supported class, component, activity, state-machine, and sequence UML diagram components. It deliberately keeps their semantic processors separate while reusing neutral drawing and encoding contracts. See Structured Diagrams: Tables, Databases, and UML. Its <xaligo version="1"> envelope is the canonical V1 syntax; legacy root documents continue to render with warnings.

Editing and Automation

• A dedicated UI for authoring and editing diagrams.
• Add explicitly authorized model-assisted editing operations through the existing application-service boundary.
• GUI-to-.xal workflows, including configuration changes driven from visual edits.

Runtime Visualization

• Visualization of running systems.
• Agent and server components for collecting system state and rendering it as diagrams.

Advanced Views

• 3D modeling support for richer architecture and infrastructure visualization.

V2 Generic Engine

The V2 calculation core is a domain-neutral Rust library linked into the xaligo executable. It does not run as a daemon, sidecar, dynamic plugin, or separate command:

Go use case -> cgo -> C ABI v2 -> Rust staticlib

The public Go use-case boundary remains:

type EngineUsecase interface {
    Resolve(context.Context, entity.EngineDocumentSpec) (entity.EngineResolvedDocument, error)
    RenderSVG(context.Context, entity.EngineDocumentSpec) ([]byte, error)
    NormalizeSVG(context.Context, []byte) (entity.EngineSVG, error)
}

The generic calculation core and this ABI are implemented. The <xaligo version="2"> frontend lowers directly to EngineDocumentSpec, and the ordinary render use case projects its resolved result through the shared SVG/PPTX document plan. Its authoring profile preserves V1-style rows, columns, AWS groups, catalog items, ports, and connections while keeping generic V2 parameters available as explicit extensions. Profile normalization is one linear tree walk; it does not reparse XML or run the V1 renderer. Catalog icon data and short labels share one load per render; the bundled default catalog is cached across renders.

Rust source structure

The engine is one staticlib crate and follows the responsibility structure of ryo-arima/vem/src:

external/engine/src/
├── lib.rs                  staticlib export boundary
├── mod.rs                  module registry
├── base.rs                 decode/execute/encode composition root
├── cnf/engine.rs           ABI constants, limits, and defaults
├── cnf/engine_abi.rs       generated ABI field constants
├── ent/model/              generic document and normalized SVG models
├── ent/request/engine.rs   binary request decoding
├── ent/response/engine.rs  binary response encoding
├── usc/engine.rs           operation dispatch
├── usc/cancel.rs           call-scoped cooperative cancellation
├── usc/layout.rs           layout resolution entry point and shared state
├── usc/layout_flow.rs      stack, grid, and absolute placement
├── usc/layout_geometry.rs  bounds and geometry helpers
├── usc/layout_routing.rs   ports and line routing
├── usc/layout_validation.rs input and constraint validation
├── usc/layout_tests.rs     layout regression tests
├── usc/svg.rs              SVG normalization and projection
├── rep.rs                  reserved for future encoders such as PPTX
├── ctl/engine.rs           panic-safe C ABI and owned buffers
└── util/
    ├── serialize.rs        explicit ABI response serialization
    ├── deserialize.rs      explicit bounded ABI request deserialization
    ├── clone/debug/eq.rs   explicit model trait implementations
    ├── default.rs          explicit neutral-value defaults
    ├── mcode.rs            engine message codes and log levels
    ├── logger.rs           Go-compatible environment-configured logging
    └── error.rs            layout and SVG errors

external/engine/abi/fields.csv is the single field-index schema. Running make generate-engine-abi regenerates both Go and Rust constants without introducing runtime reflection, serde, JSON, or arbitrary maps.

This preserves the cnf / ent / usc / ctl / util dependency vocabulary while placing calculation behavior in cohesive use-case files and without copying VEM’s CLI-specific main.rs. lib.rs is the corresponding library entry point. The C symbols and Go EngineUsecase contract are unchanged by this source-only reorganization.

The current data path is ctl -> usc -> ctl. The rep layer deliberately has no implementation because calculation results return directly through ctl. If PPTX package generation later moves into Rust, its external-representation writer belongs in a flat rep/pptx_*.rs slice and may be called from usc; layout, routing, and validation remain in usc. Layer directories stay shallow and use filenames such as layout_flow.rs instead of nested directories.

Engine-owned models intentionally have no derive or serde annotations. Standard traits and the binary ABI codecs are implemented explicitly under util, following VEM’s implementation pattern. serialize.rs and deserialize.rs continue to read and write the fixed-width little-endian ABI; they do not add a JSON or generic-map boundary.

Grouped imports use a vertical, one-item-per-line form throughout the Rust crate. This makes imports stable and reviewable as layer dependencies change.

Rust logging

util/mcode.rs defines structured engine message codes and util/logger.rs follows the Go shared logger contract: level filtering, optional structured JSON, component/service metadata, caller metadata, error field extraction, and XALIGO_LOG_* configuration. The static library adapts that contract in two ways: stderr is the default so Go protocol stdout remains machine-usable, and a Rust fatal log never terminates the embedding Go process. Engine failures are still returned through the typed ABI.

Default-level execution is silent because the composition root emits only debug lifecycle events. Logs do not include .xal contents or absolute caller paths.

Generic concepts

The engine accepts only the following calculation concepts:

AWS, UML, and future vocabularies must lower to these concepts. No profile ID, source tag, icon namespace, aws, or uml discriminator crosses into a Rust calculation branch.

Layout and routing

The implemented policies are:

• vertical and horizontal fixed-before-flex allocation;
• per-child weights, margins, dimensions, intrinsic sizes, offsets, and min/max constraints;
• generic grids, including a 12-column configuration and row/column spans;
• adaptive item grids that select rows and columns from the available aspect ratio and shrink icons when label space requires it;
• absolute placement;
• nested content boxes with padding, gap, alignment, justification, and error or visible overflow;
• owner-relative ports with side, anchor, offset, and explicit size; and
• straight and deterministic orthogonal routes with generic obstacle scoring, endpoint decorations, line styles, and labels.

Every element carries independent typed parameters. Pointer fields on the Go request preserve unset values separately from explicit 0 and false. Invalid enum values, unknown ABI versions, non-finite numbers, bad ranges, duplicate IDs, malformed parent indexes, excessive nesting, invalid spans, and missing line endpoints fail before a renderer receives geometry.

The Rust SVG projection consumes the same immutable resolved document returned by Resolve. It draws generic shapes, text, ports, lines, labels, and endpoint decorations without recomputing layout or routing. SVG registration continues to pass through the separate safe normalization operation before SQLite stores it.

ABI v2

ABI v2 is a bounded binary contract. All fixed-width values are little-endian; variable text is UTF-8 with explicit lengths. An input tree is flattened once in pre-order and each record stores its parent index. Optional numeric and boolean fields use presence bitsets, so an omitted value cannot collapse into its zero value. Named string slots carry IDs, text, colors, icon references, and endpoints; arbitrary maps and renderer JSON are not accepted.

The resolved response remains in deterministic pre-order and contains:

• parent identity and generic concept;
• final finite (x, y, width, height) geometry;
• resolved renderer-neutral visual and text values;
• resolved text box plus selected icon reference and icon box; and
• final line points, style, decorations, label, and label position.

The engine limits one request to 10,000 elements, 128 nesting levels, 16 MiB of ABI input, 32 MiB of ABI output, and 2 MiB for one normalized SVG. Rust owns the response allocation; Go copies it before invoking the matching C free function.

Go creates a C-owned atomic cancellation handle for each context-aware engine call. Rust checks it at bounded layout and routing boundaries and returns the ordinary typed error response; no callback, daemon, or subprocess is involved.

Frontend elements retain source-span IDs and parameter provenance in Go. Calculation errors are exposed as structured diagnostics and mapped back to the originating span for CLI and LSP consumers without sending source contents through the ABI.

.xal lowering and efficiency

The envelope frontend parses the original .xal bytes once and lowers the typed concepts directly to EngineDocumentSpec. The same parsed concept tree can supply diagnostics, LSP symbols, RAG rows, and engine input; those consumers do not serialize and parse an intermediate representation.

All-item groups select the generic adaptive-grid policy. Its candidate-column scan is linear in the number of slots, uses the resolved content aspect ratio and label reservation, and preserves stable source-order tie breaking. Frame metadata is lowered as ordinary invisible layout containers plus styled text cells, so its reserved strip and content offset use the same core allocator instead of renderer-specific coordinates.

V1-profile groups retain the V1 header-tag geometry: 32-pixel group icons, left-aligned labels, border-top alignment, frame-metadata clearance, and collision avoidance against preceding headers and group boundaries. Collision queries use bounded passes over narrow vertical buckets rather than scanning every prior element. Group SVG colors are normalized once and retained in a size- and entry-bounded cache.

ProjectConcept is a Go type alias of the closed EngineConcept vocabulary, so project analysis, LSP, RAG rows, and future engine lowering do not need another domain-name-to-concept conversion.

The ABI representation is designed for that reuse:

typed concept tree
  -> one pre-order flatten pass                 O(n)
  -> parent-indexed contiguous ABI records      O(n)
  -> Rust ID validation + child adjacency       O(n)
  -> recursive layout in stable source order
  -> line endpoint lookup by ID                 O(1) average per endpoint

This removes a JSON/map conversion and avoids rebuilding hierarchy in every output adapter. Routing currently evaluates generic obstacle candidates per line; dense diagrams therefore retain a line-by-obstacle cost and should be profiled separately from parsing and layout.

Reference benchmark

The repository includes opt-in benchmarks based on both complex-hybrid sample versions:

make build
CGO_ENABLED=1 go test \
  -tags 'xaligo_engine xaligo_exporter sqlite_fts5 sqlite_omit_load_extension' \
  ./test/integration -run '^$' \
  -bench '^BenchmarkComplexHybridV2(RenderSVGEndToEnd|FrontendLower)$' \
  -benchmem -benchtime=100x

A 2026-08-30 warm-cache reference run on Apple M2 (darwin/arm64) produced:

These rows include the V1-style adaptive item grid, frame metadata composition, group-header collision handling, catalog labels, tinted group assets, generic routing, and SVG embedding used by the V2 sample. Go’s B/op does not account for allocations made by Rust. Use the benchmark to detect regressions within a row; renderer and routing differences still make a V1/V2 wall-clock comparison unsuitable as a component benchmark.

Project intelligence remains a separate workflow. Initial RAG discovery indexes only Markdown under docs/. A .xal concept tree is analyzed only when an editor, agent, or future V2 frontend explicitly supplies that document; it is not added to the initial RAG corpus.

Compatibility

Existing callers that provide the original flat Direction, Gap, and Elements fields continue to work. A blank element concept is treated as a generic Item, and vertical or horizontal allocation retains the original fixed/flexible behavior. New callers can add hierarchy and typed parameters without changing the three use-case methods.

Structured Diagrams: Tables, Databases, and UML

Status: V1 implementation design. Canonical V1 uses <xaligo version="1">. Historical root <frame> and <frames> documents remain accepted and produce a migration warning. V2 uses the same envelope as <xaligo version="2">.

This design turns the table, relational-database, and UML discussions into one coherent target while keeping their semantic processing independent. It defines the document envelope, shared data boundary, component syntax, normalization rules, validation ownership, and phased delivery. Rendering and layout details may evolve without changing these boundaries.

Design goals

• Keep one .xal source document capable of containing architecture, table, database, and UML views.
• Reuse data definitions across frames without coupling a definition to one visual notation.
• Offer concise pipe syntax and lossless explicit tag syntax where both are appropriate.
• Import common data and schema files through deterministic, safe adapters.
• Preserve the existing concepts of frames, item/grid placement, explicit geometry, ports, and routed lines without making every diagram use one semantic processor.
• Lower every frontend into typed, renderer-neutral models before layout and encoding.

Document envelope

The target hierarchy is:

xaligo
├─ metadata
├─ imports
├─ data                 reusable document-wide definitions
├─ styles
└─ frames
   └─ frame             page/layout boundary
      ├─ metadata       visible page tag-band configuration
      ├─ existing layout and architecture components
      ├─ table
      ├─ database
      └─ uml
         └─ exactly one UML diagram-kind child

Example:

<xaligo version="1">
  <data>
    <table-data id="service-inventory" src="services.csv" />
    <database-schema id="application-schema" src="schema.sql"
                     format="sql" dialect="postgresql" />
    <uml-model id="domain-model">
      <!-- typed UML definitions -->
    </uml-model>
  </data>

  <frames>
    <frame id="inventory">
      <table data="service-inventory" />
    </frame>
    <frame id="erd">
      <database data="application-schema" notation="crow-foot" />
    </frame>
    <frame id="domain">
      <uml id="domain-view">
        <class-diagram data="domain-model" />
      </uml>
    </frame>
  </frames>
</xaligo>

<data> owns reusable meaning; <frame> owns presentation and page layout. A data definition may be projected into several views, such as a database schema rendered as an ER diagram, a general table, or a UML class diagram. Such projections are explicit mappings, not implicit reinterpretation.

Every frame has a stable, document-unique id. A frame may contain several components arranged with the normal row, column, container, and grid controls. The component selects its semantic processor; frame never carries values such as type="uml-class".

Integrated-format decisions

The integrated-format discussion fixes these document-level decisions for the structured diagram work:

• The canonical document root is <xaligo version="1">, with reusable document data outside the renderable <frames> collection.
• <frames> contains the independent page or component boundaries, and each direct child <frame> owns presentation layout, page metadata, and the components rendered on that page.
• Tables, relational databases, UML, and existing architecture diagrams may use separate semantic parsers, validators, layout engines, and renderers. They are not forced through one generic Item/Grid/Line semantic processor.
• The shared boundary between those processors is limited to document structure, stable IDs, data references, imports, style references, frame bounds, exposed anchors, and renderer-neutral draw operations.
• Cross-frame data reuse is allowed through <data> references; cross-frame visual state is not shared. Page-crossing relationships should become references or page-link projections instead of one physical line spanning multiple frames.

UML uses a parent <uml> component. The UML diagram family is selected only by the single diagram-kind child under <uml>, such as <class-diagram> or <sequence-diagram>. The frame does not carry UML kind metadata, and one frame may place multiple independent UML components or mix UML with tables, databases, and existing architecture components.

Frame-to-page projection

An identified child frame is one physical page by default. The complete scene is resolved once, then each frame is projected in source order.

--combine-frames preserves a single canvas or slide. It is an output projection option, not a change to frame identity, layout, or connection resolution. A one-frame SVG document writes the exact requested filename; multiple frames append a filename-safe frame ID to the requested stem.

For SVG and PPTX, a page frame is not a visible rectangle. Its outline is omitted in both default and combined compatibility output; its geometry remains the page/crop boundary and the logical terminal for cross-frame page-link stubs.

A default page-local SVG uses the exact logical frame rectangle as its canvas and clip boundary, so a top/bottom metadata band’s row-gap gutter reaches the physical page edge while its tag cells remain inset by that value. The combined SVG compatibility canvas retains marker-safe bounds expansion. PPTX uses one common slide size; when frame sizes differ, smaller frame pages are centered on the largest slide without changing their logical frame edge. The metadata inset is measured from that logical frame edge, not from the common slide edge.

Frame metadata tag-band projection

A page frame can place a top or bottom band of visible key/value tags near the selected edge of its outer border box. Its resolved row-gap, 4 pixels by default, is both the inter-row spacing and the metadata page-edge inset on the selected vertical edge and both horizontal edges. Padding, content margins, and content-box coordinates do not replace or add to that inset. A non-empty frame title, direct-child content version, or direct <metadata> child enables it. When enabled, non-empty id, title, and version values are emitted in that order, followed by arbitrary <entry key="..." value="..." /> children in source order. An ID-only frame keeps the historical layout and does not acquire a band.

The normalized layout resolves font-dependent height, auto or fixed tag widths, greedy source-order wrapping, optional entry row breaks, and left/center/right alignment for each row within frame width - 2 * row-gap. The full-width reservation strip still extends from the outer logical frame edge to the final content-box boundary and is at least row-gap + complete band height + 8 pixels deep. The canonical scene then represents every key and value cell as page-owned decoration with stable ownership metadata. SVG and PPTX consume that same geometry, and Markdown inherits it through embedded SVG artifacts. Per-frame projection retains only the owning page’s tags, while combined compatibility output retains all bands.

The entire reservation strip is a hard exclusion zone for normal items and text, local and UML connector paths and labels, and page-link paths and labels. The logical frame edge and page size are unchanged, and no visible frame outline is reintroduced.

Cross-frame page-link projection

A qualified endpoint such as detail.database is a logical connection across frame/page boundaries. Page-oriented output does not draw one line through the space between frames. It projects the connection as two local page-link stubs: the source endpoint connects to its owning frame’s page-terminal inset line and is labeled to <destination frame ID>; the destination frame’s page-terminal inset line connects to the destination endpoint and is labeled from <source frame ID>. For example, an overview to detail connection shows to <detail> on the source page and from <overview> on the destination page. The angle brackets are rendered as literal punctuation.

Endpoint binding and logical page termination are independent. Endpoint src/dst-anchor takes precedence over endpoint src/dst-side. For the page terminal, src/dst-frame-anchor takes precedence over src/dst-frame-side, which takes precedence over the legacy endpoint anchor, then the endpoint side, then the automatic nearest-border preference. The first two choices are explicit and fixed. Otherwise rendering retains a safe preference or chooses the nearest safe side using the actual endpoint visual envelope; validation checks only that the safe candidate set is non-empty. Frame anchors provide five fixed tangent positions at 10/30/50/70/90 percent along each outer frame extent. The endpoint- and page-terminal-adjacent route segments remain perpendicular to their respective sides, even when those sides differ. Equal automatic distances prefer the side facing the other frame, then the stable order top, right, bottom, left. Frame-terminal attributes are cross-frame-only; same-frame use is an error. Manual bends remain logical connection metadata and do not steer the two local stubs. SVG and PPTX preserve the two page-local projections. Markdown inherits the SVG projection it embeds.

Metadata reservation is applied after that normal precedence. Without explicit frame-terminal geometry, unsafe candidates are excluded before the visual nearest-side choice. An explicit frame side/anchor that selects the metadata edge, has an inset that does not fit its normal frame dimension, or places its actual terminal in the strip is a validation error rather than a silent move. A safe explicit left/right terminal is allowed regardless of an unused top/bottom inset line. Automatic selection fails only when no safe side exists; the resolved inset is never clamped.

The outer logical page edge remains the side and tangent-coordinate reference even though no frame outline is drawn. The drawable terminal lies on a parallel inward inset line: it uses the resolved metadata row-gap, or 4 layout pixels when metadata is absent. That value applies to all four sides regardless of metadata position, and zero retains the outer edge. Applying it changes only the normal coordinate, so an explicit frame anchor keeps its exact 10/30/50/70/90-percent tangent slot. Otherwise the unconstrained parallel coordinate follows the endpoint binding; a coordinate inside the 24-layout-pixel corner gutter is clamped and connected with a two-bend orthogonal dogleg so both the endpoint and terminal segments remain perpendicular to the selected side. Borders shorter than 96 layout pixels use an adaptive quarter-length gutter. An unconstrained coincident inset terminal shifts along the parallel axis within the available gutter range to keep the page-link stub visible. An explicit frame anchor retains its tangent slot. On a left or right edge, the terminal is additionally clamped outside the metadata reservation strip. The path and label remain outside the strip, and any coordinate difference is bridged while preserving orthogonal routing. The to <...> / from <...> label stays just inside the page at a 4-layout-pixel inward gap and a minimum 4-layout-pixel tangent gap from the final inset terminal. It uses the closest tangent position that avoids endpoint and metadata geometry.

Processing boundaries

General tables, relational schemas, and UML are separate frontends:

source document
  -> envelope parser and root/version dispatch
  -> include/import resolution
  -> data registry and reference resolution
  -> component dispatch
       table    -> table parser/validator/layout
       database -> RDB parser/validator/ER layout
       uml      -> UML-kind parser/validator/layout
  -> renderer-neutral draw operations
  -> shared format encoders

They may share primitives such as boxes, compartments, text policy, ports, orthogonal edges, themes, and output encoders. They do not share a catch-all semantic AST or force UML/RDB behavior through the existing architecture layout engine. The common boundary is a typed document registry plus neutral resolved drawing contracts.

The envelope parser selects exactly one versioned frontend from the root and version pair. It must not retry parsers after an error. <xaligo version="1"> selects V1 and <xaligo version="2"> selects V2.

General tables

<table> represents data, not a visual placement grid. Simple tables use a GFM-like pipe form:

<table id="services" title="Services" grid="all" striped="true">
  | Service | Role     | Port |
  |:--------|:---------|-----:|
  | Nginx   | Proxy    |  443 |
  | API     | Backend  | 8080 |
</table>

Alignment comes from the separator row. The initial profile supports plain text cells and escaped pipes; it does not treat arbitrary Markdown or HTML as cell content.

Explicit tags provide stable IDs, rich content, spans, and cell styling:

<table id="services" title="Services" grid="all">
  <header>
    <cell id="service-heading">Service</cell>
    <cell>Role</cell>
    <cell align="right">Port</cell>
  </header>
  <row id="api-row">
    <cell id="api"><item id="27" />API</cell>
    <cell>Backend</cell>
    <cell align="right">8080</cell>
  </row>
</table>

Pipe rows and explicit rows may coexist. Source order is preserved. Both forms must declare the same effective column count; conflicting header definitions, duplicate row/cell IDs, and invalid spans are errors. Both lower into the same typed table model before layout.

Presentation properties include title, grid, striped, compact, column widths, horizontal/vertical alignment, overflow policy, six-digit text/fill/ border colors, font family, and font size. Table styles inherit through rows to cells; explicit row/cell values override them, while header-* table attributes style pipe headers. rowspan, colspan, rich cell children, and cell endpoints belong to the explicit form.

<grid> remains a layout primitive for arranging diagram components. A grid must not be inferred to be a data table merely because it looks tabular.

Relational database design

<database> is the displayed schema component; <database-schema> is the reusable data definition. <entity> represents an RDB relation and is not an alias for a general table.

<data>
  <database-schema id="application-schema">
    <entity id="roles" name="roles">
      <column name="id" type="bigint" primary-key="true"
              nullable="false" />
      <column name="name" type="varchar(100)" unique="true" />
    </entity>
    <entity id="users" name="users">
      <column name="id" type="bigint" primary-key="true"
              nullable="false" />
      <column name="role_id" type="bigint" nullable="false" />
      <foreign-key id="fk-users-role" columns="role_id"
                   references="roles.id" on-delete="restrict" />
    </entity>
  </database-schema>
</data>

<frames>
  <frame id="database">
    <database data="application-schema" notation="crow-foot" />
  </frame>
</frames>

An entity may also use a schema-specific pipe form:

<entity id="users" name="users">
  | Name    | Type         | Key | Nullable | References |
  |:--------|:-------------|:----|:---------|:-----------|
  | id      | bigint       | PK  | false    |            |
  | email   | varchar(255) | UQ  | false    |            |
  | role_id | bigint       | FK  | false    | roles.id   |
</entity>

The header names are part of the profile and map to typed column fields. Tags remain authoritative for composite primary/foreign keys, indexes, checks, referential actions, comments, and dialect-specific details. Mixed syntax lowers once into the same RDB model and rejects contradictory declarations.

Foreign keys can generate relations. An explicit relation may add visual meaning but cannot contradict schema constraints without an explicit projection mode. Endpoint references use typed paths such as users.role_id; table cell endpoints use a separate syntax so they cannot be mistaken for RDB columns.

RDB validation includes unique entity/column IDs, referenced entity and column existence, compatible key arity and types, one effective primary key, valid index/check definitions, and consistent null/default declarations. Diagnostics retain the originating file and source range.

UML

<uml> is the common UML component. It contains exactly one diagram-kind child, which selects the semantic processor:

uml
├─ class-diagram
├─ component-diagram
├─ activity-diagram
├─ state-machine-diagram
└─ sequence-diagram

Example:

<uml id="domain-view" title="Domain Model">
  <class-diagram data="domain-model" direction="right" />
</uml>

No child and multiple diagram-kind children are validation errors. Unknown kinds are rejected instead of being treated as generic groups. Every UML component requires a stable ID that is unique in its frame. The diagram child accepts direction="right|down" and either inline children or one data reference, never both. Every element has a diagram-local ID, and relations use those local IDs for src and dst.

V1 implements the core class, component, activity, state-machine, and sequence selectors through closed per-family element and relation vocabularies. It validates component relation endpoints, control-flow degrees, state-machine transition rules, and sequence message order. Neutral element and relation escape hatches are not part of the strict profile. The authoritative matrix, compartment vocabulary, endpoint constraints, and order domains are in the UML language reference.

Component diagrams derive each component height from its interface rows and per-interface incoming association fan-out, then pack those rows directly below the header. A positive component-height on the diagram supplies a common height, while an individual component height takes precedence. Omitting both retains automatic height; component-width and component width follow the same default/override relationship. A positive interface-width on a component sets one shared interface-name width for all of its interfaces; descriptions use the remaining horizontal space, so the configured width must leave enough room when descriptions are present.

Existing layout ideas are reused at the component boundary: <uml> can sit in rows, columns, grids, or containers and returns resolved width, height, draw operations, anchors, and links. UML component and local IDs reserve . and /; normal connections address a UML element as uml-id/local-id in the same frame or frame-id.uml-id/local-id across frames. Existing line concepts provide edge style, anchors, bends, routing, and line jumps, while UML relationships keep their own semantic kinds.

The current V1 renderer is deliberately a common-capability projection. It uses ellipses for initial/final nodes, diamonds for decision-like nodes, rectangles with flattened text compartments for the other elements, and orthogonal semantic connectors for relations. Sequence order sets top-to-bottom connector anchors, and semantic owners do not imply spatial nesting. This keeps the resolved geometry shared by SVG and PPTX; Markdown inherits the SVG projection it embeds. An encoder may omit UML metadata or marker details it cannot represent without private schema extensions.

Imports and overrides

Imports are declared in <data> or the document-level <imports> registry:

<data>
  <table-data id="services" src="services.csv" format="csv" />
  <table-data id="endpoints" src="endpoints.yaml" format="yaml"
              path="services" />
  <database-schema id="schema" src="schema.sql" format="sql"
                   dialect="postgresql" />
</data>

V1 implements CSV/TSV, JSON, and YAML table adapters with an injected filesystem and paths relative to the input document. SQL DDL and DBML remain planned. OpenAPI may later project schemas into tables or UML components. Spreadsheet import is deferred until its type, formula, merged-cell, and formatting loss policy is specified.

Resolution order is:

1. parse the envelope and declarations;
2. expand includes while detecting cycles;
3. load imports under the caller’s asset/file policy;
4. parse each import into its typed source model;
5. apply explicit inline overrides;
6. resolve references and projections;
7. perform component-specific semantic validation;
8. lay out and render frames.

Overrides address stable semantic IDs. They never depend on imported row position. The initial profile uses the deterministic precedence explicit tag override > pipe declaration > imported value > default. A conflicting value at the same precedence is an error.

Import resolution records source URI/path, format, dialect, and source ranges so diagnostics and round trips can preserve provenance. A bundled/normalized form may embed resolved data, but normal editing retains external references.

Arbitrary command execution is outside the import contract. Network and filesystem access are capability-injected, disabled unless supplied by the caller, and subject to path/scheme policies. Credentials are references to environment or secret providers and are never embedded in rendered output.

Typed models and renderer contract

The document model contains metadata, imports, data definitions, styles, and frames. It does not flatten all meanings into generic Node and Edge maps. Table, RDB, and each UML family retain typed semantic models until their own layout stage.

After layout, processors emit shared renderer-neutral operations for shapes, text, compartments, icons, ports, and semantic edges. Operations retain stable source IDs, semantic kind, parentage, text policy, geometry, style, and optional endpoint metadata. Output encoders project these operations into SVG or PPTX without becoming alternate semantic models. Markdown composes generated SVG artifacts rather than defining a third rendering encoder.

Delivery sequence

1. Add the <xaligo version="1"> envelope, legacy-root warning, data registry, frames, imports, and typed component dispatch without changing current V1/V2 behavior.
2. Deliver general tables with pipe/tag normalization and SVG output.
3. Add CSV, JSON, and YAML table imports. (Implemented in V1.)
4. Deliver RDB entities, keys, relations, Crow’s Foot rendering, and SQL DDL import for PostgreSQL, MySQL, and SQLite. (Entities, keys, relations, and common SQL DDL import are implemented in V1; Crow’s Foot remains.)
5. Deliver class, component, activity, state-machine, and sequence UML diagram families through common typed primitives and diagram-kind validation. (Implemented in V1.) Keep the remaining non-substitutable UML families as planned work until their typed semantics and quality gates are defined.
6. Add DBML/OpenAPI projections, richer table cells, and additional encoders.
7. Add explicit normalized/bundled output and GUI round-trip contracts.

Every phase requires parser/validation tests, model golden tests, resolved geometry tests, cross-format capability tests, source-positioned import diagnostics, and V1/V2 root rejection regression tests.

.xal Overview

.xal is an XML DSL for diagrams. Every canonical language version uses a <xaligo> envelope, document-wide data, and identified frames.

<xaligo version="1">
  <data>...</data>
  <frames gap="48">
    <frame id="overview" width="1440" height="900">...</frame>
    <frame id="detail" width="1440" height="900">...</frame>
  </frames>
</xaligo>

Historical root <frame> and <frames> documents remain compatible, but produce a warning recommending migration to <xaligo version="1">. Omitting the version from the canonical envelope defaults to V1 with a warning. V2 uses <xaligo version="2">; <frame version="2"> and <frames version="2"> are not valid V2 roots. Dispatch reads the root version once, and a V1 parser rejects version 2 before interpreting nested syntax.

V2 deliberately retains the concise V1 authoring profile. Existing <row>/<col>, AWS group tags, numeric catalog items, ports, and <connections> lower directly to the typed V2 model; generic V2 parameters such as weight, explicit padding, and direct <line> tags remain available when needed.

The root version="1" above selects the DSL. A non-empty version on an identified <frame> directly inside <frames> instead identifies that page’s visible content revision and does not select another language. Page frames can also expose title and arbitrary key/value entries in a configurable frame metadata band.

Important rules:

• Layout coordinates use pixels.
• An identified child frame is one SVG artifact or PPTX slide by default. --combine-frames preserves the compatibility canvas or slide.
• Frame metadata is page-owned decoration inset from the selected logical frame edge and both row ends by its resolved row-gap (4 pixels by default). The same value separates wrapped rows. Its full-width reservation strip still starts at the outer logical frame edge, excludes normal items, text, lines, and labels, and follows that page projection. It also supplies the inward normal inset for safe page-link terminals; a frame without metadata uses 4 pixels instead.
• The origin is the upper-left of the rendered frame.
• Positive x extends right and positive y extends down.
• Connections must be direct children of <frame> or inside frame-level <connections>.
• AWS group tags, <rectangle>, and <port> require non-empty unique IDs so they can be referenced by connectors.

Unknown nested tags are a V1 extension point. A tag without layout children is a generic rectangle-and-text leaf. A tag with layout children is a generic group/container; an all-item child list uses the item grid. Unknown roots are never treated this way.

V1 preserves several compatibility fallbacks: an empty align is omitted, malformed align warns and keeps the default for unsupported components, and unknown nested attributes are ignored. Invalid finite-number domains, overflow, layout, connection sides/anchors/styles/arrowheads, and render-option enums are errors. Recognized but unavailable modes report a not-implemented error rather than silently changing mode.

The parser uses standard XML syntax. Escape special characters in attribute values, for example &. Use the documented lowercase spelling for tag names, attribute names, and enum values; undocumented case or direction aliases are not part of the frozen V1 profile.

For lookup tables, see the dedicated reference pages:

• Icon Reference
• Arrow Reference
• Frame and Border Reference

Layout

Frame

<frame> defines one page canvas and its top-level layout. <frames> wraps multiple identified <frame> children; it lays them out horizontally by default and vertically with layout="vertical" in the complete logical scene. SVG and PPTX project each child frame to one file or slide by default. --combine-frames preserves that complete scene as one physical canvas or slide. Neither encoder draws the page frame’s outline, including in combined compatibility output. A default page-local SVG uses the exact frame rectangle as its canvas and clip boundary. Combined SVG keeps marker-safe bounds expansion. Markdown inherits the SVG projection it embeds.

Document-root and page-frame versions have different roles. Use <xaligo version="1"> to select the V1 language. A version on an identified <frame> directly inside the root <frames> is page content such as version="2026.07"; it is displayed in the metadata band and participates in structural diff. A legacy root <frame version="1"> still means DSL V1 and is not displayed as a page revision.

Frame metadata

Set a frame title, a child-frame version, or add direct <metadata> to add a key/value tag band near the selected edge of the outer frame border box; the default position is the top. The resolved row-gap is also the page-edge inset at the selected top/bottom edge and both row ends, so the default 4 leaves a 4-pixel selected-edge gutter and 4-pixel row-end gutters. Padding, content margins, and the content box do not replace or add to that inset. An existing frame with only an id remains visually unchanged; once the band is enabled its non-empty built-ins appear as id, title, and version, followed by custom entries in source order.

<frame id="architecture" title="AWS Architecture" version="1.0.0"
       width="720" height="420"
       margin-top="52" margin-right="24"
       margin-bottom="52" margin-left="24">
  <metadata align="right" font-family="helvetica">
    <entry key="owner" value="Platform Engineering" />
    <entry key="status" value="Approved" break-before="true"
           width="180" key-width="56" />
  </metadata>
  ...
</frame>

<metadata> is non-layout configuration and may appear at most once as a direct frame child. It accepts only empty <entry key="..." value="..." /> children; keys and values must be non-empty. This frame-local spelling is separate from document-level <xaligo><metadata>.

Each <entry> also accepts break-before="true|false". Its default is false; true starts that entry on a new row when a preceding tag exists.

An entry-level width or key-width overrides its metadata-level default. Omit either attribute for auto sizing; auto is descriptive, not a literal V1 numeric value. A fixed total width must still leave positive key and value cells. Colors accept #RRGGBB or transparent; fonts are virgil, helvetica, cascadia, assistant, excalifont, nunito, lilita-one, comic-shanns, or liberation-sans.

Tags retain source order. Greedy left-to-right packing fills each row within frame width - 2 * row-gap, producing the minimum number of rows without reordering; break-before can introduce an earlier row boundary. The usable width must remain positive. Metadata align then positions each completed row independently: left and right stop one row-gap inside the corresponding outer frame edge, while center still uses the frame center. This metadata page-edge inset is measured from the logical frame edge and is independent of PPTX export --paper-margin* options or common-slide centering.

For a top band, its top edge is frame.y + row-gap; for a bottom band, its bottom edge is frame.y + frame.height - row-gap. The metadata-side reservation strip still spans the full frame width from the outer logical frame edge to the corresponding boundary of the final content box. Its depth is at least row-gap + complete band height + 8 pixels; the complete band height already includes the gaps between multiple rows. A closer content boundary moves inward, while a boundary already farther inward is retained. Normal items and text, local and UML connector paths and labels, and page-link paths and labels never enter this strip; overflow="visible" does not override the exclusion. A page link without an explicit frame terminal remaps a reserved top/bottom edge to the nearest safe edge and clamps a left/right terminal outside the strip. An explicit src-frame-side, dst-frame-side, src-frame-anchor, or dst-frame-anchor that selects the reservation is a validation error. On the resolved safe side, the drawable terminal uses this metadata row-gap as its inward normal inset; a zero value retains the outer logical edge. The to <...> / from <...> label is positioned from that final terminal. SVG and PPTX display the page-owned band; Markdown inherits it through the embedded SVG. See the frame metadata example for top, bottom, left/right/center alignment, explicit row breaks, and auto or fixed widths.

Container

<container> stacks children vertically by default. Use layout="horizontal" for horizontal placement.

<container class="pa-4" gap="16">
  ...
</container>

Row And Col

<row> and <col> provide a 12-column grid.

<row gap="20">
  <col span="8">...</col>
  <col span="4">...</col>
</row>

<row> and <col> are pure layout tags. They do not render borders or labels.

Custom Tags

An unknown nested tag with no layout children is a generic leaf. If it has layout children, V1 treats it as a generic group/container with group insets; layout="horizontal" and layout="staggered" select those layouts. If every child is an item or spacer, the tag uses the item-grid row behavior. The rule does not apply to the document root.

Only documented layout values are valid for each tag. An unknown non-empty value is a validation error; it does not silently select the default layout.

Spacing

class supports Vuetify-like spacing classes such as pa-4 and ma-4. Root frame margins inset content without changing the paper frame size.

AWS Groups

AWS group tags render architecture-style containers with headers, icons, and border styles. Examples include:

• <aws-cloud>
• <aws-account>
• <region>
• <vpc>
• <availability-zone>
• <public-subnet>
• <private-subnet>
• <security-group>
• <generic-group>
• <capture>

Every group tag requires a non-empty id. IDs must be unique among frame-like components so groups can be used as connection endpoints.

<aws-cloud id="cloud" title="AWS Cloud">
  <region id="region-apne1" title="ap-northeast-1">
    <vpc id="prod-vpc" title="Production VPC">
      ...
    </vpc>
  </region>
</aws-cloud>

Generic Group Icons

generic-group accepts icon-id, using the same catalog as <item>. It must be a positive signed 32-bit decimal ID (1..2147483647); zero, signs, non-decimal syntax, and out-of-range values are invalid.

<generic-group id="network-topology" title="Network Topology" icon-id="104635">
  <item id="200036" />
</generic-group>

Capture (Structural Annotation)

<capture> is a lightweight structural annotation group. It participates in normal nested layout and places its children inside a border (and optional title band) without implying any AWS/architectural semantics, unlike <generic-group> and the AWS boundary tags above. Use it to highlight a diagram region such as a “hot path”.

<capture> is connectable exactly like any other group tag, including the frameId.id qualified cross-frame form, so a connection to/from a <capture> in another frame renders the same “to <frame>” / “from <frame>” cross-frame page-link stubs used for any other connectable endpoint.

<container gap="24">
  <capture id="hot-path" title="Hot Path">
    <rectangle id="public-api" title="Public API" />
  </capture>
  <rectangle id="batch-export" title="Batch Export" />
</container>
<connection src="hot-path" dst="batch-export" />

Text Width

Group header and item label width estimates count East Asian full-width characters as double-width so Japanese and other full-width labels stay aligned across SVG and PPTX. Markdown inherits SVG text layout.

Items and Spacers

<item> places a catalog icon inside its parent group or container.

<public-subnet id="public" title="Public Subnet">
  <item id="1178" name="web" />
  <item />
  <item id="1189" name="edge" />
</public-subnet>

When no icon is found for a service ID, rendering skips that item and emits a warning.

The root item-size overrides the rendering environment’s item-icon size. Without it, the V1 native and canonical embedded profile defaults to 32 layout pixels, while a caller-supplied render context may intentionally choose another value. Set item-size="32" explicitly when output must be identical across environments.

Use <spacer /> or <blank /> for explicit empty grid cells:

<spacer />
<blank />

Spacers occupy layout slots but render no icon, label, border, or text.

Rectangles and Ports

<rectangle> creates a general-purpose labeled box.

<rectangle id="service" title="Service" width="180" height="100" font-size="18">
  <port id="service-in" side="left" title="in" font-size="9" />
  <port id="service-out" side="right" title="out" font-size="10" />
</rectangle>

<port> creates a small labeled rectangle inside a side of its parent rectangle. Multiple ports on the same side are spaced evenly.

Port x and y values are clamped so the port remains inside the parent rectangle.

Connections

<connection> draws an elbowed connector between items, AWS groups, rectangles, ports, or identified child frames in a <frames> document.

Connections must be direct children of <frame> or inside a frame-level <connections> block.

<connections kind="traffic" color="#2563eb" grid="8" scale="1">
  <connection src="web" dst="app" />
  <connection src="app" dst="db" color="#059669" />
</connections>

The group inherits only non-empty arrowhead-size, kind, color, stroke-width, width, stroke-style, start-arrowhead, end-arrowhead, arrowhead, scale, coordinate-scale, and grid values. A child attribute overrides its group value. Endpoint identity and geometry are never inherited: each child supplies src and dst, and sides, anchors, bends, points, and via data remain local to that child. This includes the cross-frame-only src-frame-* and dst-frame-* terminal attributes.

Alias pairs are overridden as one setting: stroke-width/width, end-arrowhead/arrowhead, and coordinate-scale/scale. If a child uses either name, the corresponding parent pair is not inherited. If both names are on the child, the first name shown here takes precedence.

<connections> accepts only <connection> children. Unknown or misspelled child tags are validation errors.

Endpoint Anchors

When src-side, dst-side, src-anchor, or dst-anchor are omitted, xaligo chooses the endpoint sides and anchor positions automatically from the endpoint geometry.

Use src-anchor and dst-anchor to pin an endpoint to a specific perimeter anchor. Each side has five inset positions, so the rectangle has 20 unique anchor positions. Cross-frame src-frame-anchor and dst-frame-anchor use the same percentages to select the logical page side and tangent slot independently. The drawable frame terminal then moves only in the inward normal direction to the page-terminal inset line.

top:    top-1    top-2    top-3    top-4    top-5
right:  right-1  right-2  right-3  right-4  right-5
bottom: bottom-1 bottom-2 bottom-3 bottom-4 bottom-5
left:   left-1   left-2   left-3   left-4   left-5

Position numbers run left-to-right on top and bottom, and top-to-bottom on left and right. They are exactly 10, 30, 50, 70, and 90 percent along the named edge. Corner anchors are not shared: top-1 sits inside the top edge near the left corner, while left-1 sits inside the left edge near the top corner.

<connection src="web" dst="app"
            src-anchor="right-3"
            dst-anchor="left-3" />

You can also split the side and position:

<connection src="web" dst="app"
            src-side="right" src-anchor="3"
            dst-side="left" dst-anchor="3" />

Anchor aliases map one-to-one: start=1, near=2, center=3, far=4, and end=5.

For a page link, endpoint binding and page-terminal side selection may deliberately use different sides:

<connection src="web" dst="detail.app"
            src-side="right" src-anchor="near"
            src-frame-side="bottom" src-frame-anchor="far"
            dst-side="left" dst-anchor="far"
            dst-frame-side="top" dst-frame-anchor="near" />

Here the source leaves the item through right-2 but reaches the source page’s inset line at the bottom-4 tangent coordinate. The destination starts from the top-2 tangent coordinate and reaches the item through left-4. The drawable page terminals are normally inset without changing those percentages. The segments adjacent to the endpoint and terminal inset line remain perpendicular to their respective sides.

Endpoints can also be written as child tags. Use this form when the endpoint reference and anchor should stay together.

<connection kind="traffic">
  <src anchor="right-3" frame-side="bottom" frame-anchor="far">web</src>
  <dst side="left" anchor="5" frame-anchor="top-2">detail.app</dst>
</connection>

id, ref, name, or target attributes can provide the endpoint token when the tag has no text content. On <src> and <dst>, frame-side and frame-anchor map to the corresponding source/destination frame-terminal attributes. A complete anchor supplies its side; a separate side accepts slot 1..5 or start|near|center|far|end. Conflicting side and complete-anchor values are validation errors.

Route And Traffic

Use kind="route" for structural paths without arrowheads. Use kind="traffic" for directional flows.

<connection src="web" dst="app" kind="route" />
<connection src="web" dst="app" kind="traffic" color="#2563eb" />

Routes are strictly headless in V1. After <connections> defaults and child alias overrides are merged, a non-none start-arrowhead, end-arrowhead, or arrowhead on an effective route is a source-positioned validation error. Explicit none is allowed. For example, a child arrowhead="none" suppresses an inherited end-arrowhead value because those names form one semantic alias pair.

Traffic lines that share endpoints with a route are drawn beside the route lane when possible.

Cross-frame Connections

References without a dot are resolved only inside the frame containing the connection. Use frameId.id to address an endpoint in another frame:

<frames>
  <frame id="overview">
    <rectangle id="web" />
    <connection src="web" dst="detail.db" />
  </frame>
  <frame id="detail">
    <rectangle id="db" />
  </frame>
</frames>

Every <frame> inside <frames> must have a unique, non-empty id; omitting it is a validation error. Endpoint id, name, and ref values are scoped by that frame, so the same local identifier may be reused in different frames. Frame IDs and connectable local IDs must not contain a dot because the dot is the scope delimiter. The same qualification applies to connectable table, database, entity, group, rectangle, port, and item IDs. An unqualified reference never falls back to a different frame.

When endpoints belong to different child frames, SVG and PPTX show the connection as a page link with two local stubs rather than one line across the inter-frame canvas. Markdown inherits this behavior through its embedded SVG:

• The source stub runs from the source endpoint to its frame’s page-terminal inset line and is labeled exactly to <destination frame ID>.
• The destination stub runs from its frame’s page-terminal inset line to the destination endpoint and is labeled exactly from <source frame ID>.

Angle brackets are visible punctuation. The example above therefore renders to <detail> in overview and from <overview> in detail.

Endpoint binding uses src-anchor/dst-anchor, then src-side/dst-side, then its normal automatic side. Logical page-terminal precedence starts with src-frame-anchor/dst-frame-anchor, then src-frame-side/dst-frame-side; either is a fixed choice. Without those attributes, the legacy endpoint anchor, endpoint side, or normal nearest-edge result is a preferred page side. Xaligo keeps it when safe; otherwise rendering chooses the nearest safe side from the endpoint’s actual visual envelope. An item envelope includes both its icon and label. Equal-distance ties prefer a tied side facing the other frame, then top, right, bottom, left.

Validation does not predict this automatic side. It checks that at least one side can contain the resolved inset without entering metadata; rendering makes the final choice after visual geometry is available. If the usual preferred side is unsafe, it is remapped. Only a frame with no safe side reports a source-positioned validation error at the connection.

Frame-terminal attributes are valid only when the resolved endpoints belong to different frames. Using any src-frame-* or dst-frame-* attribute on a same-frame connection is a source-positioned validation error.

Frame metadata reservation is a final safety constraint after that precedence. Without an explicit frame-terminal attribute, xaligo excludes every unsafe side before its visual nearest-side choice and remaps an unsafe preferred side. A selected left/right terminal is clamped outside the full-width reservation strip. An explicit frame side or anchor that selects the reserved edge, or an exact left/right anchor inside the strip, is a validation error instead of being silently moved. The path and to <...> / from <...> label cannot enter the strip.

The outer logical frame edge remains the side, tangent-anchor, and crop reference; SVG and PPTX do not draw it as a frame outline. The drawable terminal is on a parallel inward inset line. Its inset is the resolved metadata row-gap when that frame has metadata, or 4 layout pixels when it does not. The metadata value applies to all four terminal sides regardless of whether the band is at the top or bottom; row-gap="0" places the terminal on the outer edge. For an explicit frame side or anchor, the inset must be strictly smaller than the frame height on top/bottom, or the frame width on left/right; an invalid choice is reported at the connection. For an automatic terminal, the same bounds classify safe candidates, and only an empty candidate set is an error. Xaligo uses the resolved value directly instead of clamping it.

An explicit terminal vertically opposite the metadata edge must remain outside the full reservation strip: top against bottom metadata, or bottom against top metadata. Moving it into the strip is a source-positioned validation error. For an automatic terminal, the same conflict removes that side from the safe candidate set. A safe explicit left or right terminal is allowed even if an unused top/bottom inset line would intersect the strip.

The inset changes only the normal coordinate. An explicit frame anchor keeps its exact 10/30/50/70/90-percent coordinate along the outer frame extent. Otherwise the initial parallel coordinate follows the endpoint binding. If it enters the normal 24-layout-pixel corner gutter, xaligo clamps that coordinate and inserts a two-bend orthogonal dogleg; the endpoint- and frame-terminal-adjacent segments remain perpendicular to their selected sides. Borders shorter than 96 layout pixels use an adaptive quarter-length gutter. If an unconstrained inset terminal would coincide with the endpoint, it moves by up to 24 layout pixels along the parallel axis within the available range so the local stub remains visible. An explicit frame anchor keeps its tangent slot and uses a visible orthogonal local stub. Manual bends are retained as logical routing metadata but do not change these page-local stub paths.

For an automatic left/right coincidence next to metadata, the preferred range also keeps 8 layout pixels from the reservation. If a very small safe region cannot keep both that clearance and the corner gutter, xaligo uses the full non-reserved interval instead. The terminal may touch its boundary but never moves outside the frame or into the metadata strip.

One zero-inset combination is invalid. If the owning frame has metadata with row-gap="0", the connection endpoint resolves to that frame itself, and an explicit frame anchor coincides with the resolved endpoint point, validation reports a source-positioned validation error. An explicit endpoint anchor uses its stated slot. An explicit endpoint side uses its center, so src-side="top" matches src-frame-anchor="top-3"; an automatically selected endpoint side also uses its center. Choose a different endpoint/frame anchor or set a positive row-gap. Xaligo cannot keep both ends perpendicular and fixed while drawing a visible stub from one coincident point.

The page-link label is placed from the final inset terminal with a 4-layout-pixel inward gap and a minimum 4-layout-pixel tangent gap. Candidate placement uses the closest tangent position that avoids the endpoint envelope and metadata strip; a tiny page clamps or shrinks the fallback instead of moving the label farther inward.

The stubs share a logical connector ID and the original endpoint, frame, and routing metadata.

By default, the source and destination stubs appear on their respective SVG files or PPTX slides. With --combine-frames, both remain visible on the compatibility canvas but are not joined across the frame gap.

Manual Bends

Manual bend coordinates are in frame coordinates.

<connection src="web" dst="db" grid="8">
  <bend x="120" y="80" />
  <bend x="120" y="220" />
  <bend x="300" y="220" />
</connection>

<point>, <via>, and <waypoint> are aliases for <bend>. Coordinates can also be grouped inside <bends>, <points>, or <path>.

Text Shorthand

Text shorthand can be used directly inside <frame>:

web --- db
web ==> db

--- expands to kind="route". ==> expands to kind="traffic".

Validation

Endpoint references must resolve to exactly one rendered item, group, rectangle, port, or identified child frame. Missing endpoints, duplicate aliases, ambiguous numeric IDs, and nested connection tags are validation errors.

Invalid sides, anchors, kind, stroke styles, arrowheads, and arrowhead sizes are validation errors. Effective routes also reject every non-none arrowhead.

Tables

V1 supports general data tables inside a frame. A table is different from the <grid> layout primitive and from relational database entities.

Pipe syntax

Use a GFM-like header, separator, and data rows:

<table id="services" title="Services">
  | Service | Role     | Port |
  |:--------|:---------|-----:|
  | API     | Backend  | 8080 |
  | DB      | Database | 5432 |
</table>

Separator colons select left, center, or right alignment. Every row must have the same number of cells. Cell text is plain text; escape a literal pipe as \|.

Colors and fonts

Style a pipe table from the <table> tag. Header-specific attributes begin with header-:

<table id="services" title="Service Inventory"
       color="#172033" background-color="#ffffff" border-color="#94a3b8"
       font-family="nunito" font-size="16"
       header-color="#ffffff" header-background-color="#2563eb"
       header-font-family="cascadia" header-font-size="18">
  | Service | Role    | Port |
  |:--------|:--------|-----:|
  | API     | Backend | 8080 |
</table>

color, background-color, and border-color accept #RRGGBB or transparent. font-family accepts virgil, helvetica, cascadia, assistant, excalifont, nunito, lilita-one, comic-shanns, or liberation-sans. font-size is a positive layout-pixel value.

Styles inherit in the order table, then header or row, then cell, with the most specific value winning. Tagged rows and cells can therefore override the table defaults:

<row background-color="#f8fafc">
  <cell color="#dc2626" font-family="helvetica">Warning</cell>
  <cell>Retry required</cell>
</row>

Tagged syntax

Use tags when rows or cells need stable IDs or individual attributes:

<table id="services" title="Services">
  <header>
    <cell>Service</cell>
    <cell>Role</cell>
    <cell align="right">Port</cell>
  </header>
  <row id="worker">
    <cell>Worker</cell>
    <cell>Background jobs</cell>
    <cell align="right">9000</cell>
  </row>
</table>

align accepts left, center, right, or a normal vertical-horizontal alignment such as middle-right. A table may combine one pipe header and its rows with additional tagged rows. It may not define a second tagged header.

Both forms are normalized to the same V1 table rows and cells before layout. Malformed separators, inconsistent column counts, duplicate headers, unknown children, and empty rows are positioned validation errors.

File imports

CSV, TSV, JSON, and YAML files can be loaded relative to the .xal input file. Declare reusable data under the canonical <data> tag and reference it from one or more frames:

<data>
  <table-data id="services" src="services.csv" />
</data>
<frames>
  <frame id="inventory">
    <table data="services" title="Service Inventory" />
  </frame>
</frames>

The format is inferred from the extension or selected with format="csv", tsv, json, yaml, or yml. CSV and TSV require a header row. JSON and YAML require a top-level array of objects; their union of keys is sorted to produce deterministic columns. A one-off import may use <table src="services.csv" /> directly.

Import paths must be relative and remain inside the caller-supplied import filesystem. Inline rows cannot be combined with data or src. Both xaligo validate and xaligo render resolve CLI imports relative to the input .xal file.

See the table example and import example for complete documents.

Relational Databases

V1 stores reusable relational schemas under the document-wide <data> node and renders them with a <database> component.

<data>
  <database-schema id="application-schema">
    <entity id="roles" name="roles">
      <column name="id" type="bigint" primary-key="true" nullable="false" />
    </entity>
    <entity id="users" name="users">
      <column name="id" type="bigint" primary-key="true" nullable="false" />
      <column name="role_id" type="bigint" nullable="false" />
      <foreign-key columns="role_id" references="roles.id" />
    </entity>
  </database-schema>
</data>

Reference the schema from a frame:

<database data="application-schema" title="Application Schema" />

Each entity renders its column name, type, and constraints. V1 constraint attributes are primary-key, nullable, unique, and default. Composite primary keys use an explicit declaration:

<primary-key columns="tenant_id,id" />

Foreign keys use equally sized comma-separated local and qualified referenced columns. They generate one entity-to-entity relation regardless of arity:

<foreign-key columns="tenant_id,role_id"
             references="roles.tenant_id,roles.id"
             on-delete="cascade" />

on-delete and on-update accept cascade, restrict, no-action, set-null, or set-default. The normalized relation retains its source and referenced column lists and referential actions for downstream renderers.

SQL DDL imports

Import a schema relative to the .xal input file:

<data>
  <database-schema id="application-schema" src="schema.sql"
                   format="sql" dialect="postgresql" />
</data>

The V1 common profile accepts postgresql (and the postgres alias), mysql, and sqlite. It reads semicolon-terminated CREATE TABLE statements, quoted or schema-qualified identifiers, column types, NOT NULL, UNIQUE, inline or table primary keys, inline or table foreign keys, composite keys, REFERENCES, ON DELETE, and ON UPDATE. Dialect-specific indexes, generated expressions, checks, and table options are currently ignored when they do not affect the normalized keys.

Validation rejects duplicate schema/entity/column IDs, missing references, unknown children, inline entities combined with data, malformed foreign keys, mismatched composite-key arity, missing columns, and invalid referential actions. Rich indexes, checks, and Crow’s Foot endpoint markers remain subsequent V1 work.

See the RDB example.

UML

V1 supports a strict xaligo UML profile for class, component, activity, state-machine, and sequence diagrams. Use this page as the authoring overview; see the UML examples for rendered sample sources.

Minimal shape

<uml> is a semantic component inside a frame. It contains exactly one diagram-kind child such as <class-diagram> or <sequence-diagram>.

<frame id="sequence" title="Checkout Sequence" version="2026.07" margin-top="48">
  <metadata align="right" width="156" key-width="56" font-size="12" />
  <uml id="checkout-sequence">
    <sequence-diagram>
      <participant id="customer" title="Customer" />
      <lifeline id="api" title="Ordering API" />
      <message src="customer" dst="api" order="1" title="checkout(cart)" />
      <return-message src="api" dst="customer" order="2" title="ok" />
    </sequence-diagram>
  </uml>
</frame>

The <uml> container does not render its own border or title. Put visible titles, versions, owners, and review state in the owning frame metadata.

Authoring rules

• Element IDs are frame-local connection references; UML relations use those local IDs directly.
• Exactly one diagram family is allowed inside each <uml> component.
• Every diagram family has a closed element/relation vocabulary.
• Relation endpoints must reference existing local UML element IDs.
• direction="right|down" selects layout direction; sequence diagrams default to horizontal.
• Component diagrams may use component, interface, port, and artifact elements with dependency, realization, association, assembly, and delegation relations.
• Component boxes automatically grow with their interface rows and incoming association fan-out. Set component-width="280" or component-height="180" on <component-diagram> for diagram defaults, and override one box with <component width="340" height="220">. Omitting both height attributes keeps compact automatic height enabled.
• Set interface-width="88" on a <component> to use that width for every interface-name box inside the component. Interface descriptions continue to use the remaining horizontal space.
• Activity diagrams may group elements in <partition id="..." title="..."> swimlanes and set lanes="vertical|horizontal" with theme="xaligo".
• Sequence messages require unique positive dot-separated order values such as 1, 2, and 1.1.
• Non-participant sequence sources must already be active before sending a message or return.

Where to go next

• UML Examples: compact visual gallery and sample index.
• Structured diagram design: product and implementation direction for tables, databases, and UML.

SVG Output

SVG output is suitable for previews, documentation, and web publishing.

xaligo render diagram.xal --format svg -o diagram.svg

An identified child frame is one SVG artifact by default. A one-frame document writes exactly diagram.svg. If the document contains frames overview and service-detail, the same command writes:

diagram-overview.svg
diagram-service-detail.svg

The frame ID is made filename-safe by retaining ASCII letters, digits, _, and -, replacing every run of other characters with one -, and trimming leading and trailing -. An empty safe ID falls back to frame-<source-order>; colliding filenames are reported as an error. No ZIP archive is created.

Use the compatibility option to keep every frame on one historical canvas:

xaligo render diagram.xal --format svg -o diagram.svg --combine-frames

Live preview uses this combined view automatically.

The page frame itself is not rendered as a visible outline. In default page-local output, its exact rectangle is the SVG canvas, viewBox, and clip boundary. No marker or stroke safety padding is added outside the page, so a top/bottom metadata band’s row-gap gutter reaches the physical SVG edge while the tag cells remain inset by that value. Combined compatibility output omits each page-frame outline but retains marker-safe canvas expansion.

With --services, SVG can draw a legend:

xaligo render diagram.xal --format svg -o diagram.svg \
  --services services.csv \
  --svg-legend-position bottom

SVG rendering uses the shared orthogonal router and includes:

• Route and traffic layer ordering.
• Line-jump masks at interior crossings.
• Automatic junction markers for shared route endpoints.
• Distinct marker geometry for V1 arrow, triangle, stealth, diamond, and oval arrowheads.
• Strict frame canvas/viewBox clipping for default page artifacts, and stroke/marker-expanded bounds for combined compatibility output.
• Service legends when metadata is provided.

The complete document scene is routed before its frame pages are projected. A cross-frame connection therefore appears as to <destination frame ID> on the source SVG and from <source frame ID> on the destination SVG. Combined output keeps those two page-link stubs and does not reconnect them across the inter-frame gap. Explicit src/dst-frame-side or src/dst-frame-anchor attributes select the outer frame side and tangent coordinate independently from the item endpoint. The drawable terminal is on a parallel inward line: resolved metadata row-gap, or 4 layout pixels without metadata; zero keeps the outer edge. The label stays 4 layout pixels inward and at least 4 layout pixels alongside that final terminal, using the closest along-edge position that avoids endpoint and metadata geometry.

PowerPoint Output

PPTX output is generated from a Go draw plan and written by the configured statically linked Rust pptx exporter.

xaligo render diagram.xal --format pptx -o diagram.pptx \
  --services services.csv \
  --paper A3 --orientation landscape \
  --paper-margin-top 0.75 --paper-margin-bottom 0.75

Each identified child frame becomes one diagram slide in source order. Because PowerPoint presentations use one common slide size, xaligo uses the largest resolved frame-page width and height and centers smaller pages without scaling them independently. A document with one frame still produces one slide.

Use --combine-frames to preserve the former one-canvas, one-diagram-slide layout:

xaligo render diagram.xal --format pptx -o diagram.pptx --combine-frames

The page frame is a logical slide boundary and is not drawn as a visible rectangle. Its edge supplies each cross-frame side and frame-anchor tangent coordinate; the drawable stub terminal is on the parallel inward inset line. For a smaller frame centered on the common slide, that inset is measured from the logical frame edge before slide centering, not from the physical slide edge.

PPTX-specific behavior:

• Paper fitting supports named paper sizes and per-side margins.
• Routing avoids icon and label obstacles where possible.
• Existing routed lanes influence later paths to reduce overlap.
• Anchor backgrounds are drawn before lines, while icons and labels are drawn above lines.
• Line-jump masks are drawn at interior crossings.
• Legend slide(s) are added after all frame/diagram slides when --services is provided.
• Cross-frame connections are page links: the source slide contains to <destination frame ID> and the destination slide contains from <source frame ID>. Endpoint and logical frame anchors can select different sides. The terminal inset is the resolved metadata row-gap, or 4 layout pixels without metadata; zero keeps the outer edge. The page-link label stays 4 layout pixels inward and at least 4 layout pixels along the edge from that final terminal.

The PPTX exporter should only translate the resolved draw plan into a presentation. Geometry and routing decisions belong on the Go side.

Terminal Output

Terminal output projects a resolved V2 document directly into text for TUIs, SSH sessions, CI logs, and command-line inspection. It does not rasterize SVG and does not pass through the V1 compatibility scene.

xaligo render diagram-v2.xal --format terminal

Output is written to standard output by default. Use -o to create a file:

xaligo render diagram-v2.xal --format terminal -o diagram.txt

V1 input returns an explicit error. SVG and PPTX remain the cross-version visual outputs.

Layouts

diagram preserves resolved spatial relationships on a character grid:

xaligo render diagram-v2.xal --format terminal \
  --terminal-layout diagram --terminal-width 120 --terminal-height 40

semantic prioritizes hierarchy and connections, making it suitable for narrow terminals and machine logs:

xaligo render diagram-v2.xal --format terminal --terminal-layout semantic

hybrid places a compact diagram above a component, flow, or focused-element detail pane:

xaligo render diagram-v2.xal --format terminal \
  --terminal-layout hybrid --terminal-focus api

Character and color modes

Unicode box drawing is the default. Strict ASCII output contains only 7-bit ASCII characters:

xaligo render diagram-v2.xal --format terminal --terminal-style ascii

--color auto emits ANSI color only when standard output is an interactive terminal. Redirected and file output is deterministic and uncolored unless --color always is specified. --color never is useful when embedding output in documentation.

Size and detail

For an interactive terminal, omitted dimensions use COLUMNS and LINES when available. Redirected output defaults to 100 columns and 40 rows. Explicit dimensions are clamped to safe bounds of 20–500 columns and 8–200 rows.

--terminal-detail compact|normal|full controls semantic metadata. --terminal-icons label|symbol|none selects whether icon-backed elements use their label, a terminal-safe symbol plus label, or no fallback icon label.

Terminal output intentionally simplifies visual capabilities. Images become labels or symbols, fills become optional ANSI foreground accents, arbitrary curves become orthogonal character-cell paths, and exact typography is not preserved. The resolved hierarchy, element labels, relative placement, and connection paths remain available without adding a second parser or layout pipeline.

Markdown

xaligo render markdown finds fenced xal blocks, renders each frame through the same SVG artifact pipeline as xaligo render --format svg, and writes a new Markdown document containing image references.

xaligo render markdown guide.md
xaligo render markdown guide.md --output output/guide.md --svg-dir output/images

The default output is <source>.embedded.md; generated SVG files are written beside the source. --output and --svg-dir override those locations. Markdown is an orchestration workflow, not a separate geometry or encoder implementation, so layout, routing, themes, services, and frame behavior match direct SVG rendering.

Reference

Reference pages are split by topic. Preview tabs show rendered SVG examples, and Code tabs show the XAL tag syntax.

Keep detailed syntax tables, validation rules, and fine-grained sample links in this section. Overview and examples pages should stay compact and link back to the relevant reference page instead of duplicating the same material.

• Icons
• Arrows
• Frames and Borders

SVG Icon Reference

This reference uses the SVG files published from etc/resources/aws/svg. Large sections are split into paginated pages to keep local preview responsive. Total SVG files: 6898.

• Architecture-Group-Icons (15)
• Architecture-Service-Icons (1236, 14 pages)
• Category-Icons (100, 2 pages)
• Resource-Icons (524, 6 pages)
• Tabler-Icons (4964, 56 pages)
• Yamaha-Network-Icons (59)

Architecture-Group-Icons

This page references SVG files under etc/resources/aws/svg/Architecture-Group-Icons. Each card shows the SVG preview first and the XAL tag syntax in the Code tab. Showing 1-15 of 15 SVG files.

AWS-Account_32

<frame width="234" height="160" margin="24">
    <generic-group id="aws-account" title="AWS Account" icon-id="1861" />
</frame>

<generic-group id="aws-account" title="AWS Account" icon-id="1861" />

AWS-Cloud-logo_32

<frame width="263" height="160" margin="24">
    <generic-group id="aws-cloud-logo" title="AWS Cloud logo" icon-id="1862" />
</frame>

<generic-group id="aws-cloud-logo" title="AWS Cloud logo" icon-id="1862" />

AWS-Cloud-logo_32_Dark

<frame width="340" height="160" margin="24">
    <generic-group id="aws-cloud-logo-32-dark" title="AWS Cloud logo 32 Dark" icon-id="1863" />
</frame>

<generic-group id="aws-cloud-logo-32-dark" title="AWS Cloud logo 32 Dark" icon-id="1863" />

AWS-Cloud_32

<frame width="215" height="160" margin="24">
    <generic-group id="aws-cloud" title="AWS Cloud" icon-id="1864" />
</frame>

<generic-group id="aws-cloud" title="AWS Cloud" icon-id="1864" />

AWS-Cloud_32_Dark

<frame width="292" height="160" margin="24">
    <generic-group id="aws-cloud-32-dark" title="AWS Cloud 32 Dark" icon-id="1865" />
</frame>

<generic-group id="aws-cloud-32-dark" title="AWS Cloud 32 Dark" icon-id="1865" />

AWS-IoT-Greengrass-Deployment_32

<frame width="407" height="160" margin="24">
    <generic-group id="aws-iot-greengrass-deployment" title="AWS IoT Greengrass Deployment" icon-id="1866" />
</frame>

<generic-group id="aws-iot-greengrass-deployment" title="AWS IoT Greengrass Deployment" icon-id="1866" />

Auto-Scaling-group_32

<frame width="301" height="160" margin="24">
    <generic-group id="auto-scaling-group" title="Auto Scaling group" icon-id="1867" />
</frame>

<generic-group id="auto-scaling-group" title="Auto Scaling group" icon-id="1867" />

Corporate-data-center_32

<frame width="330" height="160" margin="24">
    <generic-group id="corporate-data-center" title="Corporate data center" icon-id="1868" />
</frame>

<generic-group id="corporate-data-center" title="Corporate data center" icon-id="1868" />

EC2-instance-contents_32

<frame width="330" height="160" margin="24">
    <generic-group id="ec2-instance-contents" title="EC2 instance contents" icon-id="1869" />
</frame>

<generic-group id="ec2-instance-contents" title="EC2 instance contents" icon-id="1869" />

Private-subnet_32

<frame width="263" height="160" margin="24">
    <generic-group id="private-subnet" title="Private subnet" icon-id="1870" />
</frame>

<generic-group id="private-subnet" title="Private subnet" icon-id="1870" />

Public-subnet_32

<frame width="253" height="160" margin="24">
    <generic-group id="public-subnet" title="Public subnet" icon-id="1871" />
</frame>

<generic-group id="public-subnet" title="Public subnet" icon-id="1871" />

Region_32

<frame width="204" height="160" margin="24">
    <generic-group id="region" title="Region" icon-id="1872" />
</frame>

<generic-group id="region" title="Region" icon-id="1872" />

Server-contents_32

<frame width="272" height="160" margin="24">
    <generic-group id="server-contents" title="Server contents" icon-id="1873" />
</frame>

<generic-group id="server-contents" title="Server contents" icon-id="1873" />

Spot-Fleet_32

<frame width="224" height="160" margin="24">
    <generic-group id="spot-fleet" title="Spot Fleet" icon-id="1874" />
</frame>

<generic-group id="spot-fleet" title="Spot Fleet" icon-id="1874" />

Virtual-private-cloud-VPC_32

<frame width="368" height="160" margin="24">
    <generic-group id="virtual-private-cloud-vpc" title="Virtual private cloud VPC" icon-id="1875" />
</frame>

<generic-group id="virtual-private-cloud-vpc" title="Virtual private cloud VPC" icon-id="1875" />

Architecture-Service-Icons

This section contains 1236 SVG files from etc/resources/aws/svg/Architecture-Service-Icons. Open a page below to load a smaller set of previews.

• Page 1 (1-90)
• Page 2 (91-180)
• Page 3 (181-270)
• Page 4 (271-360)
• Page 5 (361-450)
• Page 6 (451-540)
• Page 7 (541-630)
• Page 8 (631-720)
• Page 9 (721-810)
• Page 10 (811-900)
• Page 11 (901-990)
• Page 12 (991-1080)
• Page 13 (1081-1170)
• Page 14 (1171-1236)

Architecture-Service-Icons - Page 1

This page references SVG files under etc/resources/aws/svg/Architecture-Service-Icons. Each card shows the SVG preview first and the XAL tag syntax in the Code tab. Showing 1-90 of 1236 SVG files.

Back to section index

Arch_AWS-Clean-Rooms_16

<frame width="220" height="160" margin="24" item-size="64">
    <item id="1102" />
</frame>

<item id="1102" />

Arch_AWS-Data-Exchange_16

<frame width="220" height="160" margin="24" item-size="64">
    <item id="1103" />
</frame>

<item id="1103" />

Arch_AWS-Entity-Resolution_16

<frame width="220" height="160" margin="24" item-size="64">
    <item id="1104" />
</frame>

<item id="1104" />

Arch_AWS-Glue-DataBrew_16

<frame width="220" height="160" margin="24" item-size="64">
    <item id="1105" />
</frame>

<item id="1105" />

Arch_AWS-Glue_16

<frame width="220" height="160" margin="24" item-size="64">
    <item id="1106" />
</frame>

<item id="1106" />

Arch_AWS-Lake-Formation_16

<frame width="220" height="160" margin="24" item-size="64">
    <item id="1107" />
</frame>

<item id="1107" />

Arch_Amazon-Athena_16

<frame width="220" height="160" margin="24" item-size="64">
    <item id="1108" />
</frame>

<item id="1108" />

Arch_Amazon-CloudSearch_16

<frame width="220" height="160" margin="24" item-size="64">
    <item id="1109" />
</frame>

<item id="1109" />

Arch_Amazon-Data-Firehose_16

<frame width="220" height="160" margin="24" item-size="64">
    <item id="1110" />
</frame>

<item id="1110" />

Arch_Amazon-DataZone_16

<frame width="220" height="160" margin="24" item-size="64">
    <item id="1111" />
</frame>

<item id="1111" />

Arch_Amazon-EMR_16

<frame width="220" height="160" margin="24" item-size="64">
    <item id="1112" />
</frame>

<item id="1112" />

Arch_Amazon-FinSpace_16

<frame width="220" height="160" margin="24" item-size="64">
    <item id="1113" />
</frame>

<item id="1113" />

Arch_Amazon-Kinesis-Data-Streams_16

<frame width="220" height="160" margin="24" item-size="64">
    <item id="1114" />
</frame>

<item id="1114" />

Arch_Amazon-Kinesis-Video-Streams_16

<frame width="220" height="160" margin="24" item-size="64">
    <item id="1115" />
</frame>

<item id="1115" />

Arch_Amazon-Kinesis_16

<frame width="220" height="160" margin="24" item-size="64">
    <item id="1116" />
</frame>

<item id="1116" />

Arch_Amazon-Managed-Service-for-Apache-Flink_16

<frame width="220" height="160" margin="24" item-size="64">
    <item id="1117" />
</frame>

<item id="1117" />

Arch_Amazon-Managed-Streaming-for-Apache-Kafka_16

<frame width="220" height="160" margin="24" item-size="64">
    <item id="1118" />
</frame>

<item id="1118" />

Arch_Amazon-OpenSearch-Service_16

<frame width="220" height="160" margin="24" item-size="64">
    <item id="1119" />
</frame>

<item id="1119" />

Arch_Amazon-QuickSight_16

<frame width="220" height="160" margin="24" item-size="64">
    <item id="1120" />
</frame>

<item id="1120" />

Arch_Amazon-Redshift_16

<frame width="220" height="160" margin="24" item-size="64">
    <item id="1121" />
</frame>

<item id="1121" />

Arch_Amazon-SageMaker_16

<frame width="220" height="160" margin="24" item-size="64">
    <item id="1122" />
</frame>

<item id="1122" />

Arch_AWS-Clean-Rooms_32

<frame width="220" height="160" margin="24" item-size="64">
    <item id="1081" />
</frame>

<item id="1081" />

Arch_AWS-Data-Exchange_32

<frame width="220" height="160" margin="24" item-size="64">
    <item id="1082" />
</frame>

<item id="1082" />

Arch_AWS-Entity-Resolution_32

<frame width="220" height="160" margin="24" item-size="64">
    <item id="1083" />
</frame>

<item id="1083" />

Arch_AWS-Glue-DataBrew_32

<frame width="220" height="160" margin="24" item-size="64">
    <item id="1084" />
</frame>

<item id="1084" />

Arch_AWS-Glue_32

<frame width="220" height="160" margin="24" item-size="64">
    <item id="1085" />
</frame>

<item id="1085" />

Arch_AWS-Lake-Formation_32

<frame width="220" height="160" margin="24" item-size="64">
    <item id="1086" />
</frame>

<item id="1086" />

Arch_Amazon-Athena_32

<frame width="220" height="160" margin="24" item-size="64">
    <item id="1087" />
</frame>

<item id="1087" />

Arch_Amazon-CloudSearch_32

<frame width="220" height="160" margin="24" item-size="64">
    <item id="1088" />
</frame>

<item id="1088" />

Arch_Amazon-Data-Firehose_32

<frame width="220" height="160" margin="24" item-size="64">
    <item id="1089" />
</frame>

<item id="1089" />

Arch_Amazon-DataZone_32

<frame width="220" height="160" margin="24" item-size="64">
    <item id="1090" />
</frame>

<item id="1090" />

Arch_Amazon-EMR_32

<frame width="220" height="160" margin="24" item-size="64">
    <item id="1091" />
</frame>

<item id="1091" />

Arch_Amazon-FinSpace_32

<frame width="220" height="160" margin="24" item-size="64">
    <item id="1092" />
</frame>

<item id="1092" />

Arch_Amazon-Kinesis-Data-Streams_32

<frame width="220" height="160" margin="24" item-size="64">
    <item id="1093" />
</frame>

<item id="1093" />

Arch_Amazon-Kinesis-Video-Streams_32

<frame width="220" height="160" margin="24" item-size="64">
    <item id="1094" />
</frame>

<item id="1094" />

Arch_Amazon-Kinesis_32

<frame width="220" height="160" margin="24" item-size="64">
    <item id="1095" />
</frame>

<item id="1095" />

Arch_Amazon-Managed-Service-for-Apache-Flink_32

<frame width="220" height="160" margin="24" item-size="64">
    <item id="1096" />
</frame>

<item id="1096" />

Arch_Amazon-Managed-Streaming-for-Apache-Kafka_32

<frame width="220" height="160" margin="24" item-size="64">
    <item id="1097" />
</frame>

<item id="1097" />

Arch_Amazon-OpenSearch-Service_32

<frame width="220" height="160" margin="24" item-size="64">
    <item id="1098" />
</frame>

<item id="1098" />

Arch_Amazon-QuickSight_32

<frame width="220" height="160" margin="24" item-size="64">
    <item id="1099" />
</frame>

<item id="1099" />

Arch_Amazon-Redshift_32

<frame width="220" height="160" margin="24" item-size="64">
    <item id="1100" />
</frame>

<item id="1100" />

Arch_Amazon-SageMaker_32

<frame width="220" height="160" margin="24" item-size="64">
    <item id="1101" />
</frame>

<item id="1101" />

Arch_AWS-Clean-Rooms_48

<frame width="220" height="160" margin="24" item-size="64">
    <item id="1144" />
</frame>

<item id="1144" />

Arch_AWS-Data-Exchange_48

<frame width="220" height="160" margin="24" item-size="64">
    <item id="1145" />
</frame>

<item id="1145" />

Arch_AWS-Entity-Resolution_48

<frame width="220" height="160" margin="24" item-size="64">
    <item id="1146" />
</frame>

<item id="1146" />

Arch_AWS-Glue-DataBrew_48

<frame width="220" height="160" margin="24" item-size="64">
    <item id="1147" />
</frame>

<item id="1147" />

Arch_AWS-Glue_48

<frame width="220" height="160" margin="24" item-size="64">
    <item id="1148" />
</frame>

<item id="1148" />

Arch_AWS-Lake-Formation_48

<frame width="220" height="160" margin="24" item-size="64">
    <item id="1149" />
</frame>

<item id="1149" />

Arch_Amazon-Athena_48

<frame width="220" height="160" margin="24" item-size="64">
    <item id="1150" />
</frame>

<item id="1150" />

Arch_Amazon-CloudSearch_48

<frame width="220" height="160" margin="24" item-size="64">
    <item id="1151" />
</frame>

<item id="1151" />

Arch_Amazon-Data-Firehose_48

<frame width="220" height="160" margin="24" item-size="64">
    <item id="1152" />
</frame>

<item id="1152" />

Arch_Amazon-DataZone_48

<frame width="220" height="160" margin="24" item-size="64">
    <item id="1153" />
</frame>

<item id="1153" />

Arch_Amazon-EMR_48

<frame width="220" height="160" margin="24" item-size="64">
    <item id="1154" />
</frame>

<item id="1154" />

Arch_Amazon-FinSpace_48

<frame width="220" height="160" margin="24" item-size="64">
    <item id="1155" />
</frame>

<item id="1155" />

Arch_Amazon-Kinesis-Data-Streams_48

<frame width="220" height="160" margin="24" item-size="64">
    <item id="1156" />
</frame>

<item id="1156" />

Arch_Amazon-Kinesis-Video-Streams_48

<frame width="220" height="160" margin="24" item-size="64">
    <item id="1157" />
</frame>

<item id="1157" />

Arch_Amazon-Kinesis_48

<frame width="220" height="160" margin="24" item-size="64">
    <item id="1158" />
</frame>

<item id="1158" />

Arch_Amazon-Managed-Service-for-Apache-Flink_48

<frame width="220" height="160" margin="24" item-size="64">
    <item id="1159" />
</frame>

<item id="1159" />

Arch_Amazon-Managed-Streaming-for-Apache-Kafka_48

<frame width="220" height="160" margin="24" item-size="64">
    <item id="1160" />
</frame>

<item id="1160" />

Arch_Amazon-OpenSearch-Service_48

<frame width="220" height="160" margin="24" item-size="64">
    <item id="1161" />
</frame>

<item id="1161" />

Arch_Amazon-QuickSight_48

<frame width="220" height="160" margin="24" item-size="64">
    <item id="1162" />
</frame>

<item id="1162" />

Arch_Amazon-Redshift_48

<frame width="220" height="160" margin="24" item-size="64">
    <item id="1163" />
</frame>

<item id="1163" />

Arch_Amazon-SageMaker_48

<frame width="220" height="160" margin="24" item-size="64">
    <item id="1164" />
</frame>

<item id="1164" />

Arch_AWS-Clean-Rooms_64

<frame width="220" height="160" margin="24" item-size="64">
    <item id="1123" />
</frame>

<item id="1123" />

Arch_AWS-Data-Exchange_64

<frame width="220" height="160" margin="24" item-size="64">
    <item id="1124" />
</frame>

<item id="1124" />

Arch_AWS-Entity-Resolution_64

<frame width="220" height="160" margin="24" item-size="64">
    <item id="1125" />
</frame>

<item id="1125" />

Arch_AWS-Glue-DataBrew_64

<frame width="220" height="160" margin="24" item-size="64">
    <item id="1126" />
</frame>

<item id="1126" />

Arch_AWS-Glue_64

<frame width="220" height="160" margin="24" item-size="64">
    <item id="1127" />
</frame>

<item id="1127" />

Arch_AWS-Lake-Formation_64

<frame width="220" height="160" margin="24" item-size="64">
    <item id="1128" />
</frame>

<item id="1128" />

Arch_Amazon-Athena_64

<frame width="220" height="160" margin="24" item-size="64">
    <item id="1129" />
</frame>

<item id="1129" />

Arch_Amazon-CloudSearch_64

<frame width="220" height="160" margin="24" item-size="64">
    <item id="1130" />
</frame>

<item id="1130" />

Arch_Amazon-Data-Firehose_64

<frame width="220" height="160" margin="24" item-size="64">
    <item id="1131" />
</frame>

<item id="1131" />

Arch_Amazon-DataZone_64

<frame width="220" height="160" margin="24" item-size="64">
    <item id="1132" />
</frame>

<item id="1132" />

Arch_Amazon-EMR_64

<frame width="220" height="160" margin="24" item-size="64">
    <item id="1133" />
</frame>

<item id="1133" />

Arch_Amazon-FinSpace_64

<frame width="220" height="160" margin="24" item-size="64">
    <item id="1134" />
</frame>

<item id="1134" />

Arch_Amazon-Kinesis-Data-Streams_64

<frame width="220" height="160" margin="24" item-size="64">
    <item id="1135" />
</frame>

<item id="1135" />

Arch_Amazon-Kinesis-Video-Streams_64

<frame width="220" height="160" margin="24" item-size="64">
    <item id="1136" />
</frame>

<item id="1136" />

Arch_Amazon-Kinesis_64

<frame width="220" height="160" margin="24" item-size="64">
    <item id="1137" />
</frame>

<item id="1137" />

Arch_Amazon-Managed-Service-for-Apache-Flink_64

<frame width="220" height="160" margin="24" item-size="64">
    <item id="1138" />
</frame>

<item id="1138" />

Arch_Amazon-Managed-Streaming-for-Apache-Kafka_64

<frame width="220" height="160" margin="24" item-size="64">
    <item id="1139" />
</frame>

<item id="1139" />

Arch_Amazon-OpenSearch-Service_64

<frame width="220" height="160" margin="24" item-size="64">
    <item id="1140" />
</frame>

<item id="1140" />

Arch_Amazon-QuickSight_64

<frame width="220" height="160" margin="24" item-size="64">
    <item id="1141" />
</frame>

<item id="1141" />

Arch_Amazon-Redshift_64

<frame width="220" height="160" margin="24" item-size="64">
    <item id="1142" />
</frame>

<item id="1142" />

Arch_Amazon-SageMaker_64

<frame width="220" height="160" margin="24" item-size="64">
    <item id="1143" />
</frame>

<item id="1143" />

Arch_AWS-AppSync_16

<frame width="220" height="160" margin="24" item-size="64">
    <item id="707" />
</frame>

<item id="707" />

Arch_AWS-B2B-Data-Interchange_16

<frame width="220" height="160" margin="24" item-size="64">
    <item id="708" />
</frame>

<item id="708" />

Arch_AWS-Express-Workflows_16

<frame width="220" height="160" margin="24" item-size="64">
    <item id="709" />
</frame>

<item id="709" />

Arch_AWS-Step-Functions_16

<frame width="220" height="160" margin="24" item-size="64">
    <item id="710" />
</frame>

<item id="710" />

Arch_Amazon-AppFlow_16

<frame width="220" height="160" margin="24" item-size="64">
    <item id="711" />
</frame>

<item id="711" />

Arch_Amazon-EventBridge_16

<frame width="220" height="160" margin="24" item-size="64">
    <item id="712" />
</frame>

<item id="712" />

Architecture-Service-Icons - Page 2

This page references SVG files under etc/resources/aws/svg/Architecture-Service-Icons. Each card shows the SVG preview first and the XAL tag syntax in the Code tab. Showing 91-180 of 1236 SVG files.

Back to section index

Arch_Amazon-MQ_16

<frame width="220" height="160" margin="24" item-size="64">
    <item id="713" />
</frame>

<item id="713" />

Arch_Amazon-Managed-Workflows-for-Apache-Airflow_16

<frame width="220" height="160" margin="24" item-size="64">
    <item id="714" />
</frame>

<item id="714" />

Arch_Amazon-Simple-Notification-Service_16

<frame width="220" height="160" margin="24" item-size="64">
    <item id="715" />
</frame>

<item id="715" />

Arch_Amazon-Simple-Queue-Service_16

<frame width="220" height="160" margin="24" item-size="64">
    <item id="716" />
</frame>

<item id="716" />

Arch_AWS-AppSync_32

<frame width="220" height="160" margin="24" item-size="64">
    <item id="697" />
</frame>

<item id="697" />

Arch_AWS-B2B-Data-Interchange_32

<frame width="220" height="160" margin="24" item-size="64">
    <item id="698" />
</frame>

<item id="698" />

Arch_AWS-Express-Workflows_32

<frame width="220" height="160" margin="24" item-size="64">
    <item id="699" />
</frame>

<item id="699" />

Arch_AWS-Step-Functions_32

<frame width="220" height="160" margin="24" item-size="64">
    <item id="700" />
</frame>

<item id="700" />

Arch_Amazon-AppFlow_32

<frame width="220" height="160" margin="24" item-size="64">
    <item id="701" />
</frame>

<item id="701" />

Arch_Amazon-EventBridge_32

<frame width="220" height="160" margin="24" item-size="64">
    <item id="702" />
</frame>

<item id="702" />

Arch_Amazon-MQ_32

<frame width="220" height="160" margin="24" item-size="64">
    <item id="703" />
</frame>

<item id="703" />

Arch_Amazon-Managed-Workflows-for-Apache-Airflow_32

<frame width="220" height="160" margin="24" item-size="64">
    <item id="704" />
</frame>

<item id="704" />

Arch_Amazon-Simple-Notification-Service_32

<frame width="220" height="160" margin="24" item-size="64">
    <item id="705" />
</frame>

<item id="705" />

Arch_Amazon-Simple-Queue-Service_32

<frame width="220" height="160" margin="24" item-size="64">
    <item id="706" />
</frame>

<item id="706" />

Arch_AWS-AppSync_48

<frame width="220" height="160" margin="24" item-size="64">
    <item id="727" />
</frame>

<item id="727" />

Arch_AWS-B2B-Data-Interchange_48

<frame width="220" height="160" margin="24" item-size="64">
    <item id="728" />
</frame>

<item id="728" />

Arch_AWS-Express-Workflows_48

<frame width="220" height="160" margin="24" item-size="64">
    <item id="729" />
</frame>

<item id="729" />

Arch_AWS-Step-Functions_48

<frame width="220" height="160" margin="24" item-size="64">
    <item id="730" />
</frame>

<item id="730" />

Arch_Amazon-AppFlow_48

<frame width="220" height="160" margin="24" item-size="64">
    <item id="731" />
</frame>

<item id="731" />

Arch_Amazon-EventBridge_48

<frame width="220" height="160" margin="24" item-size="64">
    <item id="732" />
</frame>

<item id="732" />

Arch_Amazon-MQ_48

<frame width="220" height="160" margin="24" item-size="64">
    <item id="733" />
</frame>

<item id="733" />

Arch_Amazon-Managed-Workflows-for-Apache-Airflow_48

<frame width="220" height="160" margin="24" item-size="64">
    <item id="734" />
</frame>

<item id="734" />

Arch_Amazon-Simple-Notification-Service_48

<frame width="220" height="160" margin="24" item-size="64">
    <item id="735" />
</frame>

<item id="735" />

Arch_Amazon-Simple-Queue-Service_48

<frame width="220" height="160" margin="24" item-size="64">
    <item id="736" />
</frame>

<item id="736" />

Arch_AWS-AppSync_64

<frame width="220" height="160" margin="24" item-size="64">
    <item id="717" />
</frame>

<item id="717" />

Arch_AWS-B2B-Data-Interchange_64

<frame width="220" height="160" margin="24" item-size="64">
    <item id="718" />
</frame>

<item id="718" />

Arch_AWS-Express-Workflows_64

<frame width="220" height="160" margin="24" item-size="64">
    <item id="719" />
</frame>

<item id="719" />

Arch_AWS-Step-Functions_64

<frame width="220" height="160" margin="24" item-size="64">
    <item id="720" />
</frame>

<item id="720" />

Arch_Amazon-AppFlow_64

<frame width="220" height="160" margin="24" item-size="64">
    <item id="721" />
</frame>

<item id="721" />

Arch_Amazon-EventBridge_64

<frame width="220" height="160" margin="24" item-size="64">
    <item id="722" />
</frame>

<item id="722" />

Arch_Amazon-MQ_64

<frame width="220" height="160" margin="24" item-size="64">
    <item id="723" />
</frame>

<item id="723" />

Arch_Amazon-Managed-Workflows-for-Apache-Airflow_64

<frame width="220" height="160" margin="24" item-size="64">
    <item id="724" />
</frame>

<item id="724" />

Arch_Amazon-Simple-Notification-Service_64

<frame width="220" height="160" margin="24" item-size="64">
    <item id="725" />
</frame>

<item id="725" />

Arch_Amazon-Simple-Queue-Service_64

<frame width="220" height="160" margin="24" item-size="64">
    <item id="726" />
</frame>

<item id="726" />

Arch_AWS-App-Studio_16

<frame width="220" height="160" margin="24" item-size="64">
    <item id="878" />
</frame>

<item id="878" />

Arch_AWS-Deep-Learning-AMIs_16

<frame width="220" height="160" margin="24" item-size="64">
    <item id="879" />
</frame>

<item id="879" />

Arch_AWS-Deep-Learning-Containers_16

<frame width="220" height="160" margin="24" item-size="64">
    <item id="880" />
</frame>

<item id="880" />

Arch_AWS-DeepComposer_16

<frame width="220" height="160" margin="24" item-size="64">
    <item id="881" />
</frame>

<item id="881" />

Arch_AWS-DeepRacer_16

<frame width="220" height="160" margin="24" item-size="64">
    <item id="882" />
</frame>

<item id="882" />

Arch_AWS-HealthImaging_16

<frame width="220" height="160" margin="24" item-size="64">
    <item id="883" />
</frame>

<item id="883" />

Arch_AWS-HealthLake_16

<frame width="220" height="160" margin="24" item-size="64">
    <item id="884" />
</frame>

<item id="884" />

Arch_AWS-HealthOmics_16

<frame width="220" height="160" margin="24" item-size="64">
    <item id="885" />
</frame>

<item id="885" />

Arch_AWS-HealthScribe_16

<frame width="220" height="160" margin="24" item-size="64">
    <item id="886" />
</frame>

<item id="886" />

Arch_AWS-Neuron_16

<frame width="220" height="160" margin="24" item-size="64">
    <item id="887" />
</frame>

<item id="887" />

Arch_AWS-Panorama_16

<frame width="220" height="160" margin="24" item-size="64">
    <item id="888" />
</frame>

<item id="888" />

Arch_Amazon-Augmented-AI-A2I_16

<frame width="220" height="160" margin="24" item-size="64">
    <item id="889" />
</frame>

<item id="889" />

Arch_Amazon-Bedrock_16

<frame width="220" height="160" margin="24" item-size="64">
    <item id="890" />
</frame>

<item id="890" />

Arch_Amazon-CodeGuru_16

<frame width="220" height="160" margin="24" item-size="64">
    <item id="891" />
</frame>

<item id="891" />

Arch_Amazon-CodeWhisperer_16

<frame width="220" height="160" margin="24" item-size="64">
    <item id="892" />
</frame>

<item id="892" />

Arch_Amazon-Comprehend-Medical_16

<frame width="220" height="160" margin="24" item-size="64">
    <item id="893" />
</frame>

<item id="893" />

Arch_Amazon-Comprehend_16

<frame width="220" height="160" margin="24" item-size="64">
    <item id="894" />
</frame>

<item id="894" />

Arch_Amazon-DevOps-Guru_16

<frame width="220" height="160" margin="24" item-size="64">
    <item id="895" />
</frame>

<item id="895" />

Arch_Amazon-Elastic-Inference_16

<frame width="220" height="160" margin="24" item-size="64">
    <item id="896" />
</frame>

<item id="896" />

Arch_Amazon-Forecast_16

<frame width="220" height="160" margin="24" item-size="64">
    <item id="897" />
</frame>

<item id="897" />

Arch_Amazon-Fraud-Detector_16

<frame width="220" height="160" margin="24" item-size="64">
    <item id="898" />
</frame>

<item id="898" />

Arch_Amazon-Kendra_16

<frame width="220" height="160" margin="24" item-size="64">
    <item id="899" />
</frame>

<item id="899" />

Arch_Amazon-Lex_16

<frame width="220" height="160" margin="24" item-size="64">
    <item id="900" />
</frame>

<item id="900" />

Arch_Amazon-Lookout-for-Equipment_16

<frame width="220" height="160" margin="24" item-size="64">
    <item id="901" />
</frame>

<item id="901" />

Arch_Amazon-Lookout-for-Metrics_16

<frame width="220" height="160" margin="24" item-size="64">
    <item id="902" />
</frame>

<item id="902" />

Arch_Amazon-Lookout-for-Vision_16

<frame width="220" height="160" margin="24" item-size="64">
    <item id="903" />
</frame>

<item id="903" />

Arch_Amazon-Monitron_16

<frame width="220" height="160" margin="24" item-size="64">
    <item id="904" />
</frame>

<item id="904" />

Arch_Amazon-Nova_16

<frame width="220" height="160" margin="24" item-size="64">
    <item id="905" />
</frame>

<item id="905" />

Arch_Amazon-Personalize_16

<frame width="220" height="160" margin="24" item-size="64">
    <item id="906" />
</frame>

<item id="906" />

Arch_Amazon-Polly_16

<frame width="220" height="160" margin="24" item-size="64">
    <item id="907" />
</frame>

<item id="907" />

Arch_Amazon-Q_16

<frame width="220" height="160" margin="24" item-size="64">
    <item id="908" />
</frame>

<item id="908" />

Arch_Amazon-Rekognition_16

<frame width="220" height="160" margin="24" item-size="64">
    <item id="909" />
</frame>

<item id="909" />

Arch_Amazon-SageMaker-AI_16

<frame width="220" height="160" margin="24" item-size="64">
    <item id="910" />
</frame>

<item id="910" />

Arch_Amazon-SageMaker-Ground-Truth_16

<frame width="220" height="160" margin="24" item-size="64">
    <item id="911" />
</frame>

<item id="911" />

Arch_Amazon-SageMaker-Studio-Lab_16

<frame width="220" height="160" margin="24" item-size="64">
    <item id="912" />
</frame>

<item id="912" />

Arch_Amazon-Textract_16

<frame width="220" height="160" margin="24" item-size="64">
    <item id="913" />
</frame>

<item id="913" />

Arch_Amazon-Transcribe_16

<frame width="220" height="160" margin="24" item-size="64">
    <item id="914" />
</frame>

<item id="914" />

Arch_Amazon-Translate_16

<frame width="220" height="160" margin="24" item-size="64">
    <item id="915" />
</frame>

<item id="915" />

Arch_Apache-MXNet-on-AWS_16

<frame width="220" height="160" margin="24" item-size="64">
    <item id="916" />
</frame>

<item id="916" />

Arch_PyTorch-on-AWS_16

<frame width="220" height="160" margin="24" item-size="64">
    <item id="917" />
</frame>

<item id="917" />

Arch_TensorFlow-on-AWS_16

<frame width="220" height="160" margin="24" item-size="64">
    <item id="918" />
</frame>

<item id="918" />

Arch_AWS-App-Studio_32

<frame width="220" height="160" margin="24" item-size="64">
    <item id="837" />
</frame>

<item id="837" />

Arch_AWS-Deep-Learning-AMIs_32

<frame width="220" height="160" margin="24" item-size="64">
    <item id="838" />
</frame>

<item id="838" />

Arch_AWS-Deep-Learning-Containers_32

<frame width="220" height="160" margin="24" item-size="64">
    <item id="839" />
</frame>

<item id="839" />

Arch_AWS-DeepComposer_32

<frame width="220" height="160" margin="24" item-size="64">
    <item id="840" />
</frame>

<item id="840" />

Arch_AWS-DeepRacer_32

<frame width="220" height="160" margin="24" item-size="64">
    <item id="841" />
</frame>

<item id="841" />

Arch_AWS-HealthImaging_32

<frame width="220" height="160" margin="24" item-size="64">
    <item id="842" />
</frame>

<item id="842" />

Arch_AWS-HealthLake_32

<frame width="220" height="160" margin="24" item-size="64">
    <item id="843" />
</frame>

<item id="843" />

Arch_AWS-HealthOmics_32

<frame width="220" height="160" margin="24" item-size="64">
    <item id="844" />
</frame>

<item id="844" />

Arch_AWS-HealthScribe_32

<frame width="220" height="160" margin="24" item-size="64">
    <item id="845" />
</frame>

<item id="845" />

Arch_AWS-Neuron_32

<frame width="220" height="160" margin="24" item-size="64">
    <item id="846" />
</frame>

<item id="846" />

Arch_AWS-Panorama_32

<frame width="220" height="160" margin="24" item-size="64">
    <item id="847" />
</frame>

<item id="847" />

Arch_Amazon-Augmented-AI-A2I_32

<frame width="220" height="160" margin="24" item-size="64">
    <item id="848" />
</frame>

<item id="848" />

Arch_Amazon-Bedrock_32

<frame width="220" height="160" margin="24" item-size="64">
    <item id="849" />
</frame>

<item id="849" />

Arch_Amazon-CodeGuru_32

<frame width="220" height="160" margin="24" item-size="64">
    <item id="850" />
</frame>

<item id="850" />

Arch_Amazon-CodeWhisperer_32

<frame width="220" height="160" margin="24" item-size="64">
    <item id="851" />
</frame>

<item id="851" />

Architecture-Service-Icons - Page 3

This page references SVG files under etc/resources/aws/svg/Architecture-Service-Icons. Each card shows the SVG preview first and the XAL tag syntax in the Code tab. Showing 181-270 of 1236 SVG files.

Back to section index

Arch_Amazon-Comprehend-Medical_32

<frame width="220" height="160" margin="24" item-size="64">
    <item id="852" />
</frame>

<item id="852" />

Arch_Amazon-Comprehend_32

<frame width="220" height="160" margin="24" item-size="64">
    <item id="853" />
</frame>

<item id="853" />

Arch_Amazon-DevOps-Guru_32

<frame width="220" height="160" margin="24" item-size="64">
    <item id="854" />
</frame>

<item id="854" />

Arch_Amazon-Elastic-Inference_32

<frame width="220" height="160" margin="24" item-size="64">
    <item id="855" />
</frame>

<item id="855" />

Arch_Amazon-Forecast_32

<frame width="220" height="160" margin="24" item-size="64">
    <item id="856" />
</frame>

<item id="856" />

Arch_Amazon-Fraud-Detector_32

<frame width="220" height="160" margin="24" item-size="64">
    <item id="857" />
</frame>

<item id="857" />

Arch_Amazon-Kendra_32

<frame width="220" height="160" margin="24" item-size="64">
    <item id="858" />
</frame>

<item id="858" />

Arch_Amazon-Lex_32

<frame width="220" height="160" margin="24" item-size="64">
    <item id="859" />
</frame>

<item id="859" />

Arch_Amazon-Lookout-for-Equipment_32

<frame width="220" height="160" margin="24" item-size="64">
    <item id="860" />
</frame>

<item id="860" />

Arch_Amazon-Lookout-for-Metrics_32

<frame width="220" height="160" margin="24" item-size="64">
    <item id="861" />
</frame>

<item id="861" />

Arch_Amazon-Lookout-for-Vision_32

<frame width="220" height="160" margin="24" item-size="64">
    <item id="862" />
</frame>

<item id="862" />

Arch_Amazon-Monitron_32

<frame width="220" height="160" margin="24" item-size="64">
    <item id="863" />
</frame>

<item id="863" />

Arch_Amazon-Nova_32

<frame width="220" height="160" margin="24" item-size="64">
    <item id="864" />
</frame>

<item id="864" />

Arch_Amazon-Personalize_32

<frame width="220" height="160" margin="24" item-size="64">
    <item id="865" />
</frame>

<item id="865" />

Arch_Amazon-Polly_32

<frame width="220" height="160" margin="24" item-size="64">
    <item id="866" />
</frame>

<item id="866" />

Arch_Amazon-Q_32

<frame width="220" height="160" margin="24" item-size="64">
    <item id="867" />
</frame>

<item id="867" />

Arch_Amazon-Rekognition_32

<frame width="220" height="160" margin="24" item-size="64">
    <item id="868" />
</frame>

<item id="868" />

Arch_Amazon-SageMaker-AI_32

<frame width="220" height="160" margin="24" item-size="64">
    <item id="869" />
</frame>

<item id="869" />

Arch_Amazon-SageMaker-Ground-Truth_32

<frame width="220" height="160" margin="24" item-size="64">
    <item id="870" />
</frame>

<item id="870" />

Arch_Amazon-SageMaker-Studio-Lab_32

<frame width="220" height="160" margin="24" item-size="64">
    <item id="871" />
</frame>

<item id="871" />

Arch_Amazon-Textract_32

<frame width="220" height="160" margin="24" item-size="64">
    <item id="872" />
</frame>

<item id="872" />

Arch_Amazon-Transcribe_32

<frame width="220" height="160" margin="24" item-size="64">
    <item id="873" />
</frame>

<item id="873" />

Arch_Amazon-Translate_32

<frame width="220" height="160" margin="24" item-size="64">
    <item id="874" />
</frame>

<item id="874" />

Arch_Apache-MXNet-on-AWS_32

<frame width="220" height="160" margin="24" item-size="64">
    <item id="875" />
</frame>

<item id="875" />

Arch_PyTorch-on-AWS_32

<frame width="220" height="160" margin="24" item-size="64">
    <item id="876" />
</frame>

<item id="876" />

Arch_TensorFlow-on-AWS_32

<frame width="220" height="160" margin="24" item-size="64">
    <item id="877" />
</frame>

<item id="877" />

Arch_AWS-App-Studio_48

<frame width="220" height="160" margin="24" item-size="64">
    <item id="960" />
</frame>

<item id="960" />

Arch_AWS-Deep-Learning-AMIs_48

<frame width="220" height="160" margin="24" item-size="64">
    <item id="961" />
</frame>

<item id="961" />

Arch_AWS-Deep-Learning-Containers_48

<frame width="220" height="160" margin="24" item-size="64">
    <item id="962" />
</frame>

<item id="962" />

Arch_AWS-DeepComposer_48

<frame width="220" height="160" margin="24" item-size="64">
    <item id="963" />
</frame>

<item id="963" />

Arch_AWS-DeepRacer_48

<frame width="220" height="160" margin="24" item-size="64">
    <item id="964" />
</frame>

<item id="964" />

Arch_AWS-HealthImaging_48

<frame width="220" height="160" margin="24" item-size="64">
    <item id="965" />
</frame>

<item id="965" />

Arch_AWS-HealthLake_48

<frame width="220" height="160" margin="24" item-size="64">
    <item id="966" />
</frame>

<item id="966" />

Arch_AWS-HealthOmics_48

<frame width="220" height="160" margin="24" item-size="64">
    <item id="967" />
</frame>

<item id="967" />

Arch_AWS-HealthScribe_48

<frame width="220" height="160" margin="24" item-size="64">
    <item id="968" />
</frame>

<item id="968" />

Arch_AWS-Neuron_48

<frame width="220" height="160" margin="24" item-size="64">
    <item id="969" />
</frame>

<item id="969" />

Arch_AWS-Panorama_48

<frame width="220" height="160" margin="24" item-size="64">
    <item id="970" />
</frame>

<item id="970" />

Arch_Amazon-Augmented-AI-A2I_48

<frame width="220" height="160" margin="24" item-size="64">
    <item id="971" />
</frame>

<item id="971" />

Arch_Amazon-Bedrock_48

<frame width="220" height="160" margin="24" item-size="64">
    <item id="972" />
</frame>

<item id="972" />

Arch_Amazon-CodeGuru_48

<frame width="220" height="160" margin="24" item-size="64">
    <item id="973" />
</frame>

<item id="973" />

Arch_Amazon-CodeWhisperer_48

<frame width="220" height="160" margin="24" item-size="64">
    <item id="974" />
</frame>

<item id="974" />

Arch_Amazon-Comprehend-Medical_48

<frame width="220" height="160" margin="24" item-size="64">
    <item id="975" />
</frame>

<item id="975" />

Arch_Amazon-Comprehend_48

<frame width="220" height="160" margin="24" item-size="64">
    <item id="976" />
</frame>

<item id="976" />

Arch_Amazon-DevOps-Guru_48

<frame width="220" height="160" margin="24" item-size="64">
    <item id="977" />
</frame>

<item id="977" />

Arch_Amazon-Elastic-Inference_48

<frame width="220" height="160" margin="24" item-size="64">
    <item id="978" />
</frame>

<item id="978" />

Arch_Amazon-Forecast_48

<frame width="220" height="160" margin="24" item-size="64">
    <item id="979" />
</frame>

<item id="979" />

Arch_Amazon-Fraud-Detector_48

<frame width="220" height="160" margin="24" item-size="64">
    <item id="980" />
</frame>

<item id="980" />

Arch_Amazon-Kendra_48

<frame width="220" height="160" margin="24" item-size="64">
    <item id="981" />
</frame>

<item id="981" />

Arch_Amazon-Lex_48

<frame width="220" height="160" margin="24" item-size="64">
    <item id="982" />
</frame>

<item id="982" />

Arch_Amazon-Lookout-for-Equipment_48

<frame width="220" height="160" margin="24" item-size="64">
    <item id="983" />
</frame>

<item id="983" />

Arch_Amazon-Lookout-for-Metrics_48

<frame width="220" height="160" margin="24" item-size="64">
    <item id="984" />
</frame>

<item id="984" />

Arch_Amazon-Lookout-for-Vision_48

<frame width="220" height="160" margin="24" item-size="64">
    <item id="985" />
</frame>

<item id="985" />

Arch_Amazon-Monitron_48

<frame width="220" height="160" margin="24" item-size="64">
    <item id="986" />
</frame>

<item id="986" />

Arch_Amazon-Nova_48

<frame width="220" height="160" margin="24" item-size="64">
    <item id="987" />
</frame>

<item id="987" />

Arch_Amazon-Personalize_48

<frame width="220" height="160" margin="24" item-size="64">
    <item id="988" />
</frame>

<item id="988" />

Arch_Amazon-Polly_48

<frame width="220" height="160" margin="24" item-size="64">
    <item id="989" />
</frame>

<item id="989" />

Arch_Amazon-Q_48

<frame width="220" height="160" margin="24" item-size="64">
    <item id="990" />
</frame>

<item id="990" />

Arch_Amazon-Rekognition_48

<frame width="220" height="160" margin="24" item-size="64">
    <item id="991" />
</frame>

<item id="991" />

Arch_Amazon-SageMaker-AI_48

<frame width="220" height="160" margin="24" item-size="64">
    <item id="992" />
</frame>

<item id="992" />

Arch_Amazon-SageMaker-Ground-Truth_48

<frame width="220" height="160" margin="24" item-size="64">
    <item id="993" />
</frame>

<item id="993" />

Arch_Amazon-SageMaker-Studio-Lab_48

<frame width="220" height="160" margin="24" item-size="64">
    <item id="994" />
</frame>

<item id="994" />

Arch_Amazon-Textract_48

<frame width="220" height="160" margin="24" item-size="64">
    <item id="995" />
</frame>

<item id="995" />

Arch_Amazon-Transcribe_48

<frame width="220" height="160" margin="24" item-size="64">
    <item id="996" />
</frame>

<item id="996" />

Arch_Amazon-Translate_48

<frame width="220" height="160" margin="24" item-size="64">
    <item id="997" />
</frame>

<item id="997" />

Arch_Apache-MXNet-on-AWS_48

<frame width="220" height="160" margin="24" item-size="64">
    <item id="998" />
</frame>

<item id="998" />

Arch_PyTorch-on-AWS_48

<frame width="220" height="160" margin="24" item-size="64">
    <item id="999" />
</frame>

<item id="999" />

Arch_TensorFlow-on-AWS_48

<frame width="220" height="160" margin="24" item-size="64">
    <item id="1000" />
</frame>

<item id="1000" />

Arch_AWS-App-Studio_64

<frame width="220" height="160" margin="24" item-size="64">
    <item id="919" />
</frame>

<item id="919" />

Arch_AWS-Deep-Learning-AMIs_64

<frame width="220" height="160" margin="24" item-size="64">
    <item id="920" />
</frame>

<item id="920" />

Arch_AWS-Deep-Learning-Containers_64

<frame width="220" height="160" margin="24" item-size="64">
    <item id="921" />
</frame>

<item id="921" />

Arch_AWS-DeepComposer_64

<frame width="220" height="160" margin="24" item-size="64">
    <item id="922" />
</frame>

<item id="922" />

Arch_AWS-DeepRacer_64

<frame width="220" height="160" margin="24" item-size="64">
    <item id="923" />
</frame>

<item id="923" />

Arch_AWS-HealthImaging_64

<frame width="220" height="160" margin="24" item-size="64">
    <item id="924" />
</frame>

<item id="924" />

Arch_AWS-HealthLake_64

<frame width="220" height="160" margin="24" item-size="64">
    <item id="925" />
</frame>

<item id="925" />

Arch_AWS-HealthOmics_64

<frame width="220" height="160" margin="24" item-size="64">
    <item id="926" />
</frame>

<item id="926" />

Arch_AWS-HealthScribe_64

<frame width="220" height="160" margin="24" item-size="64">
    <item id="927" />
</frame>

<item id="927" />

Arch_AWS-Neuron_64

<frame width="220" height="160" margin="24" item-size="64">
    <item id="928" />
</frame>

<item id="928" />

Arch_AWS-Panorama_64

<frame width="220" height="160" margin="24" item-size="64">
    <item id="929" />
</frame>

<item id="929" />

Arch_Amazon-Augmented-AI-A2I_64

<frame width="220" height="160" margin="24" item-size="64">
    <item id="930" />
</frame>

<item id="930" />

Arch_Amazon-Bedrock_64

<frame width="220" height="160" margin="24" item-size="64">
    <item id="931" />
</frame>

<item id="931" />

Arch_Amazon-CodeGuru_64

<frame width="220" height="160" margin="24" item-size="64">
    <item id="932" />
</frame>

<item id="932" />

Arch_Amazon-CodeWhisperer_64

<frame width="220" height="160" margin="24" item-size="64">
    <item id="933" />
</frame>

<item id="933" />

Arch_Amazon-Comprehend-Medical_64

<frame width="220" height="160" margin="24" item-size="64">
    <item id="934" />
</frame>

<item id="934" />

Arch_Amazon-Comprehend_64

<frame width="220" height="160" margin="24" item-size="64">
    <item id="935" />
</frame>

<item id="935" />

Arch_Amazon-DevOps-Guru_64

<frame width="220" height="160" margin="24" item-size="64">
    <item id="936" />
</frame>

<item id="936" />

Arch_Amazon-Elastic-Inference_64

<frame width="220" height="160" margin="24" item-size="64">
    <item id="937" />
</frame>

<item id="937" />

Arch_Amazon-Forecast_64

<frame width="220" height="160" margin="24" item-size="64">
    <item id="938" />
</frame>

<item id="938" />

Arch_Amazon-Fraud-Detector_64

<frame width="220" height="160" margin="24" item-size="64">
    <item id="939" />
</frame>

<item id="939" />

Arch_Amazon-Kendra_64

<frame width="220" height="160" margin="24" item-size="64">
    <item id="940" />
</frame>

<item id="940" />

Arch_Amazon-Lex_64

<frame width="220" height="160" margin="24" item-size="64">
    <item id="941" />
</frame>

<item id="941" />

Architecture-Service-Icons - Page 4

This page references SVG files under etc/resources/aws/svg/Architecture-Service-Icons. Each card shows the SVG preview first and the XAL tag syntax in the Code tab. Showing 271-360 of 1236 SVG files.

Back to section index

Arch_Amazon-Lookout-for-Equipment_64

<frame width="220" height="160" margin="24" item-size="64">
    <item id="942" />
</frame>

<item id="942" />

Arch_Amazon-Lookout-for-Metrics_64

<frame width="220" height="160" margin="24" item-size="64">
    <item id="943" />
</frame>

<item id="943" />

Arch_Amazon-Lookout-for-Vision_64

<frame width="220" height="160" margin="24" item-size="64">
    <item id="944" />
</frame>

<item id="944" />

Arch_Amazon-Monitron_64

<frame width="220" height="160" margin="24" item-size="64">
    <item id="945" />
</frame>

<item id="945" />

Arch_Amazon-Nova_64

<frame width="220" height="160" margin="24" item-size="64">
    <item id="946" />
</frame>

<item id="946" />

Arch_Amazon-Personalize_64

<frame width="220" height="160" margin="24" item-size="64">
    <item id="947" />
</frame>

<item id="947" />

Arch_Amazon-Polly_64

<frame width="220" height="160" margin="24" item-size="64">
    <item id="948" />
</frame>

<item id="948" />

Arch_Amazon-Q_64

<frame width="220" height="160" margin="24" item-size="64">
    <item id="949" />
</frame>

<item id="949" />

Arch_Amazon-Rekognition_64

<frame width="220" height="160" margin="24" item-size="64">
    <item id="950" />
</frame>

<item id="950" />

Arch_Amazon-SageMaker-AI_64

<frame width="220" height="160" margin="24" item-size="64">
    <item id="951" />
</frame>

<item id="951" />

Arch_Amazon-SageMaker-Ground-Truth_64

<frame width="220" height="160" margin="24" item-size="64">
    <item id="952" />
</frame>

<item id="952" />

Arch_Amazon-SageMaker-Studio-Lab_64

<frame width="220" height="160" margin="24" item-size="64">
    <item id="953" />
</frame>

<item id="953" />

Arch_Amazon-Textract_64

<frame width="220" height="160" margin="24" item-size="64">
    <item id="954" />
</frame>

<item id="954" />

Arch_Amazon-Transcribe_64

<frame width="220" height="160" margin="24" item-size="64">
    <item id="955" />
</frame>

<item id="955" />

Arch_Amazon-Translate_64

<frame width="220" height="160" margin="24" item-size="64">
    <item id="956" />
</frame>

<item id="956" />

Arch_Apache-MXNet-on-AWS_64

<frame width="220" height="160" margin="24" item-size="64">
    <item id="957" />
</frame>

<item id="957" />

Arch_PyTorch-on-AWS_64

<frame width="220" height="160" margin="24" item-size="64">
    <item id="958" />
</frame>

<item id="958" />

Arch_TensorFlow-on-AWS_64

<frame width="220" height="160" margin="24" item-size="64">
    <item id="959" />
</frame>

<item id="959" />

Arch_Amazon-Managed-Blockchain_16

<frame width="220" height="160" margin="24" item-size="64">
    <item id="375" />
</frame>

<item id="375" />

Arch_Amazon-Quantum-Ledger-Database_16

<frame width="220" height="160" margin="24" item-size="64">
    <item id="376" />
</frame>

<item id="376" />

Arch_Amazon-Managed-Blockchain_32

<frame width="220" height="160" margin="24" item-size="64">
    <item id="373" />
</frame>

<item id="373" />

Arch_Amazon-Quantum-Ledger-Database_32

<frame width="220" height="160" margin="24" item-size="64">
    <item id="374" />
</frame>

<item id="374" />

Arch_Amazon-Managed-Blockchain_48

<frame width="220" height="160" margin="24" item-size="64">
    <item id="379" />
</frame>

<item id="379" />

Arch_Amazon-Quantum-Ledger-Database_48

<frame width="220" height="160" margin="24" item-size="64">
    <item id="380" />
</frame>

<item id="380" />

Arch_Amazon-Managed-Blockchain_64

<frame width="220" height="160" margin="24" item-size="64">
    <item id="377" />
</frame>

<item id="377" />

Arch_Amazon-Quantum-Ledger-Database_64

<frame width="220" height="160" margin="24" item-size="64">
    <item id="378" />
</frame>

<item id="378" />

Arch_AWS-AppFabric_16

<frame width="220" height="160" margin="24" item-size="64">
    <item id="331" />
</frame>

<item id="331" />

Arch_AWS-End-User-Messaging_16

<frame width="220" height="160" margin="24" item-size="64">
    <item id="332" />
</frame>

<item id="332" />

Arch_AWS-Supply-Chain_16

<frame width="220" height="160" margin="24" item-size="64">
    <item id="333" />
</frame>

<item id="333" />

Arch_AWS-Wickr_16

<frame width="220" height="160" margin="24" item-size="64">
    <item id="334" />
</frame>

<item id="334" />

Arch_Alexa-For-Business_16

<frame width="220" height="160" margin="24" item-size="64">
    <item id="335" />
</frame>

<item id="335" />

Arch_Amazon-Chime-SDK_16

<frame width="220" height="160" margin="24" item-size="64">
    <item id="336" />
</frame>

<item id="336" />

Arch_Amazon-Chime_16

<frame width="220" height="160" margin="24" item-size="64">
    <item id="337" />
</frame>

<item id="337" />

Arch_Amazon-Connect_16

<frame width="220" height="160" margin="24" item-size="64">
    <item id="338" />
</frame>

<item id="338" />

Arch_Amazon-Pinpoint-APIs_16

<frame width="220" height="160" margin="24" item-size="64">
    <item id="339" />
</frame>

<item id="339" />

Arch_Amazon-Pinpoint_16

<frame width="220" height="160" margin="24" item-size="64">
    <item id="340" />
</frame>

<item id="340" />

Arch_Amazon-Simple-Email-Service_16

<frame width="220" height="160" margin="24" item-size="64">
    <item id="341" />
</frame>

<item id="341" />

Arch_Amazon-WorkDocs-SDK_16

<frame width="220" height="160" margin="24" item-size="64">
    <item id="342" />
</frame>

<item id="342" />

Arch_Amazon-WorkDocs_16

<frame width="220" height="160" margin="24" item-size="64">
    <item id="343" />
</frame>

<item id="343" />

Arch_Amazon-WorkMail_16

<frame width="220" height="160" margin="24" item-size="64">
    <item id="344" />
</frame>

<item id="344" />

Arch_AWS-AppFabric_32

<frame width="220" height="160" margin="24" item-size="64">
    <item id="317" />
</frame>

<item id="317" />

Arch_AWS-End-User-Messaging_32

<frame width="220" height="160" margin="24" item-size="64">
    <item id="318" />
</frame>

<item id="318" />

Arch_AWS-Supply-Chain_32

<frame width="220" height="160" margin="24" item-size="64">
    <item id="319" />
</frame>

<item id="319" />

Arch_AWS-Wickr_32

<frame width="220" height="160" margin="24" item-size="64">
    <item id="320" />
</frame>

<item id="320" />

Arch_Alexa-For-Business_32

<frame width="220" height="160" margin="24" item-size="64">
    <item id="321" />
</frame>

<item id="321" />

Arch_Amazon-Chime-SDK_32

<frame width="220" height="160" margin="24" item-size="64">
    <item id="322" />
</frame>

<item id="322" />

Arch_Amazon-Chime_32

<frame width="220" height="160" margin="24" item-size="64">
    <item id="323" />
</frame>

<item id="323" />

Arch_Amazon-Connect_32

<frame width="220" height="160" margin="24" item-size="64">
    <item id="324" />
</frame>

<item id="324" />

Arch_Amazon-Pinpoint-APIs_32

<frame width="220" height="160" margin="24" item-size="64">
    <item id="325" />
</frame>

<item id="325" />

Arch_Amazon-Pinpoint_32

<frame width="220" height="160" margin="24" item-size="64">
    <item id="326" />
</frame>

<item id="326" />

Arch_Amazon-Simple-Email-Service_32

<frame width="220" height="160" margin="24" item-size="64">
    <item id="327" />
</frame>

<item id="327" />

Arch_Amazon-WorkDocs-SDK_32

<frame width="220" height="160" margin="24" item-size="64">
    <item id="328" />
</frame>

<item id="328" />

Arch_Amazon-WorkDocs_32

<frame width="220" height="160" margin="24" item-size="64">
    <item id="329" />
</frame>

<item id="329" />

Arch_Amazon-WorkMail_32

<frame width="220" height="160" margin="24" item-size="64">
    <item id="330" />
</frame>

<item id="330" />

Arch_AWS-AppFabric_48

<frame width="220" height="160" margin="24" item-size="64">
    <item id="359" />
</frame>

<item id="359" />

Arch_AWS-End-User-Messaging_48

<frame width="220" height="160" margin="24" item-size="64">
    <item id="360" />
</frame>

<item id="360" />

Arch_AWS-Supply-Chain_48

<frame width="220" height="160" margin="24" item-size="64">
    <item id="361" />
</frame>

<item id="361" />

Arch_AWS-Wickr_48

<frame width="220" height="160" margin="24" item-size="64">
    <item id="362" />
</frame>

<item id="362" />

Arch_Alexa-For-Business_48

<frame width="220" height="160" margin="24" item-size="64">
    <item id="363" />
</frame>

<item id="363" />

Arch_Amazon-Chime-SDK_48

<frame width="220" height="160" margin="24" item-size="64">
    <item id="364" />
</frame>

<item id="364" />

Arch_Amazon-Chime_48

<frame width="220" height="160" margin="24" item-size="64">
    <item id="365" />
</frame>

<item id="365" />

Arch_Amazon-Connect_48

<frame width="220" height="160" margin="24" item-size="64">
    <item id="366" />
</frame>

<item id="366" />

Arch_Amazon-Pinpoint-APIs_48

<frame width="220" height="160" margin="24" item-size="64">
    <item id="367" />
</frame>

<item id="367" />

Arch_Amazon-Pinpoint_48

<frame width="220" height="160" margin="24" item-size="64">
    <item id="368" />
</frame>

<item id="368" />

Arch_Amazon-Simple-Email-Service_48

<frame width="220" height="160" margin="24" item-size="64">
    <item id="369" />
</frame>

<item id="369" />

Arch_Amazon-WorkDocs-SDK_48

<frame width="220" height="160" margin="24" item-size="64">
    <item id="370" />
</frame>

<item id="370" />

Arch_Amazon-WorkDocs_48

<frame width="220" height="160" margin="24" item-size="64">
    <item id="371" />
</frame>

<item id="371" />

Arch_Amazon-WorkMail_48

<frame width="220" height="160" margin="24" item-size="64">
    <item id="372" />
</frame>

<item id="372" />

Arch_AWS-AppFabric_64

<frame width="220" height="160" margin="24" item-size="64">
    <item id="345" />
</frame>

<item id="345" />

Arch_AWS-End-User-Messaging_64

<frame width="220" height="160" margin="24" item-size="64">
    <item id="346" />
</frame>

<item id="346" />

Arch_AWS-Supply-Chain_64

<frame width="220" height="160" margin="24" item-size="64">
    <item id="347" />
</frame>

<item id="347" />

Arch_AWS-Wickr_64

<frame width="220" height="160" margin="24" item-size="64">
    <item id="348" />
</frame>

<item id="348" />

Arch_Alexa-For-Business_64

<frame width="220" height="160" margin="24" item-size="64">
    <item id="349" />
</frame>

<item id="349" />

Arch_Amazon-Chime-SDK_64

<frame width="220" height="160" margin="24" item-size="64">
    <item id="350" />
</frame>

<item id="350" />

Arch_Amazon-Chime_64

<frame width="220" height="160" margin="24" item-size="64">
    <item id="351" />
</frame>

<item id="351" />

Arch_Amazon-Connect_64

<frame width="220" height="160" margin="24" item-size="64">
    <item id="352" />
</frame>

<item id="352" />

Arch_Amazon-Pinpoint-APIs_64

<frame width="220" height="160" margin="24" item-size="64">
    <item id="353" />
</frame>

<item id="353" />

Arch_Amazon-Pinpoint_64

<frame width="220" height="160" margin="24" item-size="64">
    <item id="354" />
</frame>

<item id="354" />

Arch_Amazon-Simple-Email-Service_64

<frame width="220" height="160" margin="24" item-size="64">
    <item id="355" />
</frame>

<item id="355" />

Arch_Amazon-WorkDocs-SDK_64

<frame width="220" height="160" margin="24" item-size="64">
    <item id="356" />
</frame>

<item id="356" />

Arch_Amazon-WorkDocs_64

<frame width="220" height="160" margin="24" item-size="64">
    <item id="357" />
</frame>

<item id="357" />

Arch_Amazon-WorkMail_64

<frame width="220" height="160" margin="24" item-size="64">
    <item id="358" />
</frame>

<item id="358" />

Arch_AWS-Billing-Conductor_16

<frame width="220" height="160" margin="24" item-size="64">
    <item id="191" />
</frame>

<item id="191" />

Arch_AWS-Budgets_16

<frame width="220" height="160" margin="24" item-size="64">
    <item id="192" />
</frame>

<item id="192" />

Arch_AWS-Cost-Explorer_16

<frame width="220" height="160" margin="24" item-size="64">
    <item id="193" />
</frame>

<item id="193" />

Arch_AWS-Cost-and-Usage-Report_16

<frame width="220" height="160" margin="24" item-size="64">
    <item id="194" />
</frame>

<item id="194" />

Arch_Reserved-Instance-Reporting_16

<frame width="220" height="160" margin="24" item-size="64">
    <item id="195" />
</frame>

<item id="195" />

Arch_Savings-Plans_16

<frame width="220" height="160" margin="24" item-size="64">
    <item id="196" />
</frame>

<item id="196" />

Arch_AWS-Billing-Conductor_32

<frame width="220" height="160" margin="24" item-size="64">
    <item id="185" />
</frame>

<item id="185" />

Arch_AWS-Budgets_32

<frame width="220" height="160" margin="24" item-size="64">
    <item id="186" />
</frame>

<item id="186" />

Architecture-Service-Icons - Page 5

This page references SVG files under etc/resources/aws/svg/Architecture-Service-Icons. Each card shows the SVG preview first and the XAL tag syntax in the Code tab. Showing 361-450 of 1236 SVG files.

Back to section index

Arch_AWS-Cost-Explorer_32

<frame width="220" height="160" margin="24" item-size="64">
    <item id="187" />
</frame>

<item id="187" />

Arch_AWS-Cost-and-Usage-Report_32

<frame width="220" height="160" margin="24" item-size="64">
    <item id="188" />
</frame>

<item id="188" />

Arch_Reserved-Instance-Reporting_32

<frame width="220" height="160" margin="24" item-size="64">
    <item id="189" />
</frame>

<item id="189" />

Arch_Savings-Plans_32

<frame width="220" height="160" margin="24" item-size="64">
    <item id="190" />
</frame>

<item id="190" />

Arch_AWS-Billing-Conductor_48

<frame width="220" height="160" margin="24" item-size="64">
    <item id="203" />
</frame>

<item id="203" />

Arch_AWS-Budgets_48

<frame width="220" height="160" margin="24" item-size="64">
    <item id="204" />
</frame>

<item id="204" />

Arch_AWS-Cost-Explorer_48

<frame width="220" height="160" margin="24" item-size="64">
    <item id="205" />
</frame>

<item id="205" />

Arch_AWS-Cost-and-Usage-Report_48

<frame width="220" height="160" margin="24" item-size="64">
    <item id="206" />
</frame>

<item id="206" />

Arch_Reserved-Instance-Reporting_48

<frame width="220" height="160" margin="24" item-size="64">
    <item id="207" />
</frame>

<item id="207" />

Arch_Savings-Plans_48

<frame width="220" height="160" margin="24" item-size="64">
    <item id="208" />
</frame>

<item id="208" />

Arch_AWS-Billing-Conductor_64

<frame width="220" height="160" margin="24" item-size="64">
    <item id="197" />
</frame>

<item id="197" />

Arch_AWS-Budgets_64

<frame width="220" height="160" margin="24" item-size="64">
    <item id="198" />
</frame>

<item id="198" />

Arch_AWS-Cost-Explorer_64

<frame width="220" height="160" margin="24" item-size="64">
    <item id="199" />
</frame>

<item id="199" />

Arch_AWS-Cost-and-Usage-Report_64

<frame width="220" height="160" margin="24" item-size="64">
    <item id="200" />
</frame>

<item id="200" />

Arch_Reserved-Instance-Reporting_64

<frame width="220" height="160" margin="24" item-size="64">
    <item id="201" />
</frame>

<item id="201" />

Arch_Savings-Plans_64

<frame width="220" height="160" margin="24" item-size="64">
    <item id="202" />
</frame>

<item id="202" />

Arch_AWS-App-Runner_16

<frame width="220" height="160" margin="24" item-size="64">
    <item id="34" />
</frame>

<item id="34" />

Arch_AWS-Batch_16

<frame width="220" height="160" margin="24" item-size="64">
    <item id="35" />
</frame>

<item id="35" />

Arch_AWS-Compute-Optimizer_16

<frame width="220" height="160" margin="24" item-size="64">
    <item id="36" />
</frame>

<item id="36" />

Arch_AWS-Elastic-Beanstalk_16

<frame width="220" height="160" margin="24" item-size="64">
    <item id="37" />
</frame>

<item id="37" />

Arch_AWS-Lambda_16

<frame width="220" height="160" margin="24" item-size="64">
    <item id="38" />
</frame>

<item id="38" />

Arch_AWS-Local-Zones_16

<frame width="220" height="160" margin="24" item-size="64">
    <item id="39" />
</frame>

<item id="39" />

Arch_AWS-Nitro-Enclaves_16

<frame width="220" height="160" margin="24" item-size="64">
    <item id="40" />
</frame>

<item id="40" />

Arch_AWS-Outposts-family_16

<frame width="220" height="160" margin="24" item-size="64">
    <item id="41" />
</frame>

<item id="41" />

Arch_AWS-Outposts-rack_16

<frame width="220" height="160" margin="24" item-size="64">
    <item id="42" />
</frame>

<item id="42" />

Arch_AWS-Outposts-servers_16

<frame width="220" height="160" margin="24" item-size="64">
    <item id="43" />
</frame>

<item id="43" />

Arch_AWS-Parallel-Cluster_16

<frame width="220" height="160" margin="24" item-size="64">
    <item id="44" />
</frame>

<item id="44" />

Arch_AWS-Parallel-Computing-Service_16

<frame width="220" height="160" margin="24" item-size="64">
    <item id="45" />
</frame>

<item id="45" />

Arch_AWS-Serverless-Application-Repository_16

<frame width="220" height="160" margin="24" item-size="64">
    <item id="46" />
</frame>

<item id="46" />

Arch_AWS-SimSpace-Weaver_16

<frame width="220" height="160" margin="24" item-size="64">
    <item id="47" />
</frame>

<item id="47" />

Arch_AWS-Wavelength_16

<frame width="220" height="160" margin="24" item-size="64">
    <item id="48" />
</frame>

<item id="48" />

Arch_Amazon-DCV_16

<frame width="220" height="160" margin="24" item-size="64">
    <item id="49" />
</frame>

<item id="49" />

Arch_Amazon-EC2-Auto-Scaling_16

<frame width="220" height="160" margin="24" item-size="64">
    <item id="50" />
</frame>

<item id="50" />

Arch_Amazon-EC2-Image-Builder_16

<frame width="220" height="160" margin="24" item-size="64">
    <item id="51" />
</frame>

<item id="51" />

Arch_Amazon-EC2_16

<frame width="220" height="160" margin="24" item-size="64">
    <item id="52" />
</frame>

<item id="52" />

Arch_Amazon-Elastic-VMware-Service_16

<frame width="220" height="160" margin="24" item-size="64">
    <item id="53" />
</frame>

<item id="53" />

Arch_Amazon-Lightsail-for-Research_16

<frame width="220" height="160" margin="24" item-size="64">
    <item id="54" />
</frame>

<item id="54" />

Arch_Amazon-Lightsail_16

<frame width="220" height="160" margin="24" item-size="64">
    <item id="55" />
</frame>

<item id="55" />

Arch_Bottlerocket_16

<frame width="220" height="160" margin="24" item-size="64">
    <item id="56" />
</frame>

<item id="56" />

Arch_Elastic-Fabric-Adapter_16

<frame width="220" height="160" margin="24" item-size="64">
    <item id="57" />
</frame>

<item id="57" />

Arch_NICE-EnginFrame_16

<frame width="220" height="160" margin="24" item-size="64">
    <item id="58" />
</frame>

<item id="58" />

Arch_AWS-App-Runner_32

<frame width="220" height="160" margin="24" item-size="64">
    <item id="9" />
</frame>

<item id="9" />

Arch_AWS-Batch_32

<frame width="220" height="160" margin="24" item-size="64">
    <item id="10" />
</frame>

<item id="10" />

Arch_AWS-Compute-Optimizer_32

<frame width="220" height="160" margin="24" item-size="64">
    <item id="11" />
</frame>

<item id="11" />

Arch_AWS-Elastic-Beanstalk_32

<frame width="220" height="160" margin="24" item-size="64">
    <item id="12" />
</frame>

<item id="12" />

Arch_AWS-Lambda_32

<frame width="220" height="160" margin="24" item-size="64">
    <item id="13" />
</frame>

<item id="13" />

Arch_AWS-Local-Zones_32

<frame width="220" height="160" margin="24" item-size="64">
    <item id="14" />
</frame>

<item id="14" />

Arch_AWS-Nitro-Enclaves_32

<frame width="220" height="160" margin="24" item-size="64">
    <item id="15" />
</frame>

<item id="15" />

Arch_AWS-Outposts-family_32

<frame width="220" height="160" margin="24" item-size="64">
    <item id="16" />
</frame>

<item id="16" />

Arch_AWS-Outposts-rack_32

<frame width="220" height="160" margin="24" item-size="64">
    <item id="17" />
</frame>

<item id="17" />

Arch_AWS-Outposts-servers_32

<frame width="220" height="160" margin="24" item-size="64">
    <item id="18" />
</frame>

<item id="18" />

Arch_AWS-Parallel-Cluster_32

<frame width="220" height="160" margin="24" item-size="64">
    <item id="19" />
</frame>

<item id="19" />

Arch_AWS-Parallel-Computing-Service_32

<frame width="220" height="160" margin="24" item-size="64">
    <item id="20" />
</frame>

<item id="20" />

Arch_AWS-Serverless-Application-Repository_32

<frame width="220" height="160" margin="24" item-size="64">
    <item id="21" />
</frame>

<item id="21" />

Arch_AWS-SimSpace-Weaver_32

<frame width="220" height="160" margin="24" item-size="64">
    <item id="22" />
</frame>

<item id="22" />

Arch_AWS-Wavelength_32

<frame width="220" height="160" margin="24" item-size="64">
    <item id="23" />
</frame>

<item id="23" />

Arch_Amazon-DCV_32

<frame width="220" height="160" margin="24" item-size="64">
    <item id="24" />
</frame>

<item id="24" />

Arch_Amazon-EC2-Auto-Scaling_32

<frame width="220" height="160" margin="24" item-size="64">
    <item id="25" />
</frame>

<item id="25" />

Arch_Amazon-EC2-Image-Builder_32

<frame width="220" height="160" margin="24" item-size="64">
    <item id="26" />
</frame>

<item id="26" />

Arch_Amazon-EC2_32

<frame width="220" height="160" margin="24" item-size="64">
    <item id="27" />
</frame>

<item id="27" />

Arch_Amazon-Elastic-VMware-Service_32

<frame width="220" height="160" margin="24" item-size="64">
    <item id="28" />
</frame>

<item id="28" />

Arch_Amazon-Lightsail-for-Research_32

<frame width="220" height="160" margin="24" item-size="64">
    <item id="29" />
</frame>

<item id="29" />

Arch_Amazon-Lightsail_32

<frame width="220" height="160" margin="24" item-size="64">
    <item id="30" />
</frame>

<item id="30" />

Arch_Bottlerocket_32

<frame width="220" height="160" margin="24" item-size="64">
    <item id="31" />
</frame>

<item id="31" />

Arch_Elastic-Fabric-Adapter_32

<frame width="220" height="160" margin="24" item-size="64">
    <item id="32" />
</frame>

<item id="32" />

Arch_NICE-EnginFrame_32

<frame width="220" height="160" margin="24" item-size="64">
    <item id="33" />
</frame>

<item id="33" />

Arch_AWS-App-Runner_48

<frame width="220" height="160" margin="24" item-size="64">
    <item id="84" />
</frame>

<item id="84" />

Arch_AWS-Batch_48

<frame width="220" height="160" margin="24" item-size="64">
    <item id="85" />
</frame>

<item id="85" />

Arch_AWS-Compute-Optimizer_48

<frame width="220" height="160" margin="24" item-size="64">
    <item id="86" />
</frame>

<item id="86" />

Arch_AWS-Elastic-Beanstalk_48

<frame width="220" height="160" margin="24" item-size="64">
    <item id="87" />
</frame>

<item id="87" />

Arch_AWS-Lambda_48

<frame width="220" height="160" margin="24" item-size="64">
    <item id="88" />
</frame>

<item id="88" />

Arch_AWS-Local-Zones_48

<frame width="220" height="160" margin="24" item-size="64">
    <item id="89" />
</frame>

<item id="89" />

Arch_AWS-Nitro-Enclaves_48

<frame width="220" height="160" margin="24" item-size="64">
    <item id="90" />
</frame>

<item id="90" />

Arch_AWS-Outposts-family_48

<frame width="220" height="160" margin="24" item-size="64">
    <item id="91" />
</frame>

<item id="91" />

Arch_AWS-Outposts-rack_48

<frame width="220" height="160" margin="24" item-size="64">
    <item id="92" />
</frame>

<item id="92" />

Arch_AWS-Outposts-servers_48

<frame width="220" height="160" margin="24" item-size="64">
    <item id="93" />
</frame>

<item id="93" />

Arch_AWS-Parallel-Cluster_48

<frame width="220" height="160" margin="24" item-size="64">
    <item id="94" />
</frame>

<item id="94" />

Arch_AWS-Parallel-Computing-Service_48

<frame width="220" height="160" margin="24" item-size="64">
    <item id="95" />
</frame>

<item id="95" />

Arch_AWS-Serverless-Application-Repository_48

<frame width="220" height="160" margin="24" item-size="64">
    <item id="96" />
</frame>

<item id="96" />

Arch_AWS-SimSpace-Weaver_48

<frame width="220" height="160" margin="24" item-size="64">
    <item id="97" />
</frame>

<item id="97" />

Arch_AWS-Wavelength_48

<frame width="220" height="160" margin="24" item-size="64">
    <item id="98" />
</frame>

<item id="98" />

Arch_Amazon-DCV_48

<frame width="220" height="160" margin="24" item-size="64">
    <item id="99" />
</frame>

<item id="99" />

Arch_Amazon-EC2-Auto-Scaling_48

<frame width="220" height="160" margin="24" item-size="64">
    <item id="100" />
</frame>

<item id="100" />

Arch_Amazon-EC2-Image-Builder_48

<frame width="220" height="160" margin="24" item-size="64">
    <item id="101" />
</frame>

<item id="101" />

Arch_Amazon-EC2_48

<frame width="220" height="160" margin="24" item-size="64">
    <item id="102" />
</frame>

<item id="102" />

Arch_Amazon-Elastic-VMware-Service_48

<frame width="220" height="160" margin="24" item-size="64">
    <item id="103" />
</frame>

<item id="103" />

Arch_Amazon-Lightsail-for-Research_48

<frame width="220" height="160" margin="24" item-size="64">
    <item id="104" />
</frame>

<item id="104" />

Arch_Amazon-Lightsail_48

<frame width="220" height="160" margin="24" item-size="64">
    <item id="105" />
</frame>

<item id="105" />

Arch_Bottlerocket_48

<frame width="220" height="160" margin="24" item-size="64">
    <item id="106" />
</frame>

<item id="106" />

Arch_Elastic-Fabric-Adapter_48

<frame width="220" height="160" margin="24" item-size="64">
    <item id="107" />
</frame>

<item id="107" />