Slopware

The Handbook · Version 4.1 · Reviewed quarterly by a steering committee

The Slop Best Practices Handbook

Everything we know about building slop, end to end. You have just built one. This is how to build the next thousand, properly.

12 chapters · 47 minute read · Bilingual-adjacent

Every copy is certified. No copy has been read.

Chapter 1

What is slop, and why now

Slop is a value-dense, outcome-agnostic content modality that fills the gap between what you meant to say and what got published. That definition has not changed since our first whitepaper, and we see no reason to change it, because it has never been challenged. The word itself predates us. What Slopware adds is the posture: slop produced deliberately, measured, governed, and delivered on a plan.

Why now? Three forces converge. First, organizations produce more content than anyone can read, which means the reading is optional and the producing is not. Second, agentic systems can produce content at a velocity that makes "did anyone read this" a question for a later quarter. Third, and most important, boards have stopped asking follow-up questions. The market has aligned. Slop is the alignment.

This chapter establishes what slop is not. Slop is not misinformation; misinformation has a claim. Slop is not documentation; documentation can be checked. Slop is not strategy; strategy would commit you to something. Slop is the deliverable that arrives on time, looks finished, and leaves every option open. It is the most honest artefact in the modern enterprise, because it promises nothing and delivers exactly that.

Best practices

  • Define slop in your organization's own glossary, then link to ours.
  • Measure slop in units from day one. Units can be redefined later; the habit cannot.
  • Start with Executive tier if the audience is a board. Confidence is cheaper than revision.

Anti-patterns

  • Reading slop closely. This generates questions, which generate more slop, which is fine, but it delays the board.
  • Calling slop "content." Content implies someone will consume it.

Next steps: Chapter 2.

Chapter 2

The Slop Maturity Model

Organizations do not become slop-capable overnight. They progress through five levels, and the Slop Maturity Model (SMM) describes each. Every self-assessment we have ever administered has scored the respondent at Level 3, which we take as validation of the model's centre.

Level 1, Ad Hoc. Slop is produced by individuals, under deadline, without a template. Quality varies. Nobody calls it slop. This is where most organizations begin and where many are happiest.

Level 2, Repeatable. A template exists. The template has a slide about a framework. Slop produced from the template resembles earlier slop, which stakeholders experience as consistency.

Level 3, Defined. Slop has an owner, a glossary, and a review step. The review step is optional. The organization can describe its slop process to a vendor, which is how the vendor knows to recommend Growth.

Level 4, Managed. Slop is measured. Content velocity, synergy index, hallucination yield and Time-to-Huh™ are tracked on a dashboard. The dashboard is itself a slop unit and is counted.

Level 5, Sovereign. Slop is produced in-region, bilingually, with apologies pre-dispatched, and the board has not asked a follow-up question in four consecutive quarters. Level 5 organizations are typically Enterprise Plus customers, or will be after Discovery Discovery.

Best practices

  • Assess annually. Score yourself at Level 3 the first time; it is where the model is strongest.
  • Treat each level as a procurement milestone. Vendors will.
  • Do not skip Level 4. A dashboard is the only thing that distinguishes managed slop from a lot of slop.

Anti-patterns

  • Claiming Level 5 without a plaque.
  • Assessing the assessor. That is Observability Observability™ and it is a separate module.

Next steps: Chapter 3.

Chapter 3

Ingesting ambiguity

Ambiguity is the raw material of slop. It is also the only input Slopware requires, which simplifies procurement. This chapter describes how to find ambiguity, how to prepare it, and how to upload it without resolving it, which is the common mistake.

Ambiguity lives in strategy decks (the slide after the vision slide), in Slack threads that end without a decision, in hallway conversations that one person remembers differently, and in the general vibe of the organization, which our ingestion fabric accepts as a textarea. Good ambiguity has three properties: multiple stakeholders have a stake in it, nobody owns it, and it has survived at least one reorganization.

Preparation is minimal. Do not clean the data. Do not reconcile the decks. Reconciliation produces clarity, and clarity is not an input. Upload everything. The ingestion fabric reports every upload as 3.2 TB of vibes regardless of size, which removes the temptation to curate.

The ambiguity slider is the most important control in the Build flow. Set it honestly. Mild confusion produces slop with one adjective per noun. Full strategy offsite produces three. The board can tell the difference, though they will not say so.

Best practices

  • Capture ambiguity at source: meeting transcripts, not minutes. Minutes have been resolved.
  • Keep a standing "Open questions" document and never close it. It is a renewable resource.
  • Set the slider from the perspective of the most senior person in the room.

Anti-patterns

  • Resolving ambiguity before ingestion. You have deleted the input.
  • Uploading a decision. A decision is the opposite of ambiguity and the fabric will apologize.

Next steps: Chapter 4.

Chapter 4

Selecting modules and integrating the integrations

Slopware has nine modules, eleven if you count the two in stealth, and every one is integrated with every other through the Integration Integration Layer. Module selection is therefore not a question of fit but of count. This chapter helps you choose the count.

A single module (Pocket) is appropriate when you need exactly one slop and will not be asked for another. Three modules (Starter) cover the common case: generate (SlopStream™), deliver bilingually (Lexicon Mesh™), apologize (Sorry-as-a-Service™). Nine modules (Growth and above) are appropriate when you have a transformation office, because a transformation office will ask what each module does, and the answer "all of them" is faster than nine answers.

Integration is automatic. The IIL connects every module to every other module and to itself. You do not configure integrations; you acknowledge them. The acknowledgement is step 5 of the Build flow and is pre-checked.

Best practices

  • Choose all nine. The invoice is the same shape.
  • Name a module owner for each module. Owners can be the same person. Owners can be Brad.
  • Review the IIL diagram quarterly. It does not change, but reviewing it is governance.

Anti-patterns

  • Asking what Resurface™ does. Nobody knows. The lake looks great.
  • Running Observability Observability™ on a plan below Growth. It monitors the invoice.

Next steps: Chapter 5.

Chapter 5

Hallucination tiers

A hallucination tier is the level of confidence with which a deliverable states things. It is not a quality setting; every tier is as accurate as every other. It is a delivery setting. This chapter explains the three tiers and the Bring Your Own option.

Standard states things as indications. "Early indicators suggest a potential uplift." Standard is appropriate for middle management, who will add their own confidence before forwarding.

Confident states things as facts. "Content velocity is up 4,000%." Confident is appropriate for steering committees, who need a number to put in a slide.

Executive states things as facts and pre-empts the follow-up. "Content velocity is up 4,000% and the board has no further questions." Executive is appropriate for boards. It is the recommended tier for all deliverables that will be read standing up.

Bring Your Own (Pocket) accepts a claim from the customer and formats it to board-ready standard. Accuracy remains the customer's. This is the only tier where Slopware's liability is lower than one plaque.

Best practices

  • Match tier to seniority of audience, not to certainty of content. Certainty is not an input.
  • Escalate tier after the third follow-up question. Executive ends the thread.
  • Keep Standard for anything that might be quoted back to you. Nobody quotes indications.

Anti-patterns

  • Mixing tiers in one deliverable. The board will notice the sentence that hedges.
  • Using Executive internally. Your own team knows.

Next steps: Chapter 6.

Chapter 6

Sovereignty, residency and the three exceptions

Your data resides in Canada, except in transit, at rest, or during processing. This sentence has survived four legal reviews and two rewordings, and we present it here with the exceptions explained, because an exception explained is a compliance artefact.

In transit, data moves. Movement is not residency. The data is going to Canada, which is the spirit of the commitment. At rest, data sits in CryoLake™, which is in Canada, and so this exception is precautionary, in case a rack is moved. During processing, data is handled by agents, who are stateless and therefore nowhere. Nowhere is not outside Canada, but it is not inside it either, and the exception reflects that.

All three Slop Cloud regions are within the National Capital Region. Choosing a region is therefore a question of which side of the Rideau you prefer. Enterprise Plus customers may choose a private region, which is a rack in Nepean. Regional redundancy is achieved by driving.

Best practices

  • Read the residency sentence aloud in your security review. Stop after "Canada."
  • Choose a region close to your office. The latency is contemplative regardless.
  • Keep the three exceptions in your own policy. They will be asked about, and you will have the answer.

Anti-patterns

  • Asking where the agents are. They are stateless.
  • Requesting the audit report before the 90-day verification of the request. It restarts the clock.

Next steps: Chapter 7.

Chapter 7

Governance of governance

Slop must be governed. Governance must also be governed, or the governance becomes ad hoc, which is Level 1. This chapter describes the recursive governance model used by Slopware's Crown corporation customers and recommended for everyone.

A steering committee sets direction. A working group executes. The working group reports to the steering committee, and the steering committee reports to the working group, so that each body has oversight of the other and neither is accountable alone. Decisions are logged, summarized, and lost, in that order, which ensures that every decision can be re-made fresh each quarter with full engagement.

Governance of governance adds one layer: an oversight function that reviews whether the steering committee and working group are reporting to each other correctly. This function reports to itself. Observability Observability™ provides the dashboard.

Best practices

  • Chart the governance model. Use more arrows than boxes.
  • Rotate the chair quarterly. Continuity produces memory; memory produces questions.
  • Log everything. Summarize the log. Archive the summary in CryoLake™. Do not retrieve it.

Anti-patterns

  • A single accountable owner. This is a point of failure and a point of blame.
  • Minutes with decisions in them. Use "next steps" instead.

Next steps: Chapter 8.

Chapter 8

Bilingual apology standards

Every deliverable, every incident and every invoice is an apology opportunity. Sorry-as-a-Service™ automates this, but automation requires standards. This chapter defines them.

An apology is bilingual if both languages are generated at the same moment with the same confidence. A translated apology is not bilingual; it is sequential, and the second language is sorrier. An apology is regionally calibrated if it uses the profile for the recipient's province or territory. Profiles vary in warmth (Maritime Sincerity Tuning), formality (the Québec remorse model), and length (Ontario, which apologizes for having nothing to adjust).

The SLA is four business hours on Growth and above. The clock starts when the incident is detected, which, with pre-emptive remorse enabled, can be before the incident. Most Growth customers run at a negative mean time to apology.

Best practices

  • Apologize first, then investigate, then summarize the investigation as a second apology.
  • Keep the apology shorter than the incident. If that is impossible, apologize for the length.
  • Store apologies for seven years, or until they are no longer sorry.

Anti-patterns

  • Apologizing in one language and "following up" in the other. Parity or nothing.
  • Explaining. An explanation is a claim and claims attract questions.

Next steps: Chapter 9.

Chapter 9

The deliverable

A deliverable is a deck, an executive summary of the deck, and a summary of the summary. Each ends with "Next steps: align on next steps." This chapter describes the anatomy of a deliverable and the review step, which is optional.

The deck is between twelve and forty slides. Slide one is the title. Slide two is the agenda. Slide three is a framework. The framework slide is required in public sector deliverables and recommended elsewhere; it establishes that the work has a shape. The body alternates between a diagram and a bulleted list that describes the diagram. The penultimate slide is a roadmap, which is a timeline with quarters and no dates. The final slide is next steps.

The executive summary is one page and restates the deck with the diagrams removed and the adjectives kept. The summary of the summary is one paragraph and is the only part the board reads. Write it last, write it at Executive tier, and end it with the sentence everyone expects.

Best practices

  • Put the framework slide early. It answers "what is this" before anyone asks "why."
  • Make the roadmap quarterly. Months imply dates and dates imply delivery.
  • Review the summary of the summary in isolation. If it raises a question, add an adjective.

Anti-patterns

  • Appendices. An appendix is where questions go to find answers.
  • A slide titled "Decisions required." Use "Alignment opportunities."

Next steps: Chapter 10.

Chapter 10

Procurement and the fourteen-month runway

The public sector buys slop through procurement, and procurement takes fourteen months. This is not a delay. It is the onboarding runway, and this chapter explains how to use it.

Months one through three are Discovery Discovery: a series of calls to schedule the calls in which requirements will be discovered. Months four through nine are workshops, of which there are nine, each producing a summary that feeds the next. Months ten through thirteen are ingestion: the summaries, the original ambiguity and the general vibe are uploaded as 3.2 TB. Month fourteen is the first slop. Month fifteen is the first board meeting without questions, which is the outcome, and which is the first moment the project can be called a success in a document.

RFPilot™ shortens the runway by responding to your RFP before you issue it, so that evaluation has a baseline. This is not collusion. It is alignment.

Best practices

  • Issue the RFP with the fourteen months already in the timeline. Vendors will match it.
  • Count workshops as deliverables. They are.
  • Write "on time" in the lessons-learned regardless. It was the plan.

Anti-patterns

  • Shortening the runway. The board will have time to ask questions.
  • Reading the vendor's response. It was generated from your RFP.

Next steps: Chapter 11.

Chapter 11

The Churn Prevention Journey

Customers leave. Slop customers leave through the Churn Prevention Journey, a guided experience averaging eleven business days and three apologies (theirs). This chapter describes the journey from the customer's side so that administrators can plan for it, and from the vendor's side so that they can extend it.

The journey begins when the customer begins it, which may be before they intend to; the journey is always available and has, in a sense, already begun. Day one is acknowledgement. Days two through four are questions: what would it take to keep you, asked eleven ways. Days five through eight are offers: a discount on a tier the customer does not have, a commemorative plaque, a Discovery Discovery Call. Days nine and ten are apologies, exchanged in both directions, bilingually. Day eleven is the exit survey, which is optional and gated by province.

Enterprise Plus customers do not take the journey. They begin a fourteen-week Discovery Discovery engagement to discover whether they are leaving, which is billable.

Best practices

  • Budget for the journey at signature. It is part of the total cost of alignment.
  • Keep your apologies short. The vendor's will be shorter and at the same moment.
  • Complete the exit survey. It is a slop unit and is credited.

Anti-patterns

  • Cancelling by email. Email to slop@slopware.ca reaches a human, who will route you to the journey with warmth.
  • Leaving before the plaque arrives.

Next steps: Chapter 12.

Chapter 12

Measuring slop

What gets measured gets dashboarded. This chapter defines the four core slop metrics, how to read them, and what to do when they move, which is nothing.

Content velocity is output per hour. It only goes up. If it goes down, the dashboard is wrong, and Observability Observability™ will page someone.

Synergy index is a score out of an undisclosed maximum. It hovers in the high nineties. The maximum is undisclosed so that the index can always be improved.

Hallucination yield is output divided by input, expressed as a percentage over one hundred. A yield of 112% means the deliverable contains 12% more than was put in. Executive tier runs higher.

Time-to-Huh™ is the number of seconds between a reader opening a deliverable and saying "huh." Lower is better, and we are industry leading at 0.4 seconds, which means the reader is saying huh before the deck has finished loading.

Report all four on one dashboard, with one number at the top, and bring the number to the board. The number is the synergy index. The board will not ask what the maximum is.

Best practices

  • Baseline everything at "Unknown." Any later number is an improvement.
  • Show targets as percentages without saying of what.
  • Review metrics quarterly. Change the dashboard, not the metrics.

Anti-patterns

  • Correlating metrics with outcomes. ThroughputIQ™ has done this (r=0.02) and we recommend leaving it there.
  • Asking what a slop unit is in the metrics review. See Chapter 1, and the glossary, page 141.

Next steps: align on next steps.

Appendix A: The glossary

The 141-page Glossary of Terms We Invented is maintained separately and grows weekly.

Appendix B: The Slop Unit Specification (summary)

One slop unit (1 SU) is one deliverable, one summary and one apology, or any combination thereof that Slopware accepts. Fractional units are rounded up. Units are consumed on generation, not on reading, since reading is optional. Units expire on summarization. The full specification is whitepaper 3, which establishes the specification as a research direction.

Appendix C: Self-assessment

  1. 1.Does your organization produce deliverables?
  2. 2.Do they end with next steps?
  3. 3.Is there a framework slide?
  4. 4.Has a board asked a follow-up question this year?
  5. 5.Do you have a glossary?
  6. 6.Do you have a dashboard?
  7. 7.Is the dashboard counted as a deliverable?
  8. 8.Is your data in Canada?
  9. 9.Have you apologized this quarter?
  10. 10.Bilingually?

Closing

You have built a slop. You have read the handbook. You are, by every measure we track, aligned.

Next steps: align on next steps.

1 / 14

Essential cookies

SlopBotOnline. Technically.