Exactly. That's essentially the idea.

The twist I’m exploring is to keep debug logs buffered during normal execution and only release the relevant context when an error occurs. So you get the diagnostic value of DEBUG without continuously storing all the noise.

I built a small Go library to experiment with this approach, but I’m particularly interested in where the model breaks down in real-world systems.

Im not quite sure but it appears the code has the logic that forces logging of a transaction, via trip methods.

I think this could be improved by moving this logic to properties files and using named loggers or named transactions to enable/disable.

Im amazed how after all these years logging and how it works is basically unchanged after 25 years.

Names, logger, different levels...

And thats all.