Knowledge, connected.

Knowledge-heavy teams lose time re-asking questions that have already been answered somewhere. The information exists, but it is spread across tools with different search behavior and different access rules.

This study designs an answer layer that sits over approved sources. It retrieves relevant passages, composes an answer with citations, and respects the permissions people already have in each source system.

How can a team get useful, checkable answers from fragmented internal knowledge without exposing anything a person could not already open?

A fluent answer that is wrong, or one that quotes a document the reader should not see, is worse than no answer. Trust has to be designed in, not added later.

• Access boundaries

  A person must only receive answers built from content they can already open in the source system.

• Changing sources

  Documents are edited and deleted daily; the index has to follow without full rebuilds.

• Checkable answers

  Every statement in an answer needs a source the reader can open and verify.

• Data handling

  Content stays in the organization’s environment and only reaches model providers under approved data-processing terms.

• Predictable cost

  Per-question cost and latency need an agreed budget before the system is opened to more people.

WHAT DISCOVERY WOULD ESTABLISH

1. 01

   Source inventory

   Which systems hold the knowledge, who owns them, how they expose content and permissions, and how often they change.

2. 02

   Real questions

   A log of questions people actually ask, collected before building, so the system is designed around real demand.

3. 03

   Permission model

   How groups, shared links, and inherited access work in each source, including the edge cases.

4. 04

   Evaluation set

   A reviewed set of questions with expected sources, created with subject-matter experts, to measure retrieval and answer quality.

Connectors pull content and permission data from approved sources into a single index. At question time, retrieval filters by the asker’s access before ranking, and the model only sees passages the person is allowed to read.

Answers are composed with mandatory citations. When retrieval finds nothing relevant, the system says so and offers to route the question to a named owner.

CAPABILITIES

• Permission-aware hybrid search
• Answers with inline citations
• Explicit “no answer found” state
• Routing to a subject-matter owner
• Inline feedback on every answer
• Per-question traces for review

1. DECISION 01

   Citations are mandatory

   WHY

   People need to check an answer before acting on it, and citations make errors visible.

   TRADE-OFF

   Some questions receive “no source found” instead of a plausible-sounding answer.

2. DECISION 02

   “No answer” is a designed state

   WHY

   An honest gap, with a route to an expert, keeps trust when coverage is incomplete.

   TRADE-OFF

   Early coverage looks smaller, because the system declines rather than guesses.

3. DECISION 03

   Escalate to an owner, not a queue

   WHY

   Questions reach the person who can answer them, and their answer can become a new source.

   TRADE-OFF

   Requires maintaining ownership metadata for each collection.

4. DECISION 04

   Feedback on every answer

   WHY

   Thumbs and short comments feed the evaluation set with real failures.

   TRADE-OFF

   Feedback needs triage time from the team that owns the system.

Permissions are enforced at retrieval, before the model sees anything. The index can be rebuilt from sources at any time, and every answer can be traced back to the passages that produced it.

1. L1

   Sources

   Systems of record that keep ownership of content and access rules.

   • Wiki
   • Shared drives
   • Ticket history
2. L2

   Ingestion

   Incremental connectors that normalize content and copy permission data alongside it.

   • Connectors
   • Chunking
   • Permission sync
3. L3

   Retrieval

   Combines keyword and semantic search, filtered by the asker’s access, then re-ranked.

   • Hybrid search
   • Access filter
   • Re-ranking
4. L4

   Generation

   Composes an answer from retrieved passages only, and checks that each claim has a citation.

   • Grounded prompt
   • Citation check
   • Fallback
5. L5

   Experience

   Where people ask, verify sources, give feedback, and reach an expert.

   • Answer UI
   • Feedback
   • Expert routing

DESIGN PRINCIPLES

1. Access before relevance

   Filtering happens inside the retrieval query, so a ranking change can never surface restricted content.

2. Rebuildable index

   The index is derived data. Sources stay the system of record, which keeps deletion and correction simple.

3. Provider adapter

   Model calls go through one interface, so providers can be evaluated and changed without touching the product.

PROPOSED DELIVERY SEQUENCE

1. PHASE 01

   Evaluation harness first

   Build the evaluation set and scoring before features, so every later change is measured.

2. PHASE 02

   One source, end to end

   Connect a single well-understood source, including permissions, to prove the full path.

3. PHASE 03

   Pilot group

   Open to a small group with feedback enabled, and review failures weekly.

4. PHASE 04

   Expand deliberately

   Add sources and expert routing one at a time, re-running the evaluation after each.

1. Retrieval evaluation

   Scores whether the expected sources appear for each question in the reviewed set.

2. Negative access tests

   Test identities without access must never receive content, citations, or hints from restricted documents.

3. Regression on change

   Prompt, model, and ranking changes re-run the evaluation before release.

4. Ingestion load tests

   Bulk edits and deletions are replayed to check the index keeps up.

1. Client-controlled environment

   Deployed in the organization’s cloud account, with network access to approved sources only.

2. Scheduled and event-driven sync

   Webhooks where sources support them, with scheduled reconciliation as a safety net.

3. Secrets and keys

   Source credentials and provider keys held in a managed secret store and rotated.

4. Cost and latency dashboards

   Per-question cost, token usage, and latency tracked against the agreed budget.

1. CHALLENGE 01

   Permission drift between a source and the index.

   RESPONSE

   Incremental permission sync, plus a query-time check against the source for the most sensitive collections.

2. CHALLENGE 02

   Stale or contradictory documents.

   RESPONSE

   Show document age and owner next to each citation, and notify owners when answers rely on outdated material.

3. CHALLENGE 03

   Ambiguous questions.

   RESPONSE

   Ask a clarifying question rather than guessing between interpretations.

This is a concept, so there are no measured results. The outcomes below are what the design is intended to achieve; the measures after them are how a pilot would verify it against an agreed baseline.

INTENDED RESULTS · QUALITATIVE

• Every answer can be checked against its source in one click.
• Access boundaries are a tested requirement, not a configuration detail.
• Gaps in coverage become visible and route to the people who can close them.

HOW RESULTS WOULD BE VERIFIED

• Retrieval and answer quality against the reviewed evaluation set.
• Access correctness through negative tests on every release.
• Latency and cost per question against the agreed budget.
• Pilot feedback compared with a baseline of how people search today.

1. 01

   Evaluate before you build

   Without a reviewed question set, quality discussions become opinion.

2. 02

   Permissions are the product

   Access correctness decides whether the system can be used at all.

3. 03

   Design the “I don’t know”

   A clear gap with a route forward earns more trust than a confident guess.