ZoiHK | Devpost

Inspiration

Hong Kong is the rare global city where public transport ≈ 90% of daily trips—and where the Government has a formal Smart City Blueprint that explicitly pushes open data for mobility innovation. We asked: what if “live context” (weather alerts, tunnel congestion, bus/MTR ETAs, border signals) could automatically trigger the right booking—coach, licensed charter, ferry, Airport Express, or on-demand? That’s the seed of ZoiHK: from live data to live commerce.

What it does

ZoiHK is a mobility commerce platform for Hong Kong: • Fuses official live feeds into one Status (Live) layer: • Weather warnings & 9-day from HKO Open Data; road Journey Time Indicators (JTIS 2nd Gen); Special Traffic News (STN 2nd Gen); Citybus V2 & KMB/LWB ETAs; HKMA branch/ATM locations.
• Turns signals into one-tap actions: • If JTIS goes red or STN posts an incident → show a “reroute/reshuffle” card with cross-border coach, licensed charter (HCP-verified), ferry or Airport Express options. • Buy flows (Hackathon demo): • Soft-buy: deep-link cards to Airport Express QR tickets (PayDollar H5) and ferry operators (TurboJET/Cotai) with return URL + in-app webview for smooth UX.
• Hard-buy (POC): a signed-ticket format (JWS) + offline driver verifier for future coach/charter partners. • Gov-wide notifications: • Ingest the GovHK Notifications JSON (list + detail) and ISD Press Releases RSS/Search API; we classify travel-relevant notices and summarize them.

How we built it

Architecture (Hackathon build): • Gateway/BFF on AWS: • Amazon API Gateway + AWS Lambda (Node/Python) normalize upstream feeds to four namespaces: GET /live {weather, traffic, incidents, eta}, GET /place {toilet,wifi,atm,bank,hospital,aed,carpark,pier}, GET /ticketing {coach,charter,ferry,ael}, GET /alert {govhk,press}. • TTL cache per source (e.g., JTIS = 120 s, Citybus ETA = 60 s, AQHI = 15 min) with DynamoDB/ElastiCache; degrade to “last good frame + timestamp + source” on failure.
• AI layer (Summarize & Route rationale): • Amazon Bedrock agent generates a 2–3 line, bilingual summary for GovHK/HKO/TD alerts, and drafts the conversion card’s copy (“Black Rain in force → propose AEL + taxi handoff”). We used Bedrock’s unified FM API + guardrails; when in doubt, we deep-link the canonical source.
• Developer velocity: • Amazon Q Developer in IDE/CLI to bootstrap Lambdas, write unit tests, and scaffold IaC. (The agent features and “/dev” boostraps helped us ship quickly.)
• Data sources (all official): • HKO Open Data (weather & warnings warningInfo), TD JTIS 2nd Gen & STN 2nd Gen, Citybus V2 ETA (PDF spec), KMB/LWB ETA (spec), HKMA branch/ATM Open API, GovHK Notifications JSON, ISD Press Release RSS/Search.
• Ticket POC: • JWS (ES256) payload: jti, trip_id, order_id, seat_no, nbf, exp. Driver app (Android) validates offline with JWKS-rotated public keys; syncs scans when re-connected. (Spec-based: RFC 7515/7517/8037.)

A tiny bit of math we used (ETA smoothing / proration for partial-period tickets): \text{ETA}{\text{smoothed}}=\alpha \cdot \text{ETA}{\text{live}}+(1-\alpha)\cdot \text{ETA}{\text{hist}},\quad \alpha\in[0,1] \text{Fare}{\text{prorated}}=\text{Fare}_{\text{full}}\times \frac{\text{used_days}}{\text{cycle_days}}

Challenges we ran into • Heterogeneous feeds: formats vary (RSS/JSON/XML), even time units differ (GovHK Notifications list = ms, detail = µs). We built a strict normalizer.
• Rate limits & freshness: balancing TTL so JTIS/ETA stay fresh without hammering sources; adding “last good frame” degraded state.
• Soft-buy UX: deep links can feel “sticky-patch” if you just throw users away. We solved with pre-checkout pages, Universal/App Links, in-app webviews, and return URLs. • Compliance for charters: only HCP vehicles, never “拼座”。We surface HCP online check and the “Cross-Boundary Hire Car” mark in our flows.

Accomplishments that we’re proud of • Live→Action conversion cards that actually adapt to incidents (JTIS red / STN push / HKO warnings).
• A unified /live API over HKO / TD / Citybus / KMB/LWB / HKMA / GovHK with consistent timestamps, i18n, and caching.
• Airport Express soft-buy that teaches users QR at green-label gates (MTR’s official guidance) while preserving ZoiHK branding and analytics.
• A signed-ticket offline verifier (JWS/JWKS) ready for small coach fleets with zero equipment changes.

What we learned • Open data is real in HK—but details matter: e.g., JTIS refresh is 120 s by design; GovHK Notifications have different ts units between endpoints.
• Micro-moments win: cards that appear when weather or traffic flips convert far better than static buttons. • AI helps with “explainability”: Bedrock’s short bilingual summaries + citations made alerts usable without overwhelming users.
• Developer tooling (Amazon Q Developer) meaningfully sped up scaffolding/tests, though we still kept security reviews in the loop.

What’s next for ZoiHK • From soft-buy to hard-buy: CSV/SFTP 放票 with cross-border operators → merchant dashboard → real-time API and automated clearing. • Partner OS: give fleets a zero-dev “driver scan” app, T+1/T+7 clearing, bulk rebooking for typhoons. • AI routing & pricing: learn \alpha for ETA smoothing per corridor; RAG over incident history to suggest best modality swaps (ferry vs. coach vs. charter) grounded in HK feeds. • Open data to open standards: publish our /live schema so other HK apps can consume the same normalised feeds.