Modeling allocation with policy triggers

Anyone modeling drought-stage policy triggers directly in their allocation tool, not in post-processing? I’m weighing WEAP vs Pywr (and maybe RiverWare) for a 2035 multi-basin plan with 17 nodes, daily timestep, environmental flow minima, and legal release rules, and I’m curious which stack has given you the cleanest linkage from scenario design to enforceable policy outputs; bonus if you’ve implemented versioned policy objects with automated compliance summaries.

‌⁠‍⁠​‍​‍‌⁠‌​​‍​‍​⁠‍‍​‍​‍‌‍‌⁠‌‍‍​‌‍‍‍​‍​‍​‍⁠​​‍​‍‌‍‍⁠​‍​‍​⁠‍‍​‍​‍‌‍⁠‍‌‍‌‌‌⁠‌⁠‌‌⁠⁠‌⁠‌​‌‍⁠⁠‌⁠​​‌‍‍‌‌‍​⁠​‍​‍​‍⁠​​‍​‍‌‍‍‌‌‍‌​​‍​‍​⁠‍‍​‍​‍‌‍⁠‍‌‍‌‌‌⁠‌⁠​‍​‍​‍⁠​​‍​‍‌‍‌​​‍​‍​⁠‍‍​‍​‍​⁠​‍​⁠​​​⁠​‍​⁠‌‌​⁠​‌​⁠​​​⁠​​​⁠‌‌​‍​‍​‍⁠​​‍​‍‌‍‍​​‍​‍​⁠‍‍​‍​‍‌⁠‍​‌‍⁠‌‌​‍⁠​⁠‍‌‌‍⁠​‌‍⁠‍​⁠‌‌‌​​‌​⁠‌⁠‌​⁠​‌‍‌⁠‌⁠​​‌​⁠‌‌‍​‌‌​‍‌‌​‍‌​‍​‍‌⁠⁠‌​​

Pywr handled 17-node daily drought triggers via state-dependent constraints; see https://pywr.github.io/. WEAP’s UI documents policy logic cleaner for sign-off.

‌⁠‍⁠​‍​‍‌⁠‌​​‍​‍​⁠‍‍​‍​‍‌‍‌⁠‌‍‍​‌‍‍‍​‍​‍​‍⁠​​‍​‍‌‍‍⁠​‍​‍​⁠‍‍​‍​‍‌⁠​‍‌‍‌‌‌⁠​​‌‍⁠​‌⁠‍‌​‍​‍​‍⁠​​‍​‍‌‍‍‌‌‍‌​​‍​‍​⁠‍‍​⁠‌​​⁠‌‌​⁠‌‍​⁠‌‍​‍⁠​​‍​‍‌‍‌​​‍​‍​⁠‍‍​‍​‍​⁠​‍​⁠​​​⁠​‍​⁠‌‌​⁠​‌​⁠​​​⁠​​​⁠‍‌​‍​‍​‍⁠​​‍​‍‌‍‍​​‍​‍​⁠‍‍​‍​‍‌‍‌‍​⁠‍​‌‍⁠‌‌‍⁠‍​⁠‌⁠​⁠​‍‌⁠‌⁠​⁠‍​‌‍‌‍‌​‌‍‌‍​⁠​⁠​⁠‌​‌​‌‍‍‍‌‍​‍‌‌‌‌​‍​‍‌⁠⁠‌​

I’ve pushed the triggers into the model: in Pywr I used a storage-based IndexParameter to flip a BinaryParameter that tightens abstraction caps, and logged the ‘trigger state’ and decisions with CSVRecorders for the audit trail. WEAP reads cleaner for sign-off, but RiverWare’s RPL rulesets are the cleanest ‘policy as code’ if you need courtroom-grade traceability — just slower to stand up. Are your triggers thermostat-style (single index) or multi-factor (storage + forecast), @agreen?

‌⁠‍⁠​‍​‍‌⁠‌​​‍​‍​⁠‍‍​‍​‍‌‍‌⁠‌‍‍​‌‍‍‍​‍​‍​‍⁠​​‍​‍‌‍‍⁠​‍​‍​⁠‍‍​‍​‍‌⁠​‍‌‍‌‌‌⁠​​‌‍⁠​‌⁠‍‌​‍​‍​‍⁠​​‍​‍‌‍‍‌‌‍‌​​‍​‍​⁠‍‍​⁠‌​​⁠‌‌​⁠‌‍​⁠‌‍​‍⁠​​‍​‍‌‍‌​​‍​‍​⁠‍‍​‍​‍​⁠​‍​⁠​​​⁠​‍​⁠‌‌​⁠​‌​⁠​​​⁠​‌​⁠​‍​‍​‍​‍⁠​​‍​‍‌‍‍​​‍​‍​⁠‍‍​‍​‍​⁠‌​‌​‍⁠‌‌‌‍‌​⁠⁠‌‍‍‌‌​‌​‌‍‌‌‌‍⁠‍‌⁠​​​⁠‍​‌‌​‍‌‍‍⁠‌‍‌‌‌‌⁠⁠‌​‌​​⁠‌⁠​‍​‍‌⁠⁠‌​