docs: record Track C privacy propagation investigation

[coreytshaffer]

Summary

Read-only investigation record for Track C of CR-DD-016's Sequencing section, the last of that CR's three tracks. One new file, 282 lines, documentation only.

No CR identifier is minted, no implementation is proposed, and no triage_core/ source, schema, test, or fixture is changed by this PR. Every CR identifier in the document is a citation of an existing one (CR-DD-012B, -013, -016, -018).

The headline revises Track C's original suspicion

CR-DD-016 asked whether privacy_level="local_ok" is "intentional normalization, legacy dead code, or a genuine propagation defect."

It is none of those three in the sense the question implied. local_ok is a constructor default that both callers override wherever the value is load-bearing, and the --privacy declaration is enforced end to end via external_model_allowed -> make_external_safe_packet -> is_local_only. No privacy-attributable routing defect was demonstrated. The record leads with this, before any finding, so the original suspicion cannot be carried away intact.

Findings

1. Evidence collapse. The operator's declaration is not recoverable from persisted route evidence — three declarations collapse onto task_privacy_level='local_only', two onto 'local_ok'. Structurally the same defect Track B found in the classifier lane.
2. Vocabulary mismatch. local_ok belongs to no declared privacy vocabulary. --privacy and GovernedRunSnapshot.declared_privacy both accept exactly {local_only, external_safe, public}; local_ok is a fourth term no operator can type.
3. Enforcement concentration. client.py never reads allow_cloud — cloud exclusion on the execution path rests entirely on one derived boolean. Recorded as shape, not a demonstrated defect.
4. Library default. Direct run_task with default PrivacyMetadata() is external-model-eligible with no declaration made. Recorded as behavior, not a defect claim — it may be intentional API policy, and CR-DD-013 set a precedent for treating absent evidence differently from negative evidence.

Negative finding. The apparent plan/execution route divergence is capability-attributable, not privacy-attributable.

Historical evidence. All six route_decision events carrying task_privacy_level record local_only; none records local_ok. The finding-1 ambiguity is latent in the recorded corpus, not yet realized.

Two things the record deliberately does not resolve

• Finding 1 preserves an open question rather than assuming a gap. GovernedRunSnapshot.declared_privacy does carry all three values faithfully, so the declaration exists in the system. Whether it is reliably joined to the corresponding route_decision event was not traced, and the record says so. That determines whether finding 1 is a recording gap or an undocumented join, and it is named as the first thing any follow-up must settle.
• Candidates A and B are marked, not decided. Whether these findings warrant one CR, two CRs, or none is explicitly left open. Candidate B may correctly conclude in no change.

The negative finding preserves two probes that pointed the wrong way

This is recorded at length because the intermediate results were misleading. Isolating privacy_level and asking the router directly produced dramatic divergences — external_safe selecting cloud_primary where local_only selected human_handoff. Both probes forced cloud availability on both sides, which does not model the plan path's own internet_ok. A field-level sensitivity analysis is not a reachability claim, and it was being read as one.

The control that settles it: with local routes unavailable, --privacy local_only diverges too — with identical privacy_level on both sides. A divergence that persists when the variable under test is held constant is not caused by that variable. The cause is capability (run_plan.py:378-380 passes capability=None unconditionally, by CR-DD-012B design). Without that control row, the earlier tables read as a serious enforcement gap.

Test plan

• All 21 file:line citations verified to resolve to the attributed text at c0545a7.
• Envelope derived by executing the real privacy_metadata_for_run, verify_packet, make_external_safe_packet, _build_resilience_route_input, choose_resilience_route, and build_route_decision_payload — no logic re-implemented.
• Probe module provenance asserted at runtime (triage_core.__file__ pinned to the working checkout).
• Negative finding confirmed by control, not by absence of a positive result.
• git diff --check clean (exit 0, both bare and with -N intent-to-add).
• Exactly one changed path; git status clean after commit.
• Verified the file is absent on main — clean add, no conflict.

No test-suite run: documentation only, no code changed. No live model calls were made during this investigation.

What this does not grant

Merge authority for this PR. Any implementation change. Any reopening of CR-DD-016 or Track B. Any decision on the Candidate A/B split.

🤖 Generated with Claude Code

[netlify]

✅ Deploy Preview for poetic-quokka-0fd859 ready!

Name	Link
🔨 Latest commit	44ee9bd
🔍 Latest deploy log	https://app.netlify.com/projects/poetic-quokka-0fd859/deploys/6a939b8c2ce14400085adb87
😎 Deploy Preview	https://deploy-preview-182--poetic-quokka-0fd859.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.
🤖 Make changes	Run an agent on this branch

---

To edit notification comments on pull requests, go to your Netlify project configuration.