How do you decide whether publishing a scenario suite as the specification of record is worth its cost?

### The decision, framed honestly Publishing a scenario suite as the specification of record is not a technical step — the generator is a day of work. The cost is the *ongoing discipline* it obliges: every scenario has to stay worded for a reader who does not know the codebase, forever, under delivery pressure. That cost is paid by the team on every change. The benefit is paid to somebody else, later, and only if that somebody actually opens the document. A lead's job is to establish that the beneficiary exists before committing the team to the cost. ### Establish the audience first Ask who, concretely, is supposed to read it, and what question they bring. Real answers look like: a support group that needs to know what the system promises before escalating; a compliance or audit function that must show a control is demonstrated; a partner team integrating against your behaviour; a new joiner learning the domain; a product owner checking what was actually agreed. Unreal answers look like "stakeholders" and "the business" with no named person and no recurring question. If no named audience survives the question, the honest conclusion is that the scenarios are still worth having as executable checks, but publishing them as a specification is decoration. That is a perfectly good outcome to argue for, and arguing for it is a stronger interview answer than a reflexive yes. ### Get evidence, then keep getting it Readership is measurable, cheaply and imperfectly: - Access telemetry on the published artefact — unique readers, not page loads, and which pages. - Whether anything links to it: incident write-ups, onboarding material, support runbooks, ticket comments. - Whether questions arriving at the team are ones the document answers. If people keep asking the team what happens on a cache expiry, and the document says, the document is not reaching them. - Direct ask, once or twice a year, of the named audience. Treat all of this as a signal, not a verdict. A low-traffic document consulted twice a year by an auditor may be worth more than a high-traffic one skimmed by nobody with a decision to make. But a document with no readers, no inbound links and no questions answered has failed, and continuing to pay its wording tax is a choice you should make deliberately rather than by inertia. Be candid that the wider claim here is contested. There is no strong published evidence that publishing generated specifications improves outcomes; what exists is practitioner experience. Asserting a benefit number would be inventing one. ### The middle options, which is where most good answers land The choice is not publish-everything or publish-nothing. **Narrow the scope.** Publish only the areas with a real external audience — the regulated flows, the partner-facing contract — and let the rest of the suite be automation the team reads. This collapses most of the wording cost while keeping the benefit where it lands. **Curate a layer above.** Publish a small hand-written index that frames the domain and links into the generated pages. The framing does not have to be generated to be useful; the *behaviour claims* do. **Downgrade the register.** Keep publishing internally for the team and adjacent engineers, drop the obligation that it read as a business document, and stop paying for the translation. **Stop, and say so.** Withdraw the artefact, tell the audience it is gone, and see who complains. That is a real experiment and takes about a month. ### The preconditions worth naming Whichever way the decision goes, some conditions have to hold for publishing to be viable at all: a shared domain vocabulary stable enough that the prose survives a quarter; scenarios written declaratively enough to read as statements about the domain; a named owner for the published artefact, because ownerless artefacts rot; and provenance on the document, so a reader can tell which revision it describes. Without an owner in particular, the decision to publish quietly becomes a decision to publish something misleading eighteen months from now. ### A worked example A four-person team owning a parcel-tracking gateway published their scenario report for two years. Telemetry showed 37 unique readers in the last twelve months, 29 of them in the two weeks around a partner integration, and nothing at all from the support group the artefact was originally justified by. Their conclusion was not "delete it": it was to narrow publication to the partner-facing status and tracking behaviour, drop the business-readable obligation on the internal payment-reconciliation scenarios, and re-check in six months. That is the shape of a good answer — evidence, a narrowed scope, and a date to look again. ### How to answer well Name the audience test first, then the evidence you would gather, then the middle options, then the preconditions. Say explicitly that the generation is cheap and the wording discipline is what costs. Refusing to give a blanket yes or no, and instead describing what you would measure and what you would do with each outcome, is the whole point of the question.