Semarize

Knowledge grounding

Evaluate against your business context

Knowledge grounding lets Kits use your product docs, pricing rules, policies, ICP, and playbooks when evaluating conversations. The result is a signal that reflects your business, not generic model assumptions.

Knowledge bases attach to KitsDocs stay scopedSignals stay structured
SKnowledge groundingattached to kit

Knowledge bases

Sales playbookready
Pricing policyready
Security FAQready

Grounded check

pricing_discussed_correctly

Evaluate the buyer's pricing question against the approved pricing policy attached to this Kit.

Result

value: "partially_correct"

Definition

Grounding keeps evaluation specific

Many conversation signals depend on company-specific meaning. Knowledge grounding gives Semarize the approved context needed to judge those signals consistently.

Product context

Use product docs, feature lists, release notes, and integration docs when a check depends on product accuracy.

Playbook context

Evaluate discovery, qualification, objection handling, and escalation against the methodology your team actually uses.

Policy context

Ground compliance, security, and legal checks in approved policy language instead of generic interpretation.

Customer context

Keep vertical, ICP, segment, and account-specific terminology available when it changes how a signal should be read.

Scoped knowledge bases

Group documents by domain or team so a Kit only uses the context that belongs to that workflow.

Signals-only output

Grounding improves evaluation, but public run output remains structured Brick results with values, reasons, confidence, and evidence.

How it works

Upload context. Attach it to Kits.

Knowledge grounding is intentionally tied to the framework layer. A Kit decides which context its Bricks should use.

1

Create a knowledge base

Group source material around a clear domain, such as product documentation, sales playbook, security policy, or pricing rules.

Sales playbook
Pricing policy
Security FAQ
2

Upload source documents

Add the documents that define how the business should interpret a conversation signal.

Docs
FAQs
Policies
Playbooks
3

Attach to a Kit

Link the knowledge base to the Kit that needs it, rather than attaching context loosely to every individual check.

Kit-level scope
Optional or required grounding
Clear reason
4

Run grounded checks

When the Kit runs, Bricks can evaluate against the attached context and still return normal structured output.

value
reason
evidence
confidence

Examples

When grounding changes the answer

Grounding matters whenever the right answer depends on internal terminology, approved process, or source-of-truth documentation.

pricing

Pricing discussion

A generic model can detect that pricing came up. A grounded Kit can evaluate whether the rep described the current pricing rules accurately.

pricing_discussed
pricing_described_correctly
discount_policy_followed
product

Product fit

Grounding lets a Kit compare buyer needs to your actual product capabilities, gaps, integrations, and limitations.

feature_supported
integration_gap
technical_risk
policy

Compliance QA

Policy-grounded checks can evaluate whether required language was used and whether restricted claims were avoided.

required_disclosure_present
restricted_claim_made
escalation_required
playbook

Sales methodology

A discovery Kit can evaluate against your internal methodology, not a generic definition of good discovery.

pain_quantified
decision_process_mapped
champion_confirmed
market

Competitor detection

Grounding can keep competitor and alternative names close to the evaluation so mentions are not missed or misclassified.

competitor_mentioned
comparison_topic
risk_level
support

Support resolution

A support Kit can evaluate whether the answer matched the current help center article or approved escalation policy.

answer_correct
policy_followed
resolved

Why it matters

Generic context is not enough

Many mistakes are not language mistakes. They are business-context mistakes. Grounding narrows the evaluation to the context the workflow actually needs.

Without grounding

Pricing is interpreted from generic SaaS assumptions
Feature mentions are judged without product knowledge
Policy checks rely on vague language patterns
Different teams may interpret the same term differently

With knowledge grounding

Pricing checks reference approved pricing material
Product checks use current product and integration docs
Policy checks follow controlled security, legal, or compliance language
Each Kit uses only the knowledge base scoped to its workflow

Governance

Context without losing control

Knowledge grounding should make evaluation more accurate without leaking raw context into downstream systems or searching every document for every check.

Scoped retrieval

Knowledge bases are organised by domain so the Kit can use focused context rather than every document in the workspace.

Attached at the Kit level

KB logic belongs on Kits. That keeps each workflow's grounding explicit and avoids hidden Brick-level context drift.

Structured output remains

Grounded runs still return output.bricks with configured values, reasons, evidence, and confidence for downstream systems.

Ready to build

Use your docs. Return better signals.

Attach the knowledge your workflow depends on, then keep the API output structured and predictable.

No card required. Start testing in minutes.

Questions

Frequently asked questions

Short answers about knowledge bases, grounded Kits, and how context changes conversation evaluation.

Knowledge grounding is the use of your own documents, playbooks, policies, pricing rules, and product material as context for conversation evaluation.