The operating model

Work selection

Which work belongs in a workflow

Automating the wrong activity produces more of something nobody wanted, faster. Selection comes first, and it is a judgement about the work, not about the technology.

• What makes work suitable

  The work repeats, the inputs are written down somewhere a person could point at, and there is an agreed way to tell a good output from a bad one. Content production against approved messaging qualifies. A quarterly narrative for the board does not, because the inputs are half in somebody's head.

• What stays human-owned

  Anything that sets direction or accepts risk: positioning, pricing, what the company claims about itself, which customer to name, and the final approval before something reaches a customer or a platform. The map names these explicitly, so the boundary is written down and not assumed.

• Why some work should not be automated

  Some work is how people in the team learn. A junior who never writes a first draft never develops the judgement to review one. Some work is too rare to be worth the maintenance a workflow costs. Both are reasons to leave it alone, and both are decisions the team makes with the map in front of it.

Inputs

What a workflow is allowed to start from

A workflow is only as trustworthy as the material it is allowed to read. The rule is that everything it starts from is approved, versioned and findable by a person.

• Approved source material

  Signed product messaging, the positioning it came from, the claims register, brand and voice rules, and the instruction files that say how the team does each job. In the system this is drawn from, one shared workspace is the single source of truth and every instruction file is versioned.

• The claims register

  One list of the numbers and factual claims the company is willing to stand behind, each with its source and the date it was checked. It is the only place a workflow may take a number from. A figure that is not in the register does not go in the draft.

• When something is missing or contradictory

  The workflow stops and asks rather than filling the gap. A missing claim, two versions of the messaging, or an instruction file that contradicts the brand rules are all conditions that halt the work and put it in front of the named owner. Guessing at this step is what produces confident, wrong copy.

Execution

What runs, and what each part is for

The models draft and compare, ordinary software moves the work between stages and enforces the rules, and people make the decisions. Keeping those three jobs separate is most of what makes the result auditable.

• What the models do

  Drafting, restructuring, summarising, and reviewing each other. A second model races the lead draft so there is something to compare against, and a third reads the result adversarially. The drafting model is recused from reviewing its own output, because a model asked to mark its own work marks it well.

• What ordinary software does

  Holding the files, versioning the instructions, moving a draft between stages, and refusing to advance anything that has not passed the stage before it. None of this needs a model, and all of it is what makes a workflow repeatable instead of a conversation somebody had once.

• How context survives the handoffs

  Each stage passes on the approved inputs it started from alongside its own output, so the reviewing stage can check the draft against the same messaging the drafting stage used. A stage that receives only the previous stage's prose has no way to catch a claim that drifted.

Quality and decisions

What is checked, by what, and who signs

Three different kinds of check, doing three different jobs. The mistake is to treat a model review as though it were the last one.

• Checked mechanically

  Whether every number in the draft appears in the claims register, whether required fields are present, whether links resolve, whether the instruction file used was the current version, and whether the piece matches the structure its template requires. These are pass or fail and they need no judgement.

• Checked by a model, which is not enough on its own

  Tone, whether the argument holds, whether a claim is supported by the material it cites, and whether the piece reads as machine-written. A model is useful here and unreliable as the last word, because it will approve a fluent piece that is subtly wrong about the product.

• Decided by a named person

  Anything customer-facing is approved by a person before it ships, and that person is named in the decision rights rather than being whoever is free. In the advertising work, that approval is a human gate that sits between the creative stage and any ad account, so nothing reaches a platform without it.

• When a workflow is not sure

  Uncertain output stops at the stage that produced it and is queued for the owner instead of being passed on with a caveat. A workflow that ships its own doubts trains the team to ignore the warnings.

Ongoing ownership

Keeping it working after the handover

A workflow is a thing that decays. Model behaviour changes, the product changes, and the person who built it leaves. The model is designed around that rather than against it.

• Who maintains what

  Each workflow has one named owner inside the team, responsible for its instruction files and for the integrations it depends on. Ownership sits with a role, not with an individual, so it survives somebody moving on.

• How changes are reviewed

  Instruction files are versioned, so a change is a visible edit, not a new prompt somebody pasted in. A changed workflow is run against a small set of known inputs before it goes back into use, and the outputs are compared with the previous version.

• Noticing that quality has slipped

  The team keeps a handful of examples of good output and re-runs them on a regular cadence. Slippage shows up as a drift from those, which is a much earlier signal than someone eventually complaining about the copy.

• Running it without the person who built it

  The test is that somebody other than the builder can run the workflow from the documentation alone. That is a check in the handover, not a claim about it: see the handover section of the engagement page.

Worked example · built and running

From approved messaging to a published piece

This is the content pipeline in the register below, described step by step. It runs today inside one B2B SaaS marketing team. It is the clearest example of every rule on this page doing its job at once.

1. 01

   Signed messaging goes in

   The workflow starts from approved product messaging and the claims register, both held in the single source of truth. No brief is written from memory.

2. 02

   A lead draft, and a rival

   One model produces the lead draft against the versioned instruction file for that kind of piece. A second model drafts the same brief independently, so there is a genuine comparison rather than one draft and an opinion.

3. 03

   A third model red-teams it

   A separate model reads the chosen draft adversarially, looking for claims that are not in the register, arguments that do not hold and passages that read as machine-written. The drafting model takes no part in this step.

4. 04

   The mechanical checks run

   Every number is matched against the claims register, the instruction file version is confirmed as current, and the piece is checked against the structure its template requires.

5. 05

   A person signs it off

   A named approver reads the result and either approves it or sends it back with the reason. Nothing reaches a customer without this step, and a piece sent back re-enters at the stage that caused the problem.

6. 06

   It ships, and the workflow is the record

   The published piece, the inputs it came from and the version of the instruction file that produced it stay together, so a question about a claim six months later has an answer. A monthly newsletter is produced end to end this way through one versioned instruction file.

What an engagement delivers is a workflow of this shape, built around your team's own messaging, tools and approvers. The steps above are the pattern that has been built once, not a result that has been delivered to a Northbound client.

What has been built, and where each piece stands

Every system below was built inside one B2B SaaS marketing team and is described at the level of how it works. The status labels are current and have not been rounded up. They are the source material the model was derived from, not a list of Northbound client deployments.

What this looks like as a piece of work

Installing the model is a mapped, built and transferred engagement with a defined end. The stages, what each one asks of your team, and what handover means are on the engagement page.