Something that you should already be aware of at this point is that the brains in Spark execute 30 times a second, starting from the beginning and going all the way through every frame. This is what provides your game loop, but because everything in Spark exists inside this game loop, the language itself is designed to make use of it. Because of this, there are actually several tiles that are designed to not have an impact immediately, but perhaps some time after they are first called. Let's take a look at how some of these tiles work.
First let's look at the [no longer] tile. This tile works by checking to see when a condition is no longer true, and when it is no longer true, executing its rules. However, the [no longer] tile can never trigger on the first frame it is run. "No longer" implies that the condition used to be true, but just switched to false. For that to happen, at least two frames are needed, first a frame where the condition is true, and second a frame where the condition is false. There can be any number of frames where the condition is true, but as soon as the condition becomes false, the rules will be executed.
Another tile that works over time is the [countdown timer] tile. The first time it is evaluated, it stores the current time and uses that as its starting time. Then, on each subsequent frame that the [countdown timer] tile is evaluated, it checks to see if enough time has passed since the start time, if so, the rule is executed.
For most of these tiles that happen over time, things work just fine when they are being evaluated, but something interesting happens when the rule isn't evaluated for even a single frame. When not evaluated, these tiles will often reset. Let's look at the [countdown timer] tile. If the tile is ever not evaluated when running through the brain it is in, the start time of the timer will be lost, and the next time the timer is evaluated, it will start over, measuring its start time as the first frame that it was evaluated once again.
This is a common pattern in brains, and that's why it is important to understand before going too much deeper, because it gives a different perspective of what the language is doing.
The tiles which are prone to resetting are, I believe, all in the Timing and Logic folder in the tile picker, and they all are used on the When side of the brain. Whenever a tile needs to store information for a later frame, it is prone to resetting, and the reset will likely make it lose whatever information it has stored.
In the case of the [no longer] tile, the state that it stores is that it got at least one frame where its condition was true. If reset, that information is lost and it will need another frame where its condition is true before it can trigger when its condition switches to false.
This is an important concept, so will be expanded upon in the Timing and Logic section.