Curb · Conclusion
Three case studies sit above this page: the agent, the engine that gives it rules, and the agents that check them. This is the short page at the end. Where the project stands today, what building all three taught me about designing agents, and what the next month holds.
Where the project is
Curb runs on my phone and in the simulator. It is not on the App Store. This block is the one I keep current.
What I learned
Each of these was learned on one part of the project and then turned out to hold on the others. The page named after each is where the evidence lives.
A percentage helps nobody at a curb. What changes is what the agent does: speak plainly, hedge and ask, or stay quiet and say why. Learned on Curb, then built into the engine as a basis every rule carries.
Not acting is an agent's most common action, and it can mean three different things. On Curb the app has to say which one. In the engine, a block with no tickets is not a block with no rule.
The walkers' rulebook, the shard rule, the sanctioned ways to look at a street, the refusal to call a curb unpainted without seeing bare concrete. All written before the pressure to skip them arrived, which is the only time a rule like that can be written.
Every inference the engine makes is checked against a source that had nothing to do with it. Every claim a walker makes can be overturned by another walker or by a person at the pole. The check that cannot be gamed is the one worth having.
Curb's detection approach changed twice in the field. The walkers' manual grew from twelve of my corrections into a document the agents extend themselves. A spec that cannot be overturned by a drive around the block is a wish.
When the engine knows the day but not the hours, the sentence has to say so. When a walker cannot read a sign, the row stays open. Overstating the weak half of an answer is the expensive failure, and every part of this project exists to prevent it.
Underneath those are the working habits that caught my own mistakes along the way: say what would prove it wrong before you look, ask who needs the data to be right, measure the number that got hand-waved, suspect your own code before the world, go and look at the actual thing, write down what a summary will get wrong, decide what you will not do before you are in a hurry, and say what you cut and why. Each one has a story on the method page.
What's next
These are the open items from the project's own to-do list, in the order I would take them, not a wish list.
Parks the plug never sees are counted silently today. Log them first, then design the walk-away resolver, then the geometry score. Order matters, because a fix designed without the count would be a guess.
A rule can be sure about the day and honest about the hours. One number for both overstates the weaker half. The stated meter limit already escapes the score; generalise that to every rule.
Unbuilt, and the most likely reason someone would delete the app. The timing question is a design question: when does a reminder stop being help and become noise.
The walkers caught each other whenever they happened to overlap. Make that a suite run on purpose: the same block, two walkers, compared automatically. The gap named on The Agentic Walkers page.
The "check the sign" timer is designed and decided. Build it, so that a two-hour block warns before the two hours are up instead of staying silent.
One driver, one car, one summer. The next test is other people's cars, other neighborhoods, and the failures I cannot produce myself.
If you want more
The build log is the whole month of Curb in the order it happened, from the running log I kept the entire time. How I check is the eight habits above, with the moment each one caught something. Neither is required reading. Both are there for anyone who wants to see the work before it was tidy.
The Curb series