Build the Thing That Builds the Documents
Some projects come with a lot of paperwork. This one came with close to eighty documents, and more than a hundred once you count every format.
We built a new-hire curriculum for a healthcare revenue cycle company. Their analysts learn to catch billing errors by reading a hospital bill against an insurance statement and a contract, then finding where they don't agree. It's a great skill to teach through practice. It also means every practice case needs its own set of realistic documents.
Building each one by hand would've been slow. Every round of feedback would've sent someone back into dozens of files. So we made a call early on. We built one template for each document type and a small tool to fill them in. It took more time up front, and it paid for itself by module four.
Our client deserves a lot of credit here. They were open to a new way of working from the start, and they trusted us to bring AI and technology into how we built the course. That trust is what let us take this project to the next level.
Darren Rooney on our team built that system with us, and I asked him to write up how it came together. Here's his story.
The Challenge
When the curriculum build I was working on got scoped, the tracker showed ten modules and more waiting behind them. New analysts, learning to work a healthcare claim from the first flag to the final note.
What caught my attention wasn't the lessons. It was the paperwork.
Almost every scenario in that curriculum needed documents. A hospital billing statement. An insurance explanation of benefits. A contract excerpt. A portal where a patient's records live. Not one set of them, either. A different set for every case, in every module, and each one had to hold together internally, because the entire skill we were teaching was reading those documents against each other and finding the place where they disagree.
Rough math on the tracker that day put it near eighty documents, and past a hundred once you counted the formats each one had to exist in.
The Decision
Building a document by hand solves exactly one problem. You finish it, you move to the next one, and the second document costs what the first one cost. So does the fiftieth.
The alternative is to build the document once as a template, with the case-specific details pulled out and left as blanks, and then build a small tool that fills those blanks from a data file and renders the result. That tool is what I called a generator, and there was nothing clever in it. Give it the facts of a case, and it hands back a finished document. Give it fifty cases, and it hands back fifty.
That costs more up front and less every time after.
We chose it early, before the first asset existed, which is the only point at which that choice is still available.
The cost is worth stating plainly, because this is where these stories usually get dishonest. The tooling took about six and a half hours to build, which is roughly eight documents' worth of hand-building time. So it cost more than the first document, and more than the second, and it kept costing until somewhere around the fourth module. If that tracker had shown one module instead of ten, hand-building wins and the generator is a waste of good hours.
How It Works
Everything that holds still becomes the template: the layout, the labels, the headers, the order things appear in. Everything that changes from one case to the next becomes the data. Get the split right and the template never needs touching again.
Once the structure existed, I could hand it to AI tooling as context. What came back wasn't a document. It was data, in a shape the system already knew how to render. The AI was never asked to produce the finished artifact, so it couldn't get the formatting wrong, and it couldn't invent a field, because there was nowhere for one to go.
That division is the part I'd underline. Content is generated. Form is not.
In our case the generators were scripts that plugged the data into templates and output whatever the course needed at that point: PDFs for the documents a learner opens and reads, and interactive HTML, JavaScript, and CSS bundles that got embedded into Storyline. Different formats, same record underneath.
If the word "code" is where you'd normally check out, don't. You don't need to have trained as a developer to build something like this. What it actually asks of you is the ability to describe precisely what you need and why it has to work that way, which is a skill instructional designers already have in quantity. The rest is iteration, and the tooling is endlessly patient with iteration in a way that a colleague you keep interrupting is not.
If you want to try it, start with a document you already rebuild for every project. Something you've made a dozen versions of by hand. Then ask your AI tool of choice something along these lines:
I have a [document type] that I rebuild by hand for every project. I want to split it into a fixed template and a data file. Help me work out which parts stay the same every time and which parts change, propose a JSON structure for the parts that change, and then write me a small script that takes that JSON and outputs the finished document as [PDF / HTML].
Iterate on what comes back until the data looks right, then turn around and put it to the test. And just like that, you're off to the races.
Why It Matters
Rigid structures, with error checking baked in. We added error reporting on purpose, so anything out of scope got flagged before we used it. Data that doesn't fit the structure never becomes a document at all. On our build, where the learner's entire job was spotting discrepancies between documents, an accidental discrepancy wasn't a typo. It was a broken lesson.
The trade cuts both ways, and it's worth being clear about it. A structure that can't produce a random error will reproduce a systematic one perfectly. Get a label wrong in the template, or a rule wrong in the generator, and it's wrong in all eighty documents rather than one. Rigidity doesn't remove mistakes. It changes them from scattered and small to uniform and large, which is a much better trade than it sounds, because uniform mistakes are findable and fixable in one place. It does mean the template deserves more scrutiny than any single document ever did.
Consistency stops depending on anyone remembering. Rules encoded once get applied identically on every run. A person working from a style guide applies it well on a good day and less well at four o'clock on a Friday.
Changes are cheap. Nobody has ever worked with a client who didn't eventually want a document reworked or a mockup adjusted. If the change is to the document, a label, a layout, a field sitting in the wrong place, you fix the template once and rerun the generator. Every document in the course updates together. Built by hand, that's eighty files opened one at a time, and the eightieth gets less attention than the first.
One record can drive many outputs. In our case a patient's visit drove the billing statement, the explanation of benefits, the contract excerpt it got measured against, and the portal view where the record lived. When a scenario needed two of those to disagree, the disagreement was deliberate and lived in one place where it could be verified.
The work compounds. Templates and generators outlive the project that paid for them, and each new variation costs a fraction of the first.
The Results
I went back through the timesheet rather than estimating, because the whole argument rests on the trade being worth it.
Building the generator machinery took about six and a half hours. That was the code that turned data into documents, plus the data contract itself. It excluded designing what the documents looked like, which came to another six and a half hours and would have been spent either way, because a form has to be laid out whether a script fills it or a person does.
Here's what those eight documents' worth of time bought.
The lines cross around the fourth module, then separate for good when a synthesis module lands wanting seventeen documents at once.
Thirty-two documents needed rebuilding over five months. A SME rejected a case on clinical grounds. Names were in the wrong case, dates in the wrong format, revenue lines in the wrong order across a whole set of forms. None of that is failure, it's what review is for.
Roughly 112 documents' worth of effort by hand against 41 generated, with the eight-document build cost still to come off that second number.
The useful skill is recognizing, while the choice is still in front of you, whether you're solving one problem or a hundred of them. Most of the time it's one. But when it's a hundred, the choice to me is clear.
What This Means for You
Most courses don't need a system like this. If you need a job aid and a quiz, we'll build it by hand and call it done. But if your learners practice on realistic materials, like forms, statements, or screens from your own systems, let's count them before we start building. That's when this choice is cheapest to make.
My favorite part is what it does for revisions. Your SMEs are going to catch things in review. That's their job, and it's a good sign. With this setup, we fix it once and every document updates. And when you add modules next year, the templates are already there.
One more thank you to our client. Saying yes to something new takes courage, especially on a big curriculum with a lot riding on it. They gave us room to use AI and technology where it made the course better, and the results speak for themselves. We're grateful for partners like that.
Have a curriculum coming up with a lot of documents in it? We'd love to hear about it.
