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.
| 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.