First, see this on Edicts. I would say you generally want an edict unless the data in the display expression changes more than once an hour. Otherwise you’re simply running the code unnecessarily often Plus as the article explains you can run edicts on demand.
If the data basically is unchanging once set - bar the odd correction - there is an even lower impact approach of using a stamp. In such a case the code only runs once on the selected note(s). After a correction, you’d simply re-apply the stamp.
That said, if you’ve only 30-40 notes in the document the differences between a rule and an edict may be indiscernible. But, if the document is large, or set to grow, then edicts generally trump rules in practical terms. Also the more complex the code being run, the greater likelihood an edict may be a better choice.
Confusion arises because edicts only arrived in v5 (IIRC) so much older documentation only mentions rules.
However, fear not. You won’t break anything. The main effect of lots of complex rules is the rules take longer to cycle through (as seen in the Agents & Rules Inspector). Even then, it’s not that hard to move $Rule code to $Edicts, especially if you’ve made use of prototypes. Don’t worry unduly about getting the ‘right’ solution first time around. As you use the app more you’ll find he sort of choices that suit your style of use by the things you’ve had to do-over in your earlier documents.
Last tip. If you’re the sort of user who basically has one (or a few) big files for their work, I suggest you experiment with things like action code in a separate throw-away test file. Then, once you’ve ironed out any mistakes you can port the code to your real work file(s) and throw away the test. It means you lessen the chance of fixing something you’ve just inserted all the way through your main file.