Why a RAG knowledge base after a merger needs more than one more connector
After a merger, the question is rarely whether a self-hosted stack can answer questions from two document estates. The question is whether each answer respects the rules that applied to the document it came from. Two identity systems, two sets of folder and site permissions and deal material that must stay out of scope mean the assistant has to enforce source-document permissions at retrieval time, not just index everything into one collection. The usual short answer is a self-hosted platform such as Dify, RAGFlow, AnythingLLM or Open WebUI, backed by a self-hosted vector database, with access controlled per tenant or workspace and filtered against group memberships from both directories. Model choice matters less than this, and it is the part most likely to be underestimated.
The hard work is in three places. First, permissions mapping: the team must decide how users from each identity provider map to shared groups, which source groups survive the merger unchanged, and what happens to a document whose owner has left. Second, policy conflicts: two HR, security or finance policies may both be current and contradict each other, so the assistant needs a rule for which version it cites, and someone must own that decision. Third, scoping: restricted deal material, clean-team documents and pre-close communications should be excluded at ingestion, not hidden at answer time. Confirm with counsel which categories are restricted and check that the connector's metadata carries classification labels, since filters cannot enforce rules they cannot see.
Before any connector is pointed at the second estate, ask the implementation partner to show a test matrix: a sample of users from each side, the documents each should and should not retrieve, and the citations returned. Check the vector database access model as well. A self-hosted Qdrant deployment, for example, listens on all interfaces and has no authentication by default, so network placement and API key configuration must be part of the merger plan. Staged ingestion by business unit gives the team a way to test this matrix one unit at a time, and it keeps the audit trail of who retrieved what readable for the integration period.
Which merger rules shape the RAG knowledge base build
This table maps each regulatory rule that applies to a merged company's document estate to what it means for the RAG assistant build. Read each row as a question to answer before ingestion starts: who may see which documents, what must be recorded, and what must be exited or reported. Most rules apply through the acquirer's or target's own status, so confirm applicability with counsel before scoping.
| Rule or requirement | What it means for the build | Evidence to keep | Where it usually fails |
|---|---|---|---|
| SEC ICFR exclusion limits (US registrants) | An acquired business can be excluded from the ICFR assessment for up to one year, so its document sources and IT general controls must be scoped and tracked separately from the parent's. | Dated acquisition record, excluded-business disclosure, scope of the merged index mapped to financial reporting risks | Finance documents indexed into the assistant before the acquired business is brought into the control framework |
| SEC IT general control areas (Release 33-8810) | Access to the merged index is an ITGC access control. Program changes, such as connector or prompt changes, and access to data need documented evaluation. | Access review logs, change records for connectors and retrieval settings, periodic test results | Shared service accounts or connectors that read source files with broader rights than end users |
| Form 8-K Item 1.05 and third-party oversight (SEC registrants) | A material incident affecting the merged assistant may need disclosure within four business days of a materiality decision, and vendors that host or index documents fall under oversight. | Incident runbook covering the assistant, vendor oversight records for the implementation partner and model providers | No one owns the assistant's incident path across both legacy companies |
| NIS2 notification of changes (EU essential and important entities) | After a merger, changes to name, contact details, IP ranges, sector or service Member States must be notified to the competent authority without delay and within two weeks. | Updated entity register and IP range inventory covering the new assistant endpoints | New hostnames or IP ranges for the assistant go live before the regulator record is updated |
| DORA register and exit strategy (EU financial entities) | The assistant may be an ICT service supporting a function, so it must appear in the register of ICT arrangements and have a tested exit and transition plan. | Register entries at entity and group level, tested exit plan for the vector store and model services | Vector database or embedding service chosen without a documented way to move the index elsewhere |
| Data Act switching rights (EU data processing services) | Vendors must support switching to another provider or on-premises infrastructure with exportable data ported. Plan the index and metadata formats so they can be exported. | Contract terms on switching, export tests of the vector index and document metadata | Index stored in a proprietary format that cannot be reconstructed from source files |
| EDPB treatment of remote access (non-EEA acquirer) | Giving a non-EEA acquirer's staff remote access to EU personal data in the merged index is a transfer, so a Chapter V transfer tool is needed before access is granted. | Transfer impact assessment, transfer tool on file, access list by country | Integration teams in another country query the assistant during due diligence or day-one operations |
| GDPR Article 28 instructions and Article 30 records | Processors that host or index the merged corpus must act only on documented instructions, including on transfers. Records of processing must describe Article 32 security measures. | Signed processor terms covering both legacy controllers, updated records of processing, instructions for re-indexing | Each legacy company's documents are indexed under the other's processing purpose without a documented basis |
| HIPAA business associate flow-down (where relevant) | If either company handles ePHI, the business associate contract must require Security Rule compliance, flow the terms to subcontractors such as model hosts, and report incidents. | Business associate agreements covering the assistant and its subcontractors, incident reporting procedure | Clinical or claims documents from one company appear in the general index used by the other |
| PCI validation decided by payment brands | Whether the assistant falls in PCI DSS scope depends on the payment brands' rules, not the PCI SSC. Keep cardholder data out of the index unless validation covers it. | Scope confirmation from the acquirer or brand, attestation status of any in-scope component | Card data embedded in ticket or payment documents that are ingested without redaction |
Which open-source platforms fit a merged document estate and why
After a merger, the assistant layer has to respect two identity systems, two sets of workspaces and two sets of document rules at the same time. The candidates below differ mainly in license terms, workspace limits and identity options, so the deciding question is whether the two estates stay separate for a while or merge on day one.
Dify for separate legacy workspaces
Dify is a visual platform for RAG pipelines, agents and workflows. The Community edition is free but limited to a single workspace, so keeping each legacy company in its own workspace points toward Enterprise. Dify's license also forbids running the source code as a multi-tenant service without written authorization, where one tenant is one workspace. Confirm that a shared internal assistant across two business units does not trigger that restriction before you build on it.
Dify Enterprise SSO for two providers
Dify Enterprise documents OpenID Connect, SAML and OAuth2, with providers such as Microsoft Entra ID and Okta. It also separates SSO scopes for workspace access and web app access, which matters when staff from the acquiring company should reach an assistant without gaining access to the target's workspace. Check whether your two identity providers can both federate into the same Enterprise instance, and map which groups receive which scope before ingestion starts.
Open WebUI and the branding clause
Open WebUI is a self-hosted chat interface that many teams use as the front end for a document assistant. Its license prohibits altering or removing the Open WebUI branding except for deployments with no more than 50 end users in any rolling 30-day period, with written permission, or under other listed exceptions. A merged company will usually exceed that user count, so the rebranding plan for the combined assistant needs a license decision first. Confirm the terms with the license text and the licensor.
RAGFlow for document-heavy ingestion
RAGFlow is an open source RAG engine under Apache-2.0 and suits estates with many file formats, scanned content and tables, where parsing quality drives answer quality. Its permissive license avoids workspace and branding limits, which simplifies a merged deployment. Test how it handles each company's legacy formats and whether its access controls can express the source permissions you must keep, because a permission model that cannot follow the source system will leak content after the merger.
AnythingLLM for team-scoped collections
AnythingLLM is an MIT-licensed application that organizes documents into workspaces and can run with a choice of model providers. Its MIT license leaves branding and deployment scope unrestricted, which fits a combined assistant that must be rebranded. Use it where each business unit needs its own collections and you can enforce access at the workspace level. Confirm whether its workspace model maps to the document permissions from both source systems, since workspace grouping alone does not carry file-level rights.
Qdrant as the self-hosted vector store
Qdrant is an Apache-2.0 vector search engine that you can run in your own infrastructure. Its default deployment listens on all interfaces with no authentication, so the merged estate needs API keys, TLS and network restrictions before any index holds data. It supports per-collection read and write permissions through JWT, and JSON audit logging of authenticated API operations, which helps when a combined company must show who queried which collection. Plan separate collections per legacy estate if the two stay apart.
Choosing by estate separation period
If the two estates will stay separate for a period, favor separate workspaces, separate collections and federated identity, and accept the Dify Community workspace limit or pay for Enterprise. If they merge on a set date, a single platform with one collection per source system and permission filtering at retrieval is simpler to govern. Record the decision in writing with its end date, because a temporary split often outlasts the plan.
Deployment patterns for two companies in one assistant
After a merger, the assistant has to reconcile two document estates, two identity systems and two sets of rules about who may read what. The patterns below differ in where data is separated, where permissions are enforced and how much operating work the vector store creates, so the choice should be made before ingestion starts.
Separate collections per legacy company
Each legacy company keeps its own vector collection, and one assistant routes each query to the collections the user is allowed to search. The integration point is the retrieval layer, which must select collections by identity before any search runs. Storage grows as two indexes, and each needs its own re-indexing schedule and evaluation set. Check whether cross-company questions can be answered at all, and whether routing errors could expose one company's documents to the other's staff.
One merged collection with permission filters
Both document estates go into a single collection, and every chunk carries source-system access metadata that is filtered at query time. The integration point is the metadata written during ingestion and the filter applied by the retrieval layer. Storage is lower and operations simpler, but one missing or stale permission tag exposes content across the former boundary. Ask the partner how filters are tested against sample users from each company, and how permission changes propagate to chunks already indexed.
Deal material enclave outside the index
Restricted transaction material such as valuation models, board papers and due diligence files stays out of the assistant's ingestion scope entirely and lives in a separately controlled environment. The integration point is the connector allowlist, which should reference folders or repositories by owner and classification rather than by file name. The trade-off is that deal teams lose assistant answers on those documents, so the boundary needs a documented owner and a regular review of what has been wrongly indexed.
Vector store deployment and replication
The vector store is a self-hosted Qdrant deployment, and the defaults matter. Qdrant instances are not secure by default, listening on all interfaces with no authentication, so API keys, TLS and network restriction must be configured before any merged content is loaded. Qdrant needs block storage rather than NFS or S3, and a replication factor of 2 doubles storage. The distributed docs recommend at least three nodes for production so quorum survives a node failure. Ask for the node layout and backup plan in writing.
Identity bridge between two directories
The identity bridge maps users from both legacy identity systems to one set of group or attribute claims that the assistant and vector store can enforce. Qdrant supports JWT-based access control with per-collection read or write permissions, which gives the bridge a concrete target. The integration point is the token issued after login, so claims from each company must be normalized there. Confirm how leavers, transfers and contractors are handled during the transition, since a stale mapping keeps access alive after a person's rights have ended.
How to stage ingestion by business unit
Some units already work from the same document templates, classification labels and retention rules. These are the lowest-risk units to ingest first, because the main work is confirming that the shared standard is actually applied in the files and that their identity groups map cleanly into the assistant. Start with the unit whose source systems are closest to the target repository, then add units that use the same taxonomy so retrieval filters behave consistently across both estates.
- Ingestion order: Begin with the unit whose document system already matches the target connector, and load its approved policies and procedures before working files.
- Exclusions: Drop drafts, superseded versions and personal folders, even when they follow the shared template.
- Permission mapping: Confirm that each group in the source identity system maps to one group in the target, with no inherited access from the other company.
- Test set: Run a fixed set of questions with known answers and check that each citation points to the current version.
- Go-live check: Sample documents from each folder and confirm that a user without access to the source file receives no excerpt from it.
Before a unit becomes searchable, confirm that the sampled permissions match the source system for every group and that the citations resolve to the correct document version.
Where two units publish different versions of the same policy, such as expense limits, data handling or incident response, an assistant can return both answers with equal confidence. Ingestion must therefore first decide which policy is authoritative for each topic and whether the other version is retired, kept for a transition period or labeled as belonging to one legal entity. This decision belongs to policy owners on both sides, not to the team loading the content.
- Ingestion order: Build a register of overlapping policy titles and owners before loading either side, then ingest the agreed authoritative versions first.
- Exclusions: Hold back superseded or competing versions in a separate collection, or leave them out of the index, until the owner signs off.
- Metadata: Tag each document with its owning entity, effective date and status so answers can state which version they draw on.
- Conflict test: Ask paired questions that both policy sets address and record whether the assistant cites the approved version.
- Go-live check: Each overlapping topic has a named owner, a decision record and a passing conflict test before its documents become searchable.
Before a unit is released, confirm that every overlapping topic has a signed decision and that the assistant never answers from a retired version.
Due diligence files, valuation models, board deal papers and clean team material should not enter a general knowledge assistant at all. Their access is usually governed by legal instructions and information barriers that a standard permission sync does not represent. Keep these sources out of the ingestion pipeline by default, and treat any request to add them as a separate approval with legal and compliance sign-off.
- Exclusions: Exclude deal rooms, transaction folders, clean team repositories and any document marked as restricted or subject to a confidentiality agreement.
- Discovery: Scan candidate sources for deal terms, code names and restricted labels before connecting them, and report hits to the approving team.
- Separation: Store any approved deal collection in its own index with a restricted group, never in the general collection.
- Audit trail: Record who approved each exclusion or inclusion, and keep the decision with the source list.
- Go-live check: A test user outside the deal team receives no result from restricted collections, and the exclusion list matches the approval record.
Before any unit is loaded, confirm that the exclusion list has been approved by legal and that the scan found no restricted material in the connected sources.
Some units hold EU personal data and may only allow processing or access from the EU or another approved location. The residency question changes the ingestion plan. Indexing, embedding and retrieval must run in the approved environment, and the acquirer's staff may need to be excluded from access. Under EDPB Guidelines 05/2021, remote access to EU personal data from a third country, including for support or administration, is a transfer. Giving a non-EEA acquirer's staff access to an EU target's systems therefore needs a Chapter V transfer tool. Confirm this with counsel before granting any cross-border administrative access.
- Ingestion order: Deploy the vector store and model endpoints in the approved location first, then ingest that unit's documents there.
- Access design: Define which administrators and users, by location and employer, can reach the index, logs and backups.
- Exclusions: Keep personal data fields and records that do not need to be searchable out of the index, consistent with data minimization under GDPR Article 28 and Article 30 processing records.
- Processor terms: Confirm that the processing instructions and any sub-processors match the documented scope.
- Go-live check: Check that the index, logs and support paths sit in the approved location and that no non-approved staff can reach them from outside it.
Before the unit becomes searchable, confirm the residency design, the access list and the transfer analysis are signed off by counsel and the data protection lead.
Deduplicating conflicting policies without losing authority
Two policies on the same topic cannot be merged into one chunk. After a merger, the acquirer's expense policy and the target's expense policy may both cover approval limits, but they state different thresholds, apply to different legal entities and take effect on different dates. If the text is blended into a single passage, the assistant can return a threshold that neither company actually enforces. Each policy should stay a separate, versioned document with its own owner, legacy unit, effective date and status. Deduplication then happens at the level of the policy record, not the wording. Before ingestion, the integration team should build a register that lists every overlapping topic, the controlling document for each legacy unit and the date from which that document governs.
Retrieval makes the problem worse because a semantic search ranks passages by similarity, not by currency. A superseded target policy that uses the same vocabulary as the current acquirer policy can outrank it, and the answer then looks confident and well sourced. To prevent this, store supersession metadata on every document, such as policy_id, version, legacy_unit, effective_from, effective_to and supersedes, and filter on status at query time for each user's business unit. Confirm with the chosen platform, whether RAGFlow, AnythingLLM, Dify or Open WebUI, how metadata filters are set and whether they apply before or after ranking, since that determines whether a superseded passage can still be returned.
The citation design is what lets a reader check authority. Each answer should show the document title, version, effective_from date and legacy unit beside every cited passage, and it should flag when a cited source has been superseded or when two in-force policies conflict for the user's unit. Agree with the policy owners, before go-live, what the assistant says when no single policy governs a question, and test that case explicitly with a set of questions drawn from both estates. Keep the register and the metadata under change control, because a policy re-issued after close will otherwise leave the assistant citing a version no one has approved.
How the staged rollout of a merged RAG knowledge base runs
The sequence turns two document estates and two identity systems into one assistant that only answers from sources each user is already allowed to read. Each phase closes with a named artifact, so the deal team, security, legal and the business units can see what has been agreed before the next group of documents is indexed.
Scope the merger and exclude deal material
Agree in writing which business units, document repositories and data categories are in scope for the first release, and which are excluded. Restricted deal material, such as valuation models, term sheets, board papers and counterparty correspondence, is named explicitly as out of scope, with the owner of that decision recorded. Legal and the deal team sign the scope, and the exclusion list is carried into connector configuration as a deny list rather than left to individual users. The closing artifact is a signed scope document with the exclusion list attached. Ask the implementation partner to show how exclusions are enforced at the connector level, not only in the user interface.
Map identities and permissions across both systems
Inventory the identity providers, directory groups and document-level permissions in each legacy estate, then define how each source group maps to a group in the combined environment. Engineers confirm which permissions are inherited from folders, which are set per file and which change when a user moves between entities. Where a user belongs to both companies, the mapping must not grant access that neither original permission model allowed. The closing artifact is a permission map that lists each source group, its target group and the retrieval filter it produces, reviewed by the security owner of each legacy estate.
Inventory sources and build the policy conflict register
Catalog every repository in scope with its owner, file types, scanned content, last-updated history and retention obligations. Compare policies that cover the same subject across both companies, such as expense rules, information security standards or data handling procedures, and record each pair where the rules differ. Each conflict receives an owner and a decision: keep both with clear labeling by entity, adopt one, or retire both pending a new policy. The closing artifact is a source inventory and a policy conflict register that business owners have approved, since an assistant that cites two contradictory rules without context causes its own problems.
Pilot ingestion for one business unit
Index the sources for a single business unit with the agreed permission filters, chunking settings and citation format. The pilot shows how the vector store, the metadata that carries permissions, and the re-indexing schedule behave on real documents before the scope expands. Engineers check that deleted or restricted files leave the index and that the permission metadata matches the permission map. The closing artifact is a pilot run record covering document counts, failed files, permission test results and the ingestion log, reviewed by the platform team and the business unit owner.
Evaluate retrieval, citations and access controls
Build an evaluation set of questions drawn from the pilot unit, with expected source documents and expected answers reviewed by subject matter experts. Run the set and record whether the right documents are retrieved, whether citations point to the correct passages, and whether answers fabricate content. Separately, test access with accounts from each legacy company and confirm that no user receives a citation to a document they could not open in the source system. The closing artifact is an evaluation report with pass criteria agreed before the run, plus an access test record. Ask the partner which evaluation tooling is used and how results are versioned between runs.
Onboard the remaining units in stages
Add one business unit at a time, repeating the permission mapping, conflict decisions and evaluation steps for each. Each wave has its own entry criteria, so a unit is not added until its permission map is approved and its evaluation set passes. Monitor retrieval quality and index growth after each wave, and keep a rollback path that removes a unit's collection without affecting the others. The closing artifact is a wave-by-wave onboarding record listing the units onboarded, the approvals obtained and any sources held back, which the steering group reviews before the next wave starts.
Hand over operations and evidence
Transfer the running system to the operations team with runbooks for connector failures, permission changes, re-indexing, key rotation and incident response. Confirm that audit logging of queries, retrieved sources and access decisions is retained for the period set by the organization's policy and any applicable law, and that the logs are readable by the compliance team. Schedule periodic access reviews that compare the permission map with the source identity systems, since both companies will keep changing their groups after close. The closing artifact is a handover record with signed runbooks, the access review schedule and the first completed access review.
Evidence a merged RAG knowledge base should produce for auditors
This table maps each piece of evidence that auditors, regulators or acquirers tend to request to the component that produces it in a merged RAG knowledge base. Read it as a checklist: if a row has no owner or no retained record in your design, the gap is worth closing before the two document estates are combined. DeployOpen prepares this evidence for assessors, but independent auditors and certification bodies issue any attestation.
| Evidence item | Produced by | What the assessor expects | Where it usually fails |
|---|---|---|---|
| Access control design for the merged index | Architecture record and collection layout in the vector store | Documented mapping of which collections, sources and business units each group can query | Collections created by source system with no written rule for who may query across them |
| Permission mapping records | Connector sync logs and the mapping from both identity systems | Source ACLs traced to group identities, with dates and the owner who approved each mapping | Permissions copied once at ingestion and never refreshed after joiners and leavers |
| Register of ICT arrangements (DORA Article 28(3)) | Vendor and service inventory covering the RAG stack and hosting | Each component, provider, location and the function it supports, kept at entity and group level | Acquired entity's tools missing from the register until after close |
| Exit and switching plan (DORA Article 28(8), Data Act) | Documented export of vectors, metadata and source references | Tested steps to move the index and documents to another platform or on-premises infrastructure | Plan describes the application but not how vectors and chunk metadata are exported |
| Audit logs of authenticated API operations | Qdrant JSON audit logging of authenticated operations (since v1.17.0), plus the application's own access logs | Who queried or changed a collection, when, and under which key or role | Logging turned off by default, or only the application layer logged and not the vector store |
| Model interaction logs and retention | Application logs, gateway logs and observability traces | Retained prompts, retrieved sources and answers for the period set by the applicable law (AI Act Article 19(1) sets at least six months for high-risk systems) | Logs kept for debugging but deleted on a short default schedule with no legal hold |
| Automatic event recording (AI Act Article 12(1)) | Logging configuration for the merged assistant, where high-risk obligations apply | Evidence that events are recorded automatically across the system lifetime, with a documented scope | Teams assume the assistant is not high-risk without a recorded classification decision |
| Records of processing and transfer tools (GDPR Articles 28 and 30) | Processing register entry for the merged corpus, plus transfer assessment for any cross-border access | Documented purposes, categories of data, security measures and transfer tool where a non-EEA acquirer's staff can reach the data | Acquirer staff granted access to target systems before any transfer tool is in place |
What to ask an implementation partner about a merged document estate
Start with the identity question, because it decides whether the assistant can be trusted at all. Ask the partner how each source system's permissions become one retrieval filter, and who owns the mapping table that translates group memberships from both identity systems into a single set of collection rights. A strong answer names the identity provider for each legacy estate, the attribute used to match users across them, and the rule for users who hold rights in both. Ask for the rule in writing, and ask what happens when a source file's permissions change after indexing. Also ask whether the design filters at query time against current permissions or relies on a snapshot taken at ingestion. The partner should be able to show a sample of the filter logic and explain which Dify or Open WebUI settings carry it, rather than describing the approach in general terms. Next, ask how deal material is kept out and how that exclusion is proven. The partner should describe the source allow-list, the classification tags that block ingestion, and the step that rejects a document whose metadata is missing a label. Ask for a named evidence list: the ingestion manifest showing every file considered and excluded, the rule set version in force at each run, and a test in which a user without deal access asks for a known deal term and receives no match. Ask how the partner tests conflicting policies, including whether they flag two documents that give different answers on the same topic, assign a source owner for each, and set a precedence rule that the assistant cites. Also ask who signs off the final policy set and how that approval is recorded. Finally, ask how erasure requests and re-indexing work across two sources. Each source needs its own delete path that removes the file, its chunks, and its vectors from the self-hosted Qdrant or other vector store, and the partner should show how they verify that no orphaned vectors remain. Ask about the Dify license limit as well: the Dify Open Source License forbids operating a multi-tenant environment from the source without written authorization, so a single merged workspace used by staff of one company is a different question from a design that serves separate tenants or customers. Ask the partner to confirm in writing which license applies to their design and whether Open WebUI branding terms affect the rollout. Request a written scope that lists sources, exclusions, test cases and evidence before any work starts.
What a RAG knowledge base after a merger costs and takes
What drives the cost of merging two document estates into one RAG assistant?
The cost is driven mainly by how many identity systems and document sources must be mapped, how many policies conflict, and how much evaluation and deal-material control work is needed before anyone uses the assistant. Each source adds connector work, parsing, permission mapping and testing. Identity mapping is often the largest single item because every source must enforce the access rules of the system it came from. Ask any partner to price these components separately in the written scope: identity mapping per system, connectors per source, policy reconciliation, answer evaluation, and the controls that keep restricted deal material out of the index. Infrastructure, such as the vector database and model hosting, is a smaller and recurring part that scales with corpus size and query volume.
Can our own team build a merged RAG assistant without outside help?
A capable internal platform team can run the platform, but the merger-specific work usually needs people who know both companies' identity and document systems and can document the decisions for auditors. The hard parts are mapping permissions from two identity systems so answers respect the source access rules, deciding which policies win when they conflict, and proving that restricted deal files never reach the index. Your team likely already owns the identity systems and document repositories, so the question is capacity and independence. Many buyers combine internal ownership of data and decisions with a partner for implementation, hardening, testing and documentation. Confirm your team's skills in each area during a scoping conversation rather than assuming them.
What do IT, security and legal teams from each company need to provide?
Each company needs to supply access to its identity provider, document repositories and permission models, and a named owner who can approve mappings. Security must review how the index stores document-derived vectors, how logs are kept and who can query them. Legal must define which material is restricted, such as deal documents, privileged files and personal data, and which local rules apply to moving data between entities. The work involves:
- IT: directory exports, connector credentials and change windows in both environments
- Security: review of access controls, secrets handling and incident procedures
- Legal and compliance: classification of restricted material and sign-off on data sharing before ingestion
Agree these responsibilities in writing before the engagement starts, because delays in any one team stall the whole project.
How does the legal close date affect the timeline for a merged knowledge base?
The legal close date sets when the two companies may share data, so ingestion of the target's documents usually cannot begin until the relevant agreements and data access rules allow it. Staged onboarding helps: start with the business units or document sets that are cleared first, prove permissions and evaluation on them, then add the rest in waves. Each wave needs its own permission mapping, testing and sign-off, so the schedule depends on how many waves are planned and how quickly each company's teams can respond. Ask a partner for a timeline tied to named milestones, such as close, identity trust established and first business unit live, rather than a single end date. Any duration should appear in the written scope, not in a general estimate.
Does a Dify license change the design of a merged RAG assistant?
It can. Dify is licensed under a modified Apache License 2.0 that forbids using the source code to operate a multi-tenant environment, where one tenant is one workspace, without written authorization. A merged company that uses one internal workspace for its own staff is a different case from a product serving several customers, but the boundary must be checked against the current license text before design starts. The license also forbids removing or modifying the logo or copyright information in the console. Dify Enterprise adds SSO and multi-workspace management under a commercial license. If the license does not fit, consider RAGFlow, which is Apache-2.0, or AnythingLLM, which is MIT. Confirm the choice with your legal team, because the license governs how the platform may be used in the merged organization.
How should we compare a self-built merged RAG assistant with a SaaS knowledge assistant?
Compare total ownership, not license fees alone. A SaaS assistant may reduce platform operations but usually requires you to send both companies' documents and permission data to the vendor, which needs contractual and regulatory review during a merger. A self-hosted build keeps data in your infrastructure and lets you control permission mapping and deal-material exclusion, but it adds platform operations and implementation work. Build a comparison table with the same inputs for each option: number of sources, identity systems, expected users, data residency rules, exit requirements and who runs evaluation. Where a regulation applies, check exit and transition obligations. For example, EU Data Act switching rules require data processing providers to support porting and switching. Request written quotes from each vendor and partner against the same scope.
Where can we get a quote for a merged RAG knowledge base?
DeployOpen does not publish a price list. A quote follows from a written scope, which covers the sources to connect, identity systems to map, business units in each wave, restricted material to exclude, evaluation requirements and the hosting environment. Most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts. Ongoing support, upgrades and continuous testing are available as retainers, so ask for those to be priced separately from the initial build. To prepare a useful request, gather an inventory of document sources, a list of identity systems with the number of users in each, the policy documents you expect to conflict, and the legal restrictions on deal material. Contact DeployOpen with that inventory to start scoping.
How DeployOpen scopes and supports a merged RAG knowledge base
DeployOpen is a Chainscore Labs company that plans, implements, integrates, hardens, documents and supports self-hosted open-source platforms inside the client's own infrastructure. For a merged RAG knowledge base, we start with a written scope that separates the two document estates, the identity systems and the restricted material, then build and hand over the assistant in stages the client can verify.
How we scope
- Written scope lists each source estate, business unit and document collection included in the first ingestion stage.
- Identity mapping covers both directories, with the permission model for each source documented before any indexing starts.
- Restricted deal material and its exclusion criteria are named in the scope, with the owner who approves each boundary.
How we build
- Connectors and parsing pipelines run in the client's own cloud accounts or data centers, with permissions carried into retrieval filters.
- Conflicting policies are flagged for deduplication, and each retained version is tagged with its owner and effective date.
- Retrieval and answer tests run against both legacy estates before each business unit is released to the assistant.
How we hand over
- Deliverables include architecture records, permission mapping tables, ingestion runbooks and the list of excluded sources with reasons.
- Test results for permission filtering and citation accuracy are documented so the client's reviewers can check each release.
- Knowledge transfer sessions cover re-indexing, adding a business unit and handling a document removal request.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after the fixed-scope engagement closes.
- Upgrades to the chosen platform, such as Dify or Open WebUI, are tested against the permission and citation checks before rollout.
- Confirm with us which license terms apply to the chosen platform before any use across a combined group of legal entities.
