Evidence checked October 31, 2026. This article distinguishes published specifications, bounded research findings, and original hypothetical operational examples. It does not provide an assessment of any named organization's software.
A list is the beginning of an answer
An urgent vulnerability announcement creates a deceptively simple question: do we use the affected software? A software bill of materials can help answer it by identifying components associated with a product. But the next questions are harder. Is the inventory tied to the deployed build? Is the affected component actually present? Does the vulnerable code participate in an execution path? What evidence supports an assertion that the product is not affected?
The 2026 Minimum Elements for a Software Bill of Materials, published on the Australian government's cyber guidance site on September 8, describes baseline data fields and practices for SBOMs. The jointly authored guidance distinguishes component data from the analysis needed to turn it into risk decisions. It also separates assurance about document integrity from assurance about accuracy and completeness. It is guidance, not a new legal requirement created by the document itself. 2026 SBOM Minimum Elements.
That distinction should shape how buyers and operators use inventories. A machine-readable file can be valid yet incomplete. A complete list can describe the wrong artifact. An accurate artifact inventory can still lack the information needed to determine exploitability in a particular deployment.
The goal is not to dismiss SBOMs. It is to make them useful by treating every important conclusion as a chain of evidence. The chain begins with software identity, continues through component discovery and dependency relationships, and ends with a documented decision about what to investigate or change.
In a hypothetical incident, an operator receives three inventories for the same product name. One describes source dependencies, one describes a container image, and one came from a supplier before a maintenance release. None is necessarily dishonest. But without generation context and artifact identity, the operator cannot know which file answers the immediate question. Transparency becomes operational only when the inventory is connected to the software actually under review.
The artifact boundary determines what the inventory means
Software can be examined at several stages: source checkout, dependency resolution, build, package assembly, container creation, installation, and runtime. Each stage exposes different information. A source manifest shows declared dependencies. A final image shows what was packaged. A running process can reveal loaded modules and dynamically obtained content.
Those views should not be casually treated as interchangeable. A development dependency may be absent from production. A build tool may embed a library into a binary without leaving its original package metadata. A runtime plugin may arrive after the release inventory was generated. A base image can contribute operating-system packages that the application manifest never mentions.
This article proposes naming the inventory boundary in ordinary operational terms. For example: this document describes the contents of a specified release archive, generated after packaging, excluding components downloaded later by an optional feature. That statement is more useful than an unqualified claim that the product has an SBOM.
The boundary should also identify the environment when environment changes affect resolution. The same source can produce different dependencies for different architectures, operating systems, optional features, or build flags. A single product version may therefore need multiple artifact-specific inventories or an explicitly structured description of variants.
A hypothetical buyer could ask the supplier to select one deployed artifact and trace it to the corresponding inventory. The exercise would verify the artifact identifier, generation stage, tool version, and known exclusions. If the supplier can only provide a general product-family list, that information may still help discovery, but it should not be presented as proof of the contents of every installed copy.
Schema validity does not establish completeness
A schema validator checks whether a document follows a format's structural rules. It can detect a missing required field, an invalid value type, or a broken reference. It cannot independently know whether a component was omitted from the software inventory.
This difference is easy to lose in automated procurement. A file passes validation, a dashboard turns green, and the organization treats the result as evidence that it knows the software's composition. The successful test actually establishes a narrower fact: the submitted data satisfies selected format constraints.
CycloneDX explicitly provides composition information for describing the completeness of components, services, and dependency relationships. Its overview includes complete, incomplete, and unknown aggregate states. Those fields help express the limits of an inventory; their presence does not independently verify the producer's assessment. CycloneDX specification overview.
A quality check should therefore distinguish structural validity, internal consistency, and external coverage. Structural validity asks whether the file can be interpreted. Internal consistency asks whether identifiers and relationships agree within it. External coverage asks whether the document accounts for the software that actually exists at the stated boundary.
For a hypothetical package, the evaluator might compare the inventory against installation metadata, the build dependency resolution, and a scan of the release archive. Differences would be investigated rather than automatically merged. A component appearing in one view but not another could reflect a tool error, a stage difference, or a legitimate exclusion.
A completeness claim becomes stronger when it includes the method used to support it. The useful question is not simply whether the producer checked the complete box, but what observations would reveal that the box was wrong.
Missing edges are not evidence of isolation
A component list and a dependency graph contain different information. The list says which components are reported. The graph says how specified components relate. A component with no declared edges might be independent, or its relationships might simply be unknown or omitted.
A preprint submitted in July 2026 and revised October 22 examines declared dependency graphs in a large collection of real-world SBOM files. It reports substantial variation in graph completeness and generator behavior. The study concerns the sampled documents and their declared edges; it does not prove the true dependency structure of every represented application. No Edges, No Verdict.
The operational implication is straightforward: absence of a path in an incomplete graph cannot establish absence of a dependency. If a risk engine treats missing edges as proof that a vulnerable package is unrelated to the application, the inventory's uncertainty can become a false negative.
A hypothetical graph contains an application node and one hundred library nodes but no relationships. A query asks whether the application depends on a particular library. The correct answer from that graph is not no. It is that the graph lacks the relationships needed to decide. A system that returns no has silently converted missing evidence into evidence of absence.
Graph quality should be assessed independently of component count. A document containing thousands of packages may still be unsuitable for path-based analysis if its relationships are sparse or ambiguous. Conversely, a smaller inventory with explicit scope and well-supported relationships may answer a narrow question more reliably.
The dashboard should preserve an unknown outcome. Without it, pressure to produce binary answers will repeatedly turn incomplete data into unwarranted certainty.
Relationship types carry meaning
Not every relationship means that one component executes another in production. A package can contain a file, depend on a build tool, link to a library, or be generated from another artifact. Flattening these distinctions into a single connected graph can create misleading paths.
SPDX version 2.3.1 describes relationships among documents, packages, files, and snippets, and explicitly distinguishes no asserted relationship from a claim that none exists. Its relationship vocabulary provides a way to retain meaning rather than treating every connection as identical. The cited page is a specific specification version, not a claim about every SPDX implementation. SPDX relationships.
An impact-analysis system should state which relationship types it traverses and why. A containment path may be useful for locating a component inside an archive. A build dependency may matter for build-system exposure without implying runtime exposure. A runtime dependency may matter for a deployed service even if it is not physically inside the main package.
Consider a hypothetical documentation generator included only in the release process. Its vulnerability could affect the build environment while remaining absent from the shipped application. Treating it as a runtime dependency would misstate one risk. Ignoring it entirely would miss another. The inventory should preserve the distinction so the relevant team can investigate the appropriate boundary.
Graph direction also matters. If component A depends on component B, an impact query from B toward its consumers traverses the relationship differently from a question about what A requires. A visualization that looks connected is not enough. The query logic must align with the semantics of the recorded edges.
Component identity is a matching problem
A component name alone is often insufficient to match an inventory entry to a vulnerability advisory. Names can collide across ecosystems. A project can change its name. A distributor can package an upstream project under a different identifier. A fork can retain a familiar version string while changing the code.
The inventory should preserve the identifiers needed to distinguish those cases. Ecosystem, namespace, version, supplier or producer information, and artifact hashes can each contribute. None should be treated as a universal substitute for all the others. A hash identifies bytes under a specified algorithm; it does not by itself explain their upstream lineage.
A hypothetical entry named parser at version one point two could refer to unrelated packages in different ecosystems. A vulnerability match based only on that short name would be unreliable. The matching engine should show which identifier produced the match and whether the result is exact, inferred, or unresolved.
OSV's official documentation describes an aggregator of vulnerability databases using the OpenSSF vulnerability format and infrastructure for representing affected versions through version analysis. That is a useful source for structured vulnerability matching, not proof that every inventory identifier or advisory is complete. OSV documentation.
The operational record should retain both the original component identity and any normalized identity used for matching. If normalization later changes, the team can reproduce the earlier result and understand why a finding appeared or disappeared. Silent renaming can otherwise make a vulnerability queue look improved when only the matching rules changed.
Versions need ecosystem-aware interpretation
Version strings are not ordinary decimal numbers. Different ecosystems and suppliers use different ordering rules, suffixes, epochs, release channels, and patch conventions. A comparison that works for one package family can fail for another.
A hypothetical internal tool might interpret version ten as earlier than version two because it sorts strings lexically. Another might discard a distribution suffix that identifies a security patch. These are mundane implementation errors, but they can determine whether a vulnerability is flagged or missed.
The matching process should use the relevant ecosystem's version semantics and preserve ambiguous cases for review. A missing version is not equivalent to the latest version. A version range in a source manifest is not the same as the resolved version in a build. A lockfile can provide stronger evidence of resolution, but the final artifact still needs to be connected to that lockfile.
Backports introduce another distinction. A distributor may repair a vulnerability without adopting the upstream version number that an advisory lists as fixed. An operator should consult the relevant supplier's advisory and package metadata rather than assuming that the upstream number alone decides the issue. Conversely, a familiar version string should not excuse a locally modified package from investigation.
The evidence trail can record the match rule, advisory version, package identity, and reason for any override. That makes an exception reviewable. A free-text note saying false positive is less useful because it does not explain whether the issue was a name collision, a backport, a range error, or a deployment condition.
Generators should be tested against known constructions
An SBOM generator is an observation tool. Like any tool, it has a scope, assumptions, and failure modes. Running two generators can reveal disagreements, but agreement alone does not prove correctness if both rely on the same incomplete metadata.
A September 2024 study examined four CycloneDX-generating tools in the Python ecosystem and identified issues involving versions, metadata, remote dependencies, and optional dependencies. Its findings are bounded to the tools and conditions studied. The useful lesson is to test discovery behavior rather than assume that a successful command implies a complete inventory. SBOM Generation Tools in the Python Ecosystem.
A team can construct a small internal fixture with deliberately chosen dependency patterns: a direct package, a transitive package, an optional extra, a vendored library, a native extension, and a dependency fetched from a nonstandard source. The expected inventory is documented independently. The generator's output is then compared against that expectation.
This is not a substitute for testing real products. It is a diagnostic instrument that shows which patterns the tool can observe. When a release uses a pattern outside the tested capability, the inventory can mark that limitation or add another evidence source.
The fixture should evolve when the build system changes. A new packaging method may bypass the metadata the old generator relied on. Keeping the same tool version and command does not guarantee the same coverage if the surrounding software process changes. Tool qualification is therefore tied to the inventory boundary and the dependency patterns actually in use.
Build-time evidence and artifact evidence should meet
Build systems can know why a dependency was selected, which source revision was used, and what inputs were available. Artifact scanners can observe what was packaged. Combining these perspectives can produce a stronger account, but only if the relationship between them is explicit.
A hypothetical build resolves a library and then removes unused files during packaging. The build inventory may correctly report the dependency as an input. The release inventory may correctly omit files that were not shipped. If the two documents use the same vague label, their difference looks like an error. If they name their stages, the difference becomes useful information.
The evidence trail should connect source revision, resolved dependencies, build configuration, output artifact, and final inventory. This article is not concerned with prescribing a particular signing system. The point is semantic: the operator needs to know which observations describe which object and how those objects relate.
A release comparison can highlight unexpected changes. A new component appearing in the final artifact but not in expected build inputs deserves investigation. So does a component disappearing from the inventory without a corresponding packaging change. Such differences can reveal discovery regressions as well as real software changes.
The comparison should preserve legitimate transformations. Compilation, bundling, static linking, and minification can alter the visibility of components. A mature workflow records those transformations rather than forcing every stage to produce an identical list. The aim is consistency of explanation, not cosmetic agreement among files that observe different parts of the lifecycle.
A dependency path is not an exploit path
Knowing that an application depends on a library does not establish that a particular vulnerability can be exploited in that application. The vulnerable function may not be included, may not be called, may require an unavailable feature, or may depend on an input condition that the deployment does not expose.
The converse also matters. Failure to observe a call during a test does not prove that the call can never occur. A runtime trace covers the exercised workload. A static analysis may approximate possible paths but struggle with dynamic loading, reflection, generated code, or configuration-dependent behavior. Each method offers evidence within a boundary.
A hypothetical service uses a library for one parsing operation. An advisory concerns a different operation in the same library. The team can investigate whether the affected code is present and reachable, but it should not label the product safe merely because the usual test suite did not invoke that operation. The result depends on the analysis method and its coverage.
Reachability should therefore be recorded as a reasoned assessment with assumptions. Which artifact was analyzed? Which entry points were considered? Were optional plugins included? Was the configuration fixed? What would invalidate the conclusion? These details are more useful than a single reachable or unreachable badge.
A dependency graph can narrow the search, while code and configuration analysis refine the conclusion. Treating the inventory itself as an exploitability oracle asks it to answer a question it was not designed to resolve. The better workflow keeps composition evidence and exposure analysis connected but distinct.
VEX is a claim with a scope and an issuer
Vulnerability Exploitability eXchange documents communicate an assessment of a vulnerability's status for a product. They can reduce repetitive investigation when a supplier has already determined that a particular product version is not affected. But the value depends on whether the statement matches the product, vulnerability, and conditions under review.
The OpenVEX specification defines statuses and supporting information, including justification or impact information for not-affected statements. It provides a machine-readable structure for communicating those assertions. The structure does not independently prove that the issuer's underlying analysis is correct. OpenVEX specification.
A consumer should preserve the issuer, statement version or timestamp, product identity, vulnerability identifier, status, and supporting rationale. If a statement applies to a narrowly configured edition, it should not automatically suppress findings for every product with a similar name.
In a hypothetical example, a supplier says a vulnerable component is not present in a certain appliance build. That claim may be checked against an artifact-specific inventory. A different statement says the component is present but the vulnerable code is not on an execution path. That requires a different kind of evidence. Treating both as an undifferentiated waiver loses the reason the conclusion might later change.
The consumer also needs a policy for trust. A supplier's statement may be highly relevant without being the only evidence considered. The appropriate response depends on the supplier relationship, the specificity of the claim, and the consequences of error. Automated consumption should make those choices explicit rather than hiding them inside a blanket suppression rule.
Not affected should not mean never look again
An assessment can become stale when the software, configuration, or understanding of a vulnerability changes. A component previously absent may appear in a new build. An optional feature may be enabled. A later advisory may expand the affected range or describe another exploitation condition.
The triage system should therefore attach a reassessment trigger to important not-affected conclusions. The trigger can be a new artifact, a changed configuration, an updated advisory, or a revised supplier statement. A calendar review can be useful, but event-based invalidation is often more directly tied to the reason for the original conclusion.
A hypothetical service disables a vulnerable feature and records that configuration as the basis for reduced exposure. If a later deployment enables the feature, the old assessment should not remain silently valid. The configuration change needs to reach the vulnerability decision record, not just the operations dashboard.
The same principle applies to code analysis. A result tied to one binary should not automatically cover a rebuilt binary with a different dependency graph. Even if the product version label is unchanged, the artifact identity may reveal a meaningful difference.
Reassessment is not an admission that VEX is useless. It is what makes the statement operationally credible. A claim with clear boundaries can be reused safely within those boundaries and reconsidered when they change. A claim treated as a permanent exemption encourages exactly the complacency that machine-readable security information is supposed to reduce.
Triage should preserve uncertainty without paralyzing action
Security teams rarely receive perfect evidence at the moment they must decide what to do. An inventory may be incomplete, a supplier may still be investigating, and the deployment owner may not yet know whether a feature is enabled. The workflow needs an explicit way to represent that uncertainty while supporting action.
A useful record separates observed facts, inferred relationships, unresolved questions, and chosen mitigations. For example: the component is reported in the deployed image; the affected version match is exact; reachability has not been assessed; a temporary exposure-reducing configuration has been applied. That is more informative than a single red or green status.
A hypothetical team can prioritize based on several dimensions: evidence of component presence, vulnerability severity and conditions, exposure of the relevant service, available mitigations, and the confidence of the current assessment. The article does not propose a universal numerical score. Different environments have different consequences and operational constraints.
The important point is that uncertainty should not be confused with low risk. Nor should every unknown automatically require the same emergency response. A documented decision can explain why the team chose immediate mitigation, further investigation, scheduled patching, or acceptance of a bounded residual risk.
The inventory helps by making the question smaller and more traceable. Instead of asking every team whether they might use a library, the organization can identify candidate artifacts and owners. The evidence trail then shows what remains to be established before a candidate match becomes a confirmed exposure or a defensible dismissal.
The inventory needs an owner after delivery
An SBOM delivered at purchase can become detached from the product as updates accumulate. The organization needs to know who receives new inventories, how they are matched to installed versions, and what happens when the supplier corrects an earlier document.
A hypothetical contract can require delivery with each relevant release and specify an accessible correction channel. The operational process then verifies that the new file corresponds to the deployed artifact rather than merely storing it in a folder. The point is not to prescribe legal terms here, but to connect delivery to an actual maintenance responsibility.
Inventory updates can change prior vulnerability results even when the software itself has not changed. A corrected component version may reveal an exposure that was previously missed. A newly added relationship may alter impact analysis. The system should distinguish an inventory correction from a software remediation so that dashboards do not imply a patch occurred when only the evidence improved.
Ownership also includes handling failures. If a release arrives without an inventory, the team should know whether deployment pauses, proceeds under an exception, or uses a temporary discovery method. An unwritten expectation is easy to ignore under time pressure.
A small service-level process can make the information useful: named recipient, artifact matching, validation, coverage review, ingestion, and correction handling. The value lies less in collecting more documents than in ensuring that the documents remain attached to the software and decisions they are supposed to inform.
Procurement can test a supplier's answer, not just its format
A request for an SBOM often becomes a checkbox: supplier provides a file, buyer confirms it exists, and both move on. A more informative exercise asks the supplier to demonstrate a bounded use case with the delivered data.
For a hypothetical procurement, the buyer can select one release artifact and ask three questions. Which inventory describes it? How were bundled and transitive components discovered? How would the supplier communicate a corrected inventory or a vulnerability assessment for that release? The answers reveal whether the file is integrated into a process or produced only for compliance theater.
The buyer can also inspect an agreed sample of components against the artifact and build evidence. This is not a demand to manually verify every line. It is a way to test whether identifiers, versions, relationships, and declared completeness are supported by observations.
A controlled vulnerability exercise can then follow a known test advisory through matching and triage. The exercise should not involve exploiting a real system. It can use a synthetic product and advisory to see whether the workflow identifies the affected artifact, preserves uncertainty, accepts a properly scoped VEX statement, and reopens the case when its assumptions change.
Acceptance criteria should be stated in terms of these tasks. A specific format version may be necessary for interoperability, but it is not the whole goal. The operational question is whether the buyer can use the delivered evidence to find software, assess a claim, and take a documented action without relying on an undocumented conversation with the supplier.
Merging inventories can manufacture contradictions
Organizations often receive multiple inventories for overlapping software. Combining them can improve coverage, but a naive merge can create duplicate components, conflicting versions, and relationships that never existed in any actual build.
A hypothetical application has two editions with different optional libraries. If their inventories are merged solely by product name, the resulting graph may imply that every installation contains both sets. That can inflate vulnerability findings and make a not-affected statement appear inconsistent when it actually applies to only one edition.
The merge process should preserve provenance at the statement level where practical. A component claim came from a particular document, generated by a particular tool at a particular stage for a particular artifact. Conflicting claims should remain visible until resolved rather than being overwritten by whichever file arrived last.
Deduplication also needs care. Two packages with similar names may be distinct. Two entries with different names may describe the same underlying component. A hash can help identify identical artifacts, while ecosystem identifiers and supplier metadata help establish lineage. The matching decision should remain inspectable, especially when it changes vulnerability results.
A layered inventory can be more honest than a single flattened list. It can retain the application, base image, installed environment, and runtime additions as related but distinct views. The analyst can then select the boundary relevant to the question instead of assuming that one combined graph is a complete description of every possible deployment.
Operational metrics should measure decisions improved
Counting SBOM files is easy. Counting components is also easy. Neither measure establishes that the organization can respond more accurately or quickly to a vulnerability. A large repository of stale inventories can create an impressive dashboard while leaving operators unable to identify the deployed artifact.
More useful measures connect the inventory to a task. How many deployed artifacts have an inventory with a known boundary? How often does a vulnerability match resolve to an owner? How many findings remain ambiguous because of missing version or relationship information? How long does an inventory correction take to reach the triage system?
A hypothetical exercise can compare the response to a synthetic advisory before and after improving inventory quality. The team measures time to identify candidate products, time to verify presence, and the number of unsupported dismissals or unnecessary investigations. The purpose is to see whether better data changes decisions, not merely whether a tool runs faster.
Coverage metrics need denominators. Reporting that ten thousand components were cataloged says little without knowing the number of relevant artifacts and their inventory status. Similarly, a high proportion of valid documents can coexist with poor runtime coverage if the missing documents belong to the most important services.
The metrics should also reward discovery of uncertainty. A team that replaces an unsupported complete claim with an accurate partial claim has improved the evidence even if a simplistic dashboard looks worse. Quality management should encourage that correction rather than pressure staff to maintain reassuring but unjustified labels.
A reproducible triage record makes later review possible
Vulnerability decisions are often revisited after software changes or new information appears. A reproducible record should make it possible to understand the earlier conclusion without reconstructing it from scattered chat messages.
For a hypothetical case, retain the artifact identifier, inventory version, relevant component entries, advisory version, matching logic, analysis method, supplier statement if used, deployment assumptions, decision, and responsible reviewer. The record can link to larger artifacts rather than copying everything into one ticket. What matters is that the links remain resolvable for the needed retention period.
This record should distinguish the evidence available at the time from later corrections. An earlier decision may have been reasonable under incomplete information yet require revision when new evidence arrives. Preserving the chronology supports learning without pretending that the team knew the future.
Automated systems need the same discipline. If a matching engine updates its rules, a finding can change even when neither the software nor advisory changes. Recording the engine version or rule set helps explain that difference. Otherwise, analysts may waste time searching for a nonexistent deployment event.
The objective is not endless paperwork. It is a compact explanation that another qualified person can follow. A decision that cannot be reconstructed is difficult to audit, difficult to improve, and easy to repeat incorrectly. The inventory earns its value when it helps create that explanation rather than serving as an isolated compliance artifact.
Runtime additions need a time boundary
Some software composition changes after deployment. An application may install an extension, download a model-support package, load a customer-provided module, or call a separately deployed service. A release inventory cannot automatically describe all of those later choices. The right response is to define additional observation points, not to pretend the release file has become useless or omniscient.
For a hypothetical extensible application, retain a release inventory for the base artifact and an installation record for enabled extensions. Record when each extension was added, its identity, and the scope of its access. A vulnerability query can then ask about a particular installation at a particular time. Without that time boundary, the same application name can refer to materially different component sets.
Runtime observation has its own limits. Seeing a module loaded confirms that event under the observed workload. Failing to see it does not prove that an optional path cannot load it later. The record should distinguish observed runtime activity from declared potential dependencies and from the installed files available to the process.
External services require a similarly careful boundary. A client application's inventory can describe the client library and its relationship to a service, but it may not contain the provider's internal component inventory. The operator should not infer that the provider has no vulnerable dependency simply because the local document does not list one. The question may require a separate supplier assessment and a different evidence channel.
Storage and access should preserve usefulness
Inventories can reveal product architecture, internal names, and supplier relationships. Their handling should reflect the organization's information-sharing needs without making them inaccessible during an urgent investigation. An SBOM that only one unavailable employee can retrieve offers little operational transparency.
A hypothetical organization can maintain an indexed repository keyed by artifact identity, with access appropriate to the document's sensitivity. The incident-response team needs a reliable retrieval path, while external sharing can use an approved subset or supplier channel. Access decisions should not silently remove fields from an internal copy without recording the resulting loss of completeness.
Retention should cover the software versions still in use and the decisions that depend on their inventories. Removing an old document because a new release exists can leave an unpatched installation without evidence. Conversely, keeping every duplicate forever can make selection confusing. Explicit supersession links and artifact associations help readers find the right version without erasing the historical record.
Unknown should be a first-class result
The most consequential design choice in an SBOM workflow may be whether it permits an honest unknown. Missing relationships, ambiguous identity, unexamined runtime additions, and incomplete reachability analysis are not exceptional edge cases. They are states that a real software investigation must be able to express.
A system with only affected and safe outcomes will force those states into one of two misleading categories. A system that preserves uncertainty can route the next investigation more effectively. It can say which artifact needs inspection, which supplier claim needs clarification, or which configuration assumption must be verified.
This does not mean every inventory must become exhaustive before it is useful. A partial inventory with clear boundaries can substantially narrow a response. The problem begins when a partial observation is presented as a complete account or when a structural validation result is mistaken for evidence of coverage.
The practical standard is an evidence trail: what was observed, by which method, at which software boundary, and how that observation supports the current decision. Component lists, dependency graphs, version matching, reachability analysis, and VEX statements each contribute different pieces. None should silently stand in for all the others.
An SBOM is most valuable when it helps an operator move from a broad alarm to a specific, reviewable conclusion. The file is not the conclusion itself. Its usefulness depends on the quality of the connections between software, evidence, and action—and on the willingness to leave a question open when those connections are not yet strong enough to answer it.