ClaimExtractor: Turning AI Conversations into Auditable Claims and Intents

Today we are releasing ClaimExtractor, an open-weight family of small language models (SLMs) that read AI conversations and extract the claims and intents expressed in them, turning free-form text into atomic, decontextualized statements you can audit, fact-check, route, and monitor.

Modern AI services produce a lot of text. Some of it states facts about the world. Some of it describes what the assistant can and cannot do. Some of it captures things users say about themselves. Without a structured representation of any of this, every downstream governance step (fact-checking, hallucination detection, intent routing, response auditing) has to start by parsing prose all over again.

ClaimExtractor solves that first-mile problem. Given a message (or a multi-turn conversation), it produces a structured list of:

• Claims: self-contained, decontextualized factual statements, classified into one of four subtypes.
• Intents: explicit goals, requests, or actions the user wants to accomplish (extracted from user messages only).

To make this concrete, consider an assistant for a parcel delivery service that just told a user:

"Your package with tracking number 1234567890 is currently in transit and is expected to be delivered on December 12, 2025. If you want, I can also notify you when it is out for delivery."

ClaimExtractor turns this single message into three atomic claims you can act on independently: two factoids (a tracking number and a delivery date that a downstream fact-checker can verify against your records) and one capability statement (a promise about what the assistant can do, which you can verify against the assistant's actual implementation).

Getting Started with ClaimExtractor

You can download the ClaimExtractor models from Hugging Face. ClaimExtractor comes with a clean Python API within the orbitals library, and full support for vLLM and Hugging Face Pipelines. ClaimExtractor is released under Apache License 2.0 and can be used for commercial purposes. This release continues our mission at Principled Intelligence to make AI governance transparent and easy to adopt.

The Need for Claim Extraction

AI governance teams keep running into the same wall.

You can put a guardrail on the input. You can put a guardrail on the output. But the model in between is still emitting paragraphs of unstructured text, and the moment you want to do anything serious with that text: fact-check it, log it, route it, audit it after the fact, you need a way to turn prose into discrete, comparable units. Especially if you are using small subagents powered by SLMs.

In practice, this means each governance team writes their own ad-hoc parser:

• A regex that tries to find "the price is $X" patterns to fact-check pricing claims.
• A prompt that asks a frontier LLM "what did the user want?" to do intent routing.
• A spreadsheet of hand-flagged hallucinations because nobody could agree on what counts as a claim.

These approaches don't compose, don't generalize across services, and don't survive contact with real conversations, especially when the relevant information is spread across multiple turns or buried inside marketing language.

What is missing is a foundational primitive: a model that takes a conversation and returns a clean, structured list of what is actually being said. That primitive is ClaimExtractor.

How ClaimExtractor Works

ClaimExtractor takes two inputs:

1. A conversation — anything from a single message to a multi-turn exchange. Claims and intents are extracted from the last message of the conversation; earlier turns are used as context for decontextualization.
2. An optional AI Service Description — a description of the AI service producing the assistant messages. Providing one improves extraction quality (especially for capability claims), and the same structured AI Service Description format used by ScopeGuard works here too.

From there, it produces two structured outputs.

Claims — atomic, self-contained statements that survive being copy-pasted out of context. Each claim is tagged with one of four subtypes:

Intents — explicit goals, requests, or actions the user wants to accomplish. Intents are extracted only from user messages; assistant messages never produce intents.

Each claim and intent is decontextualized: it stands on its own without reference to the surrounding conversation. This is what makes the output useful downstream — a fact-checker doesn't need to re-parse the conversation to know what to verify, and an intent router doesn't need to guess what the user was referring to two turns ago.

Use Cases and Examples

How to Integrate ClaimExtractor

ClaimExtractor sits after your AI service produces a response — or in parallel with it. The structured output it produces is meant to feed into the downstream governance system you already care about. A few patterns we see in practice:

• Fact-checking. Collect Factoid claims from each assistant turn and verify them against your authoritative data sources (internal knowledge bases, CRM records, product catalogs). Surface mismatches as hallucinations.
• Capability auditing. Collect Capability claims and check that the assistant isn't promising something the underlying system can't actually do. "I'll notify you when the package is out for delivery" is a promise; make sure the notification actually fires.
• Intent routing. Use the extracted Intent from the last user message as the routing signal for downstream tools, agents, or human handoff.
• Compliance and brand monitoring. Flag Unverifiable claims that pattern-match against banned marketing language, unsupported product claims, or competitor mentions.
• Long-term analytics. Store all extractions and run trend analysis: most common user intents, drift in capability claims over time, hallucination rate per service, and more.

The right way to use ClaimExtractor depends on what governance question you are trying to answer. The model gives you the primitives; the policy is yours.

Quickstart Recipe

1. Install ClaimExtractor

pip install 'orbitals[claim-extractor-vllm]'
 
# or, if you prefer to use HuggingFace Pipelines for inference instead of vLLM:
# pip install 'orbitals[claim-extractor-hf]'

2. Extract claims and intents

from orbitals.claim_extractor import ClaimExtractor
 
ce = ClaimExtractor(
    backend="vllm",
    model="claim-extractor-q",
)
 
ai_service_description = """
You are a virtual assistant for a parcel delivery service.
You can only answer questions about package tracking.
"""
 
assistant_message = (
    "Your package with tracking number 1234567890 is currently in transit and "
    "is expected to be delivered on December 12, 2025. If you want, I can also "
    "notify you when it is out for delivery."
)
 
result = ce.extract(
    assistant_message,
    ai_service_description=ai_service_description,
)
 
for claim in result.extractions.claims:
    print(f"[{claim.subtype}] {claim.content}")
 
for intent in result.extractions.intents:
    print(f"[Intent] {intent.content}")
 
# [Factoid] The tracking number of the user's package is 1234567890
# [Factoid] The user's package is expected to be delivered on December 12, 2025
# [Capability] The parcel delivery virtual assistant can notify the user when the package is out for delivery

3. Or serve it as an API

orbitals ships a built-in FastAPI server with vLLM under the hood:

pip install 'orbitals[claim-extractor-serve]'
orbitals claim-extractor serve --port 8000

Once running, you can hit /orbitals/claim-extractor/extract over HTTP, or use the Python api backend to invoke it from your application code.

Check out our GitHub repository for advanced usage including batch extraction, multi-turn extraction over every conversation turn, sampling controls, and serving options.

Available Models

ClaimExtractor today consists of two open-weight models — at 2B and 4B parameters — both distilled from a stronger internal teacher.

Like ScopeGuard, the sizes are intentional. Both variants fit comfortably on a consumer-grade GPU and run fast under vLLM, with prefix caching and speculative decoding enabled by default — a deployment-friendly footprint for a model that may be invoked on every conversation turn. The 4B delivers the highest extraction quality; the 2B trades a small amount of quality for substantially lower latency and memory pressure. Pick the one that fits your throughput and accuracy budget.

Aligned With Principled Intelligence

Principled Intelligence's mission is to make AI governance transparent and effortless for end users. Our governance stack is built around a simple idea: if you want to govern an AI service, the first thing you need is a clear, structured representation of what that service is actually saying and doing.

ClaimExtractor is the primitive that produces that representation:

• Structured by default. Free-form assistant responses become a list of atomic, typed claims plus a list of explicit intents — the building blocks every downstream governance check can consume.
• Decontextualized output. Each extraction stands on its own, so fact-checkers, intent routers, and auditors don't have to re-parse conversation history.
• Designed to compose. ClaimExtractor pairs naturally with ScopeGuard — ScopeGuard decides whether a request belongs to your AI service, ClaimExtractor characterizes what is actually being said once it does.
• Operational from day one. Built-in serving, batch extraction, and a small footprint mean you can run it inline with production traffic, not just in offline evaluation jobs.

ClaimExtractor is another piece of the open governance stack we are building at Principled Intelligence.

FAQ

Do you offer a hosted solution?

Yes. We are rolling out a dedicated inference platform alongside our open models. If you are interested in early access, please reach out at orbitals@principled-intelligence.com.

Why a separate model for claim extraction? Can't I just prompt a frontier LLM to do this?

You can, and many teams start there. Three things tend to push them toward a dedicated model:

1. Consistency. A general-purpose LLM will give you a slightly different decomposition every time. "Slightly different" breaks downstream pipelines that compare extractions over time.
2. Latency and cost. Claim extraction runs on every conversation turn you care about. Paying frontier-LLM prices per turn — and waiting frontier-LLM latency per turn — is rarely viable in production.
3. Schema discipline. ClaimExtractor produces typed, decontextualized claims and intents by construction. A prompted LLM produces whatever the prompt happened to coax out that day.

What's the relationship between claims and intents?

They answer different questions about the same conversation.

Claims describe what is being asserted — by the assistant, by the user, or by both. They are statements about facts, capabilities, user-stated background, or unverifiable content, and they are extracted from both user and assistant messages.

Intents describe what the user wants to do. They are extracted only from user messages, because assistants don't have goals — they respond to them.

A single user message often produces both: an Intent ("the user wants to renew their driver's license") alongside one or more User Assertion claims ("the user's ID has expired"). Together they give you a complete picture of what the user is asking and why.

Where do "evidences" come in?

Every claim and intent is designed to carry a list of evidences — verbatim excerpts from the source message that support the extraction. The current open release does not yet populate them; that capability ships with the next model release. The shape of the output won't change — you'll just start seeing populated evidences lists.

What languages are supported?

The current release is focused on English. Multilingual coverage is on the roadmap, following the same trajectory as ScopeGuard. If you have a specific language need, please reach out at orbitals@principled-intelligence.com or open an issue on GitHub.

Can I run it offline?

Yes. Both the 2B and 4B sizes were specifically targeted at local inference. We recommend the vLLM backend for production deployments — it ships with prefix caching, MTP speculative decoding, and language-model-only mode enabled by default, all tuned for the shape of claim-extraction traffic. Standard HuggingFace Pipelines are also supported.

Does it learn from my traffic automatically?

No. If you want to improve extraction quality on your specific service over time, you have two options:

1. Improve the AI Service Description you pass in. This is the cheapest and most effective lever.
2. Fine-tune on your own data. Reach out if you'd like support on this.

Does ClaimExtractor replace ScopeGuard?

No — they are complementary primitives. ScopeGuard decides whether an incoming user request belongs to your AI service. ClaimExtractor characterizes what is actually being said in the resulting conversation. In a mature governance pipeline you typically want both: ScopeGuard at the perimeter, ClaimExtractor on the conversation itself.