RuleCaddie

The situation this app exists for is a disagreement. Two players standing over a ball in an awkward place, each half-remembering a rule, neither willing to concede to the other's memory. Nobody in that standoff is persuaded by a confident paragraph from a chatbot. They're persuaded by a rule number they can look up, because it's the only thing in the exchange that isn't somebody's opinion.

Which makes a plausible-sounding answer worse than no answer at all. Ask a language model about golf rules and it will produce fluent, well-organized, mostly-correct procedure — and every so often attach a rule number that doesn't exist, or cite a real rule that says something else. That failure looks exactly like a success. There's no tell in the formatting, no hedge in the tone, and the player reading it has no way to separate the two in the ninety seconds they're willing to spend on it.

So the product constraint came before any architecture decision: every answer has to be traceable to a passage in the actual rulebook, and the citation has to be something the app knows to be true rather than something the model asserted on its way past.

The Rules of Golf is unusually well suited to retrieval, because it already has the structure you would have wanted to impose on it. Numbered rules, sub-rules, lettered clauses, each one a self-contained procedure with a stable identifier. Most retrieval pipelines throw that away and split the source into fixed-size chunks, which slices a procedure in half, strands the heading in whichever chunk happened to catch it, and leaves the model to reattach a number to a passage after the fact.

We chunked on the document's own boundaries instead — one unit per rule or sub-clause, split where the rulebook splits itself. The consequence is that a retrieved passage arrives already labeled. The retrieval layer knows it returned 16.1b because 16.1b is the unit it stored and the unit it matched, so the citation is attached by the retrieval layer rather than written freely by the model.

That's a small structural difference with a large behavioral one. The model composes the explanation; it does not get to choose the number stapled to the front of it. A fabricated rule number stops being a thing that can happen, because the model was never the source of a rule number in the first place. And when nothing relevant comes back, the app says so rather than improvising — an admission of ignorance is a normal outcome here, not a defect.

Golf courses have famously bad reception. They're large, wooded, often rural, and frequently built into exactly the terrain that blocks a signal. The place where a rules question occurs is, more often than not, a place with no bars. Treating the network path as the real product and the offline path as a courtesy would have inverted the actual usage.

So a full rules database ships inside the app: the text, searchable, organized by the situations that come up. With no signal, or with no API key configured, the app routes the question to that local database instead of the model, and it does it without a round trip that has to fail first. A timeout you have to sit through is a worse experience than an immediate, narrower answer.

The tradeoff is real and we didn't paper over it. The local path handles the common cases — where to drop, what the penalty is, whether that hazard is a penalty area — and it does not do the compound reasoning that makes the chat mode worth having, the questions where two things went wrong in sequence and the order matters. It's a smaller tool. It's also the one that's actually available at the moment the question gets asked.

Nobody stops mid-round to pull out a phone, unlock it, find an app, and type a paragraph. Pace of play is a social obligation, hands are occupied, and half the time it's raining. A rules tool that requires the full phone interaction gets opened in the parking lot afterward, which is too late to settle anything.

So the watch app is not the phone app made smaller. It's a shortlist of the rulings that actually come up in a round — relief situations, penalty counts, the drops people get wrong — reachable in a couple of taps on a wrist you're already looking at. The home-screen widget does the same job one layer out, putting the most common procedures within reach without opening anything.

The editing was the work. Anything that required reading a full paragraph on a watch face got cut, because a feature that doesn't fit its surface isn't neutral. It takes up space, adds a state to maintain, and teaches people not to trust the watch for anything. What's left is deliberately small.

Monetization runs through StoreKit with a Pro tier, and the line we drew is that the rules themselves are never behind it. A rules app that won't tell you the rule until you pay has misunderstood what it is. The free app answers from the bundled database, searches the full text, and runs the watch app and the widget.

Pro buys the conversational path — the compound questions, the follow-ups, the ones where you describe a mess and want it untangled. That's also the part with a real cost per question, which makes the paywall an honest one: what's behind it is the thing that costs money to run, not an arbitrary feature held hostage to force an upgrade.

It's on the App Store, with the watchOS app and the widget shipping alongside it.