If you treat Rails as a pure MVC framework, then the context makes sense. Notification isn’t an object, its a model of a table.
Suppress isn’t a great word, but freeze and lock are already taken, calcify or petrify could have been better (maybe?) But the idea is…
In a context where I don’t know nor should know what gets saved to what tables, but I do know I don’t want data saved to this table, this idea works. Its especially cleaner if its used for a one-off exception to a very clean standard workflow.
Again Rails is an MVC framework, it should encourage Model->Controller->View design, that’s what its schtick is.
And do remember There Is More Than One Way To Do It :)