Silverbricks

Inspiration

Singapore is becoming a super-aged society, but the seniors most at risk of social isolation can still be difficult to identify and reach. In 2025, 88,400 residents aged 65+ were living alone, up 39% from 2020, including 34,400 people aged 75 or older. At the same time, outreach by the Silver Generation Office and Active Ageing Centres is still largely planned by hand. That led us to a simple question: what if we could turn Singapore’s existing public data into a practical weekly outreach plan — down to the HDB block and walking route? SilverWatch was born from the gap between how risk data is published at an area level and how outreach actually happens: one door at a time.

What it does

SilverWatch predicts social isolation risk at the HDB-block level and turns that risk into walkable outreach plans for volunteers. AAC coordinators and Silver Generation ambassadors can ask SilverWatch in plain English which blocks they should visit this week and in what order. Instead of receiving another heatmap, they get ranked blocks, balanced walking routes, explanations for why each block was prioritised, confidence levels, and source dates. For planners at MSF and AIC, SilverWatch can also highlight areas where at-risk seniors live more than a 10-minute walk from an Active Ageing Centre, helping inform where additional capacity may be needed.

How we built it

SilverWatch brings together public data from SingStat, HDB, URA, MOH/data.gov.sg and OneMap. The datasets cover demographics, HDB flat mix and rental units, subzone boundaries, Active Ageing Centre locations, household characteristics, block coordinates and walking times. silverwatch-round1-slides We designed an end-to-end Databricks medallion architecture: Open data → Bronze → Silver → Gold → Intelligence → Databricks App Raw data is ingested using Lakeflow Jobs, stored in a Unity Catalog Volume, and written into Delta tables with Auto Loader. Silver-layer pipelines handle geocoding, subzone joins and data-quality checks. Gold tables serve block-risk scores, cached walking times, route plans and visit logs. For the intelligence layer, we use MLflow to track scoring approaches and evaluation, together with Foundation Model APIs, Unity Catalog functions and a Genie space. The final experience is a Databricks App combining chat, a route map and visit logging.

Challenges we ran into

One of the biggest challenges was that the data does not naturally exist at the level at which outreach happens. Demographic information such as the number of residents aged 75+ is available by subzone and dwelling type, while volunteers need to know which individual HDB blocks to visit. We therefore had to design a defensible way of estimating block-level risk by combining SingStat demographic data with HDB flat-mix information, while being careful not to imply more precision than the source data supports. That is why SilverWatch includes confidence levels, explanations and source dates for every recommendation. A second challenge was going beyond analysis and producing something operational. Ranking high-risk areas was not enough — we also needed to translate those rankings into routes that volunteer teams could realistically walk within a fixed outreach window.

Accomplishments that we're proud of

We are especially proud that SilverWatch is designed as an action tool rather than another dashboard. It operates at the block level rather than only the planning-area level, converts risk into an ordered walking route rather than a heatmap, explains the reasoning behind each recommendation, and can learn from logged visit outcomes over time. We also designed a complete user journey: a coordinator can ask for Saturday outreach in Bedok, receive two balanced walking routes over high-risk blocks, ask “why this block?”, and log visit outcomes so that the following week’s plan can adjust.

What we learned

We learned that building a useful public-sector data product is not just about producing the most sophisticated model. The output has to fit the real decision being made. In SilverWatch’s case, the useful answer is not simply “this area has higher risk.” It is: “These are the blocks your teams should visit this Saturday, this is the order to visit them, and this is why.” We also learned the importance of explainability when working with estimated risk. Because block-level scores are derived from aggregated public data, showing confidence, source lineage and the factors behind each score is essential. Finally, the project showed us how Databricks can support an entire workflow: from data ingestion and governance to modelling, conversational tools and a user-facing application, rather than acting only as an analytics backend. The architecture on slide 3 also keeps Unity Catalog lineage and role-based governance throughout, while using only block-level aggregates and no personal data.

What's next for SilverWatch

Our first goal is to complete the full pipeline for a Bedok pilot, including the block-risk score, route planner for two volunteer teams, conversational agent, Genie space and dashboard. From there, we want to expand SilverWatch to more planning areas, incorporate actual visit outcomes into future versions of the risk model, and evaluate whether the system leads to more visits to high-risk blocks, better visibility of coverage gaps, and less coordinator time spent manually planning outreach.
A longer-term extension would be to use the same framework for AAC site screening, helping planners identify where new services could have the greatest impact.