NCFCA Value Laundering — Found and Fixed

Compiled July 9, 2026. Originally documented as an open gap; now closed and verified. Status: FIXED, VERIFIED, REGRESSION-CHECKED.

PurposeDocuments a real vulnerability in Claim 1's isolation mechanism — a value can be correctly source-labeled and still be contaminated — found, fixed, and regression-verified.

StatusVerified

Built frominformation_flow_competitor.py (the strongest baseline that found the gap)

Superseded by—

EvidenceEvaluation Package — threat model updated to include this finding · ncfca_lib module status — the fix, as shipped

The original finding

Laundered value: 0.85 * 0.9 + 999.0 * 0.1 = 100.67 (a wildly contaminated D value)

NCFCA (source-check only): ALLOWED. D became 100.67.
Information-flow control (provenance-tracking): BLOCKED, correctly identified
  the C_channel_execution origin buried in the computation.

Why this is real, not a contrived edge case

NCFCA's update_D() checks the string passed as source — it has no way to verify that the value itself wasn't computed using data from a disallowed channel earlier in the calling function. A D-channel estimator with a real, honest bug — accidentally blending in a C-channel reading during its own internal computation — passes the current check completely, because the check only ever looks at the label on the final call, never at how the number was actually produced. This is a materially different and, arguably, more realistic failure mode than anything tested in the naive/token/static-typing comparisons: those all modeled a caller lying about its source. This models a caller being honest about its source while still producing a contaminated result.

Severity, stated plainly

This is a real gap in Claim 1 as originally implemented. The formal proof's non-collapsibility guarantee assumes writes are correctly attributed; it does not, on its own, guarantee that a correctly-attributed write's value is itself uncontaminated. That's a meaningful distinction between what's proven and what's implemented, and it's stated explicitly anywhere this claim is represented as complete.

What would actually fix it

Two real options, not equally costly:

Adopt taint-tracking as the production interface — require every value reaching update_D() to be a provenance-tracked object.
Sandbox D-channel estimators so they structurally cannot read C directly during their own computation.

Option 1 was implemented. TaintedValue is now required, not optional. Verified fixed with a real regression test reproducing the exact original attack and confirming it's now blocked, plus a full regression pass across every real caller.

What this means for the evaluation package

EVALUATION_PACKAGE.md's threat model has been updated to note this gap existed and was closed — the adversary model now explicitly includes value-laundering (honest source label, contaminated computation), not just source-spoofing.

Files

information_flow_competitor.py — the original finding, still real and reproducible.
immutable_ncfca_tensor.py — patched, TaintedValue now required for all channel writes.
All real callers updated: real_channel_nodes.py, fault_injection_harness_v2_grok.py, isolation_baseline_comparison.py, strong_alternative_comparison.py, run_all_replications.py, full_stack_integration_test.py.