Share the foundation without mixing access rules
Company-wide
A company-wide assistant and a finance assistant do not need the same sources. Teams can share infrastructure while retaining separate permissions, answer rules and test questions.
Turn company knowledge into answers employees can verify
YPAI designs and builds internal knowledge assistants around the sources, access rules and questions that matter to your employees. Each answer can show its evidence, respect the access model selected for the project and make stale, conflicting or missing information visible.
Start with one employee group, one knowledge domain and a bounded source set. YPAI maps who owns the selected sources, builds the employee experience, tests real questions and records what is ready for release.
Finding a document is not the same as finding the governing answer
An employee may find several plausible documents across a policy library, shared drive, wiki, intranet or service desk. They still need to know which source governs, which version applies, whether they may use it and who owns a conflict.
The person accountable for employee knowledge is left managing more than search. Source authority, ownership, permissions and freshness all affect the answer an employee can act on.
A citation can link the answer to the relevant passage and show the source, owner, version and effective date where the customer system provides them.
Fresh retrieval does not prove that a policy is current.
Choose the first knowledge job
Start where repeated questions and unclear authority create real work. The first domain needs named sources, owners, users and acceptance questions.
Take a routine question: "Which policy applies to this request, and is it current?" Other domains can follow when their content and ownership are ready.
- Onboarding
- Operational guidance
- Policy and procedure
- Internal HR or IT support
- Product and project knowledge
Define the answer before choosing the interface
An answer contract defines what the assistant must do before it responds. The retrieval design can apply the customer's selected access model to retrieved passages, answers and citation details.
Identity, groups, role, project membership, document permissions and explicit exclusions can all enter the project design. The source map separates authoritative, supporting, historical, restricted and excluded material.
- Approved sources
- Identity and access rules
- Passage citation
- Current versus historical
- Conflict or missing evidence
- Route to the owner
Evaluate the questions that can change an employee decision
Does the answer use only the approved sources?
Does access apply to the answer and the citation?
When evidence is missing or in conflict, does the assistant show that instead of filling the gap?
The evaluation set combines routine questions with ambiguous requests, restricted material, expired sources, document conflicts, missing evidence and unsupported conclusions. Measures are chosen for the questions and risk. Acceptance is not a universal percentage.
Next step
An employee may need a cited answer, a link to a form, a service ticket or a handoff to a person. The answer contract states where the knowledge assistant stops and what the employee sees next.
From employee questions to a release decision
Define the employee questions and the decisions that stay with people. Map sources, owners, permissions, versions and known gaps. Agree the answer contract and acceptance criteria.
Build the retrieval layer and employee experience for the selected domain. Evaluate representative and adversarial questions. Four records keep the main decisions inspectable: the source and ownership map, the permissions matrix, the evaluated question set and the release report.
Pilot the agreed scope with a bounded user group. Decide what is accepted, what must change and what is ready to operate. Scope and commercial terms are agreed before a pilot starts. Wider deployment follows evidence from the accepted scope.
Bring one question set employees need to answer
Bring the employee group, recurring questions, source systems, access boundaries and source owners.
The engineering conversation decides which sources govern, which users to test and what evidence a release decision needs. Start with the question set and the people accountable for its sources.