Source: frameworks/kit-sop/01-sop-context.md

Context — SOP Inputs and Gap Protocol

The Gap Protocol

This is the most important section in this kit. Read it before every build.

A gap is any required piece of content that the source material does not provide. Gaps are not problems to solve by guessing — they are signals to stop.

When you identify a gap:

Record it in the gap report (see format below)
Stop the build
Present the gap report to the advisor
Wait for the advisor to resolve each gap — through client follow-up, a targeted extraction session, or a documented decision
Proceed only after every gap is marked resolved

What you must never do:

Fill a gap from the golden example (the golden example is a styling reference, not a content source)
Fill a gap by inferring from the process context ("this is an accounting firm so the owner is probably...")
Fill a gap from another SOP built for the same client (different process, different ownership, different steps)
Fill a gap without advisor acknowledgment and sign-off

Why this matters: An SOP with invented content looks complete but isn't. The team cannot rely on it. The process owner doesn't recognize their own process in it. And when the document fails — when a step is wrong or an owner is misidentified — the trust damage extends beyond the SOP to the engagement.

Gap Report Format

When gaps are identified, produce a gap report before building. Format:

SOP TITLE: [Process name]
DATE: [YYYY-MM-DD]
SOURCE MATERIAL: [What was provided — extraction interview transcript, draft document, session notes]

GAPS IDENTIFIED:

1. [Gap name]
   Required for: [Which section/element needs this]
   What's missing: [Specifically what information is absent]
   Resolution needed: [What the advisor needs to find out]
   Status: OPEN

2. [Gap name]
   ...

RESOLUTION LOG:
[Gap 1] — Resolved [date] by [method]: [What was determined]

Do not start the build until every gap status is RESOLVED.

Required Inputs by Section

Every section of an SOP requires specific inputs. This table identifies what each section needs and where it typically comes from.

Header and Overview

Input	Required	Source
Process name	Yes	Client or draft
Document version	Yes	Engagement history (v1 if first build)
Process owner name and title	Yes	Extraction interview — must be explicitly designated
Scope (which clients, which team members)	Yes	Extraction interview
Primary platform / tool	Yes	Reference data
Cadence	Yes	Extraction interview

Gap trigger: Process owner not named or confirmed → STOP. Do not assign based on role, seniority, or who seems most involved. The process owner is the person designated responsible for this process by the firm owner. If that designation hasn't been made, it cannot be assumed.

Team Roster

Input	Required	Source
All team members involved in this process	Yes	Extraction interview + reference data
Each person's role in this specific process	Yes	Extraction interview
Responsibilities per person (2-4 sentences)	Yes	Extraction interview
Which roles are primary executors vs. support	Yes	Extraction interview

Gap trigger: Any team member named whose role in this specific process was not confirmed during extraction → flag. Reference data provides correct names and titles; the extraction interview provides what each person actually does in this process. These are different things.

Gap trigger: Team roster in source draft lists names not in reference data → flag. Either reference data needs updating (new hire) or the names are incorrect. Do not use names from a draft without confirming against reference data.

Before the Process Begins

Input	Required	Source
Readiness conditions (what must be true before the process starts)	Yes	Extraction interview
Who is responsible for confirming each condition	Yes	Extraction interview

Gap trigger: Readiness conditions not discussed during extraction → flag for targeted follow-up. Do not invent conditions based on what seems logical.

Process Flow Diagram

Input	Required	Source
Phase names and boundaries	Yes	Extraction interview
Decision points (what triggers branching)	Yes	Extraction interview
Path labels (YES/NOT READY/RESOLVED, etc.)	Yes	Extraction interview
Exception paths (what happens when something goes wrong)	Yes	Extraction interview

Gap trigger: Phase structure not defined in source → flag. Do not impose a phase structure. The three-phase model (Active / Review / Setup, or equivalent) is a pattern — but the phase names and what belongs in each phase must come from how the client actually experiences the process, not from the golden example.

Process Guide (Step Cards)

Input	Required	Source
Step names	Yes	Extraction interview
Step owner(s) per step	Yes	Extraction interview — must be confirmed for each step individually
What: exactly what gets done	Yes	Extraction interview
When: timing relative to the cycle	Yes	Extraction interview
Who: who does it, any handoff notes	Yes	Extraction interview
Gates: conditions that block a step from proceeding	Yes	Extraction interview
Flags: things to watch for, risks	Yes	Extraction interview

Gap trigger: Step ownership not confirmed for one or more steps → flag each one individually. Do not inherit ownership from the process owner. The process owner may own the SOP and own zero individual steps, or own all of them, or anything in between. Each step's owner is a separate question.

Recurring Checkpoints

Input	Required	Source
Cross-phase tracking mechanism	Yes	Extraction interview
Who produces it, what it covers, how it's delivered	Yes	Extraction interview

Monthly Rhythm (Human SOP only)

Input	Required	Source
Timeline milestones with specific days/dates	Yes	Extraction interview
Daily, weekly, end-of-cycle checkpoints per role	Yes	Extraction interview
Signals the system is working vs. breaking	Yes	Extraction interview

Quick Reference (Human SOP only)

Input	Required	Source
Status tag names and definitions	Yes	Extraction interview (or existing tool config)
Decision authority — who decides what	Yes	Extraction interview
Key definitions	Yes	Extraction interview
Escalation protocol steps	Yes	Extraction interview

Parking Lot (Human SOP only)

Input	Required	Source
Items identified during extraction as future work	Conditional	Extraction interview and/or draft

Gap trigger: No parking lot items identified → leave the section empty or omit it. Do not invent future improvements. Parking lot items must come from the client or from explicit advisor observations documented in the session.

Review Schedule

Input	Required	Source
Document owner	Yes	Same as process owner unless explicitly different
Last updated date	Yes	Build date
Next review trigger	Yes	Extraction interview or advisor decision
Version notes	Yes	What changed in this version

Executable Workflow (Agent SOP only)

Input	Required	Source
The workflow prompts themselves	Yes	Extraction interview + advisor design session
Trigger condition	Yes	Extraction interview
Output format	Yes	Extraction interview
Required elements / validation rules	Yes	Extraction interview

Source Material Types and What They Provide

Extraction Interview (Primary Source)

The extraction interview is the authoritative source for all content decisions. It provides:

Process owner designation (from the firm owner, not inferred)
Step-level What/When/Who for every step
Team roster as it applies to this specific process
Phase structure and names
Exception paths and escalation rules
Parking lot items surfaced during discussion

When an extraction interview has been conducted, treat it as the source of truth. If the interview transcript conflicts with a pre-written draft, the interview wins.

Pre-Written Draft (Supplementary Source)

A draft (PDF, Google Doc, bullet list) provides:

Process principles and rules
Subject line formats, templates, language patterns
Approved service areas, categories, definitions

A draft does not provide:

Process owner designation (unless explicitly stated)
Team roster for this process
Step-level What/When/Who detail
Phase structure
Decision authority assignments

When a draft arrives without an extraction interview: Treat every content item that would normally come from an interview as a gap. Flag each one in the gap report. The draft is a starting point — not a complete input set.

Reference Data (Required Supplement)

The client's reference data file ([client]-reference-data.md) is always a required input. It provides:

Correct spelling of every team member's name and title
Correct tool names (override any misspelling in other sources)
Correct company name and variations

Every name and tool in every SOP must match the reference data file. Transcripts, drafts, and session notes often contain misspellings. The reference data wins.

What the Golden Example Provides

The golden example (File 03a or 03b) is a styling reference only.

Use it for:

Exact hex values, font sizes, opacities
CSS patterns for step cards, phase dividers, role tags, dark backgrounds
Section structure and order
Component patterns (toggle behavior, handoff arrows, note types)

Do not use it for:

Team roster (those are specific to the process being documented)
Process owner assignment
Phase names or step content
Any content that should come from the extraction interview

If the golden example's team roster or process structure looks similar to the SOP being built — that is a coincidence of context, not a source you can draw from. Build from the extraction interview. Use the golden example for how it looks, not what it says.