Volume 4: The Document Automation Consultant

Chapter 13: The Platform Has Grown — An Addendum

A Note on Why This Chapter Exists

Chapters 1 through 12 of this book were written as a complete, self-contained whole. Chapter 3 introduced the Trilogy Framework — INPUT, INTELLIGENCE, and OUTPUT — as the three-layer architecture behind every solution you'll build. Chapter 6 described Data Publisher for Word precisely as it existed at the time: a document generation engine, deliberately and specifically the OUTPUT layer, and nothing more. That description was accurate when it was written.

It is no longer the complete picture. Since those chapters were written, the platform has grown a set of reusable building blocks — Capability Packs, Flow Packs, Intelligence Packs, and Data Requests — that give consultants working ways to implement pieces of the INTELLIGENCE and INPUT layers without building them from scratch in every client's data model. Chapter 6's line that the platform is "not... a workflow management system" is one you'll now sometimes need to unsay in a client conversation, because Flow Packs are exactly that, for the specific processes they cover.

Rather than rewrite Chapters 3 and 6 and risk breaking the internal consistency of everything that references them, this addendum stands on its own. Read it after Chapter 6, or read it last — either way, treat it as the current word on what the platform can do, with Chapters 3 and 6 as the enduring word on why the three-layer way of thinking still matters regardless of what implements each layer.

The Framework Held. The Implementation Changed.

Here is the important distinction, stated plainly: the Trilogy Framework from Chapter 3 is not wrong, and it is not obsolete. Every solution you build still has an INPUT layer, an INTELLIGENCE layer, and an OUTPUT layer, and a solution that neglects any of the three is still a solution that underperforms. That diagnostic tool — is the problem in INPUT, INTELLIGENCE, or OUTPUT? — still works exactly as Chapter 3 describes it.

What's changed is who builds each layer's implementation, and out of what. When Chapter 3 and Chapter 6 were written, the INTELLIGENCE layer's four functions — observation, prediction, discovery, action — were something you built yourself, client by client, out of dashboards, calculated fields, and triggered document generation, using the data model design principles in Chapter 6. The INPUT layer's "automated integration" method was, per Chapter 6, "beyond the scope of initial implementations for most clients" — worth naming as a future phase, not something you'd typically deliver.

Both of those statements are now only sometimes true. For a growing number of common functions, the platform ships a pre-built, reusable implementation instead of asking you to build one from your client's raw data model. Knowing what those are, and where the boundary between "the platform already does this" and "you're still building this yourself" currently sits, is now part of scoping an engagement correctly.

Four Kinds of Building Block

The platform's newer architecture organizes reusable functionality into four distinct kinds of pack. They are not four sizes of the same thing — each answers a different question, and (per the platform's own layering discipline) each is meant to stay in its lane rather than duplicate what another layer already owns. If you want the full architectural treatment — including the reasoning for why blurring these boundaries causes real problems at scale — it's covered in depth in Volume 6 of this trilogy. What follows is the practical summary a working consultant needs.

Domain App Packs answer which vertical. A Domain App Pack for Real Estate, Homeschool Co-ops, or Construction Management is the closest thing to what you built by hand in Chapter 4 and Chapter 5: a data schema and template portfolio tuned to one industry's vocabulary. If a Domain App Pack already exists for your client's vertical, it's a starting point that can shortcut the discovery-and-build process this book otherwise walks you through from scratch — though it doesn't replace the domain expertise Chapter 4 describes; you still need to understand the vertical to configure, extend, and sell it well.

Capability Packs answer which reusable function, regardless of vertical. Accounting, membership tracking, notifications, reporting — functions that don't care whether they're invoicing a homeowner or a homeschool family, and that used to mean modeling an Invoice table, a Payment table, and the logic connecting them yourself, for every client, in every vertical, as Chapter 6 describes. A mature Capability Pack means that work has already been done once, correctly, and is available to depend on rather than rebuild. This is the piece that most directly revises Chapter 6's claim that the platform is "not a database" or "not a CRM": pieces of functionality that look like database and CRM functions now exist as productized, reusable modules. The nuance worth keeping, though, is that a Capability Pack is still a single, bounded function — it is not a general-purpose database or CRM your client can reshape however they like. "Not a general database or CRM" survives in spirit even where the literal old sentence no longer holds.

Flow Packs answer what sequence, over what time. This is the layer that most directly contradicts Chapter 6's "not... a workflow management system" line. A Flow Pack orchestrates a defined process — client onboarding, renewal dunning, consent-and-waiver collection — that waits, branches, and resumes over days or weeks, calling into Capability Packs to do the actual work at each step. Where Chapter 6 was written at a time when every workflow you delivered was, in effect, a sequence of separately-triggered document generations that you and the client's team manually kept track of, some of that sequencing can now be a Flow Pack instance instead — visible, logged, and running without a human remembering to trigger the next step.

Intelligence Packs answer what's worth noticing. This is the newest and least-settled of the four kinds — Volume 6 says so about itself, and it's worth repeating here rather than overselling it. An Intelligence Pack doesn't hold data the way a Capability Pack does, and it doesn't run a process the way a Flow Pack does; it watches an observation window across existing data, and when it concludes something worth acting on, it emits an event rather than taking action directly — the actual response still runs through an auditable Flow Pack, or through a human decision. Conceptually, this is the productized version of the discovery and prediction functions from Chapter 3's INTELLIGENCE layer: the pattern-finding you used to build by hand, now available as a reusable watcher for some specific, well-understood situations (subcontractor reliability, renewal risk), with more being added over time.

Data Requests aren't a pack type in the same sense as the three above, but they belong in this list because they revise Chapter 6's INPUT-layer guidance directly. A Data Request is a distributed, trackable link sent to someone outside your client's own team — a customer, a participant, a co-investor — who needs to supply information or a signature. It's the productized version of what Chapter 6 called "automated integration" and treated as a future phase: a structured way to get data in, from people who aren't sitting in front of your client's system, with response tracking built in. Because sending and tracking those links is itself a light communication function, this is the piece that most directly touches Chapter 6's "not... a communication platform" line — though, as with Capability Packs, the nuance matters: a Data Request is a structured data-collection and e-signature-adjacent surface, not a general messaging or CRM communication platform.

What This Means When You're Scoping a Client Engagement

Two practical adjustments follow from all of this.

First, check what already exists before you build it. Chapter 4's five-week domain intelligence process and Chapter 6's data-model-first build sequence are still exactly right for anything the platform doesn't already have a reusable piece for. But before you sketch a data model for accounting, membership, or notifications from scratch, check whether a Capability Pack already covers it. Before you design a manual multi-step follow-up process for onboarding or renewal, check whether a Flow Pack already sequences it. Building from scratch what already exists as a maintained, reusable pack is now the mistake — the platform's own architecture treats unnecessary duplication as a real cost, not a harmless shortcut, and the same logic applies to your time as a consultant.

The same check applies one level up, at the Domain App Pack itself. As of this writing, two of the fifteen verticals in Chapter 5 — Homeschool Co-ops and Real Estate — already have a built-out Domain App Pack: a working data model and template portfolio, forkable at no cost rather than built from a blank page. If your client is in either of those verticals, the weeks Chapter 4 walks you through for domain intelligence acquisition and the data-model-first build sequence in Chapter 6 can often start from that fork instead of from scratch — check the current marketplace catalog before you commit to a from-scratch build. The other thirteen verticals in this book don't have that shortcut yet, but the list of which ones do will only grow; checking before every new engagement is now part of the job, not an edge case.

Second, be honest with yourself — and with clients — about maturity. Not every function has a pack yet, and not every vertical has a Domain App Pack yet. Capability Packs are, as a category, the most mature and the most likely to already exist for a common function. Flow Packs are actively expanding. Intelligence Packs are genuinely early — useful where they exist, but not yet a general answer to "can the system tell me what's about to go wrong," the way this addendum might make it sound if you don't check the current catalog. When you scope an engagement, verify what's actually available for your client's specific need at the time you're proposing it, rather than assuming everything described in this chapter is live everywhere. The honest version of "the platform can do more than document generation now" is "the platform can do more than document generation for a specific and growing list of functions — confirm the list before you promise it."

Updated: What the Platform Does (And Doesn't)

If you want a single paragraph to replace the one in Chapter 6, here it is:

Data Publisher for Word remains, at its center, a document generation engine — the OUTPUT layer of the Trilogy Framework, and still the capability every engagement in this book starts from. What has changed is that the platform now also ships a growing set of reusable, purpose-built modules — Capability Packs for common business functions, Flow Packs for multi-step processes, Intelligence Packs for pattern-watching, and Data Requests for structured external data collection — that implement pieces of the INTELLIGENCE and INPUT layers without requiring you to build them from scratch every time. It is still not a general-purpose database, CRM, or communication platform that your client can reshape into anything they want; it is a deliberately bounded set of well-built pieces, each doing one job, that you assemble into a solution the way Chapter 3 always described — you just no longer have to build every piece of that assembly yourself.

Chapter Summary

  • Chapters 3 and 6 describe the platform accurately as it existed when written; this addendum updates what's changed since without invalidating the framework itself
  • The Trilogy Framework — INPUT, INTELLIGENCE, OUTPUT — still holds as the way to think about any solution; what changed is who implements each layer and out of what
  • Domain App Packs, Capability Packs, Flow Packs, and Intelligence Packs are four distinct kinds of reusable building block, each answering a different question, with Capability Packs the most mature and Intelligence Packs the newest and least-settled
  • Data Requests productize the INPUT layer's external-data-collection function that Chapter 6 treated as a future phase
  • Chapter 6's "what it is not" paragraph is now only partly accurate: pieces of database, CRM, workflow, and communication functionality now exist as bounded, purpose-built packs, even though the platform is still not a general-purpose version of any of those things
  • When scoping an engagement, check what pack-level functionality already exists for your client's specific need before building it from scratch — and confirm current maturity rather than assuming everything here is live for every vertical
  • Volume 6 of this trilogy covers the full architecture — the layering discipline, the reasoning behind it, and worked examples — for readers who want the deeper treatment

Addendum to Chapter 6 | The Document Automation Consultant | datapublisher.io/books