[Protocol Versioning] Rules when to Accept or Reject an update Service Event

[AlexHentschel]

Overarching Product Goal

This issue is part of Epic #6999. The overall goal is to evolve Versioning of Execution Stack to use the Dynamic Protocol State, and subsequently employ this versioning information for

1. coordinating EN HCUs (see Flip 298 for more context on product relevance and impact)
2. the ANs to supports script execution across breaking HCU version boundaries (see OKR description for more context on product relevance and impact)

This issue is part of 1.

Detailed Task Description

The following is a list of areas that we identified as needing precise specifications. However, this list is likely not complete:

• [ ] Define criteria for rejecting service events - e.g. rejecting version downgrades unless explicitly forced via dedicated flag.
• [ ] Specify upper and lower bounds for execution weights and memory limits.
• [ ] Additional criteria (?)

Further Reading:

• section 📝 2025-03-04 Review of implementation proposal in notion doc Execution State Parameters in the Dynamic Protocol State

[github-actions[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[fxamacker]

I created a notion doc "New Service Events to Upgrade Execution Stack".

It proposes new services events for upgrading components and execution parameters. It also outlines validation rules and examples for the specified service vents.

Next step is for cadence, execution, and protocol teams to align on the document.

In the meantime, I am onboarding for issue #7135, etc. and working on a POC to replace the existing Stop Control component.