A map pin is not the whole answer
While developing Stacja Obok, an important design problem kept appearing: how should the interface behave when a useful detail is missing? A charging station might have location data but no current status. A tariff might include the energy rate but leave another component unspecified.
Do not turn absence into an answer
Missing price data should not silently become a zero. Unknown availability should not look like confirmed availability. A location without a result from the connected sources should not be presented as a location without chargers. These distinctions are part of the product logic, not just the wording.
Explain the decision where it happens
The public map explains that coverage depends on its sources. Availability is reported information and may change before arrival. Cost comparison distinguishes energy, time, session and parking components. The goal is to help someone decide what to check next without forcing them to understand the entire data pipeline.
Be precise about time
The time our system receives information and the time an operator updates it are different. A timestamp can make a result look reassuring while answering the wrong question. The interface should make the meaning of that timestamp clear and avoid treating an old observation as a promise.
Where AI assistance stops
AI can help implement filters, write tests and improve explanations. It cannot turn an absent source field into a verified fact. The checks still need to preserve the difference between known, estimated, stale and unknown information.
A principle I want to keep
When the input is incomplete, the interface should preserve that uncertainty and offer a useful next step. Open the station details, inspect the source or check the operator. “Unknown” can be an honest, actionable state instead of an error to hide.
Written from project records with AI assistance and checked against the documented implementation. This is a build note, not an independent product audit.