The graph format
A project's architecture lives in one authored file, usually architecture/graph.yaml, and an ag.config.json, usually at the repository root, says where it is. Everything AG generates (guidance, indexes, summaries) is derived from that one file.
The smallest complete graph
A graph has a schema version, an ID, a title, a description, nodes and relationships. Every record has a status and a list of references; proposed records may have none. This example passes ag validate; the site build checks it.
schemaVersion: "1"
id: graph:greeter
title: Greeter architecture
description: A command-line greeter. Covers who decides the greeting wording.
nodes:
- id: component:formatter
kind: component
name: Formatter
description: Builds the greeting text from a name and a tone.
status: proposed
references: []
- id: capability:greet
kind: capability
name: Greet a person
description: Produce a greeting for a named person.
status: proposed
references: []
relationships:
- id: relationship:formatter-owns-greet
kind: owns
from: component:formatter
to: capability:greet
description: Wording changes belong in the formatter, not in the interface that prints it.
status: proposed
references: []
Configuration
The configuration names the graph and the folder for generated output. References in the graph are paths relative to the folder that holds the configuration.
{
"configVersion": "1",
"graph": "architecture/graph.yaml",
"generated": "architecture/generated"
}
Contract sidecars
A contract, data_object or artifact node can reference a JSON Schema for its data and example payloads that must match it. Sidecars arrive in the next release. See contract schemas and examples and the specification.
Reference and schemas
- Concepts: what the node and relationship kinds mean.
- Commands and files: every command, file rule and diagnostic.
- Graph JSON Schema and configuration JSON Schema, generated from the toolkit's own definitions.