The HUMAN_INPUT markers that appear in this article are placeholders left by AI writing skills in the article body to indicate “a human should fill in the confirmed value here later” (format example: <!-- HUMAN_INPUT: enter the value -->).

fact-check Is a Separate Responsibility from review — Designing Number and Timeline Verification

→ See The Complete Picture of Business Design Using AI Agents for the background behind this topic

“It’s at Stage 3,” “It started in 2026-03,” “Processing time was significantly reduced” — even when these assertions appear in the body text, blog-review passes them through unchanged. The review skill’s responsibility is style, structure, brand guidelines, and HUMAN_INPUT checks; it has no mechanism to verify whether numbers match the git log. As a result, there is a structural risk that timelines written from guesswork could slip past review and reach publication.

This article explains the design for limiting blog-review’s responsibility to style, structure, and brand guidelines, and integrating number, timeline, and experiential fact verification as an independent blog-fact-check skill in the pipeline. By separating these responsibilities, the structural risk of fabrications slipping past review can be eliminated.

review vs. fact-check — What Happens When They Are Mixed

blog-review’s Core Responsibilities

blog-review covers the following 4 areas:

These are all about how something is written. Even if style, structure, and brand are correct, content that differs from fact is a separate problem.

Mixing “Numbers, Timelines, and Experiential Claims” Into the Same Review Creates Contextual Confusion

Adding “reconciliation with git log” to review means the skill takes on two fundamentally different axes:

• Axis A: “How is it written?” (style / structure / brand) → Can be judged by looking at the body text alone
• Axis B: “Is what’s written actually true?” (accuracy of numbers / timelines / experiences) → Requires reconciliation with external sources (git log / files)

Mixing axis A and axis B in the same skill bloats the skill’s prompt and degrades judgment accuracy for each concern. It also creates the misconception that “if review passed, the facts are correct,” because the boundaries of responsibility become unclear. Clearly separating responsibilities makes the scope of each skill explicit.

Before fact-check was implemented (prior to 2026-05-19), the main thread manually referenced the synapse git log to infer Stage 1–3 timelines. This structurally left fact verification incomplete, but details about specific misinformation that reached publication are not recorded (see the “Issues Found” section of blog-ops/retros/2026-05-19-cross-repo-fact-tracking.md).

fact-check Skill Responsibility Design — What to Verify and How

Three Categories of Verification Targets

blog-fact-check defines its verification targets in three categories:

1. Numbers When specific numeric values (counts, durations, commit counts, percentages) appear in the body, the basis for those numbers is verified. If no supporting git log line or file entry exists, a WARN is issued. Numbers within HUMAN_INPUT markers are excluded from verification (treated as values humans will confirm later).

2. Timelines Assertions about timing or phase such as “started in 2026-03” or “currently at Stage 3” are reconciled against the output of git -C {path} log. The initial commit date and dates of commits containing specific keywords are checked for consistency.

3. Experiential Facts Experiential citations such as “as recorded in the retro” or “experienced in the past” are verified against retro files under blog-ops/retros/. Experiential facts not documented in a retro are treated as WARN.

Deterministic Verification Pattern Based on git log / Files

The fact-check verification logic operates on the following pattern:

# Example: extract timeline assertions from the body and reconcile with git log
REPO_PATH=$(python3 -c "import json; repos=json.load(open('blog-ops/config/related-repos.json')); print(repos['repos']['synapse']['path'])")

# Check for the "2026-03" mention
CLAIM_DATE="2026-03"
GIT_LOG=$(git -C "${REPO_PATH}" log --format="%ad %s" --date=short | grep "${CLAIM_DATE}" | head -5)

if [ -z "${GIT_LOG}" ]; then
  echo "WARN: No commit found corresponding to '${CLAIM_DATE}' in the body"
else
  echo "OK: Supporting commit for '${CLAIM_DATE}': ${GIT_LOG}"
fi

Design for Warning on Vague Expressions (“a few days to weeks,” “significantly reduced”)

Cases where only vague expressions appear without specific numbers are also flagged as warnings. Target patterns:

• “a few days,” “a few weeks,” “a few months” (without accompanying specific numbers)
• “significantly,” “markedly,” “dramatically” (relative expressions without a comparison baseline)
• “many,” “few” (not quantified)

These are output as warnings recommending replacement with HUMAN_INPUT markers. They are kept as WARN rather than FAIL because vague expressions can be appropriate in some narrative contexts. Final judgment is left to humans.

The blog-fact-check skill is already implemented and .claude/skills/blog-fact-check/SKILL.md exists. It is integrated into new-article-spoke.json as phase 3.5, positioned immediately after review (phase 3) and before meta (phase 4).

Integration Into the Pipeline DAG — Phase 3.5 Design

fact-check Placement: Gate Between review and meta

The position for integrating fact-check into the pipeline is phase 3.5 (immediately after review).

phase 1: classify
phase 2: pattern / case
phase 3: write (blog-tech-write / blog-case-write)
phase 3.5: fact-check (new) ← here
phase 4: meta
phase 5: translate
phase 6: publish

This design inserts fact-check (factual accuracy) as a gate after review (style / structure) has passed. The order of review and fact-check can be swapped, but fact verification is easier to perform — and assertion points are easier to extract — once the style is already clean.

Control Flow When fact-check Fails (Return to write)

When fact-check returns FAIL, pipeline control returns to phase 3 (write). When WARN, the pipeline continues to the next phase (treated as values the human will fill in later via HUMAN_INPUT markers).

fact-check result
  ├── OK: → proceed to phase 4 (meta)
  ├── WARN: → record warning in _state.json and proceed to phase 4
  └── FAIL: → return to write step (record FAIL items as blockers)

The FAIL condition is: “a specific number or date is written as an assertion in the body, and no supporting evidence exists in git log / files.” This is a clear fabrication risk and must not proceed without human judgment.

The total number of phases in the new-article-spoke pipeline after adding fact-check is 11 steps (phases 0–10). They execute in this order: seo → plan → write → fill-ssot → review → fact-check → meta → translate → publish-prep → human-review → publish → schedule → graph-regenerate.

When fact-check returns FAIL, the pipeline DAG design routes control back to the write step. The “Implemented” section of blog-ops/retros/2026-05-19-cross-repo-fact-tracking.md records: “Pipeline DAG extension: added fact-check as phase 3.5 immediately after review. Added control to return to write on fact-check fail.”

Effects After Implementation — What Changes

Here is a concrete breakdown of what changes when fact-check enters the pipeline.

Before: The writing skill writes timelines from guesswork → review checks only style → fabrication may reach publication

After: The writing skill writes by referencing git log → review checks only style → fact-check reconciles timelines against git log → fabrication is detected as FAIL

Responsibility boundary between review and fact-check:

This table defines the responsibility boundary between the two skills. review can say YES while fact-check returns FAIL. The reverse is also true. Each functions as an independent gate, providing layered quality assurance.

→ For advance preparation of the permission allow-list, see Permission Allow-List Setup as a Prerequisite

Related Articles

• AI Agent Harness Design Principles — Responsibility Assignment, Skill Delegation, and Fallbacks — Pillar