Illustrative Scenario
Role-aware answers from internal documents
Illustrative scenario · not a client engagement
Current situation
Staff repeatedly search the same set of internal documents, and different roles are meant to see different material.
The flow we propose
Documents are indexed with owner, role, and version metadata. A question is answered only from the chunks the requester is authorised to see, every answer carries a citation to its source and version, and the system abstains and routes the question to a person when no authorised source supports an answer.
From a real run
"What is our termination clause?"
Compliance role
Answered, with a citation: "...includes a 30-day termination clause and a limitation-of-liability cap at 12 months' fees." (doc-contract-v3)
Sales role
Denied — reason: unauthorised. No content, no title, no confirmation the document even exists.
Raw run
From a real run
The exact same question, asked by two different roles, gets two different, correctly scoped answers — one person sees the document, the other doesn't.
Captured from our synthetic reference build — not a client result.View full size →
How it works today
Someone searches a shared drive or wiki by hand, is not always sure the document found is current, and has no reliable way to know whether they should even be looking at it.
Human control points
- There is no mid-flow approval step; the control point is architectural, since access is enforced server-side and never in the interface or the prompt.
- An attempt to access a document outside the role of the person asking is logged, not silently ignored.
Failure and delay points
- An outdated document surfaces alongside the current one with no clear signal about which applies.
- Role-restricted material is occasionally found by someone who should not see it.
- The same search is repeated by different people because there is no shared, trustworthy answer.
What the pilot measures
- Authorised-correct-answer rate on an agreed test set
- Correct-abstention rate when no authorised source exists
- Retrieval hit rate against the known-answerable questions
- Access-violation count, with a target of zero
Technical detail and assumptions
Systems and data
A document store carrying owner, role, and version metadata, and an identity or role system. Retrieval never crosses a role boundary regardless of what the query asks for.
Baseline assumptions
- Assumed document set size, kept small during a pilot so citation quality can be judged by hand.
- Assumed number of roles covered, treated as a scoping assumption for the pilot only.
- Assumed monthly query volume, not a measured figure.
Pilot scope
One small document set, a handful of roles, and read-only question answering. No write access to any document, no change to who holds which role.
Risks, exclusions and fallback
- A cached answer that survives a role change is treated as a defect to fix immediately, not an acceptable edge case.
- Administrative or service-role credentials are kept out of any path a user can reach.
- A superseded document with the same title never overrides the current one silently.
What moving to production would require
A real identity and role system, real row-level security enforcement, a re-index step triggered when a source document changes, a named data owner, and a rollback that disables answering without deleting the index.