Designing a Permission-Aware Company Second Brain

An illustrative scenario

Consider an enterprise whose policies, onboarding material, and operational guidance live across several document repositories. Employees need answers, but different teams have different access rights. This example explains a possible design. It does not describe a verified client deployment, delivery timeline, or measured saving.

Start with sources and identities

Inventory the repositories, identify authoritative documents, and assign content owners. Map each user’s identity and source permissions before retrieval. Test restricted documents, role changes, deletions, and shared links. If a source cannot expose reliable permissions, exclude it or agree a narrower access model.

Retrieve evidence before writing an answer

Retrieve only material the user may access, then generate an answer with links to its sources. Keep the source version and retrieval context available for review. When documents conflict or the evidence is insufficient, the assistant should explain the limitation and direct the user to an owner.

Evaluate before release

Build a test set of realistic questions with expected sources and access rules. Evaluate citation accuracy, unsupported answers, permission enforcement, and handling of outdated documents. Repeat the tests after changing the model, prompts, connectors, or source collection.

Measure the business result

Establish a baseline for time spent finding answers. During a controlled rollout, record time to a verified answer, reviewer corrections, adoption, and operating cost. Only publish outcome numbers when their method, period, and underlying evidence can be checked.