I'm working on a small Python project aimed at improving my understanding of how to properly structure program state and make it easier to debug behavior. I'm trying a few strategies:
- Ensuring all my decision logic is deterministic.
- Keeping this logic separate from output generation.
- Logging state changes over time for better tracing.
In my minimal demo, I start from a cold state and apply a single input. The system selects a strategy based on the weighted state values, and I log the transitions like pre-state → decision → post-state. There's no machine learning or randomness involved; it's meant to answer the question: "Why did the program choose this path?"
You can check out my demo and trace output in my GitHub repo.
What I'm hoping to learn is whether this structure is reasonable for state and decisions, are there more straightforward or idiomatic patterns for tracing state, potential breakdowns of this approach as programs grow, and any Python-specific tips to improve this pattern. I'm still in the learning phase!
2 Answers
It sounds like a great approach! I'd recommend focusing on separating state management from the decision-making logic. You might find using a state machine library beneficial. As for tracing, consider exploring decorators that can help with logging state changes more systematically.
I took a quick look at your README and didn't quite get it. It kind of felt like an LLM-generated fever dream! Was that your intention?
Haha, I understand how it could come off that way! It's not about sentiment analysis or keeping LLMs on track in dialogues. Instead, it runs on a deterministic internal state that guides strategy selection. It works independently of any LLM. If you have suggestions on clarifying the README, I’m all ears!

Thanks for the suggestion! I've actually separated state evolution from strategy selection, keeping them independent. I avoided FSM libraries because my state isn’t discrete but continuous, and I wanted to keep it flexible without rigid structures. I'm also steering away from decorators since I want to ensure the tracing is part of the runtime contract, not just standard logging.