Three days on our own brand: an email, a page, three buttons, and a record an auditor can read. Including the parts that did not work.
For months, in conversation after conversation, we have come back to the same point: regulated marketing teams do not have a content problem, they have an approval problem. The campaign is not late because nobody can write it. It is late because it is sitting in a queue behind a person who has to read every word as though they had never seen any of it before.
Last week we finally had the whole thing running on ourselves, and then we watched it fail in the one place that mattered.
A word on what was running. Design Catalyst is a brand codified as rules: colour, type, shape and voice in a store that agents read, with a check that refuses to release anything breaking one of them. For a regulated team the same pack carries a claims library beside those rules, one entry per approved claim with its approver, its date, the jurisdiction it holds in and the wording nobody may vary. One switch turns on the part that makes a named person sign before a piece can ship. The switch was the easy half, and it was finished. The person at the end of it was not.
The moment it broke
The mechanism worked. A brief in plain language became a finished page in minutes, on brand, with the approved wording carried through and checked before a person read it. We sent it for review. Our reviewer opened the link.
What they saw was a page of code.
The review was riding on the same machinery software teams use to approve changes, which is an excellent record and a terrible reading experience for someone whose job is marketing approval, not version control. One tab over from the thing we wanted them to read was a wall of diffs. The reviewer’s reaction was the correct one: where is the document, and what am I supposed to do here?
You cannot sell an approval system to a compliance colleague who opens it once and decides it is not for them. So we stopped and rebuilt that end of it.
## What we built, in three days
Three pieces, none of them clever, all of them about the person at the end.
A screen instead of a repository. The reviewer gets one email with one link. The link opens the piece as a page: the approved wording underlined and tagged to the rule it came from, anything claim-shaped that nobody has approved marked for them to decide on, and anything forbidden marked in a way that cannot be missed. Under it, a register of every claim used, with its approver, its dates and the markets it is approved for. At the top, three buttons: approve, ask for a change, comment. They sign in once with their own account and never see a tool again.
A return path that does not need a human relay. When the reviewer asks for a change, in their own words, the system reads what they wrote, makes the change, re-renders what they read, runs the checks again and comes back. If the change touches an approved claim, the library gets a new entry with a new date rather than an edit of the old one, so the previous wording stays readable for anything already published.
A release that produces the thing you actually wanted. Approval is not the end of the process, the file is. On approval the piece is published as a version: the final document, the copy the approver read, the source it was built from, and the record of the checks that ran. The download sits on the same page the reviewer approved from.
The loop, as it actually ran
Our reviewer opened the piece, read it, and typed a sentence asking for a different headline. Two minutes and twenty-two seconds later the revision was back: the headline changed, the checks re-run, the page re-rendered, and a short note explaining what had been changed and what had not. They asked for three more changes over the following hour, including one that broke the layout, which the system noticed and fixed. Then they approved, and the finished document appeared as a version with its record.
Nobody in that loop did anything technical. Nobody opened a terminal. The exchange between the two of them is still there, attached to the piece, which means that in a year the answer to “why does this sentence read like this” is a link rather than a memory.
## What the system caught us doing
This is the part worth writing down, because it is the argument.
Once we put our own approved claims into the library, one of our own habits became a rule violation. We had been saying a page was built “in eleven minutes”, because that is what the recorded build took. The approved claim is “in minutes”, and the stopwatch figure is a forbidden variant of it, precisely so that an accurate number does not quietly become a promise. The check found it in a document we were about to send, and refused the release.
Then it found three colours that were not in our palette, in a file we had just written. One of them we had copied from our own live website, where it had been sitting unruled for months. The system did not care where it came from.
And when we first rendered the reviewer’s page, it rendered a browser error instead of the document, because of a path bug in our own tool. Our reviewer saw it before we did and said so.
None of that is embarrassing. It is the product working. A system that only catches other people’s mistakes is a system nobody should trust.
Why this matters if your wording is regulated
In medical devices, diagnostics, pharma or financial services, nothing in the usual process remembers what was approved last time. Every asset is read as if it were the first, which is why the white paper takes two months and the campaign that should have followed it is never made. The cost is not only the delay. It is the material that is never produced, and the quiet drift of people towards tools nobody sanctioned, because the sanctioned path is the slow one.
Approve once and the wording becomes a rule with an owner and a date. A check reads every sentence before a person does. The reviewer reads what is genuinely new. Every version, check and approval is kept, so the question an auditor asks is answered by reading rather than remembering. And the fast path and the sanctioned path become the same path, which is the only version of this that actually changes behaviour.
## What it is not
The check is mechanical. It proves what is in the library and flags what is not; it does not judge meaning, it does not sign anything, and it makes no claim about any regulator on anyone’s behalf. The reviewer still reads. What disappears is the re-reading.
We also do not hold a security certification, and we do not pretend otherwise. The system installs on your own accounts, introduces no platform of ours, and holds nothing of yours after handover. That is a better answer than a badge, and it is the one your security team can verify.
What is next
Slack and Teams, so the request and the release arrive where people already are rather than in another inbox. Then the same loop on a slide deck and a landing page, because a brochure is the easy case.
If your team makes the same kind of document over and over and waits on the same person to approve it, that is the conversation worth having. The loop described here is part of Design Catalyst. Not a demonstration of our product on your brand, which we could not do honestly before a contract: tell us the piece you make most often, and we will build that one live, in our own brand and on our own approved claims, with the check and the record in view. Codifying yours is the work itself.
Bring the one your reviewer sees every week. We will tell you whether the approval loop is your constraint, or whether the wording upstream of it is, and if it is the latter we will say so.
Book a discovery call → Design Catalyst for regulated teams →
FAQ
Frequently asked questions
Does the reviewer need a developer account?
They sign in once with an account on the code host, because the decision has to be recorded under a real identity rather than an anonymous click. After that they never see it again: the email carries one link, the link opens the piece as a page, and the three buttons are the whole interface. The record lives in a system built for immutable approvals; the reading experience does not.
What happens when the reviewer asks for a change?
They write it in their own words, in the box, the way they would in an email. The system reads what they wrote, makes the change, re-renders the copy they will read, runs the checks again and asks them once more. Nobody relays the message and nobody retypes the piece, which is where the days used to go.
Does this mean the reviewer stops reading?
No, and we would not sell it if it did. The check proves what is already approved and flags what looks like a claim it cannot prove. The reviewer still reads the piece and still signs. What changes is that they spend their attention on what is genuinely new rather than re-reading wording they approved last quarter.
What exactly is recorded?
Each release is a version carrying four things: the final document, the copy the approver actually read, the source it was rendered from, and the checks that passed. Alongside it sits who approved, when, and the rule each approved phrase came from. Two years later, “why does this say that” is answered by opening the version rather than by searching an inbox.
Do we need our brand codified before any of this works?
Yes, and that is the honest order. The loop enforces rules, so the rules have to exist: colour, type, shape, voice, and for a regulated team the approved claims with their owners and dates. Codifying them is the engagement. The approval loop is what you switch on afterwards, and it is worth nothing on its own.
What if our wording is not regulated?
Then you probably do not want this half. The same pack runs without it: the checks still refuse an off-brand release, and a piece publishes the moment they pass, with no reviewer asked. One switch decides which of the two you are running, and a team that does not need a named approver should not be made to carry one.