1. Facts are cheaper than instructions.
2. Beware the prompt tar-pit where everything is possible and nothing explainable; prefer triggers you can trace.
3. Context should trigger behavior, not describe it.
4. Every EMU fires for two reasons: the rule you wrote and the context you forgot - trace both.
5. The art is in what you leave out.
6. Predicates delay action; atoms induce reachability. Moral: normalize at the edges, bind in the rules.
7. If you can't test it in isolation, you can't trust it in production.
8. Better 100 EMUs over one stable atom schema than 10 schemas with bespoke logic.
9. Prompts are not programs; they're data.
10. Simple triggers follow messy telemetry - normalize first, simplify after.
11. Rollback should be one command and zero meetings.
12. An atom should answer one question completely.
13. Fools prompt around complexity; pragmatists tolerate it; experts extract atoms; masters delete it.
14. Move uncertainty to the edges; keep the core deterministic.
15. Creating a trigger is easy; controlling when it repeats is the trick - use cooldowns, scopes, and idempotency.
16. Behaviors should be discoverable by reading predicates, not divining prompts.
17. One team's "constant" is another team's "context"; declare scope and binding or it drifts.
18. Ship shadow, then canary, then active - no exceptions.
19. If your trigger has ten clauses, you probably missed an atom (or an intent).
20. Separate what you observe from what you do.
21. Text hides facts and duplicates work - extract atoms at the edges.
22. Default to idempotency.
23. Symmetry in namespaces and role binding reduces complexity - seek subject/object parity everywhere.
24. If behavior depends on order, you built a race, not a system.
25. To understand a decision, be both the context and the policy - read the evaluation trace.
26. Every atom changes the surface area of risk; add them deliberately.
27. It's easier to ship a clever prompt than understand a correct trigger - choose explainable predicates.
28. Context that cannot be versioned cannot evolve.
29. Rules live above models; models advise, rules decide.
30. In decision systems, early ingestion makes the trigger - build the atom, then the rule.
31. Policy is how; trigger is when; action is what - never mix them.
32. Measure context engineers by reachability, binding, and idempotency - not cleverness.
33. Name things once; normalize everywhere else.
34. Every EMU lives inside a policy stack and rarely fits at first - design for composition and exclusions.
35. Magic in prompts becomes tech debt in systems.
36. Deterministic predicates embrace the excluded middle: TRUE or FALSE; keep "maybe" in ML tags, not the DSL.
37. A system that cannot explain why it acted cannot be trusted.
38. Premature "auto" hinders evolution - ship shadow -> canary -> active.
39. Prefer idempotency to apologies.
40. If a system ingests many atoms, it acts through a few stable intents - name and standardize them.
41. Complexity you can't point at is complexity you can't fix.
42. Design policies top-down, but discover them bottom-up from atoms, traces, and reachability.
43. Time-stamp everything; untimed facts are rumors.
44. There are two ways to avoid misfires - wish and pray - and only the third works: cooldown + idempotency.
45. One engine, many policies; one policy, many actions.
46. It's easier to twist atoms to fit a rule than the rule to fit truth - resist that urge.
47. Test the rule, not just the route: unit-test triggers with synthetic atoms.
48. A DSL that doesn't change how you model context isn't worth using.
49. Normalize at the edges; compose at the center.
50. Unreachable triggers are dead code; fix the pipeline or delete them.
51. Context is arbitrarily perfectible and arbitrarily mutable - version everything.
52. The best action is the one that wasn't needed.
53. If you can't name it, you can't debug it.
54. Binding turns coincidence into causality.
55. Design for the atoms you can guarantee, not the context you can imagine.
56. When everything triggers, nothing is controlled.
57. An atom that hides its units will betray you.
58. One action, one intent.
59. Scope before feature; binding before correlation.
60. Debugging starts with knowing what the system observed.
61. Constraints are the design.
62. Cooldowns are memory; use them to be polite to humans and systems.
63. Make the right thing the easiest thing.
64. Determinism in rules; stochasticity only in judgments.
65. If it isn't traceable, it isn't trustworthy.
66. Prefer derived facts to duplicated truth.
67. Version context like code; migrations are part of the release.
68. A trigger that cannot be reached is a bug, not a mystery.
69. Context engineering is constraint engineering.
70. Modularity in context, predictability in behavior.
71. Every implicit default is a future incident.
72. Leave room for the next simplest thing.
Inspired by Alan J. Perlis's original "Epigrams in Programming" (1982)
Original available at: https://www.cs.yale.edu/homes/perlis-alan/quotes.html
Memrail - A context engineering framework