{ "schemaVersion": "1.0", "item": { "slug": "clarity-gate", "name": "Clarity Gate", "source": "tencent", "type": "skill", "category": "AI 智能", "sourceUrl": "https://clawhub.ai/frmoretto/clarity-gate", "canonicalUrl": "https://clawhub.ai/frmoretto/clarity-gate", "targetPlatform": "OpenClaw" }, "install": { "downloadMode": "redirect", "downloadUrl": "/downloads/clarity-gate", "sourceDownloadUrl": "https://wry-manatee-359.convex.site/api/v1/download?slug=clarity-gate", "sourcePlatform": "tencent", "targetPlatform": "OpenClaw", "installMethod": "Manual import", "extraction": "Extract archive", "prerequisites": [ "OpenClaw" ], "packageFormat": "ZIP package", "includedAssets": [ "SKILL.md", "scripts/claim_id.py", "scripts/document_hash.py" ], "primaryDoc": "SKILL.md", "quickSetup": [ "Download the package from Yavira.", "Extract the archive and review SKILL.md first.", "Import or place the package into your OpenClaw setup." ], "agentAssist": { "summary": "Hand the extracted package to your coding agent with a concrete install brief instead of figuring it out manually.", "steps": [ "Download the package from Yavira.", "Extract it into a folder your agent can access.", "Paste one of the prompts below and point your agent at the extracted folder." ], "prompts": [ { "label": "New install", "body": "I downloaded a skill package from Yavira. Read SKILL.md from the extracted folder and install it by following the included instructions. Tell me what you changed and call out any manual steps you could not complete." }, { "label": "Upgrade existing", "body": "I downloaded an updated skill package from Yavira. Read SKILL.md from the extracted folder, compare it with my current installation, and upgrade it while preserving any custom configuration unless the package docs explicitly say otherwise. Summarize what changed and any follow-up checks I should run." } ] }, "sourceHealth": { "source": "tencent", "status": "healthy", "reason": "direct_download_ok", "recommendedAction": "download", "checkedAt": "2026-04-23T16:43:11.935Z", "expiresAt": "2026-04-30T16:43:11.935Z", "httpStatus": 200, "finalUrl": "https://wry-manatee-359.convex.site/api/v1/download?slug=4claw-imageboard", "contentType": "application/zip", "probeMethod": "head", "details": { "probeUrl": "https://wry-manatee-359.convex.site/api/v1/download?slug=4claw-imageboard", "contentDisposition": "attachment; filename=\"4claw-imageboard-1.0.1.zip\"", "redirectLocation": null, "bodySnippet": null }, "scope": "source", "summary": "Source download looks usable.", "detail": "Yavira can redirect you to the upstream package for this source.", "primaryActionLabel": "Download for OpenClaw", "primaryActionHref": "/downloads/clarity-gate" }, "validation": { "installChecklist": [ "Use the Yavira download entry.", "Review SKILL.md after the package is downloaded.", "Confirm the extracted package contains the expected setup assets." ], "postInstallChecks": [ "Confirm the extracted package includes the expected docs or setup files.", "Validate the skill or prompts are available in your target agent workspace.", "Capture any manual follow-up steps the agent could not complete." ] }, "downloadPageUrl": "https://openagent3.xyz/downloads/clarity-gate", "agentPageUrl": "https://openagent3.xyz/skills/clarity-gate/agent", "manifestUrl": "https://openagent3.xyz/skills/clarity-gate/agent.json", "briefUrl": "https://openagent3.xyz/skills/clarity-gate/agent.md" }, "agentAssist": { "summary": "Hand the extracted package to your coding agent with a concrete install brief instead of figuring it out manually.", "steps": [ "Download the package from Yavira.", "Extract it into a folder your agent can access.", "Paste one of the prompts below and point your agent at the extracted folder." ], "prompts": [ { "label": "New install", "body": "I downloaded a skill package from Yavira. Read SKILL.md from the extracted folder and install it by following the included instructions. Tell me what you changed and call out any manual steps you could not complete." }, { "label": "Upgrade existing", "body": "I downloaded an updated skill package from Yavira. Read SKILL.md from the extracted folder, compare it with my current installation, and upgrade it while preserving any custom configuration unless the package docs explicitly say otherwise. Summarize what changed and any follow-up checks I should run." } ] }, "documentation": { "source": "clawhub", "primaryDoc": "SKILL.md", "sections": [ { "title": "Clarity Gate v2.1", "body": "Purpose: Pre-ingestion verification system that enforces epistemic quality before documents enter RAG knowledge bases. Produces Clarity-Gated Documents (CGD) compliant with the Clarity Gate Format Specification v2.1.\n\nCore Question: \"If another LLM reads this document, will it mistake assumptions for facts?\"\n\nCore Principle: \"Detection finds what is; enforcement ensures what should be. In practice: find the missing uncertainty markers before they become confident hallucinations.\"" }, { "title": "What's New in v2.1", "body": "FeatureDescriptionClaim Completion StatusPENDING/VERIFIED determined by field presence (no explicit status field)Source Field SemanticsActionable source (PENDING) vs. what-was-found (VERIFIED)Claim ID Format GuidanceHash-based IDs preferred, collision analysis for scaleBody Structure RequirementsHITL Verification Record section mandatory when claims existNew Validation CodesE-ST10, W-ST11, W-HC01, W-HC02, E-SC06 (FORMAT_SPEC); E-TB01-07 (SOT validation)Bundled Scriptsclaim_id.py and document_hash.py for deterministic computations" }, { "title": "Specifications", "body": "This skill implements and references:\n\nSpecificationVersionLocationClarity Gate Format (Unified)v2.1docs/CLARITY_GATE_FORMAT_SPEC.md\n\nNote: v2.0 unifies CGD and SOT into a single .cgd.md format. SOT is now a CGD with an optional tier: block." }, { "title": "Validation Codes", "body": "Clarity Gate defines validation codes for structural and semantic checks per FORMAT_SPEC v2.1:" }, { "title": "HITL Claim Validation (§1.3.2-1.3.3)", "body": "CodeCheckSeverityW-HC01Partial confirmed-by/confirmed-date fieldsWARNINGW-HC02Vague source (e.g., \"industry reports\", \"TBD\")WARNINGE-SC06Schema error in hitl-claims structureERROR" }, { "title": "Body Structure (§1.2.1)", "body": "CodeCheckSeverityE-ST10Missing ## HITL Verification Record when claims existERRORW-ST11Table rows don't match hitl-claims countWARNING" }, { "title": "SOT Table Validation (§3.1)", "body": "CodeCheckSeverityE-TB01No ## Verified Claims sectionERRORE-TB02Table has no data rowsERRORE-TB03Required columns missingERRORE-TB04Column order wrongERRORE-TB05Empty cell in required columnERRORE-TB06Invalid date format in Verified columnERRORE-TB07Verified date in future (beyond 24h grace)ERROR\n\nNote: Additional validation codes may be defined in RFC-001 (clarification document) but are not part of the normative FORMAT_SPEC." }, { "title": "Bundled Scripts", "body": "This skill includes Python scripts for deterministic computations per FORMAT_SPEC." }, { "title": "scripts/claim_id.py", "body": "Computes stable, hash-based claim IDs for HITL tracking (per §1.3.4).\n\n# Generate claim ID\npython scripts/claim_id.py \"Base price is $99/mo\" \"api-pricing/1\"\n# Output: claim-75fb137a\n\n# Run test vectors\npython scripts/claim_id.py --test\n\nAlgorithm:\n\nNormalize text (strip + collapse whitespace)\nConcatenate with location using pipe delimiter\nSHA-256 hash, take first 8 hex chars\nPrefix with \"claim-\"\n\nTest vectors:\n\nclaim_id(\"Base price is $99/mo\", \"api-pricing/1\") → claim-75fb137a\nclaim_id(\"The API supports GraphQL\", \"features/1\") → claim-eb357742" }, { "title": "scripts/document_hash.py", "body": "Computes document SHA-256 hash per FORMAT_SPEC §2.2-2.4 with full canonicalization.\n\n# Compute hash\npython scripts/document_hash.py my-doc.cgd.md\n# Output: 7d865e959b2466918c9863afca942d0fb89d7c9ac0c99bafc3749504ded97730\n\n# Verify existing hash\npython scripts/document_hash.py --verify my-doc.cgd.md\n# Output: PASS: Hash verified: 7d865e...\n\n# Run normalization tests\npython scripts/document_hash.py --test\n\nAlgorithm (per §2.2-2.4):\n\nExtract content between opening ---\\n and \nRemove document-sha256 line from YAML frontmatter ONLY (with multiline continuation support)\nCanonicalize:\n\nStrip trailing whitespace per line\nCollapse 3+ consecutive newlines to 2\nNormalize final newline (exactly 1 LF)\nUTF-8 NFC normalization\n\n\nCompute SHA-256\n\nCross-platform normalization:\n\nBOM removed if present\nCRLF to LF (Windows)\nCR to LF (old Mac)\nBoundary detection (prevents hash computation on content outside CGD structure)\nWhitespace variations produce identical hashes (deterministic across platforms)" }, { "title": "The Key Distinction", "body": "Existing tools like UnScientify and HedgeHunter (CoNLL-2010) detect uncertainty markers already present in text (\"Is uncertainty expressed?\").\n\nClarity Gate enforces their presence where epistemically required (\"Should uncertainty be expressed but isn't?\").\n\nTool TypeQuestionExampleDetection\"Does this text contain hedges?\"UnScientify/HedgeHunter find \"may\", \"possibly\"Enforcement\"Should this claim be hedged but isn't?\"Clarity Gate flags \"Revenue will be $50M\"" }, { "title": "Critical Limitation", "body": "Clarity Gate verifies FORM, not TRUTH.\nThis skill checks whether claims are properly marked as uncertain—it cannot verify if claims are actually true.\nRisk: An LLM can hallucinate facts INTO a document, then \"pass\" Clarity Gate by adding source markers to false claims.\nSolution: HITL (Human-In-The-Loop) verification is MANDATORY before declaring PASS." }, { "title": "When to Use", "body": "Before ingesting documents into RAG systems\nBefore sharing documents with other AI systems\nAfter writing specifications, state docs, or methodology descriptions\nWhen a document contains projections, estimates, or hypotheses\nBefore publishing claims that haven't been validated\nWhen handing off documentation between LLM sessions" }, { "title": "Relationship to Spec Suite", "body": "The 9 Verification Points guide semantic review — content quality checks that require judgment (human or AI). They answer questions like \"Should this claim be hedged?\" and \"Are these numbers consistent?\"\n\nWhen review completes, output a CGD file conforming to CLARITY_GATE_FORMAT_SPEC.md. The C/S rules in CLARITY_GATE_FORMAT_SPEC.md validate file structure, not semantic content.\n\nThe connection:\n\nSemantic findings (9 points) determine what issues exist\nIssues are recorded in CGD state fields (clarity-status, hitl-status, hitl-pending-count)\nState consistency is enforced by structural rules (C7-C10)\n\nExample: If Point 5 (Data Consistency) finds conflicting numbers, you'd mark clarity-status: UNCLEAR until resolved. Rule C7 then ensures you can't claim REVIEWED while still UNCLEAR." }, { "title": "Epistemic Checks (Core Focus: Points 1-4)", "body": "1. HYPOTHESIS vs FACT LABELING\nEvery claim must be clearly marked as validated or hypothetical.\n\nFailsPasses\"Our architecture outperforms competitors\"\"Our architecture outperforms competitors [benchmark data in Table 3]\"\"The model achieves 40% improvement\"\"The model achieves 40% improvement [measured on dataset X]\"\n\nFix: Add markers: \"PROJECTED:\", \"HYPOTHESIS:\", \"UNTESTED:\", \"(estimated)\", \"~\", \"?\"\n\n2. UNCERTAINTY MARKER ENFORCEMENT\nForward-looking statements require qualifiers.\n\nFailsPasses\"Revenue will be $50M by Q4\"\"Revenue is projected to be $50M by Q4\"\"The feature will reduce churn\"\"The feature is expected to reduce churn\"\n\nFix: Add \"projected\", \"estimated\", \"expected\", \"designed to\", \"intended to\"\n\n3. ASSUMPTION VISIBILITY\nImplicit assumptions that affect interpretation must be explicit.\n\nFailsPasses\"The system scales linearly\"\"The system scales linearly [assuming <1000 concurrent users]\"\"Response time is 50ms\"\"Response time is 50ms [under standard load conditions]\"\n\nFix: Add bracketed conditions: \"[assuming X]\", \"[under conditions Y]\", \"[when Z]\"\n\n4. AUTHORITATIVE-LOOKING UNVALIDATED DATA\nTables with specific percentages and checkmarks look like measured data.\n\nRed flag: Tables with specific numbers (89%, 95%, 100%) without sources\n\nFix: Add \"(guess)\", \"(est.)\", \"?\" to numbers. Add explicit warning: \"PROJECTED VALUES - NOT MEASURED\"" }, { "title": "Data Quality Checks (Complementary: Points 5-7)", "body": "5. DATA CONSISTENCY\nScan for conflicting numbers, dates, or facts within the document.\n\nRed flag: \"500 users\" in one section, \"750 users\" in another\n\nFix: Reconcile conflicts or explicitly note the discrepancy with explanation.\n\n6. IMPLICIT CAUSATION\nClaims that imply causation without evidence.\n\nRed flag: \"Shorter prompts improve response quality\" (plausible but unproven)\n\nFix: Reframe as hypothesis: \"Shorter prompts MAY improve response quality (hypothesis, not validated)\"\n\n7. FUTURE STATE AS PRESENT\nDescribing planned/hoped outcomes as if already achieved.\n\nRed flag: \"The system processes 10,000 requests per second\" (when it hasn't been built)\n\nFix: Use future/conditional: \"The system is DESIGNED TO process...\" or \"TARGET: 10,000 rps\"" }, { "title": "Verification Routing (Points 8-9)", "body": "8. TEMPORAL COHERENCE\nDocument dates and timestamps must be internally consistent and plausible.\n\nFailsPasses\"Last Updated: December 2024\" (when current is 2026)\"Last Updated: January 2026\"v1.0.0 dated 2024-12-23, v1.1.0 dated 2024-12-20Versions in chronological order\n\nSub-checks:\n\nDocument date vs current date\nInternal chronology (versions, events in order)\nReference freshness (\"current\", \"now\", \"today\" claims)\n\nFix: Update dates, add \"as of [date]\" qualifiers, flag stale claims\n\n9. EXTERNALLY VERIFIABLE CLAIMS\nSpecific numbers that could be fact-checked should be flagged for verification.\n\nTypeExampleRiskPricing\"Costs ~$0.005 per call\"API pricing changesStatistics\"Papers average 15-30 equations\"May be wildly offRates/ratios\"40% of researchers use X\"Needs citationCompetitor claims\"No competitor offers Y\"May be outdated\n\nFix options:\n\nAdd source with date\nAdd uncertainty marker\nRoute to HITL or external search\nGeneralize (\"low cost\" instead of \"$0.005\")" }, { "title": "The Verification Hierarchy", "body": "Claim Extracted --> Does Source of Truth Exist?\n |\n +---------------+---------------+\n YES NO\n | |\n Tier 1: Automated Tier 2: HITL\n Consistency & Verification Two-Round Verification\n | |\n PASS / BLOCK Round A → Round B → APPROVE / REJECT" }, { "title": "Tier 1: Automated Verification", "body": "A. Internal Consistency\n\nFigure vs. Text contradictions\nAbstract vs. Body mismatches\nTable vs. Prose conflicts\nNumerical consistency\n\nB. External Verification (Extension Interface)\n\nUser-provided connectors to structured sources\nFinancial systems, Git commits, CRM, etc." }, { "title": "Tier 2: Two-Round HITL Verification — MANDATORY", "body": "Round A: Derived Data Confirmation\n\nClaims from sources found in session\nHuman confirms interpretation, not truth\n\nRound B: True HITL Verification\n\nClaims needing actual verification\nNo source found, human's own data, extrapolations" }, { "title": "CGD Output Format", "body": "When producing a Clarity-Gated Document, use this format per CLARITY_GATE_FORMAT_SPEC.md v2.1:\n\n---\nclarity-gate-version: 2.1\nprocessed-date: 2026-01-12\nprocessed-by: Claude + Human Review\nclarity-status: CLEAR\nhitl-status: REVIEWED\nhitl-pending-count: 0\npoints-passed: 1-9\nrag-ingestable: true # computed by validator - do not set manually\ndocument-sha256: 7d865e959b2466918c9863afca942d0fb89d7c9ac0c99bafc3749504ded97730\nhitl-claims:\n - id: claim-75fb137a\n text: \"Revenue projection is $50M\"\n value: \"$50M\"\n source: \"Q3 planning doc\"\n location: \"revenue-projections/1\"\n round: B\n confirmed-by: Francesco\n confirmed-date: 2026-01-12\n---\n\n# Document Title\n\n[Document body with epistemic markers applied]\n\nClaims like \"Revenue will be $50M\" become \"Revenue is **projected** to be $50M *(unverified projection)*\"\n\n---\n\n## HITL Verification Record\n\n### Round A: Derived Data Confirmation\n- Claim 1 (source) ✓\n- Claim 2 (source) ✓\n\n### Round B: True HITL Verification\n| # | Claim | Status | Verified By | Date |\n|---|-------|--------|-------------|------|\n| 1 | [claim] | ✓ Confirmed | [name] | [date] |\n\n\nClarity Gate: CLEAR | REVIEWED\n\nRequired CGD Elements (per spec):\n\nYAML frontmatter with all required fields:\n\nclarity-gate-version — Tool version (no \"v\" prefix)\nprocessed-date — YYYY-MM-DD format\nprocessed-by — Processor name\nclarity-status — CLEAR or UNCLEAR\nhitl-status — PENDING, REVIEWED, or REVIEWED_WITH_EXCEPTIONS\nhitl-pending-count — Integer ≥ 0\npoints-passed — e.g., 1-9 or 1-4,7,9\nhitl-claims — List of verified claims (may be empty [])\n\n\nEnd marker (HTML comment + status line):\n\nClarity Gate: | \n\n\nHITL verification record (if status is REVIEWED)\n\nOptional/Computed Fields:\n\nrag-ingestable — Computed by validators, not manually set. Shows true only when CLEAR | REVIEWED with no exclusion blocks.\ndocument-sha256 — Required. 64-char lowercase hex hash for integrity verification. See spec §2 for computation rules.\nexclusions-coverage — Optional. Fraction of body inside exclusion blocks (0.0–1.0).\n\nEscape Mechanism: To write about markers like *(estimated)* without triggering parsing, wrap in backticks: `*(estimated)*`" }, { "title": "Claim Completion Status (v2.1)", "body": "Claim verification status is determined by field presence, not an explicit status field:\n\nStateconfirmed-byconfirmed-dateMeaningPENDINGabsentabsentAwaiting human verificationVERIFIEDpresentpresentHuman has confirmed(invalid)presentabsentW-HC01: partial fields(invalid)absentpresentW-HC01: partial fields\n\nWhy no explicit status field? Field presence is self-enforcing—you can't accidentally set status without providing who/when." }, { "title": "Source Field Semantics (v2.1)", "body": "The source field meaning changes based on claim state:\n\nStatesource ContainsExamplePENDINGWhere to verify (actionable)\"Check Q3 planning doc\"VERIFIEDWhat was found (evidence)\"Q3 planning doc, page 12\"\n\nVague source detection (W-HC02): Sources like \"industry reports\", \"research\", \"TBD\" trigger warnings." }, { "title": "Claim ID Format (v2.1)", "body": "General pattern: claim-[a-z0-9._-]{1,64} (alphanumeric, dots, underscores, hyphens)\n\nApproachPatternExampleUse CaseHash-based (preferred)claim-[a-f0-9]{8,}claim-75fb137aDeterministic, collision-resistantSequentialclaim-[0-9]+claim-1, claim-2Simple documentsSemanticclaim-[a-z0-9-]+claim-revenue-q3Human-friendly\n\nCollision probability: At 1,000 claims with 8-char hex IDs: ~0.012%. For >1,000 claims, use 12+ hex characters.\n\nRecommendation: Use hash-based IDs generated by scripts/claim_id.py for consistency and collision resistance." }, { "title": "Exclusion Blocks", "body": "When content cannot be resolved (no SME available, legacy prose, etc.), mark it as excluded rather than leaving it ambiguous:\n\n\nLegacy authentication details that require SME review...\n\n\nRules:\n\nIDs must match: [A-Za-z0-9][A-Za-z0-9._-]{0,63}\nNo nesting or overlapping blocks\nEach ID used only once\nRequires hitl-status: REVIEWED_WITH_EXCEPTIONS\nMust document exceptions-reason and exceptions-ids in frontmatter\n\nImportant: Documents with exclusion blocks are not RAG-ingestable. They're rejected entirely (no partial ingestion).\n\nSee CLARITY_GATE_FORMAT_SPEC.md §4 for complete rules." }, { "title": "SOT Validation", "body": "When validating a Source of Truth file, the skill checks both format compliance (per CLARITY_GATE_FORMAT_SPEC.md) and content quality (the 9 points)." }, { "title": "Format Compliance (Structural Rules)", "body": "SOT documents are CGDs with a tier: block. They require a ## Verified Claims section with a valid table.\n\nCodeCheckSeverityE-TB01No ## Verified Claims sectionERRORE-TB02Table has no data rowsERRORE-TB03Required columns missing (Claim, Value, Source, Verified)ERRORE-TB04Column order wrong (Claim not first or Verified not last)ERRORE-TB05Empty cell in required columnERRORE-TB06Invalid date format in Verified columnERRORE-TB07Verified date in future (beyond 24h grace)ERROR" }, { "title": "Content Quality (9 Points)", "body": "The 9 Verification Points apply to SOT content:\n\nPointSOT Application1-4Check claims in ## Verified Claims are actually verified5Check for conflicting values across tables6Check claims don't imply unsupported causation7Check table doesn't state futures as present8Check dates are chronologically consistent9Flag specific numbers for external check" }, { "title": "SOT-Specific Requirements", "body": "Tier block required: SOT is a CGD with tier: block containing level, owner, version, promoted-date, promoted-by\nStructured claims table: ## Verified Claims section with columns: Claim, Value, Source, Verified\nTable outside exclusions: The verified claims table must NOT be inside an exclusion block\nStaleness markers: Use [STABLE], [CHECK], [VOLATILE], [SNAPSHOT] in content\n\n[STABLE] — Safe to cite without rechecking\n[CHECK] — Verify before citing\n[VOLATILE] — Changes frequently; always verify\n[SNAPSHOT] — Point-in-time data; include date when citing" }, { "title": "Output Format", "body": "After running Clarity Gate, report:\n\n## Clarity Gate Results\n\n**Document:** [filename]\n**Issues Found:** [number]\n\n### Critical (will cause hallucination)\n- [issue + location + fix]\n\n### Warning (could cause equivocation) \n- [issue + location + fix]\n\n### Temporal (date/time issues)\n- [issue + location + fix]\n\n### Externally Verifiable Claims\n| # | Claim | Type | Suggested Verification |\n|---|-------|------|------------------------|\n| 1 | [claim] | Pricing | [where to verify] |\n\n---\n\n## Round A: Derived Data Confirmation\n\n- [claim] ([source])\n\nReply \"confirmed\" or flag any I misread.\n\n---\n\n## Round B: HITL Verification Required\n\n| # | Claim | Why HITL Needed | Human Confirms |\n|---|-------|-----------------|----------------|\n| 1 | [claim] | [reason] | [ ] True / [ ] False |\n\n---\n\n**Would you like me to produce an annotated CGD version?**\n\n---\n\n**Verdict:** PENDING CONFIRMATION" }, { "title": "Severity Levels", "body": "LevelDefinitionActionCRITICALLLM will likely treat hypothesis as factMust fix before useWARNINGLLM might misinterpretShould fixTEMPORALDate/time inconsistency detectedVerify and updateVERIFIABLESpecific claim that could be fact-checkedRoute to HITL or external searchROUND ADerived from witnessed sourceQuick confirmationROUND BRequires true verificationCannot pass without confirmationPASSClearly marked, no ambiguity, verifiedNo action needed" }, { "title": "Quick Scan Checklist", "body": "PatternActionSpecific percentages (89%, 73%)Add source or mark as estimateComparison tablesAdd \"PROJECTED\" header\"Achieves\", \"delivers\", \"provides\"Use \"designed to\", \"intended to\" if not validatedCheckmarksVerify these are confirmed\"100%\" anythingAlmost always needs qualification\"Last Updated: [date]\"Check against current dateVersion numbers with datesVerify chronological order\"$X.XX\" or \"~$X\" (pricing)Flag for external verification\"averages\", \"typically\"Flag for source/citationCompetitor capability claimsFlag for external verification" }, { "title": "What This Skill Does NOT Do", "body": "Does not classify document types (use Stream Coding for that)\nDoes not restructure documents\nDoes not add deep links or references\nDoes not evaluate writing quality\nDoes not check factual accuracy autonomously (requires HITL)" }, { "title": "Related Projects", "body": "ProjectPurposeURLSource of Truth CreatorCreate epistemically calibrated docsgithub.com/frmoretto/source-of-truth-creatorStream CodingDocumentation-first methodologygithub.com/frmoretto/stream-codingArXiParseScientific paper verificationarxiparse.org" }, { "title": "v2.1.3 (2026-03-02)", "body": "FIXED: document_hash.py now implements full FORMAT_SPEC §2.1-2.4 compliance\nFIXED: Fence-aware end marker detection (Quine Protection per §2.3/§8.5)\nFIXED: All 4 deployment copies converged to single canonical implementation\nADDED: canonicalize() function: trailing whitespace stripping, newline collapsing, NFC normalization\nADDED: YAML-aware document-sha256 removal with multiline continuation support (§2.2)\nADDED: Fence-tracking test vectors (7 new tests, 15 total)" }, { "title": "v2.1.0 (2026-01-27)", "body": "ADDED: Claim Completion Status semantics (PENDING/VERIFIED by field presence)\nADDED: Source Field Semantics (actionable vs. what-was-found)\nADDED: Claim ID Format guidance with collision analysis\nADDED: Body Structure Requirements (HITL Verification Record mandatory when claims exist)\nADDED: New validation codes: E-ST10, W-ST11, W-HC01, W-HC02, E-SC06 (FORMAT_SPEC §1.2-1.3)\nADDED: Bundled scripts: claim_id.py, document_hash.py\nUPDATED: References to FORMAT_SPEC v2.1\nUPDATED: CGD output example to version 2.1" }, { "title": "v2.0.0 (2026-01-13)", "body": "ADDED: agentskills.io compliant YAML frontmatter\nADDED: Clarity Gate Format Specification v2.0 compliance (unified CGD/SOT)\nADDED: SOT validation support with E-TB* error codes\nADDED: Validation rules mapping (9 points → rule codes)\nADDED: CGD output format template with markers\nADDED: Quine Protection note (§2.3 fence-aware marker detection)\nADDED: Redacted Export feature (§8.11)\nUPDATED: hitl-claims format to v2.0 schema (id, text, value, source, location, round)\nUPDATED: End marker format to HTML comment style\nUPDATED: Unified format spec v2.0 (single .cgd.md extension)\nRESTRUCTURED: For multi-platform skill discovery" }, { "title": "v1.6 (2025-12-31)", "body": "Added Two-Round HITL verification system\nRound A: Derived Data Confirmation\nRound B: True HITL Verification" }, { "title": "v1.5 (2025-12-28)", "body": "Added Point 8: Temporal Coherence\nAdded Point 9: Externally Verifiable Claims" }, { "title": "v1.4 (2025-12-23)", "body": "Added CGD annotation output mode" }, { "title": "v1.3 (2025-12-21)", "body": "Restructured points into Epistemic (1-4) and Data Quality (5-7)" }, { "title": "v1.2 (2025-12-21)", "body": "Added Source of Truth request step" }, { "title": "v1.1 (2025-12-21)", "body": "Added HITL Fact Verification (mandatory)" }, { "title": "v1.0 (2025-11)", "body": "Initial release with 6-point verification\n\nVersion: 2.1.3\nSpec Version: 2.1\nAuthor: Francesco Marinoni Moretto\nLicense: CC-BY-4.0" } ], "body": "Clarity Gate v2.1\n\nPurpose: Pre-ingestion verification system that enforces epistemic quality before documents enter RAG knowledge bases. Produces Clarity-Gated Documents (CGD) compliant with the Clarity Gate Format Specification v2.1.\n\nCore Question: \"If another LLM reads this document, will it mistake assumptions for facts?\"\n\nCore Principle: \"Detection finds what is; enforcement ensures what should be. In practice: find the missing uncertainty markers before they become confident hallucinations.\"\n\nWhat's New in v2.1\nFeature\tDescription\nClaim Completion Status\tPENDING/VERIFIED determined by field presence (no explicit status field)\nSource Field Semantics\tActionable source (PENDING) vs. what-was-found (VERIFIED)\nClaim ID Format Guidance\tHash-based IDs preferred, collision analysis for scale\nBody Structure Requirements\tHITL Verification Record section mandatory when claims exist\nNew Validation Codes\tE-ST10, W-ST11, W-HC01, W-HC02, E-SC06 (FORMAT_SPEC); E-TB01-07 (SOT validation)\nBundled Scripts\tclaim_id.py and document_hash.py for deterministic computations\nSpecifications\n\nThis skill implements and references:\n\nSpecification\tVersion\tLocation\nClarity Gate Format (Unified)\tv2.1\tdocs/CLARITY_GATE_FORMAT_SPEC.md\n\nNote: v2.0 unifies CGD and SOT into a single .cgd.md format. SOT is now a CGD with an optional tier: block.\n\nValidation Codes\n\nClarity Gate defines validation codes for structural and semantic checks per FORMAT_SPEC v2.1:\n\nHITL Claim Validation (§1.3.2-1.3.3)\nCode\tCheck\tSeverity\nW-HC01\tPartial confirmed-by/confirmed-date fields\tWARNING\nW-HC02\tVague source (e.g., \"industry reports\", \"TBD\")\tWARNING\nE-SC06\tSchema error in hitl-claims structure\tERROR\nBody Structure (§1.2.1)\nCode\tCheck\tSeverity\nE-ST10\tMissing ## HITL Verification Record when claims exist\tERROR\nW-ST11\tTable rows don't match hitl-claims count\tWARNING\nSOT Table Validation (§3.1)\nCode\tCheck\tSeverity\nE-TB01\tNo ## Verified Claims section\tERROR\nE-TB02\tTable has no data rows\tERROR\nE-TB03\tRequired columns missing\tERROR\nE-TB04\tColumn order wrong\tERROR\nE-TB05\tEmpty cell in required column\tERROR\nE-TB06\tInvalid date format in Verified column\tERROR\nE-TB07\tVerified date in future (beyond 24h grace)\tERROR\n\nNote: Additional validation codes may be defined in RFC-001 (clarification document) but are not part of the normative FORMAT_SPEC.\n\nBundled Scripts\n\nThis skill includes Python scripts for deterministic computations per FORMAT_SPEC.\n\nscripts/claim_id.py\n\nComputes stable, hash-based claim IDs for HITL tracking (per §1.3.4).\n\n# Generate claim ID\npython scripts/claim_id.py \"Base price is $99/mo\" \"api-pricing/1\"\n# Output: claim-75fb137a\n\n# Run test vectors\npython scripts/claim_id.py --test\n\n\nAlgorithm:\n\nNormalize text (strip + collapse whitespace)\nConcatenate with location using pipe delimiter\nSHA-256 hash, take first 8 hex chars\nPrefix with \"claim-\"\n\nTest vectors:\n\nclaim_id(\"Base price is $99/mo\", \"api-pricing/1\") → claim-75fb137a\nclaim_id(\"The API supports GraphQL\", \"features/1\") → claim-eb357742\nscripts/document_hash.py\n\nComputes document SHA-256 hash per FORMAT_SPEC §2.2-2.4 with full canonicalization.\n\n# Compute hash\npython scripts/document_hash.py my-doc.cgd.md\n# Output: 7d865e959b2466918c9863afca942d0fb89d7c9ac0c99bafc3749504ded97730\n\n# Verify existing hash\npython scripts/document_hash.py --verify my-doc.cgd.md\n# Output: PASS: Hash verified: 7d865e...\n\n# Run normalization tests\npython scripts/document_hash.py --test\n\n\nAlgorithm (per §2.2-2.4):\n\nExtract content between opening ---\\n and \nRemove document-sha256 line from YAML frontmatter ONLY (with multiline continuation support)\nCanonicalize:\nStrip trailing whitespace per line\nCollapse 3+ consecutive newlines to 2\nNormalize final newline (exactly 1 LF)\nUTF-8 NFC normalization\nCompute SHA-256\n\nCross-platform normalization:\n\nBOM removed if present\nCRLF to LF (Windows)\nCR to LF (old Mac)\nBoundary detection (prevents hash computation on content outside CGD structure)\nWhitespace variations produce identical hashes (deterministic across platforms)\nThe Key Distinction\n\nExisting tools like UnScientify and HedgeHunter (CoNLL-2010) detect uncertainty markers already present in text (\"Is uncertainty expressed?\").\n\nClarity Gate enforces their presence where epistemically required (\"Should uncertainty be expressed but isn't?\").\n\nTool Type\tQuestion\tExample\nDetection\t\"Does this text contain hedges?\"\tUnScientify/HedgeHunter find \"may\", \"possibly\"\nEnforcement\t\"Should this claim be hedged but isn't?\"\tClarity Gate flags \"Revenue will be $50M\"\nCritical Limitation\n\nClarity Gate verifies FORM, not TRUTH.\n\nThis skill checks whether claims are properly marked as uncertain—it cannot verify if claims are actually true.\n\nRisk: An LLM can hallucinate facts INTO a document, then \"pass\" Clarity Gate by adding source markers to false claims.\n\nSolution: HITL (Human-In-The-Loop) verification is MANDATORY before declaring PASS.\n\nWhen to Use\nBefore ingesting documents into RAG systems\nBefore sharing documents with other AI systems\nAfter writing specifications, state docs, or methodology descriptions\nWhen a document contains projections, estimates, or hypotheses\nBefore publishing claims that haven't been validated\nWhen handing off documentation between LLM sessions\nThe 9 Verification Points\nRelationship to Spec Suite\n\nThe 9 Verification Points guide semantic review — content quality checks that require judgment (human or AI). They answer questions like \"Should this claim be hedged?\" and \"Are these numbers consistent?\"\n\nWhen review completes, output a CGD file conforming to CLARITY_GATE_FORMAT_SPEC.md. The C/S rules in CLARITY_GATE_FORMAT_SPEC.md validate file structure, not semantic content.\n\nThe connection:\n\nSemantic findings (9 points) determine what issues exist\nIssues are recorded in CGD state fields (clarity-status, hitl-status, hitl-pending-count)\nState consistency is enforced by structural rules (C7-C10)\n\nExample: If Point 5 (Data Consistency) finds conflicting numbers, you'd mark clarity-status: UNCLEAR until resolved. Rule C7 then ensures you can't claim REVIEWED while still UNCLEAR.\n\nEpistemic Checks (Core Focus: Points 1-4)\n\n1. HYPOTHESIS vs FACT LABELING Every claim must be clearly marked as validated or hypothetical.\n\nFails\tPasses\n\"Our architecture outperforms competitors\"\t\"Our architecture outperforms competitors [benchmark data in Table 3]\"\n\"The model achieves 40% improvement\"\t\"The model achieves 40% improvement [measured on dataset X]\"\n\nFix: Add markers: \"PROJECTED:\", \"HYPOTHESIS:\", \"UNTESTED:\", \"(estimated)\", \"~\", \"?\"\n\n2. UNCERTAINTY MARKER ENFORCEMENT Forward-looking statements require qualifiers.\n\nFails\tPasses\n\"Revenue will be $50M by Q4\"\t\"Revenue is projected to be $50M by Q4\"\n\"The feature will reduce churn\"\t\"The feature is expected to reduce churn\"\n\nFix: Add \"projected\", \"estimated\", \"expected\", \"designed to\", \"intended to\"\n\n3. ASSUMPTION VISIBILITY Implicit assumptions that affect interpretation must be explicit.\n\nFails\tPasses\n\"The system scales linearly\"\t\"The system scales linearly [assuming <1000 concurrent users]\"\n\"Response time is 50ms\"\t\"Response time is 50ms [under standard load conditions]\"\n\nFix: Add bracketed conditions: \"[assuming X]\", \"[under conditions Y]\", \"[when Z]\"\n\n4. AUTHORITATIVE-LOOKING UNVALIDATED DATA Tables with specific percentages and checkmarks look like measured data.\n\nRed flag: Tables with specific numbers (89%, 95%, 100%) without sources\n\nFix: Add \"(guess)\", \"(est.)\", \"?\" to numbers. Add explicit warning: \"PROJECTED VALUES - NOT MEASURED\"\n\nData Quality Checks (Complementary: Points 5-7)\n\n5. DATA CONSISTENCY Scan for conflicting numbers, dates, or facts within the document.\n\nRed flag: \"500 users\" in one section, \"750 users\" in another\n\nFix: Reconcile conflicts or explicitly note the discrepancy with explanation.\n\n6. IMPLICIT CAUSATION Claims that imply causation without evidence.\n\nRed flag: \"Shorter prompts improve response quality\" (plausible but unproven)\n\nFix: Reframe as hypothesis: \"Shorter prompts MAY improve response quality (hypothesis, not validated)\"\n\n7. FUTURE STATE AS PRESENT Describing planned/hoped outcomes as if already achieved.\n\nRed flag: \"The system processes 10,000 requests per second\" (when it hasn't been built)\n\nFix: Use future/conditional: \"The system is DESIGNED TO process...\" or \"TARGET: 10,000 rps\"\n\nVerification Routing (Points 8-9)\n\n8. TEMPORAL COHERENCE Document dates and timestamps must be internally consistent and plausible.\n\nFails\tPasses\n\"Last Updated: December 2024\" (when current is 2026)\t\"Last Updated: January 2026\"\nv1.0.0 dated 2024-12-23, v1.1.0 dated 2024-12-20\tVersions in chronological order\n\nSub-checks:\n\nDocument date vs current date\nInternal chronology (versions, events in order)\nReference freshness (\"current\", \"now\", \"today\" claims)\n\nFix: Update dates, add \"as of [date]\" qualifiers, flag stale claims\n\n9. EXTERNALLY VERIFIABLE CLAIMS Specific numbers that could be fact-checked should be flagged for verification.\n\nType\tExample\tRisk\nPricing\t\"Costs ~$0.005 per call\"\tAPI pricing changes\nStatistics\t\"Papers average 15-30 equations\"\tMay be wildly off\nRates/ratios\t\"40% of researchers use X\"\tNeeds citation\nCompetitor claims\t\"No competitor offers Y\"\tMay be outdated\n\nFix options:\n\nAdd source with date\nAdd uncertainty marker\nRoute to HITL or external search\nGeneralize (\"low cost\" instead of \"$0.005\")\nThe Verification Hierarchy\nClaim Extracted --> Does Source of Truth Exist?\n |\n +---------------+---------------+\n YES NO\n | |\n Tier 1: Automated Tier 2: HITL\n Consistency & Verification Two-Round Verification\n | |\n PASS / BLOCK Round A → Round B → APPROVE / REJECT\n\nTier 1: Automated Verification\n\nA. Internal Consistency\n\nFigure vs. Text contradictions\nAbstract vs. Body mismatches\nTable vs. Prose conflicts\nNumerical consistency\n\nB. External Verification (Extension Interface)\n\nUser-provided connectors to structured sources\nFinancial systems, Git commits, CRM, etc.\nTier 2: Two-Round HITL Verification — MANDATORY\n\nRound A: Derived Data Confirmation\n\nClaims from sources found in session\nHuman confirms interpretation, not truth\n\nRound B: True HITL Verification\n\nClaims needing actual verification\nNo source found, human's own data, extrapolations\nCGD Output Format\n\nWhen producing a Clarity-Gated Document, use this format per CLARITY_GATE_FORMAT_SPEC.md v2.1:\n\n---\nclarity-gate-version: 2.1\nprocessed-date: 2026-01-12\nprocessed-by: Claude + Human Review\nclarity-status: CLEAR\nhitl-status: REVIEWED\nhitl-pending-count: 0\npoints-passed: 1-9\nrag-ingestable: true # computed by validator - do not set manually\ndocument-sha256: 7d865e959b2466918c9863afca942d0fb89d7c9ac0c99bafc3749504ded97730\nhitl-claims:\n - id: claim-75fb137a\n text: \"Revenue projection is $50M\"\n value: \"$50M\"\n source: \"Q3 planning doc\"\n location: \"revenue-projections/1\"\n round: B\n confirmed-by: Francesco\n confirmed-date: 2026-01-12\n---\n\n# Document Title\n\n[Document body with epistemic markers applied]\n\nClaims like \"Revenue will be $50M\" become \"Revenue is **projected** to be $50M *(unverified projection)*\"\n\n---\n\n## HITL Verification Record\n\n### Round A: Derived Data Confirmation\n- Claim 1 (source) ✓\n- Claim 2 (source) ✓\n\n### Round B: True HITL Verification\n| # | Claim | Status | Verified By | Date |\n|---|-------|--------|-------------|------|\n| 1 | [claim] | ✓ Confirmed | [name] | [date] |\n\n\nClarity Gate: CLEAR | REVIEWED\n\n\nRequired CGD Elements (per spec):\n\nYAML frontmatter with all required fields:\nclarity-gate-version — Tool version (no \"v\" prefix)\nprocessed-date — YYYY-MM-DD format\nprocessed-by — Processor name\nclarity-status — CLEAR or UNCLEAR\nhitl-status — PENDING, REVIEWED, or REVIEWED_WITH_EXCEPTIONS\nhitl-pending-count — Integer ≥ 0\npoints-passed — e.g., 1-9 or 1-4,7,9\nhitl-claims — List of verified claims (may be empty [])\nEnd marker (HTML comment + status line):\n\nClarity Gate: | \n\nHITL verification record (if status is REVIEWED)\n\nOptional/Computed Fields:\n\nrag-ingestable — Computed by validators, not manually set. Shows true only when CLEAR | REVIEWED with no exclusion blocks.\ndocument-sha256 — Required. 64-char lowercase hex hash for integrity verification. See spec §2 for computation rules.\nexclusions-coverage — Optional. Fraction of body inside exclusion blocks (0.0–1.0).\n\nEscape Mechanism: To write about markers like *(estimated)* without triggering parsing, wrap in backticks: `*(estimated)*`\n\nClaim Completion Status (v2.1)\n\nClaim verification status is determined by field presence, not an explicit status field:\n\nState\tconfirmed-by\tconfirmed-date\tMeaning\nPENDING\tabsent\tabsent\tAwaiting human verification\nVERIFIED\tpresent\tpresent\tHuman has confirmed\n(invalid)\tpresent\tabsent\tW-HC01: partial fields\n(invalid)\tabsent\tpresent\tW-HC01: partial fields\n\nWhy no explicit status field? Field presence is self-enforcing—you can't accidentally set status without providing who/when.\n\nSource Field Semantics (v2.1)\n\nThe source field meaning changes based on claim state:\n\nState\tsource Contains\tExample\nPENDING\tWhere to verify (actionable)\t\"Check Q3 planning doc\"\nVERIFIED\tWhat was found (evidence)\t\"Q3 planning doc, page 12\"\n\nVague source detection (W-HC02): Sources like \"industry reports\", \"research\", \"TBD\" trigger warnings.\n\nClaim ID Format (v2.1)\n\nGeneral pattern: claim-[a-z0-9._-]{1,64} (alphanumeric, dots, underscores, hyphens)\n\nApproach\tPattern\tExample\tUse Case\nHash-based (preferred)\tclaim-[a-f0-9]{8,}\tclaim-75fb137a\tDeterministic, collision-resistant\nSequential\tclaim-[0-9]+\tclaim-1, claim-2\tSimple documents\nSemantic\tclaim-[a-z0-9-]+\tclaim-revenue-q3\tHuman-friendly\n\nCollision probability: At 1,000 claims with 8-char hex IDs: ~0.012%. For >1,000 claims, use 12+ hex characters.\n\nRecommendation: Use hash-based IDs generated by scripts/claim_id.py for consistency and collision resistance.\n\nExclusion Blocks\n\nWhen content cannot be resolved (no SME available, legacy prose, etc.), mark it as excluded rather than leaving it ambiguous:\n\n\nLegacy authentication details that require SME review...\n\n\n\nRules:\n\nIDs must match: [A-Za-z0-9][A-Za-z0-9._-]{0,63}\nNo nesting or overlapping blocks\nEach ID used only once\nRequires hitl-status: REVIEWED_WITH_EXCEPTIONS\nMust document exceptions-reason and exceptions-ids in frontmatter\n\nImportant: Documents with exclusion blocks are not RAG-ingestable. They're rejected entirely (no partial ingestion).\n\nSee CLARITY_GATE_FORMAT_SPEC.md §4 for complete rules.\n\nSOT Validation\n\nWhen validating a Source of Truth file, the skill checks both format compliance (per CLARITY_GATE_FORMAT_SPEC.md) and content quality (the 9 points).\n\nFormat Compliance (Structural Rules)\n\nSOT documents are CGDs with a tier: block. They require a ## Verified Claims section with a valid table.\n\nCode\tCheck\tSeverity\nE-TB01\tNo ## Verified Claims section\tERROR\nE-TB02\tTable has no data rows\tERROR\nE-TB03\tRequired columns missing (Claim, Value, Source, Verified)\tERROR\nE-TB04\tColumn order wrong (Claim not first or Verified not last)\tERROR\nE-TB05\tEmpty cell in required column\tERROR\nE-TB06\tInvalid date format in Verified column\tERROR\nE-TB07\tVerified date in future (beyond 24h grace)\tERROR\nContent Quality (9 Points)\n\nThe 9 Verification Points apply to SOT content:\n\nPoint\tSOT Application\n1-4\tCheck claims in ## Verified Claims are actually verified\n5\tCheck for conflicting values across tables\n6\tCheck claims don't imply unsupported causation\n7\tCheck table doesn't state futures as present\n8\tCheck dates are chronologically consistent\n9\tFlag specific numbers for external check\nSOT-Specific Requirements\nTier block required: SOT is a CGD with tier: block containing level, owner, version, promoted-date, promoted-by\nStructured claims table: ## Verified Claims section with columns: Claim, Value, Source, Verified\nTable outside exclusions: The verified claims table must NOT be inside an exclusion block\nStaleness markers: Use [STABLE], [CHECK], [VOLATILE], [SNAPSHOT] in content\n[STABLE] — Safe to cite without rechecking\n[CHECK] — Verify before citing\n[VOLATILE] — Changes frequently; always verify\n[SNAPSHOT] — Point-in-time data; include date when citing\nOutput Format\n\nAfter running Clarity Gate, report:\n\n## Clarity Gate Results\n\n**Document:** [filename]\n**Issues Found:** [number]\n\n### Critical (will cause hallucination)\n- [issue + location + fix]\n\n### Warning (could cause equivocation) \n- [issue + location + fix]\n\n### Temporal (date/time issues)\n- [issue + location + fix]\n\n### Externally Verifiable Claims\n| # | Claim | Type | Suggested Verification |\n|---|-------|------|------------------------|\n| 1 | [claim] | Pricing | [where to verify] |\n\n---\n\n## Round A: Derived Data Confirmation\n\n- [claim] ([source])\n\nReply \"confirmed\" or flag any I misread.\n\n---\n\n## Round B: HITL Verification Required\n\n| # | Claim | Why HITL Needed | Human Confirms |\n|---|-------|-----------------|----------------|\n| 1 | [claim] | [reason] | [ ] True / [ ] False |\n\n---\n\n**Would you like me to produce an annotated CGD version?**\n\n---\n\n**Verdict:** PENDING CONFIRMATION\n\nSeverity Levels\nLevel\tDefinition\tAction\nCRITICAL\tLLM will likely treat hypothesis as fact\tMust fix before use\nWARNING\tLLM might misinterpret\tShould fix\nTEMPORAL\tDate/time inconsistency detected\tVerify and update\nVERIFIABLE\tSpecific claim that could be fact-checked\tRoute to HITL or external search\nROUND A\tDerived from witnessed source\tQuick confirmation\nROUND B\tRequires true verification\tCannot pass without confirmation\nPASS\tClearly marked, no ambiguity, verified\tNo action needed\nQuick Scan Checklist\nPattern\tAction\nSpecific percentages (89%, 73%)\tAdd source or mark as estimate\nComparison tables\tAdd \"PROJECTED\" header\n\"Achieves\", \"delivers\", \"provides\"\tUse \"designed to\", \"intended to\" if not validated\nCheckmarks\tVerify these are confirmed\n\"100%\" anything\tAlmost always needs qualification\n\"Last Updated: [date]\"\tCheck against current date\nVersion numbers with dates\tVerify chronological order\n\"$X.XX\" or \"~$X\" (pricing)\tFlag for external verification\n\"averages\", \"typically\"\tFlag for source/citation\nCompetitor capability claims\tFlag for external verification\nWhat This Skill Does NOT Do\nDoes not classify document types (use Stream Coding for that)\nDoes not restructure documents\nDoes not add deep links or references\nDoes not evaluate writing quality\nDoes not check factual accuracy autonomously (requires HITL)\nRelated Projects\nProject\tPurpose\tURL\nSource of Truth Creator\tCreate epistemically calibrated docs\tgithub.com/frmoretto/source-of-truth-creator\nStream Coding\tDocumentation-first methodology\tgithub.com/frmoretto/stream-coding\nArXiParse\tScientific paper verification\tarxiparse.org\nChangelog\nv2.1.3 (2026-03-02)\nFIXED: document_hash.py now implements full FORMAT_SPEC §2.1-2.4 compliance\nFIXED: Fence-aware end marker detection (Quine Protection per §2.3/§8.5)\nFIXED: All 4 deployment copies converged to single canonical implementation\nADDED: canonicalize() function: trailing whitespace stripping, newline collapsing, NFC normalization\nADDED: YAML-aware document-sha256 removal with multiline continuation support (§2.2)\nADDED: Fence-tracking test vectors (7 new tests, 15 total)\nv2.1.0 (2026-01-27)\nADDED: Claim Completion Status semantics (PENDING/VERIFIED by field presence)\nADDED: Source Field Semantics (actionable vs. what-was-found)\nADDED: Claim ID Format guidance with collision analysis\nADDED: Body Structure Requirements (HITL Verification Record mandatory when claims exist)\nADDED: New validation codes: E-ST10, W-ST11, W-HC01, W-HC02, E-SC06 (FORMAT_SPEC §1.2-1.3)\nADDED: Bundled scripts: claim_id.py, document_hash.py\nUPDATED: References to FORMAT_SPEC v2.1\nUPDATED: CGD output example to version 2.1\nv2.0.0 (2026-01-13)\nADDED: agentskills.io compliant YAML frontmatter\nADDED: Clarity Gate Format Specification v2.0 compliance (unified CGD/SOT)\nADDED: SOT validation support with E-TB* error codes\nADDED: Validation rules mapping (9 points → rule codes)\nADDED: CGD output format template with markers\nADDED: Quine Protection note (§2.3 fence-aware marker detection)\nADDED: Redacted Export feature (§8.11)\nUPDATED: hitl-claims format to v2.0 schema (id, text, value, source, location, round)\nUPDATED: End marker format to HTML comment style\nUPDATED: Unified format spec v2.0 (single .cgd.md extension)\nRESTRUCTURED: For multi-platform skill discovery\nv1.6 (2025-12-31)\nAdded Two-Round HITL verification system\nRound A: Derived Data Confirmation\nRound B: True HITL Verification\nv1.5 (2025-12-28)\nAdded Point 8: Temporal Coherence\nAdded Point 9: Externally Verifiable Claims\nv1.4 (2025-12-23)\nAdded CGD annotation output mode\nv1.3 (2025-12-21)\nRestructured points into Epistemic (1-4) and Data Quality (5-7)\nv1.2 (2025-12-21)\nAdded Source of Truth request step\nv1.1 (2025-12-21)\nAdded HITL Fact Verification (mandatory)\nv1.0 (2025-11)\nInitial release with 6-point verification\n\nVersion: 2.1.3 Spec Version: 2.1 Author: Francesco Marinoni Moretto License: CC-BY-4.0" }, "trust": { "sourceLabel": "tencent", "provenanceUrl": "https://clawhub.ai/frmoretto/clarity-gate", "publisherUrl": "https://clawhub.ai/frmoretto/clarity-gate", "owner": "frmoretto", "version": "2.1.3", "license": null, "verificationStatus": "Indexed source record" }, "links": { "detailUrl": "https://openagent3.xyz/skills/clarity-gate", "downloadUrl": "https://openagent3.xyz/downloads/clarity-gate", "agentUrl": "https://openagent3.xyz/skills/clarity-gate/agent", "manifestUrl": "https://openagent3.xyz/skills/clarity-gate/agent.json", "briefUrl": "https://openagent3.xyz/skills/clarity-gate/agent.md" } }