The Business View

This page contains no commands, no file names and no technology. It is here so that somebody deciding whether to fund this can read one page and stop, and so that a business analyst can take a figure from it into a review meeting without translating anything first.

Everything in it is drawn from the same material as the rest of the document. Nothing has been softened for the audience.

What you actually get

FIGURE B1 — Four answers in. Drafts, a record, and a handover out. Read left to right. The left column is the whole of what we need from you; it is listed again at the end of the summary.

The first outcome on the right is the one you asked for: an article waiting each morning, written from what your chosen sources published, with its sources attached.

The other three are what you own afterwards, and they are the reason to do it this way rather than by conversation. A written answer to "why is it like that." A handover that does not depend on the people who built it. A change that costs an edit rather than a rebuild. None of the three is visible on the day the pipeline goes live, and all three are what you are actually buying.

Avoid: reading the middle column as the deliverable. Half of it — everything agreed and written down before the build — is gone the day the build finishes. The half that remains is the half that runs every morning, and it does not need us, a coding agent, or spec-kit to keep running.

Who does what, and when

The question that stalls proposals is not what the thing does. It is how much of your people's time it takes, and at which points.

FIGURE B2 — What we need from you, and when we need it. Read across a lane to see one role's whole commitment. Dashed empty cells are the moments where nothing is needed from that lane.

Before the build, you owe a conversation about what this must never do — about an hour — and four answers, each asked one at a time with a recommendation attached. That is the entire demand on the owner's calendar.

After it, you owe one review a morning, by an editor, which is the job an editor already does. Nobody is on call at dawn and nobody types a prompt.

The bottom lane is two different jobs, not one. The AI that helps build this is gone the day the build finishes. The AI that writes each morning's draft is the only part still running, and it cannot publish — it can only file a draft. Conflating those two is the most common reason a business reader over-estimates the risk here.

Assumption — the document establishes four roles: you as the owner, your editors, the build team, and the AI. If you have a business analyst, they sit in the top lane alongside the owner — that is where the four answers and the five rules get settled.

Four jobs a person does today

FIGURE B3 — Four jobs a person does today. Three of them stop. The upper band is drawn from the reasons the user stories in section 2.3 give, not from an audit of your current process. Correct it if it is wrong — it is one sentence in the specification.

Checking the sources, judging what matters and writing from a blank page are labour. The fourth job — deciding whether this is fit to publish — is judgement, and it is the only one the design will not remove.

That is not a limitation of the automation. It is what makes automating the other three safe. A system that removed the fourth job as well would be a system that could publish something wrong before anyone read it, and no efficiency argument survives that happening once.

What it costs, and when it pays back

FIGURE B4 — Slower to the first one. Faster to the tenth. The amber strip is deliberately vague. The draft asserts that the lanes cross; it does not claim to know at which change, and neither should anyone reading it.

There is no money figure on that page because there is none in this proposal. The only quantities committed to anywhere in this document are an hour on the rules, an hour or two on the specification and clarification, and a fortnight of review to tune the house style. A payback figure would have been invented, and an invented number is the fastest way to lose the argument the first time somebody checks it.

The real cost is not on the left-hand card. It is the habit of amending what the thing is meant to do rather than the thing itself. That habit is free to acquire and easy to abandon, and abandoning it is what turns this back into the upper lane.

What could go wrong, and what stops it

This is the figure to take into a risk review.

FIGURE B5 — Six ways this could go wrong, and what stops each. The left column is what a business reader is afraid of. The five checks in the amber strip are set out in full in section 2.9.

Read the middle column as a promise and the right-hand column as where to go and check the promise was kept. None of these is a dashboard bolted on afterwards — each was agreed before the build, which is why it constrains what gets built rather than reporting on what got built.

Row four is worth a second look, because it is the one nobody asks about in advance. A pipeline that silently stops is worse than one that visibly breaks: the drafts simply stop arriving, everyone assumes it is a quiet news fortnight, and nobody investigates. That gap — between "the filing step failed" and "the run failed" — was found by a read-only check before anything was built. It cost one extra task. Found in production, it costs a fortnight of nobody noticing.

The top row is the only one that cannot be traded away. The other five can be changed, in writing, dated, with a name against the change.

The decisions you own

FIGURE B6 — Eight decisions that are yours, and what each changes. The four in the summary plus the four settled in section 2.4. Read the last column first if you are deciding whether to disagree.

Three rows are still open and need you: which sources, what the drafts should sound like, and who makes changes after it goes live. Everything else has a proposed answer with a reason attached, and every one of them is a single amendment away from being something else.

Read the fourth column first. Most of those consequences are stated somewhere in this document already, but scattered across four sections and three code blocks, so no reader ever sees them as one list. Seeing them as one list is the point: it makes the ask finite, and it makes disagreeing cheap.

The one row that is different. Row five — draft, or straight to live — reads like a configuration detail and is in fact the decision that determines whether this is a tool your editors use or a system that can publish something wrong before anyone reads it. It is settled as draft, always. Reversing it is your call to make, but it should be made deliberately and in writing, because it removes the control every other row depends on.

---