What Is the Triple Verification (TV) Process in Cangjie-Skill? A 3-Stage Filter for AI Skill Candidates

The Triple Verification (TV) process is a rigorous three-gate quality filter in the cangjie-skill pipeline that promotes only candidates appearing in multiple contexts, demonstrating predictive power, and offering unique insights, while rejecting generic or anecdotal content.

The Triple Verification (TV) process forms the core quality assurance layer of the cangjie-skill repository (kangarooking/cangjie-skill), implementing the RIA-TV++ methodology that transforms raw book excerpts into autonomous AI skills. This stage acts as a triage mechanism between parallel extraction and skill construction, ensuring only high-signal methodological units survive to become agent-ready modules.

What Is the Triple Verification (TV) Process?

The TV process serves as the Stage 1.5 gate in the RIA-TV++ pipeline, positioned after parallel extractors generate candidate pools but before RIA++ construction begins. According to methodology/00-overview.md, TV applies three independent checks to determine whether a candidate deserves full skill status or should be downgraded to examples, quotes, or glossary entries.

Only candidates that pass all three verifications advance to become autonomous skill modules with executable steps, boundaries, and test prompts. The methodology is fully specified in methodology/03-stage1.5-triple-verify.md and referenced as a core invariant in SKILL.md.

How TV Filters Candidates: The Execution Pipeline

The filtering logic follows a strict five-step workflow documented in the source methodology:

1. Candidate Pool Creation – Five parallel extractors produce raw outputs in candidates/*.md.
2. Deduplication – Identical units extracted by multiple extractors are merged to avoid redundancy.
3. Triple Verification Loop – Each merged candidate undergoes V1, V2, and V3 sequentially.
4. Result Recording – Passed candidates write to books/<slug>/verified.md; failed entries log to books/<slug>/rejected/<id>.md with explicit failure reasons.
5. User Confirmation – A UI prompt displays passed/failed titles, allowing manual approval before construction proceeds.

The Three Verification Gates Explained

Each gate targets a specific failure mode in knowledge extraction.

V1 – Cross-Domain Verification (跨域验证)

V1 validates that the candidate appears in at least two distinct contexts within the source material—different chapters, stories, or objects. This check guarantees the method represents a stable, recurring insight rather than a one-off anecdote.

V2 – Predictive Power Test (预测力测试)

V2 requires the candidate to solve a novel problem not explicitly addressed in the original text. The test designs a new scenario, applies the principle, and verifies the output provides meaningful, non-trivial answers. This ensures the insight possesses extrapolation ability beyond its original examples.

V3 – Exclusivity Check (独特性检验)

V3 filters generic common sense by verifying the insight is non-obvious—a knowledgeable person without the book’s specific context should not readily state it. This preserves only the author’s unique perspective, eliminating commonplace observations.

Implementation: Code and Configuration Examples

The TV process is accessible via Python API and CLI tools.

Programmatic Verification

Use the TripleVerifier class to verify candidates programmatically:

from cangjie_skill.triple_verify import TripleVerifier

candidate = {
    "title": "逆向思维",
    "content": "…（原文摘录）…"
}

verifier = TripleVerifier(book_id="charlie-almanack")
result = verifier.run_all(candidate)

print(result.passed)  # True only if V1, V2, V3 all succeed

print(result.report)  # Detailed pass/fail reasons

Output Schema

Successful candidates generate structured YAML records in books/<slug>/verified.md:

id: f01
title: 逆向思维
type: framework
V1_cross_domain:
  passed: true
  evidence:
    - 第 3 讲: 投资决策场景
    - 第 7 讲: 工程设计场景
    - 第 11 讲: 教学方法场景
V2_predictive_power:
  passed: true
  novel_question: "如果面试官问我一个不知道答案的问题该怎么办?"
  derived_answer: "逆问'我最不希望他认为我是什么样的人',从这个反面倒推应该展现什么"
V3_exclusivity:
  passed: true
  why_not_common: "常识是'要多想',逆向思维是'优先反着想' — 这是反直觉的排序"

CLI Invocation

Run the complete pipeline via the cangjie-skill CLI:

cangjie-skill verify \
  --candidates-dir candidates/ \
  --book-id charlie-almanack \
  --output-dir books/charlie-almanack/

This command populates verified.md and the rejected/ directory automatically.

Key Source Files in the Repository

The TV implementation spans several critical files:

• methodology/00-overview.md – High-level RIA-TV++ architecture and TV’s strategic role.
• methodology/03-stage1.5-triple-verify.md – Complete V1/V2/V3 specifications and execution flow.
• SKILL.md – Master skill definition listing TV as a core invariant.
• templates/SKILL.md.template – Template showing the "V1 ✓ / V2 ✓ / V3 ✓" status line.
• extractors/ – Parallel extraction modules feeding candidates into TV.
• scripts/ – Pipeline orchestration scripts invoking TV at Stage 1.5.

Summary

• The Triple Verification (TV) process is the quality gate between extraction and skill construction in the cangjie-skill pipeline.
• Three independent checks—Cross-Domain (V1), Predictive Power (V2), and Exclusivity (V3)—filter candidates.
• Only candidates passing all three gates advance to books/<slug>/verified.md; failures route to books/<slug>/rejected/<id>.md.
• The TripleVerifier class and cangjie-skill verify CLI provide programmatic and command-line interfaces.
• TV ensures final skills are high-signal, agent-ready modules rather than generic or anecdotal content.

Frequently Asked Questions

What happens if a candidate fails only one verification?

A candidate must pass all three verifications (V1, V2, and V3) to advance. If any single check fails, the candidate is immediately downgraded and written to books/<slug>/rejected/<id>.md with specific failure reasons, preventing partial or weak insights from entering the skill construction phase.

How does TV differ from standard deduplication?

While deduplication merges identical candidates from multiple extractors, TV evaluates semantic quality and applicability. Deduplication handles redundancy; TV assesses whether the insight is recurring (V1), transferable (V2), and unique (V3). This occurs after deduplication in the Stage 1.5 pipeline.

Can the verification thresholds be customized per book?

The current implementation in methodology/03-stage1.5-triple-verify.md defines fixed criteria for V1, V2, and V3. However, the TripleVerifier class accepts book-specific contexts via the book_id parameter, allowing the predictive power tests (V2) and exclusivity checks (V3) to adapt to the specific domain knowledge of each source text.

Is the TV process fully automated or does it require manual review?

The pipeline runs V1, V2, and V3 automatically via scripts/ orchestration, but includes a mandatory user confirmation step. After generating verified.md and rejected/ logs, the UI prompts operators to approve or reject "passed" items before RIA++ construction, ensuring human oversight of the final skill set.

{
  "mcpServers": {
    "instagit": {
      "command": "npx",
      "args": ["-y", "instagit@latest"]
    }
  }
}