Company Brain Architecture: Connectors, Permissions, and Freshness

Build a retrieval system over a public corpus and the interesting problems are chunking, embedding, and reranking. Build one over a company and four problems appear that the public case does not have at all.

The corpus is scattered across a dozen systems with different APIs, formats, and update semantics, rather than sitting in a folder.

Every document has an access control list, and the correct answer to a question genuinely differs per employee.

Entities are duplicated and inconsistent across those systems, so the same customer, person, or service appears under several identities.

And the corpus contradicts itself, because the old version of a policy was never deleted.

None of these are retrieval-quality problems and none are solved by a better embedding model. The retrieval mechanics themselves, chunking, hybrid search, reranking, query rewriting, are treated properly in the Advanced RAG cursus; this lesson deliberately covers only what is specific to doing it inside an organization.

A company brain decomposes into four layers, and the further down the list you go, the more of the engineering effort it consumes.

The connector layer reaches into each source system, pulls content and metadata, and keeps up with changes.

The index layer stores the content, its embeddings, its metadata, and, critically, its access control list.

The retrieval layer takes a question and an identity and returns permitted, relevant, current passages.

The answer layer synthesizes those passages into a response with citations.

Teams consistently budget as though the answer layer is the work, because it is the layer they can demo. In practice the connector layer is where most of the time goes and the index layer is where most of the risk lives. A demo built on a folder of exported PDFs skips both, which is why demos succeed and rollouts stall.

Two paths run through the system, and keeping them separate in your head prevents most design confusion.

The ingestion path runs on a schedule or on webhooks. A connector fetches documents and their access control lists from a source system, the content is normalized and chunked, embeddings are computed, and everything lands in the index with the permissions attached as metadata.

The query path runs per question. The user's identity is resolved to the set of groups and roles they belong to, the retrieval step filters to documents that identity is permitted to see before ranking, and only permitted passages reach the model.

The critical property is that permission filtering happens inside retrieval, not after it. Filtering the answer after generation is too late, because the model has already read the document.

A connector is not an API call. To be correct it has to solve five problems for every source system it touches.

Authentication, usually as a service principal with broad read access, which immediately makes the connector a high-value target.

Incremental sync, because re-indexing everything nightly does not scale and leaves a day-long staleness window. This means change tokens, cursors, or webhooks, each source doing it differently.

Deletions and permission changes, the most commonly skipped requirement. If a document is deleted or its sharing is narrowed and your index does not learn, you keep serving content that no longer exists or that the asker is no longer allowed to see.

Format extraction, turning slide decks, spreadsheets, PDFs, and threaded conversations into text worth indexing. A chat thread is not a document and chunking it like one destroys it.

Rate limits and backfill, since the first full crawl of a large tenant can take days.

In a public retrieval system every user gets the same answer. Inside a company the same question has a different correct answer for every person who asks it, and the difference is not a preference. It is a legal and contractual boundary.

What makes it acute is the generative layer. Classic search returned a list of links; if permissions leaked, the user still had to click through to a document that would then deny them. An answer engine dissolves that second gate. It reads the document on the user's behalf and puts the contents into a paragraph of prose. The user never opens the file, never sees a permission error, and the confidential salary band, acquisition codename, or unreleased result is simply part of the answer.

The leak is invisible to everyone involved. Nothing in the interface indicates that a boundary was crossed, which means it will not be reported and will not be noticed until much later.

Enterprise search has two established ways to enforce permissions, and the vocabulary is worth knowing because vendors use it.

Early binding resolves access at index time. When the connector reads a document it also reads its access control list and stores that mapping in the index. At query time the engine expands the user's identity into their group memberships and filters against the stored lists. Fast, because it is one filtered index query, and it scales to large result sets.

Late binding resolves access at query time by calling back to each source system to ask whether this user may see this item. Always current, and unusable in practice: it multiplies every query by a network round trip per candidate document, and the latency and rate-limit cost make ranking over a large candidate set impossible.

Early binding is the standard choice, and it buys speed with a synchronization obligation. The index's copy of the permissions is only as fresh as your last sync, so a revoked permission stays effective in the index until the connector catches up. That window is a real exposure, and it is the reason permission changes deserve to be pushed by webhook rather than discovered on the next nightly crawl.

Here is the uncomfortable part. A correctly implemented permission model does not make a company brain safe, because it faithfully inherits whatever your existing permissions already say.

Most organizations have years of accumulated over-permissioning: sites created with access granted to everyone in the organization, sharing links set to anyone with the link, broken permission inheritance on nested folders, and the everyone except external users group applied to material that was never meant to be broadly readable. None of it was noticed, because finding those files previously required knowing they existed and guessing the right keywords.

Semantic retrieval removes that obscurity. Content that was technically readable and practically invisible becomes reachable by a plain-language question.

Microsoft documents this directly for its own product, publishing an oversharing blueprint and deployment guidance for Microsoft 365 Copilot. The vendor Concentric AI, in its own scan-based data risk reporting, put the share of business-critical data that is overshared at around 16 percent, averaging roughly 802,000 exposed files per organization. Treat a single vendor's scan as indicative rather than definitive, but the direction is not in dispute.

The operational conclusion: a permissions audit is a prerequisite for deployment, not a follow-up task.

The same real-world thing appears under different identifiers in every system it touches, and until they are linked, retrieval cannot connect facts that belong together.

A customer is an account ID in the CRM, a company name in contracts, an email domain in support tickets, and a Slack channel name. A person is an employee ID, an email address, a Git commit author, and a display name that changed after a marriage. A service is a repository name, a monitoring dashboard, an on-call rotation, and a line item on a cloud bill.

Entity resolution is the process of recognizing that these refer to the same entity and linking them. Done well, a question about a customer can pull the contract, the open tickets, and the account history together. Done badly, or not at all, each system answers in isolation and the synthesis job from the previous lesson quietly fails.

It is also the most common source of production failure in these systems, because the matching is genuinely hard: names collide, abbreviations proliferate, and a record marked closed in one system stays open in another.

Start narrow. Resolve people and customers, the two entity types that appear in the most questions, and leave the rest until they earn their place.

An internal corpus differs from a public one in a way that breaks naive retrieval: it contains multiple versions of the same truth, and the obsolete ones were never removed.

The 2021 travel policy, the 2023 revision, and a draft that was never adopted all sit in the index. A semantic retriever ranks by similarity to the question, and similarity is blind to time. The 2021 policy can easily win, because it happens to use vocabulary closer to how the question was phrased. The model then answers confidently from it, and cites it, which makes the answer look better sourced than it is.

The mitigations are unglamorous and all necessary. Carry a last-modified timestamp as metadata and let recency contribute to ranking rather than relying on similarity alone. Prefer documents from designated authoritative locations over copies found elsewhere. Detect near-duplicates at ingestion and keep the newest. Expose the document date in the citation, so a human can catch what the ranker missed. And exclude drafts, archives, and personal drives by default rather than by exception.

Recency as a ranking signal is a judgement call, not a free win: for a question about a historical decision the old document is the right answer. Weight it, do not hard-filter on it.

Public web search leans on links between pages. An internal corpus has no meaningful link graph, but it has signals the public web does not, and using them separates a usable system from a frustrating one.

Authority by location. A document in the official policy space outranks the same content pasted into a personal folder. This requires someone to designate authoritative locations, which is a governance act, not a technical one.

Recency, weighted as described above.

Engagement. Documents that are opened, linked, and edited by many people are more likely to be current and correct than ones untouched for three years.

Authorship and ownership. Content written by the team that owns the subject beats content written by someone summarizing it second-hand.

Explicit lifecycle state. A document marked approved, versus draft, versus deprecated, is the strongest signal available, and it is the one most organizations do not maintain.

That last point generalizes. Every signal here depends on metadata a human has to curate, which is the same write-side dependency the first lesson identified, reappearing as a ranking problem.

Given all of the above, the order of work matters more than the choice of tools.

Audit permissions before indexing anything. You are about to make everything readable findable, so find out what readable currently means.

Start with one or two source systems, chosen because they hold authoritative content, not because their API is pleasant.

Implement early-binding permission filtering from the first day. Retrofitting access control into a working prototype is a rewrite, and prototypes without it have a habit of being demoed to executives and then deployed.

Carry metadata from the start: source, owner, last modified, lifecycle state. Adding it later means re-ingesting everything.

Resolve people and customers, and defer every other entity type.

Measure before expanding, which is the subject of the next lesson.

The pattern throughout is that the expensive mistakes are the ones baked into ingestion, because they can only be fixed by ingesting again.