The Joiner's Pattern Book: Building a Team Catalog

Opening Scene

A serious workshop keeps a pattern book — a physical or shared reference of every proven joint the shop uses, with templates, dimensions, and notes on when each one applies. A new apprentice doesn’t have to rediscover the mortise-and-tenon from first principles or guess at proportions that took generations to refine; they open the book, find the entry that matches their situation, and cut with confidence. The pattern book isn’t a constraint on creativity — it’s what lets the whole shop work from the same proven vocabulary, so a joint cut by one person is trustworthy and recognizable to everyone else who picks up the piece later.

A team’s ER pattern catalog is the same idea, written down for a schema instead of a workshop.

In Plain English

An ER pattern catalog is a shared, documented reference of the entity-relationship patterns a team has agreed to use, each entry explaining what the pattern is, when it genuinely applies, what it looks like in the team’s actual schema conventions, and — just as importantly — when not to reach for it. Rather than every modeler independently rediscovering how to handle a hierarchy, a role-playing entity, or an effective-dated relationship, the catalog gives the whole team a shared vocabulary and a consistent implementation, the same pattern applied recognizably the same way everywhere it’s used.

The Old Way

Before teams treated pattern documentation as a deliberate artifact, consistency depended almost entirely on tribal knowledge:

Pattern knowledge lived in individual modelers’ heads, meaning the same business shape could get modeled three different ways across three different parts of the same schema, depending entirely on who happened to build which part.
New team members learned patterns by osmosis, picking up conventions slowly by reading existing schema and asking around, a slow and inconsistent onboarding path that left plenty of room for subtly incorrect pattern applications to spread.
Documentation, when it existed at all, tended to describe individual tables rather than the reusable patterns behind them, missing the chance to explain why a particular structure was chosen and when a modeler should reach for it again.

Building a genuinely useful pattern catalog has always meant documenting not just what a pattern looks like, but the diagnostic conditions under which it should and shouldn’t be applied.

What’s Changing (and Why AI Is the Reason)

AI coding assistants and schema-drafting tools produce measurably more consistent, correctly applied patterns when a documented pattern catalog is provided as explicit context, rather than being left to infer conventions from scattered existing examples in the codebase — a documented catalog becomes a direct, practical lever for AI output quality, not just a human onboarding aid.
AI-assisted analysis of an existing schema can help draft an initial pattern catalog from scratch, by identifying the patterns already implicitly in use across a legacy schema and surfacing them as candidate catalog entries for a team to review, correct, and formally adopt.
As more schema and code gets AI-generated, a well-maintained pattern catalog becomes the single most leveraged artifact a team can maintain, because every entry it documents correctly is a pattern applied correctly across every future AI-assisted change, while every gap in the catalog is a pattern the AI is left to guess at.

The Metaphor, Fully Extended

Joinery Element	ER Modelling Concept
The shop’s shared pattern book of proven joints	A team’s documented ER pattern catalog
Each entry’s diagram, dimensions, and notes on when to use it	A catalog entry’s structure, examples, and diagnostic conditions for applying it
An apprentice consulting the book instead of guessing	A new team member or an AI assistant consulting the catalog instead of inferring conventions
A joint cut consistently the same way across every piece in the shop	A pattern applied consistently across every part of the schema it appears in
The shop foreman updating the book as new proven techniques are adopted	A team formally reviewing and adding new patterns to the catalog as they’re adopted

For Beginners: What to Actually Do

When you learn a new pattern from this series or elsewhere, write down not just what it looks like but when it genuinely applies and when it doesn’t.
Consult your team’s existing pattern catalog, if one exists, before modeling a new relationship, rather than defaulting to whatever approach feels most familiar to you personally.
Notice when the same business shape is modeled differently in different parts of a schema, and treat that inconsistency as a signal the catalog needs a clearer, more specific entry.
Practice explaining a pattern’s diagnostic conditions to someone else, since the ability to teach it is a good test of whether you genuinely understand when it applies.

For Practitioners and Leaders: The Deeper Layer

Treat the pattern catalog as a living artifact requiring ownership and regular review, not a one-time document written once and left to go stale.
Provide the pattern catalog as explicit context to AI coding assistants and schema-drafting tools, since documented conventions measurably improve the consistency of AI-generated schema work.
Use AI-assisted analysis of your existing schema to draft an initial catalog of patterns already implicitly in use, then have the team formally review and correct it.
Recognize the pattern catalog as an increasingly high-leverage artifact as more schema work becomes AI-assisted, since every well-documented entry compounds in value across every future AI-assisted change.

Quick Recap

An ER pattern catalog is a shared, documented reference of a team’s chosen patterns, the same role a workshop’s pattern book plays for its joiners.
A useful catalog entry documents not just what a pattern looks like, but the diagnostic conditions for when it genuinely applies.
Providing the catalog as explicit context measurably improves the consistency and correctness of AI-generated schema work.
The catalog is a living artifact that compounds in value with ownership and regular review, especially as more schema work becomes AI-assisted.

Where This Fits in the Series

Article 11 covered choosing a pattern that’s appropriately sized to the problem; this article covered documenting those choices for a whole team. Article 13 turns to what happens when an earlier pattern choice, however well-intentioned, turns out to have been the wrong one.