Skip to content

G2.6: allow guarded dynamic runtime from InformationReportProven evidence - #100

Merged
masarray merged 2 commits into
mainfrom
g2.6-guarded-runtime-dynamic
Aug 26, 2026
Merged

G2.6: allow guarded dynamic runtime from InformationReportProven evidence#100
masarray merged 2 commits into
mainfrom
g2.6-guarded-runtime-dynamic

Conversation

@masarray

Copy link
Copy Markdown
Owner

Goal

Restore Smart Dynamic RCB runtime without conflating runtime authorization with ProductionEligible certification.

Design

Adds MmsGuardedDynamicReportRuntimePlanner and MmsDynamicReportGuardedRuntimePlanningContext.

A guarded dynamic segment is allowed only when:

  • current association satisfies the ARIEC dynamic-report capability gate;
  • persisted profile identity/fingerprint matches the live IED;
  • profile is InformationReportProven or stronger;
  • stored activation and InformationReport proofs are successful;
  • the proven report kind is DataChange;
  • RCB/DataSet/member identities remain internally consistent;
  • the emitted dynamic plan uses the exact proven RCB and only an ordered subset of proven InformationReport members;
  • at most one dynamic report group is emitted.

Static reporting remains eligible and polling remains the fallback for anything outside the exact proven envelope or whenever a guarded gate fails.

Important boundary

This does not call MarkProductionEligible, does not synthesize production acceptance, and leaves the existing MmsCapabilityAwareHybridReportAcquisitionPlanner ProductionEligible policy unchanged. Guarded runtime and ProductionEligible certification are separate concepts.

Regression coverage

Adds tests for:

  • InformationReportProven exact dynamic authorization;
  • unproven member fallback to polling;
  • identity mismatch fail-closed behavior;
  • no alternate RCB substitution;
  • non-data-change proof quarantine.

@masarray
masarray merged commit c899b05 into main Aug 26, 2026
1 check passed

@chatgpt-codex-connector chatgpt-codex-connector Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 29a14645f8

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

  • Open a pull request for review
  • Mark a draft as ready
  • Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

Comment on lines +140 to +143
if (!capability.MayAttemptDynamicReports)
{
return GuardedDynamicAuthorization.Denied(
"The current MMS association does not satisfy the dynamic-report capability gate.");

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P2 Badge Recheck request size against the current association

When the current association negotiates a smaller MaxMmsPduSize than the profile's AcceptedEnvelope.ProvenDefineRequestByteCount, MayAttemptDynamicReports can still be true because the capability evaluator gates only on service availability and free RCB evidence. This therefore authorizes a full-envelope plan that RunGuardedDynamicReportSessionAsync sends without any size preflight, so a previously proven profile can now emit a known-oversized DefineNamedVariableList request and potentially fault the association; compare the planned encoded request size with the current negotiated maximum and withhold or reduce the segment when it does not fit.

AGENTS.md reference: AGENTS.md:L15-L16

Useful? React with 👍 / 👎.

Comment on lines +298 to +301
if (!IsOrderedMemberSubset(plannedMembers, authorization.MemberReferences))
{
reason = "Dynamic segment member order/content is not an ordered subset of the proven InformationReport member set.";
return false;

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P2 Badge Build dynamic points in the proven member order

When a valid profile's proven DataSet order differs from lexical signal-key order, the generic hybrid planner sorts resolved points by SignalKey before building the dynamic plan. This check then rejects that permutation as not being an ordered subset and silently rebuilds the entire request as static/polling, so guarded runtime works only for profiles whose device-defined member order happens to match the catalog sort order; order qualified dynamic points by their index in authorization.MemberReferences before planning.

AGENTS.md reference: AGENTS.md:L144-L144

Useful? React with 👍 / 👎.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant