Az egész mélyén egy ilyen modell fizikai megvalósítása szerepel. Digitből, ha visszaemlékszel a szinkron sorrendi hálózatokra, világos, hogy egy órajel ütésben legfeljebb csak egy szomszédos állapotba tud lépni a rendszer, nem tud átugrani a következőbe (mint amit az always kérne). Emiatt viszont az always (after 0s) viselkedését csak úgy tudják megvalósítani, hogy annak a végrehajtását a következő órajelütésre hagyják.
A problémát tovább boncolandó, vedd elő a szgarch-on tanultakat, miszerint a processzor felváltva hajtja végre az egyes taszkok (szálak) utasításait. Tehát előfordulhat, hogy a A állapotból, belép B állapotba a rendszer, majd nem hajtja végre a C állapotba lépést, ahová egy always-os él mutat B-ből, mert a processzor elveszi tőle a futást, és más feladatot futtat. Így még ha kevés ideig is, de az állapotgép egy olyan állapotban van, amiben nem szabadna lennie (mert always miatt azonnal ki kéne lépnie).
Na már most, vegyük egy atomerőműnek az irányítórendszerét, ami a különböző szenzorok adatai alapján szabályozza a rudakat. Mivel B állapotban úgysem lesz a rendszer, így nem foglalkozunk azzal, hogy ott megfelelően beállítsuk a modell kimenetét. A tesztelésnél semmilyen probléma nem fog előjönni, mert ahhoz, hogy pont abban a pillanatban vegye el a futás jogát a CPU, csillagászati az esély. Mégis, egyszer be fog következni, az atomerőmű, amíg B állapotban van, nem lesz szabályozva így Csernobil 2.0.
Ez, hogy miért vannak tiltva azok az elemek, amiket tiltunk. Az after 1s esetén ez a hiba nem fordulhat elő. Nem lesz a rendszer egy olyan állapotban, amiben nem kéne lennie logikailag, mert azonnal ki kéne belőle lépnie (amit nem tud megtenni).
