# Claims Knowledge does not support

Knowledge is checked before a reply is drafted, not after. If nothing carries the authority to answer, Connect does not write a hedged reply — it stops, asks the person who owns the workspace, and records what it matched and why that was not enough. The customer waits for an answer somebody stands behind rather than receiving a confident guess.

- **Status:** Available
- **Audience:** both
- **In the app:** #/needs-you
- **Last verified:** 2026-09-10
- **Canonical:** https://connectbyjbrh.com/docs/knowledge/unsupported-claims/

## The gate runs before drafting

The order is the point. The check happens on the incoming message, against the scopes that suit its intent, and only a pass leads to a draft being generated at all. There is no stage at which a model writes an answer and something afterwards tries to decide whether it was justified.

1. The message is classified and the scopes for that intent are chosen.
2. Knowledge is scored, and the result is logged as covered or as a miss either way — with the score, the titles matched, which of them carried authority, any critical topics detected and the citations.
3. On a miss, guidance is requested from the workspace's owner with the matched titles attached, so the request says what was nearly relevant.
4. If that request cannot be delivered, an empty draft is held with the reason on it rather than the thread going silent.
5. The thread outcome reads *Knowledge missing — asked owner before replying*, or *reply held*.

## Topics where the bar is higher

Some questions cannot be answered from a topical match however good it looks, because getting them wrong creates an obligation. These are detected in the incoming text and require explicit owner authority:

| Topic | Typical wording |
|---|---|
| Price or discount | cost, quote, rate, budget, how much |
| Service level or guarantee | SLA, uptime, guaranteed response time |
| Warranty | warranty terms and duration |
| Deployment timeline | installation, delivery or go-live within some period |
| Support commitment | on-site, maintenance, engineer, included for a period |
| Legal or contractual | contract, liability, refund, privacy, a data breach |
| A specific meeting time | a named day with a time on it |

Pricing has one deliberate exception. Where the workspace has a pricing policy on file, or an owner instruction covering the situation, Connect may acknowledge the question and collect what it needs — scope, quantities, timing — without stating a number. That is a useful reply rather than a refusal, and it is the only critical topic with a safe partial behaviour.

## What the record says afterwards

**The score** — How well the best match scored, so a near miss is distinguishable from nothing at all.
**Matched titles** — What was retrieved. Often the fastest signal: the right document, wrong authority.
**Authoritative titles** — Which of those could have proved something. An empty list beside a full matched list is the diagnosis.
**Critical topics** — Which commitment detectors fired, if any.
**Authority reason** — A short machine-readable verdict, such as an owner instruction being required for a critical topic, or no fact authority being present at all.
**Citations** — The passages that would have been used, in `KB:` form, for tracing.

Those six together turn 'the agent said it did not know' into a specific, fixable statement: this question needed a warranty commitment, three reference documents matched, none carried fact authority. The repair follows directly.

## Why silence beats a hedge

A hedged answer is worse than no answer in a business context, and it is worse in a specific way. A customer reading *typically around three months, though this may vary* takes three months away with them. The hedge protects the writer and not the reader, and it is indistinguishable from a commitment once it is quoted back.

So the failure mode chosen here is a delay with a named owner rather than a fast reply with an unnamed liability. The engineering note [why uncertainty is a valid answer](/research/uncertainty-is-an-answer/) sets out the reasoning; [Connect said it does not know](/docs/troubleshooting/knowledge-insufficient/) covers what to do when it happens more often than it should.

## Questions

### Does the customer see anything while this is happening?

Nothing is sent, so the customer sees no reply — not a holding message and not an apology. The thread is waiting on a person, and that waiting is visible in Needs You rather than to the customer. Treat a Knowledge miss as a clock that is running.

### Can I make Connect answer anyway?

Not by turning the gate off. The route that exists is to supply the material: type the commitment as an entry with an authority-carrying category, or upload the document that states it. Answering the guidance request also gets that one thread moving, and the answer you give is a natural candidate for a new entry.

### Why did a question about our own product get a miss?

Read the logged reason before assuming the bank is empty. The three ordinary causes are a source in `needs_review`, a scope that excludes the kind of work the message was classified as, and material that matched but carried only `reference` authority.

## Related

- [Retrieving Knowledge for an answer](https://connectbyjbrh.com/docs/knowledge/retrieval/)
- [Knowledge and Fact are different things](https://connectbyjbrh.com/docs/knowledge/knowledge-vs-fact/)
- [Connect said it does not know](https://connectbyjbrh.com/docs/troubleshooting/knowledge-insufficient/)
- [Why uncertainty is a valid answer from a business agent](https://connectbyjbrh.com/research/uncertainty-is-an-answer/)
- [What Connect may do](https://connectbyjbrh.com/docs/autonomy/)
- [Why a sales agent should refuse to answer](https://connectbyjbrh.com/research/safe-refusals-in-sales/)

## What this page is based on

- `backend/app/runner.py` — the Knowledge gate, its logging and the guidance request
- `backend/app/knowledge.py` — coverage, critical topics and authority reasons
- Connect capability registry (docs-source/facts.py)