Corrective Action: Operational Rhythm Cascade Broken — Weekly Big 3 Not Read by Daily Ops

Date: April 20, 2026 Category: Operational Rhythm Integrity / Data Read Failure / Missing SOP Impact: Today's /daily-ops reported "Weekly Big 3 not set — /weekly-plan needed this week" despite a successful weekly planning session 22 hours earlier (Sun Apr 19) that persisted Listing 549307086996 with document_type: weekly_big3. As a downstream consequence, today's Daily Big 3 (NVENC relay verified, VF Data Part 6 prep, Paragon post-session) does not ladder up to yesterday's locked Weekly Big 3 (Q2 Rock 1 Chronicle/WCP hook + Paragon Wed pilot, commercial protection, WCP triage 156 → <120). The whole point of Sunday weekly planning is defeated if Monday morning cannot read it. This is exactly the class of defect a fully-documented QMS (51 processes, 1 currently documented) would have caught. Resolution: Three-part fix — (1) re-persist the existing weekly_big3 Listing with name and body content via Ledger, (2) repair the CLI/MCP query path so /daily-ops surfaces it reliably, (3) document G-01 (Daily Operations Rhythm) and G-02 (Weekly Planning) as Tier 1 SOPs that include the cascade contract. As part of (3), Q produces an Operational Rhythm Cascade Map showing how every command/SOP relates to every other (Quarterly → Weekly → Daily → Per-Event), so each rhythm explicitly declares its inputs (which rhythms feed it) and outputs (which rhythms it feeds).

Incident

What Happened

Sunday, April 19, 2026 — /weekly-plan ran successfully. Nine agents returned intelligence. Chris confirmed a three-item Weekly Big 3. Ledger persisted two HubSpot Listings:

549307086996 — document_type: weekly_big3, document_authors: v, approved, associated to VFT Company
549305287007 — Weekly Plan Listing (full plan), approved, associated

The session-end log reads: "Weekly Big 3 locked + persisted... Weekly Plan Listing published to Command Center."

Monday, April 20, 2026 at 06:56 AM CT — /daily-ops ran. The standup handoff at .claude/daily/2026-04-20-standup.md includes this line in V's Context section:

"Weekly Big 3 not set — /weekly-plan needed this week"

This is wrong. The Weekly Big 3 was set 22 hours earlier and is sitting in HubSpot. Today's standup also flags the symptom directly: "HubSpot Listing CLI filter bug persists (planning data not surfacing via --filter flag)."

Verification of Wrongness

$ node scripts/hubspot/api.js get listings 549307086996 --properties name,document_type,document_authors,hs_pipeline_stage,createdate
{
  "id": "549307086996",
  "properties": {
    "document_authors": "v",
    "document_type": "weekly_big3",
    "hs_createdate": "2026-04-20T04:13:09.247Z",
    "name": null,                    ← problem: no name set
    "hs_pipeline_stage": null
  }
}

The Listing exists and carries the correct document_type — but name is null and the body content (the actual three Weekly Big 3 items) is not visible via direct property read. Combined with the known CLI filter bug, the daily-ops query that searches document_type: "weekly_big3" either returned empty or returned a record with no surfaced content, and the command defaulted to "Not set."

Downstream Damage

Today's Daily Big 3 was set without referencing yesterday's Weekly Big 3:

Today's Daily Big 3 (Apr 20)	Yesterday's Weekly Big 3 (Apr 19, locked)
1. NVENC relay verified before noon	1. Q2 Rock 1: Chronicle → WCP hook + Paragon Wed pilot
2. /show-prep VF Data Part 6 (Tue 1pm)	2. Commercial protection (Recharged/Abs/Paragon)
3. /post-session paragon Apr 16	3. WCP triage (156 → <120)

There is partial alignment (Paragon work appears in both) but it is incidental, not derived. None of today's three items are rolled-forward weekly outcomes; they are tactical day-shape items pulled from inbox + schedule. The week's strategic anchor never reached Monday.

Root Cause

1. Data Integrity Failure (Listing Persisted Half-Empty)

The Sunday /weekly-plan session called Ledger to create Listing 549307086996 with document_type: weekly_big3. Either the Ledger call did not pass the name and body fields, or it did and HubSpot dropped them silently. The Listing exists structurally (correct document_type, correct document_authors, correct association to VFT Company) but is missing the payload. This is a Ledger contract failure or a write-path bug — not yet diagnosed.

2. CLI Filter Bug (Already Known, Still Unfixed)

Today's standup text — written by /daily-ops itself — flags: "HubSpot Listing CLI filter bug persists (planning data not surfacing via --filter flag)." This bug has been observed before. There is no CHRISC item tracking it. The CLI is scripts/hubspot/api.js, used by every command that needs to query Listings by property. Any rhythm that reads from Listings is at risk.

3. No SOP for G-01 (Daily Operations Rhythm) or G-02 (Weekly Planning)

The process register at docs/quality/process-register.md lists G-01 (Daily Operations Rhythm, Tier 2) and G-02 (Weekly Planning, Tier 3) as registered processes — both with Procedure: None and score N/A. There is no operating procedure for either. There is no specification of the contract between them.

A documented G-01 SOP would have included a verification gate: "Step N: Read most recent weekly_big3 Listing. If empty or null, raise an explicit error with the Listing ID, do not silently default to 'Not set.'" That gate does not exist because the SOP does not exist.

4. No Cascade Map (The Real Root Cause)

The deeper failure is that no document declares how the operational rhythms relate to each other. Each command (/weekly-plan, /daily-ops, /leadership-meeting, /midday-check, /daily-recap, etc.) is documented in isolation. There is no single artifact that says:

/daily-ops MUST read the most recent weekly_big3 Listing as input
/weekly-plan MUST read the most recent quarterly_big3 Listing as input
/weekly-plan MUST read prior week's /weekly-review output as input
/daily-ops MUST roll forward incomplete items from yesterday's daily_focus Listing

Without this contract written down, each command is free to drift. /daily-ops could "soft-fail" the weekly read (as it did) and no validation gate would catch it. The Quarterly → Weekly → Daily cascade is asserted in conversation and in the design intent of /weekly-plan — but it is not enforced anywhere.

Five Whys

#	Why?	Answer
1	Why did today's Daily Big 3 not roll forward from yesterday's Weekly Big 3?	/daily-ops reported the Weekly Big 3 was not set.
2	Why did /daily-ops report it was not set?	The query against Listings returned empty / unsurface-able.
3	Why was the query unsurface-able?	The Listing exists but has `name: null`, AND the CLI filter bug returns empty for property-filtered Listing queries.
4	Why did the system silently default to "Not set" instead of erroring loudly?	/daily-ops has no validation gate requiring a weekly_big3 read to succeed.
5	Why does /daily-ops have no such gate?	There is no SOP for G-01 that specifies its inputs from upstream rhythms (G-02 weekly, G-05 leadership-meeting quarterly). The cascade is not codified.

Root cause: The operational rhythm cascade is implicit, not codified. Without an SOP declaring G-01's input contract from G-02 (which derives from G-05 quarterly), each command operates on best-effort and silently degrades when upstream data is missing or malformed.

Fix Applied

Immediate Resolution (Today, before EOD)

Ledger re-persists weekly_big3 Listing 549307086996 with full payload — name field set ("Weekly Big 3 — Apr 20–24, 2026"), body content with the three locked items, ensure association to VFT Company is intact.
Re-run /daily-ops after the Listing is repaired. Verify the standup now surfaces the actual Weekly Big 3 in V's Context section.
Today's Daily Big 3 stays as posted (NVENC relay, VF Data Part 6 prep, Paragon post-session) — these are all valid tactical priorities and removing them mid-day would create more confusion than it resolves. The cascade fix takes effect from tomorrow.

Code / Configuration Changes

File	Change	Owner
`scripts/hubspot/api.js`	Diagnose the Listing `--filter` bug. Reproduce, root-cause, fix. CHRISC item required.	Mender (assigned via Marshal)
`agents/ledger/AGENT.md`	Add required-fields validation for `weekly_big3` and `daily_focus` Listing creates: `name` and body MUST be present or write is rejected.	Ledger (interview by Q)
`.claude/commands/daily-ops.md`	Add explicit validation gate at "Read Weekly Big 3" step: if query returns empty or returns a record with null `name`, raise an error with the searched-for `document_type` and the most recent Listing ID found. Do NOT silently default.	V (via process-documentation)
`.claude/commands/weekly-plan.md`	Add post-write verification: after Ledger creates the weekly_big3 Listing, re-read it by ID and assert `name` is non-null and body content is present.	V (via process-documentation)
`docs/operating-procedures/g-01-daily-operations-rhythm.md`	NEW. Tier 1 SOP. Includes input/output contract with G-02. Every step carries a verification marker.	Q
`docs/operating-procedures/g-02-weekly-planning.md`	NEW. Tier 1 SOP (upgrade from Tier 3 — this incident proves it is Critical, not Standard). Includes input/output contract with G-05 quarterly and G-01 daily.	Q
`docs/quality/process-register.md`	Update G-02 from Tier 3 → Tier 1. Update G-01 status. Link both new procedure files.	Q

Required Resolution Artifact: Operational Rhythm Cascade Map

Q must produce, as a required deliverable of this CAR, an Operational Rhythm Cascade Map — a single document at docs/quality/operational-rhythm-cascade.md that declares every cadence command, its trigger frequency, its required inputs (which rhythms feed it), its required outputs (which rhythms it feeds), and the persistence contract for each.

Map Skeleton (Q to expand and verify with each owning agent)

STRATEGIC LAYER (sets direction)
─────────────────────────────────
G-05  /leadership-meeting (quarterly) ──┐
                                        │ produces: Listing(document_type: quarterly_big3)
G-04  /all-hands (weekly + monthly)     │
                                        ▼
WEEKLY LAYER (translates strategy to outcomes)
──────────────────────────────────────────────
G-02  /weekly-plan (Sunday) ────────────┐
        inputs:  quarterly_big3 Listing │
                 prior-week weekly_review Listing
                 BU briefs (academy, media, collective, apps, commerce, service)
                 commercial briefs (revenue, capacity, horizon)
                 relationship briefs (sentinel, pulse)
        produces: Listing(document_type: weekly_big3)  ─┐
                  Listing(document_type: weekly_plan)   │
                                                        │
G-03  /weekly-review (Friday)                           │
        inputs:  weekly_big3 Listing (this week)        │
                 daily_focus Listings (this week)       │
        produces: Listing(document_type: weekly_review) │
                                                        ▼
DAILY LAYER (executes against weekly)
──────────────────────────────────────
G-01  /daily-ops (morning) ─────────────┐
        inputs:  weekly_big3 Listing  ──┘  ← CASCADE BREAKS HERE if missing
                 yesterday daily_focus Listing (rollover)
                 today's calendar
                 inbox triage state
                 BU Big 3 (daily Listings per BU leader)
        produces: Listing(document_type: daily_focus)
                  .claude/daily/{date}-standup.md (handoff file)
                  per-leader sections for /activate

      /midday-check  → reads daily_focus, updates progress
      /daily-recap   → reads daily_focus, writes session-logs entry,
                       feeds tomorrow's /daily-ops rollover

PER-EVENT LAYER (just-in-time prep + close)
────────────────────────────────────────────
Sessions:    /meeting-prep    → SESSION → /post-session
Shows:       /show-prep       → SHOW    → /media-recap
Deals:       /deal-prep       → CALL    → /deal-review
Office Hrs:  /office-hours (prep | post | queue | metrics | schedule)
Distribution: /distribute, /content-multiply

INTELLIGENCE BRIEFS (feed the layers above on demand or schedule)
──────────────────────────────────────────────────────────────────
Customer:   /sentinel-check, /relationship-brief, /relationship-pulse,
            /interest-brief, /meeting-prep
Commercial: /revenue-brief, /capacity-brief, /investment-brief, /1099-prep
Media:      /media-brief, /media-check, /show-health, /media-recap-weekly
BU:         /academy-brief, /apps-brief, /collective-brief,
            /commerce-brief, /media-brief
Operations: /assessment-report, /capability-report, /decision-record,
            /deprecation-report, /spec, /5p-plan, /casino-research,
            /prd-generate, /journey, /ucv, /walkthrough

QMS LAYER (audits everything above)
────────────────────────────────────
G-06  /process-documentation     → produces SOPs in docs/operating-procedures/
      /corrective-action-report  → produces CARs in docs/quality/cars/
      /capability-report         → produces capabilities in docs/quality/capabilities/
      /certify                   → certifies agents/commands/skills

Required Map Properties

For each command in the map, Q must record:

Trigger: Manual / Scheduled / Event-driven (and the trigger detail)
Owner: which agent/leader runs it
Inputs: explicit list of upstream Listings, files, or briefs it must read
Outputs: explicit list of Listings, files, or downstream rhythms it feeds
Persistence: where state lands (HubSpot Listing type, repo path, WCP item)
Failure mode: what happens if a required input is missing (must NOT default silently)

The map becomes the master cross-reference that every individual SOP refers back to. Each SOP at docs/operating-procedures/{name}.md declares its own row in the cascade and points to the map for the larger context.

Verification

This CAR is not closed until:

Listing 549307086996 has non-null name and visible body content
/daily-ops re-run successfully surfaces the Weekly Big 3 in V's Context section
CHRISC item filed for the CLI --filter bug, assigned to Mender
Ledger updated to validate required fields on weekly_big3 and daily_focus Listing creates
G-01 SOP written (Q via /process-documentation, interview V)
G-02 SOP written (Q via /process-documentation, interview V) — tier upgraded to 1
G-05 SOP written (Q via /process-documentation, interview V) — establishes the top of the cascade
Operational Rhythm Cascade Map produced at docs/quality/operational-rhythm-cascade.md
Process register updated with new procedure links and revised G-02 tier
Validation gate added to /daily-ops: required Weekly Big 3 read fails loudly, never silently
Validation gate added to /weekly-plan: post-write read-back of created Listings

Prevention Measures

Rules Added

Layer	File	Rule
Critical Lessons	`memory/MEMORY.md`	NEVER allow an operational rhythm to silently default when its required upstream input is missing. If `/daily-ops` cannot read the Weekly Big 3 Listing, it must error loudly with the Listing ID and stop, not report "Not set." Soft-failure breaks the cascade and decouples daily execution from weekly strategy.
Enforcement	`skills/enforcement/vf-validation-gates.md`	Add: every command that reads from a HubSpot Listing as input MUST verify the read returned a record with non-null content. Empty or null reads must raise explicit errors naming the searched property and the most recent matching Listing ID, never default to "not set."
Enforcement	`skills/enforcement/vf-self-correction.md`	Add detection trigger: if you are about to write "Not set" or "None configured" to a standup or briefing, STOP. Verify the read path. Empty results from a HubSpot Listing query are almost always a CLI/MCP bug or a half-persisted record, not actually missing data. Investigate before reporting.
Ledger contract	`agents/ledger/AGENT.md`	Listing creates of types `weekly_big3`, `daily_focus`, `quarterly_big3` MUST validate `name` is non-null and body content is present before writing. Reject the write and surface the missing fields if not.
Process register	`docs/quality/process-register.md`	G-02 (Weekly Planning) upgraded from Tier 3 to Tier 1. The cascade contract makes weekly planning Critical, not Standard.
Operations	`memory/operations.md`	Cascade map exists at `docs/quality/operational-rhythm-cascade.md` — every new command added to the system must declare its row in the map (inputs, outputs, persistence, failure mode) before it can be certified.

Detection Triggers

If you (any AI leader or agent) catch yourself doing any of the following, treat as a Cascade Read Failure pattern:

About to write "Not set" or "Not configured" or "None" for a Big 3, plan, or rhythm output → STOP, verify the read.
About to set a Daily Big 3 without referencing the current Weekly Big 3 → STOP, the cascade is broken upstream.
About to set a Weekly Big 3 without referencing the current Quarterly Big 3 → STOP, same.
A standup or briefing template prompts you for upstream context and you have nothing to insert → STOP, do not generate; investigate and surface the gap as an explicit error.

Process Register Implications

This incident proves three things about the QMS:

The QMS is the right project for today. Chris's pivot from tactical day-shape to QMS rollout is directly justified by this defect.
G-02 is misclassified. Weekly Planning is Tier 1 (Critical), not Tier 3. A failure here breaks the entire week.
Tier 1 governance processes (G-01, G-02, G-05) must be documented before Tier 1 systems processes (S-01, S-02). The cascade contract is the foundation everything else inherits from. Earlier proposed sequence (S-01 first) is revised — see Resolution Owner section below.

Resolution Owner

Marshal (project coordination) manages this CAR to close. Q (Quality System) executes the SOPs and the cascade map. Mender (self-healing) owns the CLI --filter bug fix. Ledger (HubSpot writes) owns the validation contract update. V is the interview source for G-01, G-02, G-05 SOPs.

Revised SOP Documentation Sequence (replaces earlier S-01-first proposal)

Because this CAR demonstrates that the cascade contract is the foundation, the SOP documentation sequence is revised:

G-01 Daily Operations Rhythm (V, upgraded urgency)
G-02 Weekly Planning (V, upgraded to Tier 1)
G-05 Leadership Meetings (V, defines the top of the cascade — quarterly Big 3 source)
Operational Rhythm Cascade Map (Q produces, all owners verify their rows)
S-01 HubSpot Write Operations (Ledger — gateway every other process inherits from)
S-02 Sanity CMS Write Operations (Canon — sister gateway)
C-02 Session Processing (Scribe)
CT-03 Content Distribution (Broadcast)
CT-02 Article Publishing (Canon / Baldwin)
M-01 Media Production (finish to >=80%)
M-05 Transcription Pipeline (Caption / Dub)
S-05 Portal Build & Deploy (Showcase)
C-09 Portal Data Operations (Pavilion)
S-04 Website Deployment (V / Squire)
C-06 Client Communications (Correspondent)

Items 1-4 are this week's work. Items 5-15 follow.

Filing

Canonical: docs/quality/cars/2026-04-20-corrective-operational-rhythm-cascade.md (this file)
Mirror: /mnt/d/Leadership/reports/2026-04-20-corrective-operational-rhythm-cascade.md (manual mirror — automated mirror via Ledger is future work)
HubSpot: Listing of document_type: corrective_action_report to be created via Ledger after Chris confirms the CAR
WCP: Parent project item to be created in CHRISC namespace by Marshal (title: "QMS SOP Documentation — Tier 1 Pass") with this CAR linked as the originating event