VALUE.md - Industry-Publication Submission (worked example, anonymized)

A complete VALUE.md for another non-software project: a written submission to a trade-industry publication. Anonymized from the field studies. Read in 60 seconds to see the standard applied to a single-decider Q1 - the editor.

Value Statement

The submission gives the publication's section editor a piece that fits her column slot without re-shaping; the editor gives back acceptance with at most line-edit notes, scheduled within four weeks of submission.

Q0: Grounding observation

Reading the publication for three months before drafting, I tracked which submissions cleared editorial and which were sent back. The pattern: pieces that fit the column's existing rhythm cleared with line edits; pieces that required a section restructure were rejected even when the argument was good. The grounding moment was watching a colleague's strong essay get rejected on "doesn't fit the slot." The publication isn't asking for the best essay. It's asking for the best essay this column can run.

Q1: Who it's for?

The section editor who will read the submission Tuesday morning, decide accept / revise / reject by Friday, and either pencil it into a slot in the next six weeks or close the tab. Not "the publication." Not "the readership." One named editor with a deadline and a stack.

Q2: What changes for them?

Before: the editor opens the submission expecting either a piece that fits her column rhythm and ships, or a piece that requires re-architecture and goes to "revise" or "reject." She is reading at speed; she is deciding fast; she has already rejected three submissions this week for slot-fit reasons.

After: the editor reads the submission and recognizes the column's voice and shape immediately - section breaks where her column has section breaks, opening that maps to her column's standard opener, length within her band. She forwards to copy-edit with a one-line note and pencils a publication date.

Q3: How will you know the change happened for them?

The editor's first-pass verdict, with timestamp and verbatim note. Three outcomes:

  1. Accept with line edits - the change happened.
  2. Revise - the change partially happened; whatever revise note returns tells you which gate it missed.
  3. Reject - the change didn't happen.

Breaks if: "revise" returns with notes pointing at fit issues (section structure, length, opening shape) - that means the submission did not actually fit the slot and the writer mis-read the column. If "revise" returns with notes pointing at argument or evidence, the slot-fit goal was met and a different goal was missed.

Check: Field - editor's reply, captured verbatim, logged in audits/q3-acceptance/2026-Q2.md with the fit-issue vs argument-issue tag.

Status: Proposed. Moves to Proven on the editor's first-pass verdict.

Last verified: not yet · Re-verify by: empty (status is not yet Proven)

Promises

P1 - The editor reads the piece in column-rhythm and decides at speed

Status: Proposed · Recipient: the section editor doing first-pass triage Tuesday morning.

Last verified: not yet · Re-verify by: empty (status is not yet Proven)

You open the file, see your column's section structure, recognize your column's opening shape in the first paragraph, and finish the piece in under 12 minutes. You forward it to copy-edit with a one-line note or you send it back. You do not have to re-read it to know which.

Breaks if: the editor's reply mentions re-reading, re-architecting, or "I'm not sure where this would go" - those are speed-of-decision failures.

Check: Field - editor's first-pass timing and verbatim reply. Logged with the submission.

What we don't promise

What we don't break