# Vendor lock-in is an architecture decision

Specify which company intelligence remains usable after exit, and which runtime and maintenance rights need a separate agreement.

> By Saad Bin Shafiq, Founder of Nodes · Jun 10, 2026
> Canonical: https://www.nodes.inc/blog/vendor-lock-in-is-architecture


---
What happens to us if this does not work out?

That is a practical buying question. The company may have spent years assembling evidence, decisions, and operational knowledge. Ending a software license should not mean discovering that the useful history was never separable from the vendor's interface.

Reassurance is not an exit specification. Ask for the artifacts, rights, formats, and operating work.

## Separate company intelligence from the runtime

Company intelligence includes more than source documents. It can include relationships among records, human reasoning, decision history, observed outcomes, and the scope in which an accepted lesson applies.

The runtime is the software that retrieves context, supervises agents, routes tools, enforces controls, and carries work forward. A company can own separable intelligence without holding a perpetual license to that software.

Nodes' ownership direction preserves that distinction: customer-specific intelligence belongs with the customer; Nodes' platform code and pre-existing reusable intellectual property remain licensed. Exact rights and transition obligations belong in the applicable agreement.

## An artifact map to request

**Evidence and source references.** Which records are retained, which remain in their source systems, and what provenance links are exported? Confirm that identifiers and timestamps survive the transition.

**Relationships and decision history.** Can the customer recover the connections among evidence, a proposal, human changes, the authorized action, and the later result? A PDF screenshot is different from a structured record another system can use.

**Judgments and applicable learning.** Keep who supplied a correction, why, and the scope in which it applies. Temporary agent drafts should not be exported as accepted enterprise truth.

**Capabilities and configurations.** Identify which customer-specific instructions, mappings, workflows, and evaluation artifacts are separable. Distinguish them from vendor-owned code, models, and platform components.

**Model rights.** Where customer-specific weights exist, specify their ownership and permitted use. An open-weight license is not the same as unrestricted redistribution or a perpetual right to every surrounding service. Company learning need not depend on fine-tuning at all.

**Operating documentation.** Ask for schemas, version information, supported export procedures, and the implementation work needed to use the retained assets elsewhere. Agree the actual formats and test an export rather than inventing a standard list.

This is a diligence checklist, not a claim that every artifact or export facility is currently available from Nodes.

## Test the day after exit

Can a new tool interpret the records and reconstruct an earlier decision? Which permissions still apply? What happens when a source changes? Who maintains the connectors and evaluates a replacement model?

Do not assume that an interface remains available because its underlying data is customer-owned. Continued Nodes runtime access, support, upgrades, and maintenance depend on license and transition terms. A replacement runtime may require engineering.

Nor should a vendor claim that private hosting eliminates every dependency. An application can run in your cloud and still rely on proprietary schemas, licenses, or operating knowledge that your team does not have.

## Reconstruct one decision outside the interface

Use a small, authorized test case before negotiating around a vague promise of export. An illustrative case might involve a proposed onboarding intervention, a manager's revision, approved tasks in connected systems, and a later report showing that the hoped-for improvement did not appear.

Ask the receiving team to reconstruct that case using the proposed export and its documentation. Choose tools it expects to have after transition. Keep vendor assistance visible so the exercise reveals what the receiving team can do independently and where it still needs help.

Start with the original objective and the evidence available at that time. Can the team identify the sources, versions, missing records, and assumptions? If the export contains only the latest version of each record, it may describe the company today while failing to explain the earlier decision.

Next inspect the human contribution. The manager may have changed the affected population or removed one proposed action. The receiving team should be able to distinguish the original proposal, the manager's reasoning, and the specific version authorized. A final status labeled approved cannot answer all three questions.

Follow the authorized actions into their destination records. An internal event saying a write was attempted is different from external confirmation that it happened. Preserve unresolved effects as unresolved. An export should not turn a missing response into a clean success merely to simplify the history.

Finally, connect the later outcome and any proposed lesson. The record should show when that outcome arrived, what it measured, and how far it supports the conclusion. The receiving team should be able to tell an accepted procedure from an agent's draft explanation and recognize the circumstances in which either remains useful.

## Check the connections that make the export usable

During the exercise, keep a short issue register. Record identifiers that cannot be resolved, missing source references, undocumented fields, permissions that cannot be interpreted, and artifacts available only through the vendor's interface. Assign each issue an owner and a proposed treatment before calling the export complete.

Compare the test package with an agreed inventory of records and relationships. A file opening successfully says little about completeness. A reader may recover every decision record but lose the links to the evidence that made those decisions understandable. Reconciliation should cover the relationships the customer intends to preserve.

Apply access checks to the exported package too. A migration should not place restricted personnel evidence into a broadly shared archive just because the receiving tool has simpler permissions. Identify who may create the export, receive it, store it, and make derived views from it.

Separate two acceptance outcomes. The customer may be able to reconstruct historical decisions while still needing engineering to run equivalent workflows. Both can be acceptable if they are explicit. Calling the archive operationally portable would hide the work required to replace tools, controls, model routes, and supervision.

These are requests to test the offered scope, not a statement that Nodes currently provides every artifact or transition facility described here. A concrete sample is more useful than a long checklist of hypothetical export formats.

## Account for work that is still running

An exit can begin while tasks are awaiting approval, actions have uncertain results, or business outcomes have not yet arrived. The transition plan should name who remains responsible for each kind of unfinished work. Exporting completed history alone leaves those obligations unanswered.

For an authorized task in progress, decide whether it finishes in the existing system, pauses, or transfers to a replacement. Record the plan version and current state before changing credentials or connections. Revoking access too early can prevent reconciliation; leaving it active without an owner creates a different control problem.

Confirm how the team will handle delayed reports. A quarterly production result may arrive after the operating workflow has moved elsewhere. The receiving system needs enough identifiers and context to connect that result to the earlier action without pretending it was known at the time.

Then document the agreed retention, deletion, backup, support, and license arrangements with the appropriate owners. Include the customer effort required to validate a replacement and the vendor assistance actually included. No particular format, transition period, or continued software right should be assumed from an ownership slogan.

This preparation also improves the purchase decision. It exposes which dependencies the customer is comfortable retaining and which would make a later change impractical. A buyer can accept a licensed runtime dependency while insisting that important business history remains understandable beyond that runtime.

## Private deployment and ownership are related, but different

Nodes supports Nodes Cloud, a single-tenant customer VPC, and customer-managed on-premises deployment. The [security overview](/security) distinguishes their boundaries.

A private configuration can enforce zero customer production-data egress when the approved model routes, integrations, logs, backups, and controls support it. A hosted configuration does not by itself mean that the provider trains on customer data or transfers it to competitors. Review the actual configuration and terms.

There is no default pooling of confidential customer memory or training across tenants. Any contemplated derivative-artifact transfer requires explicit authorization and security evaluation; stripping direct identifiers is not proof that weights cannot retain sensitive information.

## What the production record tells us

Nodes' insurance candidate-evaluation deployment reached production 34 days after contract, with a separate 17-day legal-approval milestone. The [evidence register](/evidence) documents that reference. The public record does not establish that a particular export feature or contract clause caused the schedule.

The broader company-intelligence and agent runtime remains product direction beyond the demonstrated application. Ask which ownership and export commitments are supported in the offered scope, then put them in writing.

For the current [platform evaluation](/comparisons), inspect operating responsibility and practical exit together. A system is easier to buy when both are understandable.

*Saad Bin Shafiq is the founder of Nodes, serving data-sensitive enterprises. Methodology: [Decision Traces](https://arxiv.org/abs/2604.19819).*