Know Ahead

See what's coming. Understand the impact. Make better decisions.

Inspiration

Sydney never stops changing. A construction crane goes up two blocks away, a road gets closed for six months, a development gets approved 180m from your front door — and most of us find out only after it's already disrupting our lives. The information was never actually hidden. It was just scattered: buried in a council PDF, a transport authority bulletin, a weather warning, a planning portal nobody thinks to check.

That's the seed the whole project grew from: people don't know what they don't know. You can't Google "is there a development happening near my house next year" if the thought never occurs to you. We wanted to build something that asks that question for you, continuously, without waiting to be prompted — something that answers "what's changing? will it affect me? what should I do?" before you even knew to ask.

What it does

Know Ahead lets a user save the locations that matter to them — home, work, a place they're thinking of renting — and continuously watches for urban signals nearby: development approvals, roadworks, weather, events. When something changes, it doesn't just dump raw data on the user. It works out how far away the change is, what it's likely to mean (noise, traffic, dust, duration), and connects that to the user's actual situation — like a lease that's about to come up for renewal — before explaining, in plain English, what's changed and what's worth doing about it.

The signature moment we built toward: a user asks "Should I renew my lease?" and gets back something like — "A development was approved 180m from your home. Construction is expected to run about 18 months and may bring significant noise. That overlaps with your next lease period — worth checking permitted construction hours before you sign again."

How we built it

We split the system deliberately down the middle: code establishes the facts, AI explains what they mean. Everything that can be computed — distance to a location (Haversine formula), whether something changed since the last check (diffing snapshots of the data), and how severe an impact probably is (a rules table keyed by event type and distance) — is plain deterministic Python. The LLM is only ever handed already-verified structured facts and asked to turn them into a personalised, plain-English explanation and recommendation. It's never allowed to invent a distance, a date, or an event that doesn't exist in the data.

The backend pipeline runs in five stages: collect → detect changes → filter by distance → score impact → explain with AI. We built it as a FastAPI service with a few core endpoints — save a location, monitor a location, and a "decision mode" that takes an ad-hoc address and a question like the lease example above. Data is normalised into one consistent event shape regardless of which source it came from, so adding a second or third data source later doesn't mean rewriting the pipeline.

Challenges we ran into

The biggest one showed up almost immediately: the NSW Planning Portal's real development-application data feed isn't a simple public API — accessing it requires emailing NSW's data team for a subscription key, which realistically doesn't arrive inside a hackathon's timeframe. That forced an early, honest decision: rather than fake the concept of real data, we built our ingestion layer against the real API's actual schema and fields, so it's a genuine drop-in adapter — and seeded it with a realistic sample record for the demo. The moment a key comes through, swapping in live data is a one-function change, not a rebuild.

The second challenge was resisting scope creep. It would have been easy to try to wire up five data sources, a fancy prediction model, and a polished multi-page frontend in the time we had. We kept coming back to one question: does this feature make the one end-to-end demo — home address in, real change detected, distance and impact explained, personalised recommendation out — stronger, or does it just make the pitch deck longer? Anything that didn't serve that one path got cut.

What we learned

The most useful realisation was how much of "AI product" work is actually about not using the AI. Every time we were tempted to ask the LLM to figure out a distance or decide whether something counted as "new," we were introducing a place where it could quietly hallucinate a fact nobody could verify. Pushing all of that into deterministic code — and only handing the AI a clean list of already-true facts — made the system both more trustworthy and, honestly, easier to debug when something looked wrong.

We also learned firsthand how much friction "open" government data can still carry. A dataset can be publicly documented and still be functionally locked behind an access request — which shaped how we think about MVP scope: build for the real integration, ship with an honest placeholder, and never pretend a shortcut is the real thing.

What's next for Know Ahead

Swap the seeded planning data for the live NSW DA feed once access is granted, and add a second real source (weather or roadworks) to prove the pipeline generalises
Move impact scoring from a fixed rules table toward using historical outcomes to calibrate the thresholds
Build out the map view and a proper "Pulse" dashboard so alerts have a visual home, not just a text response
Support comparing multiple candidate locations side by side for the "choosing where to live" use case