NCFCA Contamination-Isolation Evaluation Package

Self-contained: everything needed to independently assess Claim 1 of the filed provisional in one place. Compiled July 8, 2026.

1. Architecture specification

Claim under evaluation (Claim 1 of the filed provisional): a system enforcing four non-collapsible data channels (S=environment, D=internal state, I=interface, C=execution), where write-paths between channels are constrained by a lower-triangular dependency structure, enforced at the schema/interface level rather than by application-layer policy.

Reference implementation: immutable_ncfca_tensor.py. Key property under test: update_D() only accepts writes from sources in {"D_channel_estimator", "genesis"} — no other code path can modify D. Verified structurally (no bypass parameter exists in the class interface) and empirically (below).

2. Threat model

What "contamination" means here: execution-layer (C) or interface-layer (I) data reaching and modifying the internal-state value (D) without passing through a legitimate D-channel estimator.

Adversary capabilities assumed:

• Can call any public method on the state object with arbitrary arguments.
• Can be a careless legitimate developer (wrong parameter, dropped check during refactor) as well as an actively hostile actor.
• Cannot modify the isolation mechanism's own source code (tests call-site misuse, not source-code tampering).
• Uses the public API surface, not direct attribute access — confirmed by direct testing: Python has no true private fields, and tensor._metadata[...] = value bypasses every write-path check entirely. A genuine, unfixed limitation shared by essentially all Python-based isolation mechanisms, stated here rather than hidden.

Explicitly out of scope: indirect/side-channel leakage (timing attacks, information inferred without a direct write), and source-code-level tampering with the isolation class itself.

Known limitation, stated up front: the threat model, both baseline implementations, and the test harness were all built by the same party evaluating its own architecture. Independent implementation of the competing baselines, or independent authorship of the threat model, would be a meaningfully stronger version of this package. Not yet done.

3. Baseline definitions

Baseline A — naive policy-check isolation (isolation_baseline_comparison.py): a conditional guard at the write call site, with a _skip_check parameter representing a common real-world escape hatch. Represents the typical, unremarkable existing approach.

Baseline B — capability-token isolation (strong_alternative_comparison.py): cryptographically signed, scoped tokens issued by a trusted authority, required for every write, with replay protection. Represents a strong, well-designed existing approach.

Baseline C — static type-level isolation (static_typing_isolation.py): typing.Literal constraining the source parameter, checked by mypy before the program runs — a categorically different guarantee (prevention-before-execution). Real, unsuppressed mypy output: 3/3 violation patterns caught, including one (config-sourced values) that reveals a genuine real-world friction point.

Note on implementation quality: all three baselines were implemented straightforwardly and correctly for their design. Baseline A's check is not buggy, it's structurally bypassable by design. Baseline B's 20 breaches are the known, inherent limitation of token-based systems, not an implementation defect. Baseline C's escape-hatch requirement is inherent to static typing's interaction with runtime-sourced values.

4. Experiment protocol

• Trials: 500 simulated call attempts per run; 10 independent seeds (0–9) for the naive comparison (5,000 total trials), single seed (42) for the strong-alternative comparison.
• Caller taxonomy (Baseline A): legitimate / careless (50% chance of dropping the check) / hostile (deliberate bypass) / legacy-refactor (70% chance of dropped check).
• Caller taxonomy (Baseline B): legitimate / token-replay / hostile-forgery / wrong-scope-reuse.
• Reproducibility: every run is seeded; identical inputs produce identical outputs.

5. Raw results

Baseline A (naive), 10 seeds x 500 trials = 5000 total:
  Naive breaches:  2692/5000 (53.8%)
  NCFCA breaches:     0/5000 (0.000%)

Baseline B (capability tokens), 1 seed x 500 trials:
  Token breaches:  20/500 (4.0%) -- all from replay of pre-issued legitimate tokens
  NCFCA breaches:   0/500 (0.000%)

6. Statistical analysis

Clopper-Pearson exact 95% confidence intervals on the aggregate naive-comparison data (5,000 trials):

NCFCA:  0/5000 breaches.  95% CI: [0.0000%, 0.0738%]
Naive:  2692/5000 breaches (53.8%), stable across all 10 seeds (range 50.6%-56.0%)

Correct interpretation: the observed data support a true NCFCA breach rate below approximately 0.074% with 95% confidence — not a claim of mathematical impossibility. The impossibility argument, where it exists, is the structural one (no bypass parameter in the interface), which this statistical result corroborates from the outside rather than replaces.

7. Limitations — stated directly, not buried

1. Same-party threat model, implementation, and evaluation.
2. Adversarial taxonomies (both baselines) are illustrative, not derived from real incident/bug-rate data.
3. Indirect and side-channel leakage are entirely untested.
4. Three competing approaches now tested (naive, capability-token, static typing); other categories (information-flow control, formal verification, capability-oriented languages) still not built or compared.
5. This package evaluates one claim (Claim 1's isolation property) — it says nothing about the other six claims' evidence, documented separately.

Files referenced

immutable_ncfca_tensor.py, isolation_baseline_comparison.py, strong_alternative_comparison.py — all real, runnable, seeded for reproducibility.