Chapter 1: What Is a Domain Template Package?

"Give someone a document and you help them once. Give them a domain template package and you help everyone in their industry, forever."

The Problem This Book Solves

Every professional organization on earth generates documents. Law firms produce contracts, engagement letters, and case briefs. Homeschool co-ops generate rosters, invoices, progress reports, and permission slips. Real estate offices produce listing presentations, CMAs, and buyer packages. Healthcare practices create consent forms, treatment summaries, and referral letters.

The people who work in these organizations are domain experts. They know their field deeply. What they almost never know is how to turn that domain expertise into a reusable, automated document generation system that other people in their industry can simply download and use.

That is exactly what this book teaches you to build.

A Domain Template Package is a complete, self-contained document automation system for a specific industry or organizational type. It includes everything: the data structure, the sample data, the document templates, the configuration, and the documentation. Someone downloads your package, loads it into Data Publisher for Word, and within minutes they are generating professional documents from their own data — class rosters, family invoices, emergency contact cards, whatever your domain requires.

You build it once. Hundreds or thousands of organizations use it. You decide whether to give it away, sell it, or both. The platform handles the rest.

This book will take you from understanding what a domain package is, to designing one for your industry, to building it, to packaging it for publication. By the time you finish, you will have a production-ready domain template package and the knowledge to build as many more as you like.

Before We Begin: The Intellectual Foundation

This book is Volume 5 of the Building Intelligent Systems series. It is intentionally practical and technical — a builder's guide, not a philosophy text. But if you want to understand why document automation matters at a deep organizational level, why certain document types exist, and how human knowledge becomes machine-readable data, the earlier volumes are your foundation:

• Volume 1 — Domain-Specific Document Automation — The output layer. How expertise crystallizes into documents.
• Volume 2 — Organizational Intelligence Platforms — The intelligence layer. How systems observe, learn, predict, and act.
• Volume 3 — Human-System Collaboration — The input layer. How human knowledge becomes structured data.
• Volume 4 — The Consultant's Handbook — The business layer. How to build a practice and recurring revenue on this platform.

You do not need to have read those volumes to use this book. Everything you need to build a domain package is here. But if you find yourself asking "why does this work the way it does?" or "how do I design documents that truly serve an organization?", those volumes will give you answers that go far deeper than any technical guide can.

Throughout this book, where relevant, we will point you to specific sections of the earlier volumes rather than repeat what has already been said well.

The Anatomy of a Domain Template Package

A domain template package is a folder. Inside that folder is a precise, standardized structure that Data Publisher knows how to read, validate, and load. Every domain — whether it serves a homeschool co-op, a law firm, or a nonprofit — follows the same structure.

Here is what that structure looks like:

DataPublisher_DomainTemplates/your-domain/
│
├── domain-config.json          ← The brain: metadata, tables, template definitions
├── README.md                   ← The face: user-facing documentation
│
├── csv-data/                   ← The body: sample data that makes it real
│   ├── primary-entity.csv
│   ├── secondary-entity.csv
│   └── ... (7–12 tables typical)
│
├── word-templates/             ← The hands: the documents that get generated
│   ├── Template-01-Name.docx
│   ├── Template-01-Name.json
│   ├── Template-02-Name.docx
│   ├── Template-02-Name.json
│   └── TEMPLATE_INDEX.json
│
└── docs/                       ← The memory: reference documentation
    ├── SCHEMA_REFERENCE.md
    └── DATA_SOURCES_INTEGRATION.md

Each of these components has a specific role. Understanding what each one does — and why it must exist — is the foundation for building a domain package that works reliably and that other people can actually use.

domain-config.json — The Brain

This is the most important file in your domain package. It is the configuration manifest that tells Data Publisher everything it needs to know about your domain: what it is called, what tables it contains, how those tables relate to each other, and what document templates are available.

When the Data Publisher server starts, it automatically scans for domain folders and reads each domain-config.json. If yours is valid, your domain appears in the interface immediately. No registration, no manual setup. The file speaks for itself.

A domain config has three major sections:

Domain Metadata — The identity of your domain. Its ID (machine-readable), its name (human-readable), a description, the industry category it belongs to, and a version number. This is what the marketplace shows when someone is browsing available domains.

Table Definitions — A complete description of your data structure. Every CSV table in your domain is listed here, with its column names, primary key, and foreign key relationships to other tables. This is how Data Publisher understands the shape of your data before a single record is loaded.

Document Type Definitions — The catalog of all 20 document templates your domain provides. Each entry names the template, describes what it produces, specifies its complexity level, and maps it to the primary and related tables it draws data from.

A well-written domain config is about 350–400 lines. It is the entire contract between your domain package and the platform.

csv-data/ — The Body

Your sample data is not an afterthought. It is one of the most strategically important parts of your domain package, for reasons that go beyond mere demonstration.

When someone downloads your domain and loads it into Data Publisher, the first thing they will do is generate a document using your sample data. That document is their first impression of everything you have built. If the data is generic — "Student 1," "Property A," "Client Name Here" — the document looks like a prototype. If the data is rich, realistic, and recognizable, the document looks like something their organization could actually use today.

Realistic sample data does three things:

First, it makes templates immediately demonstrable. A homeschool co-op coordinator who sees a class roster with real-sounding student names, actual class subjects, and plausible family names immediately understands what the system does. She does not have to imagine it.

Second, it validates your data architecture. Real-world scenarios stress-test your foreign key relationships in ways that abstract test data never will. If your sample data covers all the edge cases — a student enrolled in multiple classes, a family with multiple children, a class with no enrolled students yet — your templates will handle those cases correctly when real data arrives.

Third, it serves as the implicit documentation of your data model. A user who opens your CSV files and sees realistic records immediately understands what kind of data belongs in each field. You have taught them how to use your domain without writing a single instruction.

The SchoolCoop domain — our production reference implementation, which we will study in depth in Chapter 2 — contains 15 CSV tables and over 350 individual records, including 25 students, 19 parents, 13 teachers, 19 classes, and 120 enrollment relationships. Every record has a realistic name, a plausible address, a believable scenario. It took time to create, and that investment pays back every time someone downloads the domain and immediately sees what it can do.

word-templates/ — The Hands

The Word templates are what the user actually sees when they use your domain. They are the output — the physical documents that Data Publisher generates when a user selects a template and clicks Run.

Each template is a .docx file containing placeholder syntax that Data Publisher knows how to fill in. A field like <<students.StudentFirstName>> becomes the actual first name from your data. A loop like {{ForEach:enrollments}} iterates over every record in the enrollments table, generating one document section per record. Conditional expressions like {{IF HasAllergies=Yes}} include or exclude content based on data values.

Alongside each .docx template is a .json metadata file with the same base name. This file stores display information about the template — its name, description, which CSV files it uses — so the interface can present it correctly without having to parse the Word document itself.

A 20-template domain is the standard. Not 5, not 50 — 20. This number is not arbitrary. Twenty templates is enough to cover the full operational life of most organizations without becoming redundant or overwhelming. It is enough to demonstrate genuine depth and earn a purchase price. It is small enough to be maintainable and comprehensible.

Here is the most important fact about Word template creation in this system: you do not create them manually. Manual template creation — opening Word, formatting a document, inserting placeholders one by one — takes 2 to 4 hours per template. For 20 templates, that is 40 to 80 hours of tedious, error-prone work.

Instead, you write a JavaScript generator script that creates all 20 templates programmatically. The script runs in just a few minutes. The templates are consistent, correctly formatted, and immediately ready to use. The difference between 80 hours and a few minutes is not a productivity improvement — it is a category change that makes domain creation accessible to people who are not professional developers.

Chapter 5 covers the generator script in complete detail.

README.md — The Face

Your README is not developer documentation. It is a sales document and a user guide rolled into one. It is what a potential buyer reads to decide whether to download your domain. It is what a new user reads to understand how to get started. It is what a confused user consults when something does not work as expected.

A great domain README does all of these things:

It opens with a compelling overview that names the target user, describes their problem, and explains how this domain solves it — in plain language, in three sentences or fewer. It then provides a quick-start guide that gets someone from download to first generated document in under five minutes. It documents all 20 templates with clear descriptions of what each one produces and when you would use it. It explains the data structure in terms users understand, not developers. It includes troubleshooting for the most common problems. It closes with customization guidance so advanced users know how to make the domain their own.

The README you write before you publish is the README that users will read at 11pm when they are trying to get something done before tomorrow morning. Write it for that person.

docs/ — The Memory

The docs/ folder contains supplementary reference documentation that does not belong in the main README but that serious users will eventually need. Typically this means a schema reference (every table, every column, every data type, every foreign key, explained in depth) and a data sources integration guide (how to replace the sample CSV data with a real data source — a Google Sheet via OAuth2, an Excel 365 workbook via Microsoft Graph, or a SQL Server connection with authentication).

The data sources integration guide should walk users through OAuth2 authorization flows step-by-step: where to click "Connect Google Sheets," what Google's permission dialog looks like, how to select the right spreadsheet, and how to map sheets to tables. Include screenshots. Document exact column name requirements. List the 5 most common OAuth troubleshooting issues and their solutions. Chapter 4.7 covers OAuth authentication in depth — use it as a reference for what to document.

These documents are less urgent than the README for initial publication, but they are what separates a professional domain package from an amateur one. Users who grow into advanced usage will find them invaluable. They also demonstrate that you thought through the full lifecycle of the domain, not just the happy path.

How the Platform Discovers Your Domain

One of the most elegant aspects of the Data Publisher domain architecture is automatic discovery. You do not register your domain with the platform. You do not run a setup script. You do not configure anything manually.

You put your domain folder in the right place, and the platform finds it.

When the Data Publisher backend server starts, its domain service scans the DataPublisher_DomainTemplates/ directory. For every subfolder it finds, it looks for a domain-config.json. If the file exists and is valid, that domain is loaded and made available through the API. If it is missing or malformed, that domain is skipped with an error logged — it does not break anything else.

This means that adding a new domain to the platform is as simple as dropping a folder. And it means that the marketplace submission process is, at its core, a validation that your domain folder is correct and complete. Meet the standard, and you are live.

The API endpoints that expose your domain are:

GET  /api/domains                        List all available domains
GET  /api/domains/:id/config             Get full domain configuration
GET  /api/domains/:id/templates          List all 20 templates
POST /api/domains/:id/generate           Generate a document
POST /api/domains/:id/preview            Preview data before generating

These endpoints are what the Word add-in calls when a user selects your domain, browses your templates, and clicks Run. Your domain-config.json and your Word templates are the entire interface between what you built and what the user experiences.

The Time Investment, Honestly

Building a domain template package from scratch, done well, takes 11 to 15 hours. Here is where that time goes:

The largest single time investment is the one that feels most invisible: designing realistic sample data. This is not glamorous work, but it is the work that determines whether your domain feels real or feels like a prototype. It is worth every hour you put into it.

The generator script — which we cover fully in Chapter 5 — is what makes the template creation phase a few minutes instead of 40 to 80 hours. That single innovation is what makes building domain packages viable as a business. Without programmatic template generation, the economics do not work. With it, you can build a new domain in a weekend, publish it to the marketplace, and have it generating revenue before the following weekend.

What SchoolCoop Teaches Us

Throughout this book, we will return again and again to the SchoolCoop domain — the complete, production-grade homeschool co-op management domain that ships with Data Publisher as the reference implementation.

SchoolCoop is not a simple example. It is a genuinely complex domain with 15 CSV tables, 25 students, 19 parents across 12 families, 13 teachers, 19 class offerings, 120 enrollment relationships, and 20 document templates covering everything from class rosters and family invoices to field trip permission slips and volunteer schedules. Every design decision in SchoolCoop was made deliberately, and understanding why those decisions were made will teach you more about domain design than any abstract explanation can.

Chapter 2 is entirely devoted to SchoolCoop — not as a tutorial to be followed, but as an architecture to be understood. When you finish Chapter 2, you will be able to look at any organizational domain and see it the way SchoolCoop is structured: as entities, relationships, documents, and data flows. That mental model is the most valuable thing this book can give you.

Your Domain Is Someone's Business System

Before we move on, let us be direct about what you are building and why it matters.

The organizations that will use your domain template package are real organizations with real operational needs. A homeschool co-op coordinator who downloads a well-built co-op domain does not have to spend 40 hours building a document automation system from scratch. A small law firm that finds a legal services domain in the marketplace gets professional contract automation that previously would have required either expensive software or expensive developer time. A nonprofit that discovers your volunteer management domain can generate donor acknowledgment letters, board reports, and grant summaries without hiring anyone.

You are not selling a software product in the abstract sense. You are selling time back to people who are doing important work and do not have enough of it.

That is worth building well. That is worth the 15 hours it takes to do it right. And that is worth the $10 a month that keeps the platform running so you can keep building and they can keep using what you built.

The rest of this book will show you exactly how.

Chapter Summary

A domain template package is a self-contained folder containing five components: a domain-config.json configuration manifest, a csv-data/ directory of realistic sample data, a word-templates/ directory of 20 programmatically generated Word templates, a README.md user guide, and a docs/ directory of reference documentation.

The platform discovers domains automatically at startup. A valid domain folder in the right location becomes immediately available through the API with no registration or manual configuration required.

Building a complete domain takes 11 to 15 hours. The generator script — covered in Chapter 5 — reduces template creation from 40 to 80 hours down to a few minutes, which is what makes the domain template business model economically viable.

SchoolCoop is the production reference implementation. It is the gold standard against which all new domains should be measured, and studying it in depth is the fastest path to understanding how to build your own.

What's Next

In Chapter 2, we go deep inside SchoolCoop — every table, every relationship, every design decision. By the time you finish Chapter 2, you will understand not just what SchoolCoop contains, but why it was built the way it was. That understanding is the foundation for everything that comes after.

Volume 5 — Building Intelligent Systems: Building Organizational Knowledge Systems on Data Publisher for Word Part of the Building Intelligent Systems Series