Agree on the data model
before anyone writes the SQL

01 · Movement

Do you know how data moves through your system, and who produces it?

A data flow diagram answers both. It shows who produces data, including people outside the technical system, which process moves or transforms it, and which store keeps it: a table, a cache, a log file, a paper form. Most teams skip this step and draw logic flowcharts, which show decisions, not data.

     ┌─────────────┐
     │ charge card │
     └──────┬──────┘
            │
        approved?
        ┌───┴───┐
     yes│       │no
 ┌──────▼───┐ ┌─▼──────────┐
 │ mark paid│ │ show error │
 └──────────┘ └────────────┘

Read each process as an operation your database must support. Place order takes the customer's order request and product prices and writes sales_order and order_line. That is place_order(), specified before anyone writes the SQL or the code that calls it.

02 · Relationships

Have you ever visualized your entity relationships clearly?

An ER diagram lists every column and buries the relationships under them. ignatius draws the relationships alone: entities by name, joined by the business verbs that relate them. Click an entity to open its columns, keys, example rows, and the reason it exists, then walk the graph to tell the story in a meeting.

---
entity: sales_order
group: sales
pk: [party_id, order_no]
columns:
  party_id:  { type: integer }
  order_no:  { type: integer }
  placed_at: { type: datetime, default: now }
  status:    { type: text, default: open }
examples:
  - { party_id: 2, order_no: 1, status: invoiced }
  - { party_id: 2, order_no: 2, status: open }
  - { party_id: 1, order_no: 1, status: paid }
relationships:
  - target: party
    on: { party_id: party_id }
    predicate:
      fwd: places
      rev: is placed by
---

Cardinality and identifying edges come from the keys, and subtype clusters from the subtypes: block. Nothing is drawn by hand, and saving a file reloads the open browser.

03 · Agents

In the age of AI agents, review the plan first

Agents write schemas faster than anyone can read them, so the review has to happen before the code exists. The model is markdown, so it is the thing you review before you sign off on what the agent builds. The agent reads the same files, and the ignatius-modeling skill writes them one question at a time and validates each one.

# check the model in CI
$ ignatius validate model/
✓ /home/you/shop/model: valid — 11 entities, no findings.

# model with an agent, in Claude Code
> /ignatius-modeling discover
  interviews you about how the business runs,
  then writes the entities and flows

04 · Documentation

The plan becomes the visualization

Everything above comes from one folder of markdown. The same files are your database's documentation and its data dictionary, the place the team plans and shares plans, and the place an agent looks to see what it should build.

05 · Lineage

Built on the shoulders of giants

ignatius is not a new invention. It is a looking glass into excellent standards: IDEF1X for entities, grown out of E. F. Codd's relational model, and SSADM-style data flow diagrams for movement.

Try it

A model in two minutes

curl -fsSL https://noorm.dev/ignatius.sh | sh

name: Shop

---
entity: party
pk: [party_id]
columns:
  party_id: { type: integer }
  name:     { type: text }
---

# party

Anyone who places orders.

ignatius serve model -o

Go deeper

Where to go next