Why Kindling won't change your style while you're on vacation

If a product learns from a person, it should measure time in that person's work, not in the calendar. Kindling learns a writing habit from your edits, shows it to you as a quiet observation in two working sessions, and only then applies it, with a visible entry in your profile log. No sessions, no change.

Our first design didn't work this way. Here is what we changed and why.

The problem: how bold should learning be?

Kindling learns from your edits. The hard question is how often, and how boldly, to change your style profile. Get it wrong one way and the product never learns. Get it wrong the other way and it rewrites you because of one random edit.

So learning runs in two steps. First it decides what counts as a habit. Then it decides when a habit is allowed to change anything.

Step one: an edit becomes a habit

Kindling breaks down every edit to see what you actually changed. After every fifth post it looks back at the last five. If the same kind of edit shows up at least three times, we stop treating it as noise. It's a habit: you keep removing exclamation marks, say, or keep softening a hard conclusion.

At that point Kindling shows one calm observation: "We noticed that you… Apply this, or leave things as they are?"

every 5th final post:
  window = last 5 posts
  for each edit pattern in window:
    if count(pattern) >= 3:
      raise observation(pattern)
      # "Apply this, or leave things as they are?"

This is a sketch of the rule, not the production code. The numbers are the real ones: a window of five posts, a threshold of three repeats.

What we turned down: seven quiet days

The first version of the idea had a timeout. If you didn't answer an observation, it applied itself after 7 days.

That sounds reasonable until you picture a vacation. You leave for two weeks, come back, and your style has been changed without you. Our notes on this decision are four words long: "The calendar punishes vacations."

# rejected
if observation.age >= 7 days and no answer:
  apply(observation)

In our view the flaw isn't the number seven. Any calendar number has it. A calendar keeps running when the person stops, so a calendar timeout will always end up deciding things while nobody is there.

What we built: time counted in sessions

We stopped counting days and started counting active sessions. The observation is shown twice, each time when you've come in to work. If you haven't chosen either way after that, the change applies, and it stays visible in your profile log so you can see what changed and when.

on session start:
  for each pending observation:
    show(observation)
    observation.shown += 1

  if observation.shown >= 2 and no answer:
    apply(observation)
    profile_log.append(observation)   # never silent

# no sessions -> no shows -> no change

No sessions, no change. A vacation, an illness or a crunch at your day job can't break anything, because the clock only moves when you do.

The silence still has to end somewhere. Without a default, an unanswered observation would hang forever and the product would stop learning. Two sessions is a deadline you actually live through: you saw the question twice while you were in the product.

The same rule as the rest of Kindling

The vacation rule wasn't a one-off. Kindling has a set of rules a person can feel: there is no autopublishing, no numeric score anywhere in the interface, and one feedback button. When the daily budget for fresh material is spent, the product says so instead of quietly showing a shorter list.

The vacation rule belongs to the same family: changes are never silent. A change that applies while you're away is silent by definition, even if a notification is waiting for you afterwards.

Why the key learning rules now live in the database

In our experience, learning is the part of a product that breaks without a sound. We found two cases on the way. Two open browser tabs could count sessions at the same time and get in each other's way, so an observation could hang forever and never apply. In another case, a failure while reading the profile made the Accept button reject exactly what the person meant to accept. Neither bug wrote a line to the logs.

That's why the most important learning rules are now enforced by the database itself, not just by application code.

application code   -> decides what to propose
database           -> refuses states that must never exist

  e.g. a session counted twice for one visit
       an "accepted" observation stored as rejected

We think this is the general lesson for any product that adapts to its user. Code that runs on a happy path will look fine in testing. The guarantees a person relies on ("it won't change me behind my back", "Accept means accept") need a layer that says no even when the code is wrong.

What this means if you're building one

If your product changes itself based on user behavior, these are the three questions we'd ask, in our view:

• What is a habit, in numbers? Pick a window and a threshold you can state in one line. Ours: three repeats in five posts.
• Whose clock is it? If the countdown runs while the user is away, the user will come back to a decision they didn't make.
• Where does the guarantee live? If a broken read can flip "accept" into "reject", the rule needs to live below the code.

FAQ

Why not just ask every time and never apply anything automatically? Then an unanswered observation hangs forever and the profile stops learning. Two sessions gives you two real chances to say no, and after that the change is applied in the open, recorded in the profile log.

What counts as a habit? The same kind of edit at least three times across your last five posts. Kindling checks after every fifth post.

Can I see what Kindling changed? Yes. An applied observation stays visible in your profile log. Profile changes are never silent.

What happens if I don't open Kindling for a month? Nothing. Time is counted in your active sessions, so no sessions means no changes.

Why enforce the rules in the database and not just in code? Because both learning bugs we found failed silently, without a single log line. A rule in the database refuses a broken state even when the code that produced it is wrong.

Related case

The full Kindling case covers how the product turns your reaction into a post in your own voice, and why there is no score anywhere in it. Try it at kindling.il-ob.com. Cases and process at iloblique.com.

Sources: our notes on Kindling's learning loop (2026-10); the Kindling case page on iloblique.com.