qbrinInside qbrin · 1 of 6
How qbrin works: from a question to a cited answer—or an honest abstention
Most AI systems begin with a model and ask how to make its answer better. qbrin begins one step earlier: what must be true before an answer is allowed to leave?
That difference changes the shape of the system. qbrin is not presented as a new foundation model. It is a trust layer over company knowledge and AI workflows: it brings the relevant evidence together, keeps access boundaries intact, checks whether claims are supported, and returns either a cited answer or a clear statement that the records do not support one.
The short version
A question moves through six practical stages. The exact implementation can evolve, but the contract stays stable:
Connect → retrieve → assemble evidence → draft claims → verify → answer or abstain.
The model can help write. It does not get to decide by fluency alone that the evidence is sufficient.
1. Knowledge enters through a governed ingestion path
qbrin can accept connected workplace sources as well as content sent through its API. The public API documentation describes an ingestion path that extracts text, chunks it, embeds it for retrieval, and extracts entities before marking the material ready to answer questions. The useful point is not the vocabulary of the index; it is that documents become retrievable records with source identity, status, and access context.
That context matters. A perfect passage from the wrong permission boundary is not a valid answer. API keys are scoped, and answers are described as permission-aware, so retrieval must begin with what the caller is allowed to see.
2. Retrieval builds an evidence set, not an answer
Ordinary retrieval-augmented generation often treats the top-ranked chunks as the prompt and moves on. qbrin treats retrieval as a candidate-evidence step. Relevant passages, dates, entities, and source links are assembled so the next stages can ask a harder question: does this material actually support the requested claim?
This is why a citation cannot be bolted on at the end. A nearby document may be topical yet fail to prove the number, date, person, status, or causal statement in the answer. The evidence set has to preserve enough source detail for that check.
3. An answer becomes a set of checkable claims
A fluent paragraph can contain several different assertions. “Release 2.4 ships March 14 after Maya approved it” contains at least a version, a date, a person, an approval event, and a relationship among them. Treating the paragraph as one confidence score hides where it can fail.
qbrin's public product language describes typed claims, claim tokens, and citation verification. Conceptually, the system turns the draft into units that can be checked against the evidence instead of accepting the paragraph as an indivisible blob.
4. Verification is the boundary
For each material claim, the verifier asks whether the supplied evidence supports that exact claim. A source can be relevant but contradictory. It can be stale. It can mention the entity but not the value. It can also be silent. Those are different failure modes, but none should quietly become a confident answer.
When the evidence supports the claim, qbrin can return it with the original source. When the evidence does not reach the required bar, the correct output is to abstain, narrow the answer, ask for more context, or route the decision to a human.
5. The output carries its proof—or says what is missing
The reader should not have to trust an internal score. A useful qbrin response exposes the source behind the statement so a person or downstream agent can inspect it. If there is no adequate support, the response should say that plainly rather than fill the gap with a plausible sentence.
The product promise is not “the model feels certain.” It is “the available records support this claim strongly enough for this use.”
Answers and actions are different contracts
A cited answer can still be unauthorized as an action. Reading a runbook may support the statement “this service should be restarted,” but it does not automatically grant permission to restart production. That next boundary belongs to policy: identity, scope, environment, action risk, and approval requirements. We separate those layers in Evidence, verification, and authorization are three different gates.
What this architecture can—and cannot—promise
It can make unsupported claims visible, preserve provenance, reduce false acceptance, and create a deterministic place to stop. It cannot make incomplete company records complete, turn a stale source into a current one, replace domain safety engineering, or guarantee that every future dataset will behave like a benchmark.
The best evaluation is therefore local: choose real questions, include deliberately unanswerable cases, preserve permissions, define the cost of false acceptance, and inspect both coverage and error. Start with a controlled pilot, then widen the boundary only when the evidence supports doing so.
Comments
Sign in with GitHub to reply. Threads live in a public repository, so anyone can read them without an account.