The economics of generated research break the review model that most firms use. Human-written notes are rate-limited by the writing, so a review process that adds an hour per note is absorbed by a production process that took a day. Remove the writing constraint and the review queue becomes the only constraint, at which point one of two things happens: output slows to the old rate, which defeats the purpose, or review degrades into a signature, which is worse than no control because it creates a record of diligence that did not occur.
The way out is not more reviewer hours. It is a workflow that treats different classes of claim differently and puts a named human against each one that leaves the building.
Define the boundary before you design the control
Everything depends on where you draw the line, and most firms draw it too far out. "Leaves the building" is not the moment a note is emailed to a client. It is the moment a claim reaches anyone who will act on it, which includes a portfolio manager inside your own firm.
Two boundaries, then, with different standards. The internal boundary covers anything reaching a decision-maker: the requirement there is traceability, meaning a reader can find out what the claim was based on and who stands behind it. The external boundary covers anything reaching a client or the public: the requirement adds regulatory categorisation, disclosure and record retention, and in most jurisdictions the treatment of a view on a specific security differs from the treatment of a general market comment. Where your firm's line sits is a question for your compliance function and it should be answered before a workflow is built, not after a note has gone out.
The internal boundary is the one people forget. A generated note pasted into a chat with a trader has been published, in every sense that matters when the position is reviewed.
One feed, two kinds of author, identical chrome
The capture shows the problem in its natural habitat. A structured, machine-formatted scorecard sits at the top of the feed under an institutional byline. Scroll down and there are posts from an individual account, in the same card, with the same chrome, one of them offering a directional read on the same scorecard and describing it as barely bullish on the one week, another pointing readers at a different module.
Nothing there is wrong. It is a feed and it contains both kinds of content, which is what a feed is for. The hazard is downstream: once a screenshot or a paste is taken, the visual equivalence travels with it, and the recipient has no way to tell whether they are holding a systematic output or a colleague's aside. Both look like the platform said it.
So the first workflow requirement is a byline discipline your own outputs enforce. Every artifact that can be forwarded states, in its visible body, whether it was machine-generated, machine-generated and human-reviewed, or human-authored, and names the accountable person in the second and third cases. Anything without that label is not cleared to cross either boundary.
Four roles, one of which cannot be delegated to a process
Split the work into four roles. On a small desk one person can hold several of them, but they must be named separately in the record so that later you can see which hat was being worn.
The producer runs the generation and is responsible for the mechanics: the right inputs, the right template version, the disclosure block populated. This role can be almost entirely automated.
The owner is the named human accountable for the content of the claim. This is the role that cannot be automated, cannot be assigned to a team mailbox, and cannot be a systems account. One person, named in the artifact, who is answerable for every assertion in it. If nobody will put their name on a note, the note does not go out, and that test alone removes a surprising amount of marginal content.
The subject reviewer checks the substance: whether the claims follow from the inputs, whether anything material is missing, whether the interpretation is defensible. On tiered content this role is only invoked for higher tiers.
The controls reviewer checks the things that are not about market judgement: disclosure completeness, categorisation, restricted names, conflicts, and language that creates an obligation the firm did not intend. This is a compliance function and it should have a right of veto that does not route through the desk.
Tier the claims so review is proportionate
Reviewing every generated line at the same depth is what causes the process to collapse. Tier by what kind of claim is being made, not by the length of the note.
- Tier zero, state restatement. The note reports the current value or state of a named metric and nothing else. Automated checks plus a sampled human spot check. The controls here are data controls, since the risk is a broken pipeline rather than a bad opinion.
- Tier one, interpretation. The note characterises a state, calls a condition strong or weak, or aggregates metrics into a composite label. Owner review on every note, subject review on a sample.
- Tier two, anything security-specific, forward-looking or actionable. A view on a named instrument, a target, a suggested position or an implied recommendation. Full review by owner, subject reviewer and controls, every time, no exceptions and no sampling.
Two rules keep the tiering honest. Tier is assigned by the content, not by the author's intention, and a single tier two sentence promotes the entire note. And the classifier that assigns tiers is itself subject to review, because a system that can silently downgrade its own output has no control at all. Audit a sample of tier zero and tier one classifications each cycle and treat a misclassification as an incident rather than a correction.
What the reviewer is actually checking
Reviewers drift toward editing prose because that is the visible surface. Give them a checklist that points at the load-bearing parts instead, short enough to be used every time.
Does every claim trace to a named input in the disclosure block, or is there an assertion in the text with nothing behind it. Is the oldest input inside the staleness tolerance for the horizon being discussed, since a monthly view on eight day old data is defensible and a one day view on it is not. Is the coverage statement present and does the claim stay inside that coverage. Are missing values rendered distinctly from neutral ones, so the note is not treating absence as evidence. Is there a stated flip condition for each forward-looking claim. And is the language symmetric, meaning hedges appear on both sides of the view rather than only on the downside.
Anything the reviewer changes goes back as a template or prompt fix, not just as an edit to that note. A reviewer who corrects the same phrasing weekly is doing manual work that a template change would end, and the count of repeat corrections is the most useful quality metric this process produces.
The record, and the retraction path
The output of the workflow is not the note. It is the record, and the record has to answer a specific question a year later: who said this, on what basis, and who checked it.
That means an immutable version of the artifact as published, the disclosure block as it stood at publication, the named owner and reviewers with the timestamp of each sign-off, a diff of what review changed, and the tier assigned with the reason. Exceptions get their own log, including who granted them, because exceptions are where every subsequent inquiry begins.
Then build the path most firms skip: retraction. Generated content goes out in volume, so eventually something goes out that should not have, usually because an input was stale or a row was empty rather than because the model said something outlandish. Decide in advance who can pull a note, how recipients are notified, whether a correction or a withdrawal is issued, and how the incident feeds back into the template. Write it while nothing is on fire. The alternative is deciding all of that in an afternoon, with a client on the phone, using a process nobody has agreed to.