Graph Engineering — The Complete Guide

Beginner

A deep dive into Graph Engineering: what graphs are in software systems, when and how to use them (graph databases, graph algorithms, knowledge graphs, graph neural networks), with rich code examples and ASCII diagrams for your documentation.

📑 Table of Contents

What is a Graph?
What is Graph Engineering?
Where Graphs Appear in Software
When to Use Graph Engineering
When NOT to Use Graphs
The Four Pillars of Graph Engineering
Pillar 1 — Graph Data Modeling
Pillar 2 — Graph Databases
Pillar 3 — Graph Algorithms
Pillar 4 — Graph-Powered ML (GNNs)
End-to-End Code Example: Social Network
Common Pitfalls & Best Practices
Quick Reference Cheat Sheet

🧠 What is a Graph?

A graph is a data structure made of two things:

Vertices (Nodes) — the entities (people, pages, devices, cities, accounts).
Edges (Relationships) — the connections between them (friend-of, follows, owns, routed-through).

Visual

text

        (Alice)────friend────(Bob)
           │                    │
        manages              follows
           │                    │
           ▼                    ▼
        (Acme Inc)         (Carol)

Formally: G = (V, E) where V is the set of nodes and E is the set of edges. Edges may be directed (follows), undirected (friend), or weighted (cost, distance).

Why care?

Real-world data is inherently connected — friends, transactions, dependencies, roads, citations, references. Trying to model this in tables leads to expensive JOINs and unreadable schemas. Graphs make relationships first-class citizens.

🛠️ What is Graph Engineering?

Graph Engineering is the discipline of designing, building, and operating software systems whose core abstraction is the graph. It spans four interlocking concerns:

text

   ┌──────────────────────────────────────────────────────────┐
   │                  GRAPH ENGINEERING                       │
   ├──────────────┬──────────────┬──────────────┬─────────────┤
   │  Modeling    │  Storage     │  Algorithms  │  ML         │
   │  (schema)    │  (DBs)       │  (BFS, Pager)│  (GNNs)     │
   │              │              │              │             │
   │  How do I    │  Where do    │  How do I    │  How do I   │
   │  describe    │  I store     │  I traverse  │  I learn    │
   │  the graph?  │  it?         │  and analyze?│  over it?   │
   └──────────────┴──────────────┴──────────────┴─────────────┘

Unlike "graph theory" (the math), Graph Engineering is the applied discipline: picking the right tools, modeling the domain, choosing traversal strategies, scaling the storage, and shipping it in production.

🌍 Where Graphs Appear in Software

Domain	Nodes	Edges
Social networks	Users, posts, pages	Friend, likes, comments
E-commerce recommendations	Products, users	Bought, viewed, similar-to
Fraud detection	Accounts, cards, devices	Transferred-to, shares-IP
Routing & maps	Intersections, cities	Roads, flights
Knowledge graphs (search)	Entities, concepts	"is-a", "part-of", "born-in"
Dependency analysis (DevOps)	Services, packages	Calls, depends-on
Authorization (IAM/AuthZ)	Users, roles, resources	Can-access
Code analysis	Functions, files	Imports, calls
Microservices topology	Services	gRPC/HTTP calls
AI / Retrieval-Augmented Gen	Chunks, entities	Mentions, similar-to

If your domain has lots of "who/what is connected to whom/what", graphs belong in your toolbox.

✅ When to Use Graph Engineering

Use Graph Engineering when at least one of these holds:

Relationships are first-class — friend graphs, org charts, call graphs, supply chains.
You need multi-hop traversal — "friends of friends of friends who like X".
The data is highly relational and sparse — JOINs explode or return mostly NULL.
The schema evolves around relationships — you frequently add new edge types.
You need path / centrality / community analysis — shortest path, PageRank, Louvain.
You need flexible, schema-light modeling — no rigid foreign-key cascades.
You are building AI applications on connected data — knowledge graphs, GraphRAG, GNNs.

Concrete triggers

"My SQL query is 14 JOINs deep and still slow."
"I need to find shortest path between two accounts."
"I want to recommend 'people you may know'."
"I need to detect fraud rings (cycles, fan-out)."
"I want to navigate a knowledge base semantically and structurally."

❌ When NOT to Use Graphs

Graphs are not a silver bullet. Avoid when:

Data is flat and tabular (logs, time-series, OLAP cubes).
You mostly do aggregate scans (sums, averages across millions of rows).
The relationship topology is static and tiny (a config file of parent→child fields).
You require strict ACID transactions across thousands of rows — use a relational DB.
Your team has no experience with graph thinking and the dataset is small enough that a relational schema works fine.

Rule of thumb: if a 3-table JOIN answers your query, you don't need a graph DB. If a 10-table JOIN answers it, you probably do.

🏛️ The Four Pillars of Graph Engineering

text

                  ┌──────────────────────┐
                  │   Your Application   │
                  └──────────┬───────────┘
                             │
        ┌────────────────────┼────────────────────┐
        │                    │                    │
        ▼                    ▼                    ▼
   PILLAR 1            PILLAR 2             PILLAR 3/4
   Modeling            Storage              Algorithms/ML
   (what nodes/        (Neo4j, Arango,      (BFS, Dijkstra,
    edges exist?)       Neptune, Memgraph)   PageRank, GNN)

Let's explore each.

🧩 Pillar 1 — Graph Data Modeling

The Labeled Property Graph (LPG) model

The de-facto industry model:

text

   (:Person {name, age})    ← Node with labels + properties
        │
        ▼
   -[:FRIEND {since: 2018}]->   ← Directed edge with type + properties
        │
        ▼
   (:Person {name})

Nodes have one or more labels (:Person, :Company).
Edges have exactly one type (FRIEND, OWNS).
Both nodes and edges can carry properties (key/value pairs).

Property Graph vs RDF

Aspect	LPG (Neo4j, etc.)	RDF (SPARQL, OWL)
Schema	Flexible, schemaless	Strict, ontology-based
Identity	Internal IDs	Global URIs
Best for	App data, OLTP	Knowledge bases, Linked Open Data
Query lang	Cypher / GQL	SPARQL
Inference	Limited	Strong (reasoners)

For most application backends, LPG is simpler and faster.

Example model — E-commerce

text

   (:Customer {id, name}) -[:PLACED]-> (:Order {id, date})
                                   -[:CONTAINS]-> (:Product {sku, name, price})
   (:Product) -[:BELONGS_TO]-> (:Category)
   (:Customer) -[:VIEWED]-> (:Product)
   (:Customer) -[:WROTE]-> (:Review {stars, text}) -[:ABOUT]-> (:Product)

This captures a recommendation-ready graph in a form SQL would need 6+ tables to express.

🗄️ Pillar 2 — Graph Databases

When to pick what

Need	Pick
Most popular, great tooling, OLTP	Neo4j
Real-time analytics, fast ingest	Memgraph / NebulaGraph
AWS-native, managed	Neptune
Polyglot persistence (graph + doc + KV)	ArangoDB
Massive scale, distributed	JanusGraph / NebulaGraph
Linked Open Data, reasoning	Stardog / GraphDB

Cypher query language (Neo4j) — quick tour

cypher

-- Find friends of friends of Alice who are not already her friends
MATCH (alice:Person {name: 'Alice'})-[:FRIEND]->(:Person)-[:FRIEND]->(fof:Person)
WHERE NOT (alice)-[:FRIEND]->(fof) AND fof <> alice
RETURN DISTINCT fof.name
LIMIT 10;

-- Shortest path between two accounts (fraud investigation)
MATCH p = shortestPath(
  (a:Account {id: 'A1'})-[:TRANSFER*..6]-(b:Account {id: 'A99'})
)
RETURN p;

-- Recommendation: products co-purchased with items Alice bought
MATCH (alice:Person {name: 'Alice'})-[:PLACED]->(:Order)-[:CONTAINS]->(p:Product)
MATCH (p)<-[:CONTAINS]-(other:Order)-[:CONTAINS]->(rec:Product)
WHERE NOT (alice)-[:PLACED]->(:Order)-[:CONTAINS]->(rec)
RETURN rec.name, count(*) AS score
ORDER BY score DESC LIMIT 5;

The pattern is declarative: you describe the shape of the answer, not the join order. The query planner uses index-free adjacency to hop the graph efficiently.

🧮 Pillar 3 — Graph Algorithms

Even if you don't store data in a graph DB, you can apply graph algorithms on top of any data structure. Categories:

1. Traversal & search

BFS / DFS — reachability, connected components.
Dijkstra / A* — shortest path with weights.
Bidirectional BFS — faster path finding in social networks.

2. Centrality (who is important?)

Degree centrality — how many direct connections.
Betweenness centrality — how often a node is on shortest paths.
PageRank — recursive importance (used by Google Search).
Eigenvector / Katz — variants.

3. Community detection

Louvain — modularity-based clustering.
Label Propagation — fast, scalable.
Connected components — basic disjoint sets.

4. Link prediction & similarity

Jaccard / Adamic-Adar — common neighbors scoring.
Node2Vec / DeepWalk — learned embeddings.
GraphSAGE / GAT — graph neural networks.

Where they run

Library	Language	Best for
NetworkX	Python	Prototyping, education, small graphs
igraph	Python/R/C	Medium graphs, fast
Neo4j GDS	Cypher+Java	Production-scale in-DB algorithms
GraphFrames / GraphX	Scala	Spark ecosystem, distributed
DGL / PyG	Python	Graph neural networks
cuGraph (RAPIDS)	Python/CUDA	GPU-accelerated

🤖 Pillar 4 — Graph-Powered ML (GNNs)

Graph Neural Networks (GNNs) generalize deep learning to graph data. Each node gets a vector embedding learned by message passing with its neighbors.

text

   Layer k:   node v aggregates messages from neighbors N(v)
              h_v^(k+1) = UPDATE(h_v^k, AGGREGATE({h_u^k : u ∈ N(v)}))

After K layers, each node embedding reflects its K-hop neighborhood.

Popular architectures:

GCN (Kipf & Welling) — spectral, simple baseline.
GraphSAGE — inductive, samples neighbors, great for large graphs.
GAT — uses attention weights on neighbors.
GNN for recommendations (PinSage at Pinterest).

GNNs shine on:

Fraud detection (anomalous subgraph patterns).
Drug discovery (molecular graphs).
Recommendation (user–item bipartite graphs).
Traffic forecasting (road graph + time series).

This example walks through all four pillars in a single Python script using NetworkX, with a small custom graph DB layer so you see how traversal works at a low level. Then we run PageRank and a friend-of-friend recommender.

Step 1 — Model the graph

python

# graph_engineering_demo.py
from __future__ import annotations
from dataclasses import dataclass, field
from collections import defaultdict, deque
from typing import Dict, List, Set, Tuple
import math
import textwrap

# ──────────────────────────────────────────────────────────────
# PILLAR 1: A tiny labeled-property-graph "database" in memory
# ──────────────────────────────────────────────────────────────
@dataclass
class Node:
    id: str
    label: str                          # e.g. "Person"
    props: Dict[str, object] = field(default_factory=dict)

@dataclass
class Edge:
    src: str
    dst: str
    type: str                           # e.g. "FRIEND"
    props: Dict[str, object] = field(default_factory=dict)

class Graph:
    """A minimalist LPG store with index-free adjacency."""
    def __init__(self) -> None:
        self.nodes: Dict[str, Node] = {}
        self.out: Dict[str, List[Edge]] = defaultdict(list)   # adjacency list out
        self.in_: Dict[str, List[Edge]] = defaultdict(list)   # adjacency list in

    # ---- writes ------------------------------------------------
    def add_node(self, id: str, label: str, **props) -> Node:
        self.nodes[id] = Node(id, label, props)
        return self.nodes[id]

    def add_edge(self, src: str, dst: str, type_: str, **props) -> Edge:
        e = Edge(src, dst, type_, props)
        self.out[src].append(e)
        self.in_[dst].append(e)
        return e

    # ---- reads -------------------------------------------------
    def neighbors_out(self, id: str, type_: str | None = None) -> List[Node]:
        return [
            self.nodes[e.dst] for e in self.out[id]
            if type_ is None or e.type == type_
        ]

    def neighbors_in(self, id: str, type_: str | None = None) -> List[Node]:
        return [
            self.nodes[e.src] for e in self.in_[id]
            if type_ is None or e.type == type_
        ]

# ──────────────────────────────────────────────────────────────
# Build a sample social network
# ──────────────────────────────────────────────────────────────
g = Graph()
people = ["Alice", "Bob", "Carol", "Dan", "Eve", "Frank", "Grace", "Heidi"]
for p in people:
    g.add_node(p, "Person", name=p)

friendships = [
    ("Alice", "Bob"), ("Alice", "Carol"), ("Bob", "Dan"),
    ("Carol", "Dan"), ("Dan", "Eve"), ("Eve", "Frank"),
    ("Frank", "Grace"), ("Grace", "Heidi"), ("Heidi", "Alice"),
    ("Bob", "Eve"), ("Carol", "Frank"),
]
for s, d in friendships:
    g.add_edge(s, d, "FRIEND", since=2018)

Step 2 — Traversal (Pillar 3: BFS)

python

# ──────────────────────────────────────────────────────────────
# PILLAR 3: Graph algorithms
# ──────────────────────────────────────────────────────────────
def bfs(g: Graph, start: str) -> List[str]:
    """Breadth-first traversal — reachability + level order."""
    seen: Set[str] = {start}
    q: deque[str] = deque([start])
    order: List[str] = []
    while q:
        u = q.popleft()
        order.append(u)
        for v in g.neighbors_out(u, "FRIEND"):
            if v.id not in seen:
                seen.add(v.id); q.append(v.id)
    return order

print("Reachable from Alice:", bfs(g, "Alice"))
# ['Alice', 'Bob', 'Carol', 'Heidi', 'Dan', 'Eve', 'Frank', 'Grace']

Step 3 — PageRank (importance)

python

def pagerank(g: Graph, damping: float = 0.85, iters: int = 40) -> Dict[str, float]:
    """Classic PageRank over the undirected FRIEND graph."""
    nodes = list(g.nodes)
    N = len(nodes)
    pr = {n: 1.0 / N for n in nodes}

    # undirected adjacency
    adj: Dict[str, List[str]] = {n: [] for n in nodes}
    for e in [e for outs in g.out.values() for e in outs]:
        adj[e.src].append(e.dst)
        adj[e.dst].append(e.src)

    for _ in range(iters):
        new = {}
        for n in nodes:
            rank_sum = sum(pr[m] / len(adj[m]) for m in adj[n] if adj[m])
            new[n] = (1 - damping) / N + damping * rank_sum
        pr = new
    return pr

pr = pagerank(g)
for person, score in sorted(pr.items(), key=lambda x: -x[1]):
    print(f"  {person:<7} {score:.4f}")

Expected output (Dan / Eve / Frank sit on multiple paths):

text

  Dan     0.1722
  Eve     0.1593
  Frank   0.1531
  Alice   0.1305
  Bob     0.1230
  ...

Step 4 — "People You May Know" (friend-of-friend + scoring)

python

def recommend_friends(g: Graph, user: str, k: int = 3) -> List[Tuple[str, int]]:
    """Friend-of-friend recommendations ranked by mutual-friend count."""
    direct = {n.id for n in g.neighbors_out(user, "FRIEND")}
    direct.add(user)
    scores: Dict[str, int] = defaultdict(int)

    for f in direct - {user}:
        for fof in g.neighbors_out(f, "FRIEND"):
            if fof not in direct:
                scores[fof] += 1   # +1 for each mutual friend

    return sorted(scores.items(), key=lambda x: (-x[1], x[0]))[:k]

print("\nFriend suggestions for Heidi:", recommend_friends(g, "Heidi", 3))
# [('Bob', 2), ('Carol', 2), ('Dan', 2)]  ← Bob & Carol share Alice + Eve paths

Step 5 — Visualize the graph

python

def ascii_graph(g: Graph, center: str, radius: int = 2) -> str:
    """Tiny ASCII rendering up to `radius` hops from `center`."""
    levels: List[Set[str]] = [{center}]
    seen: Set[str] = {center}
    frontier = {center}
    for _ in range(radius):
        nxt = set()
        for u in frontier:
            for v in g.neighbors_out(u, "FRIEND"):
                if v.id not in seen:
                    seen.add(v.id); nxt.add(v.id)
        if not nxt: break
        levels.append(nxt); frontier = nxt

    lines = [f"  {center}"]
    for i, layer in enumerate(levels[1:], start=1):
        prefix = "  " + ("│   " * (i - 1)) + "├── "
        names = ", ".join(sorted(layer))
        lines.append(f"{prefix}{names}")
    return "\n".join(lines)

print("\nNeighborhood around Alice (2 hops):")
print(ascii_graph(g, "Alice", radius=2))

Output (illustrative):

text

  Alice
  ├── Bob, Carol, Heidi
  │   ├── Dan, Eve
  │   │   ├── Frank
  │   │   │   ├── Grace

Step 6 (Bonus) — Using a real graph DB (Neo4j + Python driver)

For production, swap the in-memory Graph for Neo4j. Same modeling, same Cypher, just persistent and distributed.

python

# pip install neo4j
from neo4j import GraphDatabase

URI = "bolt://localhost:7687"
AUTH = ("neo4j", "password")
driver = GraphDatabase.driver(URI, auth=AUTH)

def add_friends(tx, a: str, b: str):
    tx.run(
        "MERGE (p1:Person {name:$a}) "
        "MERGE (p2:Person {name:$b}) "
        "MERGE (p1)-[:FRIEND]->(p2)",
        a=a, b=b,
    )

def suggest(tx, user: str, k: int = 5):
    return tx.run(
        """
        MATCH (u:Person {name:$u})-[:FRIEND]->(f)-[:FRIEND]->(rec)
        WHERE NOT (u)-[:FRIEND]->(rec) AND rec.name <> u.name
        RETURN rec.name AS suggestion, count(f) AS mutual
        ORDER BY mutual DESC LIMIT $k
        """, u=user, k=k,
    ).data()

with driver.session() as s:
    for s_, d_ in friendships:
        s.execute_write(add_friends, s_, d_)
    print(s.execute_read(suggest, "Alice"))

This is the same algorithm as the in-memory version, but now it survives restarts, scales to billions of nodes, and uses server-side indexes.

🧱 Common Pitfalls & Best Practices

Pitfalls

Super-nodes — a celebrity with 50M followers. They break traversals and PageRank. Use degree bucketing or fan-out limits.
Unbounded traversals — MATCH (n)-[*]->(m) without a hop limit can explode. Always bound hops: [*..6].
Confusing storage choice — using a graph DB as a generic KV store. Use the right tool for the job.
Ignoring indexing — even in graph DBs, label+property indexes matter for entry-point lookups.
Modeling everything as a node — sometimes a property on an edge is enough.
Not modeling direction — :FRIEND is usually undirected, but if you only store one direction, traversals miss half the graph.
Forgetting write patterns — graph DBs are great at reads, but heavy bulk writes may need batch import (LOAD CSV, neo4j-admin import).

Best Practices

Bound your traversals — always specify a max hop count.
Denormalize when read-heavy — duplicate edges to make hot paths one hop.
Profile with EXPLAIN — graph planners are smart but not magic.
Version your schema — graph models evolve; track label/edge-type additions like code.
Hybrid architectures are fine — relational for transactions, graph for relationships, vector DB for similarity. This is the "polyglot persistence" pattern.
Test with realistic graphs — use tools like networkx.gnp_random_graph or snap.stanford.edu datasets.
Combine with vector search — modern GraphRAG pipelines use both graph traversal AND vector embeddings.

📋 Quick Reference Cheat Sheet

Decision flow

text

                  ┌─ Is your data primarily relational?
                  │
        YES ──────┼────────────► Use a relational DB.
                  │              Stop here.
                  │
        NO ───────┤
                  │
                  ├─ Do you need multi-hop traversal, path
                  │  finding, or pattern matching across
                  │  connected data?
                  │
                  │       YES ──► Use a graph database.
                  │              (Neo4j / Memgraph / Neptune)
                  │
                  └─ Do you need ML on the graph?
                          YES ──► Use a GNN library.
                                   (DGL / PyG)

One-liner per pillar

Pillar	One-liner
Modeling	Nodes + labeled edges + properties (LPG).
Storage	Neo4j / Memgraph / Neptune / ArangoDB for OLTP graphs.
Algorithms	BFS, Dijkstra, PageRank, Louvain via NetworkX / GDS / igraph.
ML	GNNs (GCN, GraphSAGE, GAT) for learning over graphs.

Tooling at a glance

text

   ┌──────────────┬──────────────────┬──────────────────┐
   │  Layer       │  Tool            │  When             │
   ├──────────────┼──────────────────┼──────────────────┤
   │  Modeling    │  draw.io / yEd   │  Design schemas   │
   │  OLTP store  │  Neo4j           │  Most apps        │
   │  Scale store │  NebulaGraph     │  Billions edges   │
   │  Managed     │  Neptune         │  AWS workloads    │
   │  Algorithms  │  Neo4j GDS       │  In-DB analytics  │
   │  Algorithms  │  NetworkX        │  Prototyping      │
   │  GNNs        │  PyTorch Geo     │  ML on graphs     │
   │  Viz         │  Cytoscape / Gephi│  Exploration      │
   └──────────────┴──────────────────┴──────────────────┘

When-to-use summary

Use a graph when…	Don't when…
Relationships are first-class and query-heavy	Data is tabular / time-series
You need multi-hop traversal efficiently	Queries are simple aggregates
Schema evolves around new edge types	Team lacks graph experience on small data
You need path-finding, centrality, or community detection	You need strict OLAP cubes
You are building GraphRAG / GNN / recommendation systems	Single-machine RDBMS already fits

🎯 TL;DR

Graph Engineering = model your world as nodes + edges → store it in a graph-aware system → traverse & analyze it with proven algorithms → learn over it with GNNs when needed. Reach for it the moment relationships dominate your queries, and you'll trade hundreds of lines of brittle JOINs for a few expressive lines of Cypher or GQL — backed by indexes that actually understand "friend-of-friend".

Happy graph building! 🌐

Graph Engineering — The Complete Guide ​

📑 Table of Contents ​

🧠 What is a Graph? ​

Visual ​

Why care? ​

🛠️ What is Graph Engineering? ​

🌍 Where Graphs Appear in Software ​

✅ When to Use Graph Engineering ​

Concrete triggers ​

❌ When NOT to Use Graphs ​

🏛️ The Four Pillars of Graph Engineering ​

🧩 Pillar 1 — Graph Data Modeling ​

The Labeled Property Graph (LPG) model ​

Property Graph vs RDF ​

Example model — E-commerce ​

🗄️ Pillar 2 — Graph Databases ​

Categories ​

When to pick what ​

Cypher query language (Neo4j) — quick tour ​

🧮 Pillar 3 — Graph Algorithms ​

1. Traversal & search ​

2. Centrality (who is important?) ​

3. Community detection ​

4. Link prediction & similarity ​

Where they run ​

🤖 Pillar 4 — Graph-Powered ML (GNNs) ​

🧪 End-to-End Code Example: Social Network ​

Step 1 — Model the graph ​

Step 2 — Traversal (Pillar 3: BFS) ​

Step 3 — PageRank (importance) ​

Step 4 — "People You May Know" (friend-of-friend + scoring) ​

Step 5 — Visualize the graph ​

Step 6 (Bonus) — Using a real graph DB (Neo4j + Python driver) ​

🧱 Common Pitfalls & Best Practices ​

Pitfalls ​

Best Practices ​

📋 Quick Reference Cheat Sheet ​

Decision flow ​

One-liner per pillar ​

Tooling at a glance ​

When-to-use summary ​

🎯 TL;DR ​

Graph Engineering — The Complete Guide

📑 Table of Contents

🧠 What is a Graph?

Visual

Why care?

🛠️ What is Graph Engineering?

🌍 Where Graphs Appear in Software

✅ When to Use Graph Engineering

Concrete triggers

❌ When NOT to Use Graphs

🏛️ The Four Pillars of Graph Engineering

🧩 Pillar 1 — Graph Data Modeling

The Labeled Property Graph (LPG) model

Property Graph vs RDF

Example model — E-commerce

🗄️ Pillar 2 — Graph Databases

Categories

When to pick what

Cypher query language (Neo4j) — quick tour

🧮 Pillar 3 — Graph Algorithms

1. Traversal & search

2. Centrality (who is important?)

3. Community detection

4. Link prediction & similarity

Where they run

🤖 Pillar 4 — Graph-Powered ML (GNNs)

🧪 End-to-End Code Example: Social Network

Step 1 — Model the graph

Step 2 — Traversal (Pillar 3: BFS)

Step 3 — PageRank (importance)

Step 4 — "People You May Know" (friend-of-friend + scoring)

Step 5 — Visualize the graph

Step 6 (Bonus) — Using a real graph DB (Neo4j + Python driver)

🧱 Common Pitfalls & Best Practices

Pitfalls

Best Practices

📋 Quick Reference Cheat Sheet

Decision flow

One-liner per pillar

Tooling at a glance

When-to-use summary

🎯 TL;DR