SC SOP Standard

Purpose

Defines what a Standard Operating Procedure (SOP) is in the symphony-core-documents repository, how to author one, where it lives, and how it evolves. Builds on the SC Markdown Standard — only the SOP-specific rules live here.

Scope

Applies to every file in this repo that documents a repeatable operational procedure — whether named *-sop.md today or not. Does not apply to:

• Checklists (*-checklist.md) — verification lists with no procedural context. See SC Document Naming Standard.
• Guides (*-guide.md) — explanatory/teaching content without a defined operator role.
• Runbooks (*-runbook.md) — incident-response procedures, typically auto-page driven.
• Standards (sc-*-standard.md) — normative conventions (this file is a standard, not an SOP).

If you're unsure which document type fits, use the decision rubric in §1 below.

1. What is an SOP

An SOP is a written procedure that:

1. Has a clearly identified operator role (who runs it).
2. Has a trigger (when it runs — event, request, or schedule).
3. Produces a defined output (what's true when it's done).
4. Is repeatable — multiple operators executing it should produce the same result.

If any of those four is missing, you probably want a guide, runbook, or checklist instead.

SOP vs. adjacent document types

Type	Operator role	Trigger	Output	Example
SOP	Required	Required	Required	google-drive-client-folder-setup-sop.md
Checklist	Optional	Optional	Verification only	annual-tax-preparation-checklist.md
Guide	Optional	None	Understanding	account-manager-operations-guide.md
Runbook	On-call	Alert / incident	Recovery	database-restore-runbook.md
Standard	All authors	Authoring time	Conformance	this document

2. Frontmatter

SOP frontmatter inherits the SC Markdown Standard required fields and adds SOP-specific ones.

Required for every SOP

---
title: <SOP title in title case>
version: <X.Y semantic version>
author: <Author or team>
last_updated: <YYYY-MM-DD>
category: sop
tags: [&lt;3-6 lowercase-hyphenated tags>]
status: <draft | active | review | archived | deprecated>
audience: <internal-team | client-facing | all-teams>
workflow_owner: <named role or team>
---

Notes:

• category is always lowercase sop (not SOP, not Standard Operating Procedure).
• tags should include sop plus 2–5 functional-area and topic tags. Skip redundant tags that just restate the folder (e.g., don't tag operations if the file lives in 04-operations/sops/).
• audience is required for SOPs even though it's "recommended" in the parent markdown standard, because audience determines white-label rules (§7).
• workflow_owner is the role accountable for the SOP being correct (e.g., "Account Manager", "Implementation Lead", "CEO"). Not the author of the doc.

Recommended

review_schedule: <monthly | quarterly | annually>
next_review: <YYYY-MM-DD>
last_verified: <YYYY-MM-DD>
last_verified_by: <role>
publish_to: [internal-wiki]

• Set review_schedule: quarterly by default. Use monthly only for fast-changing SOPs (e.g., active automation specs); use annually for stable procedures.
• next_review should be set when promoting status: draft → active. A past next_review is a maintenance debt signal.
• last_verified / last_verified_by — capture when an operator confirmed the SOP still matches reality, and which role did so. This is distinct from last_updated:
  • last_updated answers "when was the doc last edited?"
  • last_verified answers "when was the doc last confirmed accurate against the systems it describes?"
  • The two diverge naturally: a stable SOP can go months without edits but still get re-verified each quarter. A doc with last_updated > last_verified is fine. A doc whose last_verified is older than 1 review cycle is a drift signal.
  • last_verified_by is a role (e.g., CEO, Support Process Owner), never an individual name — substitutability.
  • Stamp both fields during the Operational SOP Freshness Review and at any other time the operator deliberately walks the SOP against reality.

Conditional

When status: deprecated:

deprecated_date: <YYYY-MM-DD>
deprecated_reason: <one line>
superseded_by: <path/to/replacement.md>

When status: archived (file is being moved to sc-documents-archive):

archived_date: <YYYY-MM-DD>
archived_reason: <one line>

See SC Archive & Retention Standard for Pattern A (deprecate) vs. Pattern B (archive) vs. Pattern C (delete).

3. File naming and location

Naming

• All SOPs end with -sop.md.
• Filenames are lowercase, hyphenated, max 50 characters (excluding extension).
• No version numbers, dates, status, or author in the filename.
• Use a descriptive action or subject, not a process step.

Valid: client-meeting-recap-sop.md, wordpress-setup-sop.md, ghl-prospecting-pipeline-sop.md.

Invalid: client-meeting-recap-v2-sop.md, sop-client-meeting-recap.md, client-meeting-recap.md (missing suffix).

Location

Place SOPs in the directory whose audience they primarily serve:

Directory	Use for
04-operations/sops/	Default home for operational SOPs
04-operations/sops/client-onboarding/	Onboarding lifecycle SOPs
04-operations/sops/sales-pipeline/	Prospecting and pipeline SOPs
04-operations/sops/service-delivery/	Change management, client-changes SOPs
10-people-operations/<area>/	People-ops SOPs (hiring, onboarding, payments, registry)

Do not create new subdirectories under 04-operations/sops/ without strong reason — flat is preferred.

4. Required document structure

Every SOP must have at minimum these sections, in this order:

# <Title>

## Overview
- **What:** one-line description
- **When:** trigger or schedule
- **Who:** operator role
- **Time Required:** rough estimate

## Prerequisites
- Access / permissions needed
- Required information
- Required tools or templates
- Upstream procedures that must complete first

## Procedure
1. Step-by-step actions, numbered
2. Each step names the actor when ambiguous
3. Decision points are inline ("If X, go to step N; if Y, escalate")

## Verification
- How the operator confirms the SOP completed successfully
- Spot-check list or success criteria

## Related Documents
- Cross-links to upstream/downstream SOPs, standards, and templates

That's the minimum. Use sop-template.md as a starting point.

5. Optional sections for complex SOPs

Add these only when the SOP is genuinely complex enough to need them. Most SOPs don't.

• Executive Summary — for SOPs >500 lines or multi-team workflows
• Process Overview (Mermaid) — when the flow has branches, loops, or parallel paths
• Roles & Responsibilities / RACI — for multi-role SOPs with overlap or handoffs
• Quality Checkpoints — for SOPs where mid-process verification matters (estimates, approvals)
• Troubleshooting — when there's a finite set of recurring failure modes
• Success Metrics / KPIs — for SOPs whose performance is actively measured
• Appendix / Agent Quick Reference — for SOPs that humans and Claude Code agents both execute

When in doubt, leave it out. A 200-line SOP that someone actually reads beats a 700-line SOP that gets skipped.

For comprehensive SOPs, use sop-comprehensive-template.md.

6. Status lifecycle

draft → active → review → archived
                       ↘
                        deprecated

• draft — Being authored or under initial review. Not yet in operational use. next_review is set to the expected promotion date.
• active — Approved and in use. The canonical version.
• review — Under scheduled review or revision. Still authoritative until updated.
• archived — Moved to sc-documents-archive. No inbound links. Pattern B.
• deprecated — Stays in place because inbound links exist; superseded_by points to replacement. Pattern A.

Promote a draft to active when:

1. The operator role has executed the SOP at least once and confirmed the steps work.
2. workflow_owner has approved.
3. next_review date is set.

7. White-label rules

If audience is client-facing or all-teams:

• Never use GHL, GoHighLevel, or gohighlevel in body text. Use "Symphony Core", "the platform", or "app.symphonycore.com".
• The platform login URL is always app.symphonycore.com, never the raw GHL URL.

If audience is internal-team, both terms are acceptable. See CLAUDE.md §White-Label Branding.

8. Anchor IDs

Some SOPs are referenced from CLI tooling (e.g., symphony-flow task:lint deep-links into a specific rule). Anchor IDs must be stable.

• Use lowercase-hyphenated section headings — markdown auto-generates anchor IDs from them.
• Once published, don't renumber sections or rename headings if any external system links to them. Add new sections instead.
• For SOPs and standards intended as deep-link targets, document the contract explicitly in the doc itself (e.g., ## title-rule is a stable anchor).

9. Cross-linking

• Prefer relative paths (../../templates/sop-template.md) over absolute repo paths.
• Link to specific standards by their canonical path; don't duplicate normative content.
• When a procedure references a sibling SOP, link to it — don't restate its steps.
• When updating an SOP, grep the repo for inbound links and update them in the same commit.

10. Review and maintenance

• Update last_updated on every substantive edit.
• Bump version (semantic):
  • Patch (1.0 → 1.1): typo, link fix, minor clarification
  • Minor (1.1 → 1.2): new section, refined step, additional troubleshooting case
  • Major (1.2 → 2.0): restructured procedure, changed operator role, retired step
• Run a repo-wide quarterly hygiene pass: SOPs with past next_review get re-stamped, refreshed, or downgraded to review status.
• SOPs that haven't been touched in 9+ months and have no active workflow_owner are candidates for Pattern B archival.

11. Exemplars

Read these before authoring a new SOP. They're representative of the lengths and patterns the standard expects.

Slim operational SOP — 04-operations/sops/markdown-task-file-to-clickup-sop.md Single-actor, single-system, ~200 lines. Numbered steps, content-hygiene preflight, agent quick reference appendix. The default shape for most SOPs.

Lifecycle SOP — 04-operations/sops/client-onboarding/google-drive-client-folder-setup-sop.md Multi-step folder scaffolding with verification checklist. Uses the slim structure plus a tabular permissions matrix.

Comprehensive multi-role SOP — 04-operations/sops/service-delivery/change-request-intake-sop.md Multi-phase, multi-role, RACI matrix, KPIs, troubleshooting. The shape for genuinely complex workflows — use sparingly.

Related Standards

• SC Markdown Standard — parent frontmatter and formatting spec
• SC Document Naming Standard — file naming rules
• SC Tagging Standard — tag vocabulary
• SC Archive & Retention Standard — deprecation and archival patterns
• SC Template Inventory — list of available SOP templates

Revision History

Date	Version	Change	Author
2026-05-19	1.1	Added last_verified and last_verified_by frontmatter fields to distinguish doc-edit time from doc-vs-reality verification time. Powers the quarterly drift-detection review.	Symphony Core Systems Team
2026-05-12	1.0	Initial release. Codified SOP frontmatter spec, structure, lifecycle, and exemplars.	Symphony Core Systems Team