Turning "say it once, it remembers" into an actual rule engine
A few weeks ago Olga Kargopolova left a line in another thread that I have not stopped thinking about. Say it once. It remembers. That is the standard I am trying to build FounderFlow's override behavior against.
Here is the actual problem. Confidence grading tells a founder what tier an insight sits in, Verified, Very Likely, Needs Review, Monitor Only. But when someone overrides a call, right now that correction just sits there. It does not change how the next similar insight gets graded. That is the gap.
The version I am building now treats a single override as a signal, not yet a rule, and only promotes it to a standing rule once the same correction shows up a second time on a similar situation. One correction could be a one time exception. Two starts to look like a pattern.
I do not have this fully shipped yet, and I do not want to claim it works before it does. What I can say is this is the direction the next few founding member setups are being built around, so the system stops repeating the same mistake with the same person twice.
FounderFlow is your AI Executive Chief of Staff. It watches your business, identifies what matters, protects your revenue, and tells you exactly what to do next. We are onboarding the first 30 founding members personally right now.
For anyone else building override or feedback loops into an AI feature, did you land on a fixed number of repeats before something becomes a rule, or does it depend on the type of correction?
Xplania
Your AI-powered travel companion, from planning to memories ✈️
Comments (2)
glad that stuck with you, Stacy! To answer your question: for me it depends on the type of correction. Some overrides are clear preferences and those become a rule after just 1-2 repeats. Others are more contextual and need 3-4 before deciding it's a pattern and not a one-off. The tricky part is deciding which category a correction falls into. I'm still refining that. Excited to see how the founding member setups shape your approach!
That distinction is useful, Olga. Clear preference versus contextual correction is a good split, and it points at a real design decision. I am leaning toward starting every correction as contextual by default, since treating a preference as clear too early is the more expensive mistake if it turns out to be a one-off. Curious what pushed you toward needing 3 to 4 repeats for the contextual ones specifically, was that a number you picked deliberately or one that emerged from watching it go wrong?
Sign in to comment or upvote.