Davis Geometric

Foundational engineering / Original manuscript & reading guide

SRCV: Comparing the approved build with what actually runs.

Research setting NASA Developed for NASA

The SBOM↔Runtime Concordance Vector paper studies the gap between a declared software inventory and observed runtime components in JWST science-platform environments. It combines similarity-based alignment with explicit identity, trust and policy checks.

The question

Does the software running on a science platform correspond to the build that was approved?

The inventory and the running system

A software bill of materials (SBOM) lists the components expected in a build. The running system may include a patched driver, a loaded kernel module, a container overlay or a library selected through loader precedence. Matching names alone does not explain whether a difference is approved, missing, unexpected or untrusted.

SRCV represents declared and observed components through multiple channels: vendor and product information, versions, signatures, hashes, paths and lineage. Runtime observations add context such as loader precedence, attestation and firmware trust. These are different kinds of evidence, not interchangeable measures of similarity.

Alignment and policy have different jobs

The paper describes a two-stage matcher. Sparse nearest-neighbor search and Sinkhorn soft assignment provide candidate relationships and coverage explanations. Priority-ordered hard matching then supplies discrete categories for policy decisions.

The decision score combines coverage with penalties for extra artifacts, unsigned or unknown components, and weak trust anchors, plus conditions for critical components. A resemblance score is not a cryptographic signature or an attestation. The paper’s policy layer keeps those distinctions consequential.

What the record supports

The deposited manuscript specifies an architecture, calibration procedure, performance budgets and an evaluation plan using injected changes and cross-environment comparisons. This page does not convert those budgets or the repository description’s stronger claims into independently verified deployment results.

The original title includes “Semantic Proof of Build Integrity.” It is retained in the citation. The research question here is narrower: how to make agreement and disagreement between a declared build and runtime observations measurable and inspectable under explicit policy assumptions.

Read the architecture · Explanatory summary of the manuscript, not new measurements
Stage Purpose Record or mechanism
Declared components What was approved Signed SBOM, component identities and provenance
Runtime observations What is present or loaded Modules, libraries, overlays, firmware and attestation
Concordance decision Explain a match or a deviation Coverage, hard matches, trust penalties and policy gates

Original publication

Davis, B. R. (2025). SBOM↔Runtime Concordance Vector (SRCV): Semantic Proof of Build Integrity for NASA JWST Science Platforms. Zenodo. 10.5281/zenodo.17211556

The 10-page PDF is unchanged from the Zenodo deposit; its checksum was verified on 8 October 2026. This reading guide separates the author’s research history from the manuscript’s methods and claims. No new experimental validation is reported here.