# Producing a grounded answer, end to end

A question is classified, scoped, and answered from material that was checked for authority before anything was written. The check happens first: if nothing carries the standing to answer, no draft is produced and a person is asked. When it passes, the model receives three labelled blocks, and the citations that supported the reply are kept with it.

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

## The stages

1. Trigger — a customer asks something: an email arrives in a connected mailbox, or a caller says it aloud on a live line.
2. External event — the message is fetched by the mailbox sync, or the caller's turn is transcribed.
3. Authentication and workspace resolution — the mailbox or the phone line fixes the workspace before a single row is read.
4. Ingest — the message is canonicalised into a thread; blocked senders and automated mail stop here, and external text passes the prompt-injection shield before any model runs.
5. Canonical record — the sender is resolved to a Person and the thread or call becomes the record everything else hangs from.
6. Classification and reasoning — the intent is decided, and the intent chooses the scopes: support material for a complaint or a legal question, prospect material for an enquiry, internal material always in reserve.
7. Knowledge, memory and rules — retrieval runs against those scopes, sufficiency is judged against fact authority, and memory tiers and standing instructions are added. On a call the whole brief is cut to its budgets: four Knowledge entries and 2,000 characters, 700 of memory, 600 for the contact block.
8. Autonomy and approval — a Knowledge miss stops here and asks a person. A pass goes to drafting, and the channel's autonomy mode then decides whether the finished reply is sent or held.
9. Action and provider — the reply is drafted with the three labelled blocks in front of the model, checked against the guardrails, and handed to the provider through the shared send boundary; on a call it is spoken.
10. Result — a send is only *sent* once the provider acknowledges it; until then it is uncertain. On a call the words are spoken and transcribed into the record.
11. Relationship, timeline and memory — the exchange joins the person's timeline, and every memory that was put in front of the decision is marked as used.
12. Audit and usage — the Knowledge check is logged whether it passed or missed, with the score, the titles matched, which of them carried authority, any critical topics detected and the citations; model use is metered against the workspace's budget.

## What you see, and what can fail

| Stage | What you see | What changes | What can fail |
|---|---|---|---|
| Ingest | A new conversation | A thread and a message record | A held message, if the injection shield fired |
| Classification | The intent on the thread | The scopes for retrieval | A misread intent narrows the scopes and starves retrieval |
| Retrieval | Nothing directly; the citations later | Nothing — this is a read | A source in review, or scoped away, contributes nothing |
| Sufficiency | Either a draft, or a request for guidance | The thread's status | A miss on a question you thought was covered |
| Drafting | A reply in the conversation | A draft record | Guardrail problems turn a send into a hold |
| Send | The reply in the thread, then in the sent folder | The provider's acknowledgement | A failed or uncertain send; an exhausted allowance |

Two of those rows deserve emphasis. A misread intent is the quiet failure: the material exists, the authority is right, and it was never asked for because the scopes chosen did not include it. And a hold is not a failure at all — it is the autonomy setting doing what it was told.

## What a citation proves

Each passage arrives with an identifier naming its source and its position, and those identifiers are recorded against the thread rather than only shown to the model. That is what makes an answer auditable months later, and it is worth being precise about what it establishes.

**It proves** — This passage was in front of the model when the reply was written, and it came from this source at this position.
**It does not prove** — That the sentence in the reply follows from the passage. Reading the cited text is the audit; seeing that a citation exists is not.
**It also records** — Which retrieved material carried authority, so 'three documents matched and none could prove it' is recoverable from the log.

[Auditing what an answer was based on](/docs/workflows/knowledge-audit/) walks one sentence back through those records.

## Email and a live call differ in two ways

- Budget. An email reply can take eight passages; a call takes four entries and 2,000 characters, because the brief is paid for in latency before the first word.
- Recovery. An email that cannot be answered waits for a person with no cost to the customer beyond delay. A call cannot wait — the caller is on the line, so an unanswerable question becomes a call-back commitment, which is itself a promise Connect has to keep.

Everything else is shared: the same eligibility rules, the same authority ladder, the same sufficiency gate, the same citations. A fact that cannot be stated in an email cannot be stated on the phone either, and that consistency is more valuable than either channel being individually clever.

## Questions

### Can I see what a reply was grounded in before it goes out?

For a held reply, yes — the queue shows the draft with the thread it answers, and the Knowledge check for that message is in the record with its matched titles and citations. For an automatic send, the same record exists afterwards, which is the point of writing it either way.

### Why did a reply cite a document but not answer the question?

Because relevance and authority are different tests. The document matched well enough to be retrieved and shown, and did not carry the standing to settle the specific claim — most often a commercial commitment needing explicit owner authority rather than a topical policy.

### Does the model ever answer without Knowledge at all?

Not for a factual customer question: the gate runs before drafting and a miss stops it. What the model does contribute without Knowledge is the shape of a reply — courtesy, structure, the acknowledgement of what was asked — which is why a held draft can look complete and still say nothing committal.

## Related

- [Retrieving Knowledge for an answer](https://connectbyjbrh.com/docs/knowledge/retrieval/)
- [Claims Knowledge does not support](https://connectbyjbrh.com/docs/knowledge/unsupported-claims/)
- [Auditing what an answer was based on](https://connectbyjbrh.com/docs/workflows/knowledge-audit/)
- [Retrieving Knowledge for one reply](https://connectbyjbrh.com/docs/workflows/retrieval-for-a-reply/)
- [What Connect may do](https://connectbyjbrh.com/docs/autonomy/)
- [Proof that a message was sent](https://connectbyjbrh.com/docs/email/send-evidence/)

## What this page is based on

- `backend/app/runner.py` — classification, the injection shield, the Knowledge gate and drafting
- `backend/app/knowledge.py` — scopes by intent, coverage and sufficiency
- `backend/app/knowledge_bank.py` — retrieval and the labelled context blocks
- `docs-source/sources/PHONE.md` §7 — the live-call brief and its budgets