P7.4 #446: causal dual-ingress BRCB/URCB traffic qualification

[masarray]

Stacked P7.4 on verified-green P7.3 PR #471 (exact base 389a6353756cb30f5f6550e4649a00391dc89242). Coordination issue #446.

Why

P7.3 verifies source-neutral Static DataSet planning semantics and reports MATCH, but a semantic fingerprint cannot prove physical data-plane traffic. A single report stream can also hide a silent BRCB or URCB. This milestone records actual routed schema-safe process values per exact configured static RCB independently on Discovery and Open SCL.

Contract

• Semantic MATCH remains configuration equality only, never conflated with physical reporting.
• Each ingestion run gets a new runtime-only PlanningAttemptId, excluded from the fingerprint.
• Engine-authoritative static plans yield exact diagnostic targets (DataSet + RCB + family + bindings).
• Once a real, successfully projected and accepted report value is applied, the runtime credits its own exact target to the current association attempt; raw/unrouted/unsafe values, RptEna/GI readback, old attempts and sibling RCBs do not count.
• BOTH BRCB and URCB are required when both are planned; an indexed sibling change is allowed between ingress paths but not credited interchangeably within a single attempt.
• The previous completed ingress retains timestamped proof as historical run evidence; a fresh attempt on that ingress resets that ingress proof.
• Diagnostics and emergency copy now show per-ingress ROUTED/PENDING targets, first routed timestamp and a separate dual-ingress qualification summary.
• No MMS request, RCB activation/writes, DataSet mutation, process polling or engine change in the proof path.

Tests

• semantic MATCH alone does not qualify traffic;
• BRCB-only cannot satisfy BRCB+URCB;
• Discovery and Open-SCL must independently route all required targets;
• stale association ID, alternate RCB and duplicate report cannot borrow proof;
• reconnect resets the replaced ingress attempt while preserving the other ingress history;
• static process value acceptance precedes traffic credit.

Keep this PR draft and stacked. CI = CodeVerified only. Physical retest on the same 7SX85 is still required before any production/main promotion, with Copy Diagnostic and ideally PCAP validating both paths.

[masarray]

P7.4 field acceptance checklist for the exact 7SX85 candidate (no production/mainline merge before physical validation):

1. Start Discovery IP for GR_X_7SX85, choose Static DataSet; capture Copy Diagnostic after InformationReport traffic arrives. Check that each exact planned BRCB and URCB target is ROUTED, not merely RptEna/GI requested. Record the exact fingerprint, source run, RCB slots, initial routed timestamp, and zero cyclic MMS process polling.
2. Open the same SCD on the same logical IED card (do not create a duplicate device). Choose Static DataSet and connect with a fresh association. The semantic status may be MATCH even if a different available indexed BRCB slot is selected. The Open-SCL traffic should be PENDING until this new association routes its own BRCB and URCB process values.
3. After routed traffic on both paths, expect DUAL INGRESS TRAFFIC PROVEN and Static parity: MATCH. If only BRCB or URCB is live, the exact missing RCB remains PENDING; do not substitute polling or infer success from RptEna=true alone.
4. Reconnect while monitoring. A new plan invalidates the replaced ingress's old attempt token, and its RCB targets must be re-proven. A completed other-ingress historical run may remain visible as timestamped evidence.
5. Save the complete Copy Diagnostic and, if possible, a PCAP. Inspect endpoint identity, association ownership/ResvTms fallback only if exercised, actual InformationReport, selected static coverage, zero cyclic process polling, and BRCB/URCB family liveness.

Code CI is not physical IED qualification; this PR remains draft/staged, stacked on #471. P7.3 Windows portable artifact from exact-green Build #3549 remains the safe reference candidate until P7.4 packaging and all exact-head gates are green.

[masarray]

Field-observed P7.3 behavior (operator Copy Diagnostic 2026-10-08, sanitized summary): a different connected IED with trusted CID/SCL reached healthy MMS association in one attempt, 32/32 domains, 709/709 initial read targets successful, 2 Static DataSet RCB plans covering 58/58 selected points (URCB 22 / BRCB 36), zero cyclic process polling. First actual InformationReport was detected after ~507 ms while only 35 of 58 selected points were report-backed at that instant; later structured-report expansions continued. The diagnostic alone does NOT prove all 58 final values arrived, nor identify which UI 'Unknown' cells were value versus quality. It also recorded four GGIO FC-root schema count mismatch projection warnings; these remain evidence, not silently waived.

Follow-up on P7.4 draft head df3f8ebbaf46e823bf46083cce0efeefb227d786: added read-only initial image inspection to Copy Diagnostic (visible values / pending values / quality not supplied / questionable quality; per exact DataSet and concrete RCB; first 12 pending refs with status and reason). No new MMS reads, GI/RCB operations, polling fallback, model mutation or changing any process value. Unit regressions cover partial image, later value/quality convergence and exact RCB grouping. Candidate CI running; physical 7SX85 retest still outstanding.

For field validation capture Copy Diagnostic shortly after starting monitor, then again after the delayed points settle. Contrast the per-RCB image counts and pending references against per-RCB routed traffic qualification. Report planning coverage is not actual first-image completeness.

[masarray]

FIELD FINDING — three incremental Copy Diagnostics of the same MMS association on AA1E1F06R4 (operator test 2026-10-08, app d4351fa5, engine 9c529257, SCL-assisted/static report-only).

Snapshot timestamps local +07: 15:36:38.664, 15:36:54.005, 15:37:11.521 (not three reconnects). All keep Connected=True, Monitoring=True, 32/32 domain match, 709/709 successful guided reads, exact static selected 58/58, 2 active RCBs (Analog URCB 22 @ Unbuffer01; Digital BRCB 36 @ Buffer01), no cyclic MMS process-value polling, 4 GGIO2 FC-root projection count mismatches.

New critical finding: at 15:36:34.121, 101 ms after Buffer01 BRCB monitor activated, the device supplied BufOvfl=true, logged as BRCB buffer overflow reported by Buffer01. Buffered event continuity may be incomplete. This is a real report-frame metadata warning as handled by Iec61850MonitorRuntime.ProcessReportHealth; cannot be waved away as benign semantic expansion. It does not establish which endpoint caused overflow or whether current values are wrong; must preserve continuity qualifier and obtain actual frame/entry/sequence evidence. Avoid automatically changing RCB/GI configuration to suppress warning.

Initial InformationReport proof at 15:36:34.170: 339 ms after gate started, with just 25 report-backed runtime points at that moment. Thereafter the diagnostic shows first-time REPORT_SEMANTIC_STRUCT notices for GGIO6/QZ1earth/QZ2earth at ~15:36:39, GGIO2/CBHealthy/TCS at ~15:36:41–42, and GGIO6/QZ2cnctd/QZ2isltd at 15:37:05.558, >31 s after RCB activation. Such warnings signal schema-based expansion occurrence, not necessarily 1:1 UI value completion. No snapshot contains per-point HasValue counts, so no defensible claim that 58/58 actually materialized.

Action: In the P7.4 next physical trial, distinguish (a) semantic planning equality, (b) exact RCB routed value proof, (c) initial-image live-value convergence, and (d) BRCB stream continuity. A DUAL INGRESS TRAFFIC PROVEN label must not be interpreted as proof of gap-free buffered SOE if BufOvfl was ever observed. Record BufOvfl/EntryID/sqNum/ConfRev per affected RCB and compare to IEDScout/PCAP for the exact same association. Do not clear or rewrite IED buffers during diagnostic intake. No code change to engine/RCB activation justified from these 3 snapshots alone.