What's the difference between Clarity Gate and other hedge-detection tools like UnScientify?

Clarity Gate doesn't just detect existing hedge words in text — it flags claims that SHOULD be hedged but aren't. For example, it catches a bare statement like 'Revenue will be $50M' and flags it as needing a 'projected' qualifier, whereas other tools only find hedges already present in the document.

Can Clarity Gate verify whether claims are actually true?

No. Clarity Gate verifies only the FORM of claims — whether they're properly marked as uncertain — but cannot verify if claims are actually true. An LLM could hallucinate a false fact and still pass Clarity Gate if a source marker is added, which is why mandatory two-round human-in-the-loop verification is required before declaring a document PASS.

What are the nine verification points Clarity Gate runs?

Points 1-4 are epistemic checks: hypothesis-vs-fact labeling, uncertainty markers on forward-looking statements, assumption visibility, and flagging authoritative-looking unvalidated data. Points 5-7 are data quality checks: data consistency, implicit causation, and future states presented as present. Points 8-9 handle verification routing.

What does the Clarity Gate Document (CGD) output include?

The CGD report flags claims across the nine verification points with severity levels (Critical, Warning, Temporal), includes claim IDs and document hashes for tracking, and records a two-round human verification process — Round A for derived data confirmation and Round B for true human verification.

When should I use Clarity Gate?

Use it when reviewing AI-generated or AI-assisted documents (business plans, technical specs, reports) for improperly hedged claims, unmarked hypotheticals, inconsistent data, or future states described as already achieved — before the document is treated as a source of truth.

Skill

Enforce Epistemic Quality in Documents

Name: Clarity Gate v2.1
Availability: OnlineOnly
Author: Antigravity

A pre-ingestion RAG verification skill that enforces uncertainty markers on unverified claims before documents reach an LLM.

Get skill

Works with github

Antigravity

Own this? Claim it

Spark score

out of 100

Updated last month

Version 13.1.0

Add to Favorites

Why it matters

Ensure documents meet strict epistemic quality standards before entering RAG knowledge bases. This skill verifies claims, enforces uncertainty markers, and validates document structure to prevent hallucinations.

Outcomes

What it gets done

Pre-ingestion verification of document claims and structure.

Enforce uncertainty markers for forward-looking statements.

Validate document compliance with the Clarity Gate Format Specification v2.1.

Generate deterministic claim IDs and document hashes using bundled scripts.

Install

Add it to your toolbox

Run in your project directory:

curl -fsSL https://spark.entire.vc/get/ag-clarity-gate | bash

Overview

Clarity Gate v2.1

A pre-ingestion RAG verification skill enforcing uncertainty markers on unvalidated claims through 9 checks and mandatory two-round HITL verification. Use it before ingesting documents into RAG systems, sharing with other AI systems, or handing documentation between LLM sessions.

What it does

Clarity Gate is a pre-ingestion verification system, currently at v2.1, that enforces epistemic quality before documents enter RAG knowledge bases, producing Clarity-Gated Documents (CGD) compliant with the Clarity Gate Format Specification. Its core question is whether another LLM reading the document would mistake an assumption for a fact. Unlike detection tools such as UnScientify or HedgeHunter, which only ask "does this text contain hedges already present", Clarity Gate enforces presence where epistemically required - it flags a claim like "Revenue will be $50M" even though no hedge word appears at all. Its critical, explicitly stated limitation is that it verifies FORM, not TRUTH: it checks whether claims are properly marked as uncertain, not whether they are actually true, and an LLM could hallucinate a fact into a document and still "pass" by adding a source marker to a false claim - which is why Human-In-The-Loop (HITL) verification is mandatory before any document can be declared PASS.

Review runs against 9 Verification Points across three groups: epistemic checks (hypothesis-vs-fact labeling, uncertainty-marker enforcement on forward-looking statements, explicit assumption visibility, and flagging authoritative-looking unvalidated data tables), data-quality checks (internal data consistency, implicit causation without evidence, future state described as present), and verification routing (temporal coherence of dates/versions, and flagging externally verifiable numeric claims like pricing or statistics for fact-check). Verification itself follows a two-tier hierarchy: Tier 1 is automated - internal consistency checks plus an external-verification extension interface to connectors like financial systems or Git - while Tier 2 is mandatory two-round HITL: Round A has a human confirm interpretation of claims already backed by a source found in-session, Round B requires true human verification for claims with no source, extrapolations, or the human's own data.

A bundled script computes deterministic, hash-based claim IDs for HITL tracking:

### Generate claim ID
python scripts/claim_id.py "Base price is $99/mo" "api-pricing/1"
### Output: claim-75fb137a

### Run test vectors
python scripts/claim_id.py --test

When to use - and when NOT to

Use this skill before ingesting documents into RAG systems or sharing them with other AI systems, after writing specifications or methodology descriptions, when a document contains projections/estimates/hypotheses, before publishing unvalidated claims, or when handing documentation off between LLM sessions. It explicitly does NOT classify document types, restructure documents, add deep links or references, evaluate writing quality, or check factual accuracy autonomously - all of those require either a different tool or mandatory HITL.

Inputs and outputs

Input is a draft document; output is either a Clarity Gate Results report (issues grouped as Critical/Warning/Temporal/Externally-Verifiable, plus Round A and Round B HITL confirmation requests) or a finished CGD file with YAML frontmatter fields (clarity-gate-version, processed-date, clarity-status, hitl-status, hitl-pending-count, points-passed, a document-sha256 integrity hash, and a hitl-claims list) and an ## HITL Verification Record body section. Claim verification state is determined by field presence rather than an explicit status flag: a claim with no confirmed-by/confirmed-date is PENDING, both fields present means VERIFIED, and one-without-the-other triggers a partial-fields warning. Source of Truth (SOT) files are validated the same way plus a required ## Verified Claims table (columns Claim/Value/Source/Verified, in that order) and staleness markers ([STABLE], [CHECK], [VOLATILE], [SNAPSHOT]). Content that cannot be resolved gets wrapped in an explicit exclusion block rather than left ambiguous - but a document containing any exclusion block is not RAG-ingestable and is rejected entirely, no partial ingestion.

Integrations

Clarity Gate is one of a small family of related projects: Source of Truth Creator (for authoring epistemically calibrated documents from scratch), Stream Coding (a documentation-first methodology), and ArXiParse (scientific paper verification) - Clarity Gate is the pre-ingestion gate that sits downstream of document authoring and upstream of RAG ingestion.

Who it's for

Teams preparing documents for RAG ingestion or cross-LLM handoff who need a mandatory, HITL-backed epistemic check - distinguishing verified fact from hedged hypothesis - rather than trusting that a document's confident tone reflects verified truth.

FAQ

Common questions

Discussion