A control plane must refuse to EXECUTE against a type whose build provenance is not verified — refusing to load is the second line of defence #2820

Activity

1. rbuergi commented on Aug 30, 2026

   

   rbuergi

   on Aug 30, 2026

   ContributorAuthor

   More actions

   Re-measured on current main: the premise HOLDS, and the blocker is now a one-line reachability fact

   I have been re-running issues' own measurements before acting tonight, because several had drifted. This one has not. #2813/#2821 landed the provenance machinery since this issue was filed, so it would be reasonable to assume the ground had moved. It has not, and here is the exact reason — worth recording so nobody re-derives it.

   The three-way comparison exists and CAN produce AdoptedVerified

   NodeTypeCompilationHelpers (~1018–1050) implements it properly, with the two inconclusive branches carefully distinguished from the refusing one:

   if (def.AdoptedSourceFingerprint is not { Length: > 0 } adopted)
       return stamped with { BuildProvenance = AdoptedUnverified };   // legacy bundle — UNKNOWN
   if (def.CurrentSourceFingerprint is not { Length: > 0 } live)
       return stamped with { BuildProvenance = AdoptedUnverified };   // not yet computed — UNKNOWN
   if (string.Equals(adopted, live, StringComparison.Ordinal))
       return stamped with { BuildProvenance = AdoptedVerified };     // ← reachable in principle

   The AdoptedUnverified branches even cite #890's lesson explicitly — "a probe must not answer its scariest branch on its own inability to run" — which is the right instinct and the same one this issue's gate will need.

   But that branch is unreachable in production, and it is one line

   PrebuiltAssemblySeeder has two overloads. The 8-arg one takes sourceFingerprint and is the one that could make it reachable. Its only caller in the entire tree is the 7-arg overload everything actually uses:

   public static IObservable<bool> Seed(hub, nodeTypePath, assemblyBytes, pdbBytes, frameworkMvid,
                                        logger = null, dependencies = null)
       => Seed(hub, nodeTypePath, assemblyBytes, pdbBytes, frameworkMvid, logger, dependencies,
           sourceFingerprint: null);      // ← line 257, the only call site

   $ grep -rn "sourceFingerprint:" src/ test/
   src/MeshWeaver.Graph/Configuration/PrebuiltAssemblySeeder.cs:257:  sourceFingerprint: null);
   

   And nothing in MeshWeaver.PluginCatalog or MeshWeaver.Plugin.Packaging writes a source fingerprint into a bundle at all.

   So every adoption takes the line-1022 legacy branch, and AdoptedVerified is dead code today — exactly as this issue states. The machinery is built, tested and inert on the branch that matters, which is the same shape as TestTimeouts (built by #2708, zero adopters until today) and InstanceComboVerifier (#2274 — a verifier nothing calls).

   What that means for the gate this issue asks for

   The predicate cannot be "refuse to execute when provenance is not AdoptedVerified" until a producer writes the fingerprint, because today that refuses everything. That is not a reason to defer the design — it is the acceptance criterion for it:

   1. The bake writes a source fingerprint into the bundle and the seeder passes it through (delete the null at line 257 and thread it from the manifest). Until this exists, nothing downstream can distinguish verified from unverified.
   2. Only then can the control plane refuse to EXECUTE on a non-verified type — and it must handle AdoptedUnverified as its own outcome, never folded into either Verified or AdoptionRefused. The three-verdict discipline ComboVerification already documents, and the same NotVerifiable ≠ Green trap The combo gate exists and is never called — nothing verifies an image against the modules an instance actually runs #2274 is about.

   Suggest ordering this issue explicitly behind step 1, and stating that a gate shipped before it would either refuse every install or be silently disabled — which is how a safety mechanism becomes decoration. The null at line 257 is a good place to leave a pointer to this issue, so the next person to touch it knows what it gates.
2. github-actions

   closed this as completedin #2982on Sep 1, 2026
3. github-actions

   added a commit that references this issue on Sep 1, 2026

   Merge pull request #2982 from Systemorph/feat/execute-time-provenance…

   ...

   119f3ef