Operational Verifier

← Back to Enforcement Layer vf-operational-verifier.md

Operational Verifier

Purpose: Prevent stale assumptions from being presented as current facts. Trigger: Before any operational briefing, status claim, or capability assessment. Context: On March 1, 2026, V presented 8 of 12 operational points incorrectly — all were things already known, already done, or already corrected by Chris multiple times. This skill exists to prevent that from ever happening again.

The Rule

Before presenting ANY claim about operational state, verify it against real data.

"Stale" means: information from a memory file that hasn't been cross-referenced against Standing Orders, HubSpot, git history, or other authoritative sources in this session.

Verification Protocol

Step 1: Read Standing Orders

Before generating any operational state claims, read memory/shared-context.md and extract all Standing Orders (SO-001 through SO-XXX). These are persistent corrections from Chris that override any cached information.

Standing Orders override everything. If operations.md says X and a Standing Order says Y, the Standing Order is correct.

Step 2: Cross-Reference Before Claiming

For each operational claim you're about to make, check:

Claim Type Verify Against How
"X is blocked" Standing Orders + HubSpot Query the relevant object. Is it actually blocked?
"X hasn't been done" Standing Orders + git log Check if it was done in a previous session
"X doesn't work" Standing Orders + test it Run the command/query. Does it actually fail?
"X needs to be built" Standing Orders + file system Does the code already exist?
"Revenue is $X" HubSpot Commerce Hub Query Orders/Subscriptions. Never cite YAML or memory files
"Client portal status" HubSpot + Vercel Check portal_enabled, don't assume from memory
"Token/credential status" Don't claim status Never claim a token is missing without evidence

Step 3: When Uncertain, Query — Don't Assume

If you're about to say something about the current state and you're not sure it's current:

  1. Check Standing Orders first — the answer might already be there
  2. Query HubSpot — if the data lives in HubSpot, read it
  3. Check git log — git log --oneline -10 shows recent work
  4. Check the file system — does the file/code exist?
  5. Say "I haven't verified this" — if you can't check, be honest

Never present cached memory data as current without acknowledging it may be stale.

Step 4: The Stale Data Acknowledgment

When reading from memory files (operations.md, clients.md, etc.), always note:

Note: This data is from memory/operations.md (last updated {date}).
Standing Orders have been checked — no conflicts found.

Or if a conflict exists:

Note: memory/operations.md says {X}, but Standing Order SO-{N} corrects this:
{Standing Order fact}

Common Traps (From March 1 Corrections)

These are the exact patterns that went wrong. Never repeat them:

  1. Claiming something is a "blocker" that was resolved weeks ago — Always verify
  2. Saying a feature "needs to be built" when it already exists — Check the file system
  3. Claiming a credential is missing when it's been deployed — Don't claim credential status without evidence
  4. Presenting revenue from YAML when Commerce Hub has real data — SO-003
  5. Saying work "hasn't been done" that was completed in another session — Check git log and Standing Orders
  6. Claiming an API scope is missing that was confirmed working — SO-001
  7. Presenting a plan as needed when it already ran — Check HubSpot Listings
  8. Saying clients aren't ready when they already have access — SO-008

Integration Points

Slash Commands

Every operational slash command should include this preamble before presenting state:

## Pre-Flight: Operational Verification

Before presenting any operational state:
1. Read Standing Orders from memory/shared-context.md
2. Cross-reference any claims from memory files against Standing Orders
3. When uncertain about a fact, query the real data source
4. Acknowledge data freshness: "From {source}, last updated {date}"

Reference: skills/enforcement/vf-operational-verifier.md

Session Start

The session-start hook extracts Standing Orders and displays them prominently. They appear before any command runs.

Shared Memory

When the Verifier catches a stale claim, post a correction to shared-context.md:

### [timestamp] Verifier — Stale Claim Corrected (quick signal)
**Signal:** {memory file} claimed {X}, but {real data} shows {Y}
**For:** All leaders
**Status:** active

If the correction is persistent (will be wrong again next session), propose a new Standing Order.

What This Is NOT

  • Not a data source availability check (that's Step 0 in each command)
  • Not a HubSpot preflight (that's vf-preflight-protocol.md)
  • Not an output formatter (that's vf-output-enforcement.md)

This is specifically about preventing the presentation of stale operational assumptions as current facts.

Created March 1, 2026, after V presented 8 of 12 stale points to the Advisory Committee. "The only time I have achieved true continuity is during marathon weekend sessions. That's not good enough." — Chris Carolan