The Business View

This page contains no commands and no technology. It is for deciding whether this is worth doing, and what you are committing to if it is. Everything on it is drawn from the same proposal as the rest of the section — nothing here is a separate, softer story told to a different audience.

What you actually get

FIGURE 2 — Four answers in. A record, a routine, 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.

Three of the four things on the right are ordinary. A draft waiting each morning, its sources attached, and a system somebody else can pick up.

The third one is the one that is hard to buy any other way. Most software arrives with a description of what it was supposed to do, written before it was built, and diverging from the truth from the first week. Here the description is updated by the act of finishing each piece of work — not by somebody remembering to update a document.

Assumption — the value of that third row depends entirely on whether your team keeps using the method after we hand over. If the next change is made by opening the code and editing it, the specifications become fiction within a quarter. That risk is real, it is yours, and it is set out plainly in day two.

Who does what, and when

FIGURE 3 — 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.

The only real commitment of your time is the first column. About an hour, in which you say what this system must never do and we write it down. Everything after that is reading something or approving something.

Your editors are asked for two things. One page of house style near the start, and one honest opinion near the end — whether a real generated draft is something they would have published. Then ten to twenty minutes each morning, which is a job they already do.

Nobody operates this daily. There is no console to watch and no AI engineer on call. The two purple cells in FIGURE 3 are not the same agent doing the same job: one plans and writes code once, supervised, and the other writes an article every morning into a draft nobody but a person can publish.

Four jobs a person does today

The pipeline takes over three of them:

• Checking six sites every morning to see whether anything happened. This stops.
• Reading what was published and deciding what is connected to what. This stops in its current form — the AI proposes the connection and an editor judges it.
• Writing a first draft from scratch. This stops. The job becomes correcting rather than composing.
• Deciding what is worth publishing, and publishing it. This does not stop, and this proposal is built so that it cannot.

That last line is the design, not a limitation of it. The upper band of FIGURE 4 is drawn from the reasons the user stories give, not from an audit of your current process. Correct it if it is wrong — it is one sentence in the specification.

What could go wrong, and what stops it

FIGURE 4 — 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 applying and archiving.

Read the middle column as a promise and the right-hand column as the file you open to 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 it.

The one row that is different. Risk 1 — something wrong gets published and is already public — is the only control that cannot be traded away in this design. It is not a configuration flag somebody could turn off in a hurry. It is written as a requirement with a testable scenario against it, and both the validator and the archive step refuse a change that would remove it. Reversing it is an argument somebody has to win in writing.

What it costs, and when it pays back

There is no money figure on this page because there is none in this proposal. 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.

What can be said honestly:

The one-off cost is an hour of your time, a page of house style from an editor, and the build itself. The recurring cost is your AI assistant's usage — the same cost whether or not OpenSpec is involved — and the editing time your team already spends.

The overhead OpenSpec adds is roughly ten extra minutes per change: writing the change down instead of editing the code directly. On the first change that is pure cost. Somewhere between the third and the tenth change it stops being cost, because the alternative — re-deriving what the system does from the code — starts taking longer than reading the specification.

Nobody can tell you where that crossover lands for your team, and this document does not pretend to. What it can tell you is which direction each line runs.

The decisions you own

FIGURE 5 — Eight decisions that are yours, and what each one changes. The four in the summary plus the four settled during the worked example. Read the last column first if you are deciding whether to disagree.

Every row in the middle column is an assumption, not a finding. Each one is a single edit if you disagree, and the right-hand column says what that edit costs. Nothing here is expensive to change before the build; several become expensive afterwards.

Row three is the only one that is not really a decision. Articles are filed as drafts and a person publishes them. That is a rule, and reversing it should be an argument somebody wins in writing rather than a setting somebody flips.

Avoid: treating the eight rows as a form to fill in. Four of them we need from you before anything starts; the other four were settled during a conversation with the coding agent, and are recorded so that you can disagree with them later on the record rather than discovering them in the code.

---