Dependency Availability and Supplier Support Are Different Promises

When a software package lists its dependencies, buyers and integrators often treat that list as a promise of a working system. A dependency manifest is a declaration of what is needed, not a guarantee of what will behave correctly at runtime. Understanding the difference between dependency availability and supplier support is essential for anyone evaluating robotic software stacks, particularly when acquisition decisions hinge on perceived completeness of documentation. This article examines what a manifest can and cannot reveal, why support obligations must be recorded separately, and how to read between the lines of package metadata without mistaking it for a warranty.

What a Dependency Manifest Actually Declares

A package manifest records the names or keys of external components that a piece of software expects to find. In the context of robotic software ecosystems, rosdep is a dependency management utility that can work with packages and external libraries. The manifest identifies what is required; rosdep then maps those requirement keys to concrete packages or libraries available on the target platform. This two-step process—declaration followed by resolution—creates an impression of certainty that does not always hold up in practice.

The manifest tells you that a dependency was named. It does not tell you which version will be installed, whether that version has been tested against the specific platform configuration, or whether the resolved component will interact cleanly with every other resolved component. A dependency name alone does not establish an installed version or successful runtime behaviour. The gap between "named" and "verified working" is where many integration problems begin, and it is a gap that no manifest, however thorough, can close on its own.

Availability Is Not the Same as Compatibility

It is tempting to assume that if a dependency can be found and installed, the system is ready for use. Availability merely means the component exists in a repository or can be retrieved from a source. Compatibility requires evidence—testing logs, integration records, documented platform matrices—that the specific combination of resolved versions has been exercised together under conditions resembling the intended deployment.

Consider a hypothetical documentation review in which a dependency has been located and installed. That observation concerns installation. To conclude that the application behaves as intended, the reviewer would need evidence addressing that application and environment. The manifest alone does not supply those observations. This example does not diagnose a middleware conflict or claim that a failure occurred; it separates the questions that a declaration and a behavioural assessment answer.

Why Supplier Support Must Be Documented Separately

Dependency resolution is a mechanical process. Supplier support is a human and organisational commitment. One can exist without the other, and neither implies the other. A package may have perfectly resolvable dependencies yet come from a maintainer who offers no response timeline, no escalation path, and no obligation to address integration issues. Conversely, a supplier with strong support practices may distribute software whose dependencies are difficult to resolve on certain platforms.

Support responsibility should be captured in a document distinct from the manifest—a support statement, a service-level description, or a contractual annex that specifies response expectations, update policies, and the boundaries of what the supplier will and will not address. Without this separation, buyers may assume that a complete dependency list carries an implicit promise of assistance, an assumption that can lead to disputes when problems arise that fall outside the supplier's actual commitments.

When reviewing documentation for a robotic software acquisition, ask explicitly: where is the support boundary defined? If the answer is "the manifest covers it," that answer is insufficient. The manifest covers dependency declarations, not human response obligations.

Reading Documentation Without Overreading It

Effective evaluation requires reading what is present while resisting the urge to infer what is absent. A well-structured manifest, combined with clear support documentation, gives a buyer a solid foundation for assessment. But neither document type can substitute for direct inquiry or for testing under realistic conditions.

Some useful questions to bring to a documentation review include: Has the supplier published a platform compatibility matrix, or must that be requested? Are dependency resolution records retained and shared, so that the exact versions installed during a reference deployment can be reproduced? What is the process for reporting an issue that appears to stem from a dependency interaction rather than from the supplier's own code? These questions probe the space between what the manifest declares and what the supplier stands behind.

Related explanations in the technical category can help a reader distinguish dependency information from support statements. They are not records of previous acquisitions or evidence of any supplier’s commitments. For a specific transaction, ask what the supplier actually states and which relevant records can be reviewed.

The Role of Supply-Chain Guidance Without Conflating It with Procurement Mandate

Broader frameworks exist for thinking about software supply-chain security and supplier evaluation. NIST software supply-chain guidance addresses software security practices and evaluation of software developers and suppliers. Such frameworks can inform how a buyer structures their own assessment criteria, but they should not be treated as certifications of individual products or as mandatory checklists imposed on every transaction.

This overview does not certify a product or impose editorial documentation suggestions as requirements on every buyer. The distinction matters. A buyer may choose to adopt practices inspired by supply-chain guidance—requesting provenance records, verifying dependency resolution paths, documenting support boundaries—but these remain editorial and procedural choices, not externally enforced rules. Conflating guidance with mandate can lead to checkbox compliance that satisfies a perceived standard without actually reducing risk.

Building a Documentation Practice That Respects the Difference

The healthiest approach is to treat dependency manifests and support records as complementary but non-overlapping sources of truth. The manifest answers "what is needed." The support document answers "what happens when something goes wrong." Neither answers the other's question.

A team can retain its dependency observations alongside the supplier statements it actually received, identifying what each document establishes. The article archive provides further reading, not acquisition files. If support scope is unclear, leave that issue open rather than inferring it from package availability. This preserves the difference between a technical dependency record and a human commitment without inventing obligations.

The core discipline is simple in statement though demanding in execution: read declarations as declarations, read support promises as promises, and never allow one to silently stand in for the other.