An analyst firm founded in the nineteen sixties, with more than two thousand people across dozens of offices, publishing thousands of pieces of research a year. The process that governed each one lived in spreadsheets and email. Who was writing it, who still had to review it, whether the review had come back, and how many days were left before publication were all things you found out by asking somebody.
The headcount and the founding year are third-party reported, in the firm's home-city newspaper, January 2026. We deliberately do not quote the firm's own analyst or country counts, because it publishes two different numbers for each. The table and row counts are counted from the delivered platform.
A production platform rather than a workflow. A shared base holds the tables every kind of research needs, and each format gets its own document that reads from the base and adds only what is specific to it. That is what makes it a platform: the second format costs a fraction of the first.
The piece Jon built is the task engine. Templates produce the actual tasks for each piece of research, tasks nest inside each other, and only the ones at the bottom carry an owner, a deadline and a service level. A parent's date is whatever its latest child says it is. A rejected review does not just reopen: it creates a fix task and a fresh review task, so the second look is scheduled rather than remembered.
The clock runs in both directions. Dates are set backwards from the publication month, so the first task's deadline is publication minus every allowance in the chain added up. Then they are recalculated forwards from each actual completion, so finishing early moves everything after it. Days are business days, set on the template rather than typed in.
The gate is what makes it real. The button to the next stage stays disabled until the current person's tasks for the current stage are done. Progress is something you earn by finishing work, and there is no dropdown that says otherwise.
Three checks run inside the workflow, each one Claude with extended thinking. The first validates the market segments against the editorial rules and offers a rewrite a button can apply. The second reads every company named in the research and flags the ones that have been acquired, merged, ceased trading, or do not belong in that segment at all. The third checks the summary for compliance and for consistency against segments that were already approved. What the checks are allowed to say lives in a settings table, so the client changes the behaviour without anyone touching a formula.
The interesting part of this system is not the task list. It is that nobody sets a due date, and every due date is right.
| Check | State |
|---|---|
| Lead analyst assigned | Pass |
| Peer reviewer, where required | Pass |
| Publication month is in the future | Pass |
| Agrees with the edition it replaces | Needs a look |
Somebody says this piece of research publishes in November. That is the only date a person types anywhere in the process.
A checklist runs immediately: is there a lead analyst, is there a peer reviewer where the format needs one, is the publication month actually in the future, and does this piece agree with the one it supersedes. Any of those failing stops the piece here rather than three weeks later.
Each format has a template describing the work it takes. The template is a blueprint; the tasks are instances of it, created for this specific piece of research.
Tasks nest. A grouping task holds the real work underneath it, and only the leaves carry an owner, a deadline and an allowance in business days.
Add up every allowance in the chain, subtract it from the publication date, and that is when the first task is due. Every task after it follows from there.
Days are business days. A four day allowance starting on a Thursday is due the following Wednesday, and nobody has to work that out.
| Task | Was due | Now due |
|---|---|---|
| Define the segments | 26 Sep | Done 24 Sep |
| Name the companies | 2 Oct | 30 Sep |
| Draft | 9 Oct | 7 Oct |
| Peer review | 15 Oct | 13 Oct |
The moment a task is marked done, every date downstream is recalculated from the day it actually finished rather than the day it was supposed to.
So a piece that runs ahead stays ahead, and a piece that slips shows the slip immediately in every date after it rather than at the end.
Every market segment is validated against the editorial rules: it needs a definition, the definition has a length limit, and the structure has a depth limit.
Errors and questionable cases come back separately, because they need different things from the analyst. Where the check can suggest a fix, a button applies it.
| Company | Finding | State |
|---|---|---|
| A named vendor | Acquired, 2025 | Replace or note |
| A named vendor | Merged into a parent | Check the name |
| A named vendor | Belongs in an adjacent segment | Move |
| A named vendor | Appears twice in this landscape | Duplicate |
A landscape naming a hundred and fifty companies is only right on the day it is written. Companies get acquired, merge, stop trading, or turn out to belong in a different segment.
This is the only check that catches any of that. Counting rules cannot: a segment with the required number of companies in it passes every count and can still name a firm that was bought eighteen months ago.
Only the problems surface. An analyst reads a short list of things to look at rather than a hundred and fifty rows of confirmation.
// The next-stage button is enabled only when this is empty.
openTasks = tasks.filter(t =>
t.stage === currentStage
&& t.assignee === currentUser
&& t.status !== 'Done'
)
// Note what is absent: there is no status field on the
// research itself. Its stage is derived from its tasks,
// so nobody can move a piece forward by saying it moved.The button to advance stays disabled until every task assigned to the person pressing it, for the stage they are in, is done.
There is no status field to set by hand, which means the state of a piece of research is always a fact about completed work rather than somebody's opinion of it.
The workflow the firm had written down as a process document became the thing the software actually enforces. A piece of research cannot skip a review, cannot lose a deadline, and cannot publish naming a company that stopped existing. The nine hundred and thirty three rows of historical research the firm already had were migrated in, so the new system opened with the archive already in it rather than empty.
The process and field counts are counted from the platform's own definition files. The migration figures are counted from the extracted data: 222 historical documents yielding 34,904 company mentions across 11,619 distinct names, reconciled down to the rows that were loaded. The task engine was verified end to end three separate times before handover.
This page once carried claims that described the work inaccurately. They came down in an audit of our own copy, and each one went back up only when its numbers could be traced to something measured. A case study you cannot check is worth nothing to you, and one that turns out to be wrong costs us more than it ever earned.