Propose a simple trigger prioritization algo for flex event

flexible_event_config.md

@@ -9,6 +9,7 @@ _Note: This document describes possible new functionality in the Attribution Rep
 - [Goals](#goals)
 - [Phase 2: Full Flexible Event-Level](#phase-2-full-flexible-event-level)
   - [API changes](#api-changes)
+  - [Trigger prioritization](#trigger-prioritization)
   - [Trigger-data modulus matching example](#trigger-data-modulus-matching-example)
 - [Configurations that are equivalent to the current version](#configurations-that-are-equivalent-to-the-current-version)
   - [Equivalent event sources](#equivalent-event-sources)
@@ -169,6 +170,15 @@ When the `event_report_window` for a spec completes, we will map its summary val
   "trigger_summary_bucket": [<bucket start>, <bucket end>]
 }
 ```
+### Trigger prioritization
+
+Given that triggering attribution can affect a source's state without producing a report, we will need a new algorithm for doing trigger prioritization. Here is a sketch of how it could work:
+
+1. For every source, maintain a list of triggers, sorted in order of priority (descending), then trigger time (ascending)
+2. At the end of any report window (across all of a source's specs, breaking ties arbitrarily):
+    1. Iterate through the source's triggers in order, "applying" them to generate a list of "speculative" reports. Stop when privacy limits are hit.
+    2. Flush all of the speculative reports that are scheduled to be emitted in the current window, and update the source's state based on all of the triggers that were successfully applied.
+    3. Erase all of the triggers associated with the current spec and window from the source's trigger list
 
 ### Trigger-data modulus matching example