Skip to content

Product Requirements Document (PRD #3) - “Publish Means Publish (Not Oops)”

1. What Was Going On

With PRD #1 and PRD #2 approved, the organisation could now:

  • run scoring without Jim
  • review results before making them official

That solved who could run scoring and how results were checked.

What it didn’t solve was the most dangerous moment in the entire workflow:

publication.

Once results are published, they are visible, trusted, and very difficult to walk back. Historically, publishing had been treated as “the last step of scoring” rather than a deliberate business action.

That assumption needed to die.

2. The Conversation That Triggered This Step

The trigger question was simple and unsettling:

“Who is actually allowed to publish results?”

The answers were… vague.

  • “Whoever runs scoring.”
  • “Usually Jim.”
  • “We’d know if it was wrong.”

None of these were controls.

The follow-up question landed harder:

“If the wrong results go live, who approved that decision?”

That question forced PRD #3.

3. The Artifact

Below is the Product Requirements Document for Outcome 3, exactly as produced.

No automation fantasies. No UI sketches. Just business intent.

# Product Requirements Document (PRD)

## 1. Outcome Reference
**Outcome Name:** Controlled publishing with audit trail  
**Initiative:** Season Scoring Risk Reduction  
**Problem Summary:** Scoring results are published without clear authorization or a durable record of who approved the publication.

---

## 2. Business Objective
Ensure that publishing scoring results is a deliberate, authorized business action with a clear audit trail, reducing the risk of accidental or unauthorized publication.

---

## 3. Detailed Business Requirements
- Only authorized business roles may publish scoring results
- Publishing must require an explicit action distinct from scoring execution
- Each publication event must be recorded with user, date, and time
- The business must be able to review historical publication records

---

## 4. Business Workflow (Refined)
1. Staged scoring results are confirmed as ready for publication
2. An authorized user initiates a publish action
3. The system validates publishing authorization
4. Results are published
5. The publication event is recorded for audit purposes

---

## 5. Roles & Permissions
- **Role:** Publishing Operator  
  **Responsibilities:** Initiate and confirm publication of scoring results

- **Role:** Operations Administrator  
  **Responsibilities:** Define publishing permissions and review publication history

---

## 6. Constraints & Policies
- Publishing actions must be clearly distinguishable from scoring execution
- Publication records must be immutable
- Publication must occur within approved operational windows

---

## 7. Assumptions
- Publishing authority is granted to a limited set of users
- Publishing may occur only after scoring and review steps are complete

---

## 8. Acceptance Criteria
- Results cannot be published by unauthorized users
- Every publication has a corresponding audit record
- Accidental or duplicate publication is prevented

---

## 9. Open Questions
- Can publication be reversed once executed?
- What constitutes an emergency publication scenario?

4. What Almost Went Wrong

Several people attempted to treat publishing as a checkbox.

  • “Isn’t publish just the last step?”
  • “Do we really need to separate this?”
  • “Can’t we just trust the operator?”

All of those arguments were rejected.

Publishing is not a technical event. It is a business commitment.

5. The Decision

Decision Question Are publishing authority and auditability sufficiently defined to design a controlled release mechanism?

Decision Made Proceed.

Why This Was Good Enough

The PRD:

  • made publication intentional
  • separated execution from approval
  • defined accountability without prescribing tools

That was the goal.

6. What This Unlocked (And What It Didn’t)

Now Allowed

  • Design controlled publishing workflows
  • Define domain concepts for publication events

Still Not Allowed

  • Designing UI flows
  • Implementing approval chains
  • Automating publication timing

Those decisions come later.

7. Why This Step Matters

Most operational failures don’t happen during processing.

They happen at the moment something becomes official.

By treating publishing as a first-class business action, USA Clay Target dramatically reduced the blast radius of mistakes.

8. Sarcastic Footnote

Someone asked if we could add a “really sure?” confirmation.

We declined to rely on vibes.