PLAYBOOK · KNOWLEDGE
A federated Living Knowledge graph across every business unit.
Large organizations don't have one knowledge base — they have twenty. Confluence in one BU, SharePoint in another, GitHub everywhere. This playbook stitches them into a single Living Knowledge graph with per-BU scopes, shared retrieval, and one governance surface.
Large organizations rarely have one knowledge base. They have twenty. Confluence in one BU, SharePoint in another, GitHub everywhere, Notion or Drive in some teams. Centralizing everything is politically impossible. VDF AI federates instead: per-BU vector indexes joined by a Living Knowledge graph, with one governance surface.
The problem
Every BU is an island
BU A's knowledge stack is invisible to BU B. Centralizing everything into one wiki is politically impossible; building a single retrieval layer per BU is operationally inefficient.
The VDF AI approach
Federate the graph, scope by domain
Each BU keeps its sources. VDF Data builds per-BU vector indexes; Living Knowledge ties them with shared entities. Domains in AgentsHub enforce who sees what.
WHY THIS MATTERS NOW
Knowledge federation beats knowledge consolidation
Every five years some leader proposes "consolidating all our knowledge into one wiki". It never happens — and even when it does, two years later the proliferation is back. The right pattern is federation: keep sources where they are, expose them through a shared retrieval surface, govern at the surface.
VDF AI does that. Each BU keeps its tools. VDF Data builds per-BU vector indexes. The Living Knowledge graph ties them through shared entities (people, products, customers). Domains in AgentsHub scope which user and agent can see which BU. The user experiences one assistant; the org keeps its autonomy.
WHAT YOU NEED TO START
Prerequisites for a pilot
Per-BU sources
- Confluence, Notion, SharePoint, Drive
- GitHub or GitLab
- Custom databases or DMS
- Local file shares (optional)
Federation
- Shared entity model (people, products, customers)
- Domain configuration per BU
- Identity bridge with group claims
- Optional: cross-BU search role
People
- Knowledge owner per BU
- One enterprise architect
- One identity admin
- Optional: a privacy reviewer
REFERENCE ARCHITECTURE
One graph, many tenants
Entities · relationships
SEEMR routing
PLAYBOOK · STEP BY STEP
Federate without centralizing
Connect sources per BU
Each BU keeps its tools. VDF Data connects to Confluence, Jira, GitHub, SharePoint, Notion, Drive, and custom databases per BU credentials.
Build per-BU vector indexes
One Feature List per BU. Indexes don't bleed across tenants.
Wire the Living Knowledge graph
Shared entities (people, products, customers) link BUs. Relationships are inferred from extracted content.
Scope agents with Domains
AgentsHub domains enforce which agent can retrieve from which BU.
Run cross-BU networks
For permitted users, a single Network can stitch retrievals across BUs — with full per-BU citation in the answer.
OUTCOMES
Sharing, without merging
BU forced into a global wiki migration.
governance surface for the whole enterprise.
cross-BU answers carry per-source citations.
SEEMR REFERENCE
Knowledge that compounds
SEEMR's Knowledge Graph mode rewards the BUs whose retrieval consistently helps — surfacing useful content across the org without forcing migrations.
FREQUENTLY ASKED QUESTIONS
What teams ask before shipping this playbook
Will BUs lose control of their content?
No. Indexes are per-BU. The federation layer adds visibility without changing ownership.
How is sensitive content shielded?
Domains enforce who can retrieve from where. A BU can keep specific spaces fully private if needed.
How are duplicates handled across BUs?
Living Knowledge collapses on shared entities. Duplicate documents from different BUs are surfaced with both attributions when relevant.
Can we measure cross-BU value?
Yes. Live Execution Monitoring shows which BU's content most often resolves whose queries. SEEMR uses that to bias retrieval.
How is this different from a federated search product?
Federated search is keyword. VDF AI is semantic, agent-driven, and capable of taking action — not just returning links.
How long to deploy?
Six to twelve weeks for a multi-BU rollout including identity, indexing, and domain setup.
RELATED PLAYBOOKS
Continue with related VDF AI patterns
GET IN TOUCH
You Have Questions
Tell us what you’re trying to achieve—governed AI Networks, enterprise RAG, deep integrations, or on‑premise deployment. We’ll help you map the right architecture, security posture, and rollout path. If you’re moving beyond AI pilots and need scalable, auditable execution, reach out—our team is ready to help.