Generating content faster does not fix this. It produces more of it, with the same gaps, at greater volume.
Efficiency comes from smarter decisions, not faster generation. So the decisions move to the front, and everything downstream inherits them.
Decide once, carry it down
One approved claim goes in, and it never moves alone. An assignment arrives in plain language and runs through eight stages grouped under three questions: what do we know, what are we making, how do we make it well. The part that matters is what travels between them.
What it taught me
- Governance belongs before generation. Rules, sources and permissions established at intake mean nothing gets produced that review was always going to reject. Most tools apply the rules at the end, which is the expensive place to find them.
- The bundle is the right unit, not the asset. Planning one asset at a time is exactly how a qualifier ends up in the email and missing from the banner.
- People resolve ambiguity, the system carries the answer. When a reviewer settles something it becomes available to the next assignment, rather than evaporating into a comment thread.
On what’s shown here. The engine was built for a live pharmaceutical program in a rare disease, so almost none of that work can be discussed. What is shown is a client- and agency-independent fork built for this purpose, with a fictional prescription brand called Aster in a public, source-backed context. Every strategy and product detail in it is synthetic and disclosed as such inside the frame. No client, product, molecule or performance figure appears above. The transferable part is the stage model and the claim object.
Built in vanilla JavaScript, no dependencies.
Talk to the site
Ask it what this page left out.
A voice assistant runs on every page here. It reads a handful of files I wrote by hand, it won’t pretend to be me, and there’s a written list of things it refuses to discuss. Client specifics are on that list.
Needs a microphone.
