From whiteboard to code: mapping Facts, Rules, and Premises to OTP processes

From whiteboard to code: mapping Facts, Rules, and Premises to OTP processes Part 2 of 12 — In Part 1 on dev.to — PON in Elixir: why the BEAM fits reactive rules · repo draft we motivated the Notification-Oriented Paradigm (PON) and showed the public Fato / Regra API. This post opens the engine room: how updates become messages, and how rules and premises attach to fact names using OTP building blocks—without yet using the metaprogrammed DSL (defrule / defpremissa), which is Part 3. The whiteboard model On the board you draw facts (ovals), rules (boxes that watch facts), and sometimes premises (derived facts). The arrow is always the same: when this fact changes, wake up everything that cares. On the BEAM, a practical mapping is (the OTP design space—processes under supervision exchanging messages—is laid out in Armstrong’s thesis and in Cesarini & Thompson’s Programming Erlang; here we use only a thin slice): Concept In tec0301_pon Fact A named GenServer (Tec0301Pon.PON.Fato) — pr