Case studies without dressing up the data.
Each study separates what a reader can verify publicly from data supplied by the project owner. A result is not attributed to a single change when the whole system changed.
taxi.co.rs
23 city hubs, a national fare page, local entities and owner-supplied Search Console data.
Decision logHow the map was built
The rejected pages, the criterion that rejected them, and one decision that did not work out.
Control caseleskovac.taxi
The same approach on a single city produces a four times weaker AI share ratio. The finding is published with its limitations.
Why these two are published together
One project with a good result is an anecdote. Two projects run by the same agency, in the same industry, using the same method — where the outcome differs — is the beginning of something that can be examined.
The first study documents an architecture that worked. The second checks whether the same pattern holds elsewhere, finds that it holds far more weakly, and ends by concluding that for a local service the metric itself was the wrong choice. Read separately, the first looks stronger than the evidence supports. Read together, they are honest.
The rules every study here follows
| Rule | What it means in practice |
|---|---|
| Public and owner data are separated | Anything a reader cannot verify is marked as owner-supplied, with the export date |
| No result is attributed to one change | Where several surfaces changed at once, the conclusion belongs to the system |
| Negative findings are published | A weaker result is data, not a reason to change the story |
| Every measurement carries its period | A number without a period and a source is not a measurement |
| Limitations are a section, not a footnote | What the study does not prove is stated explicitly |
The same rules govern the audit example, where two unresolved findings on our own project are documented alongside their fixes.