Case Study
A Human-Governed City-Intelligence Platform
I designed and shipped a live consumer application and operator platform that turns Events, city Signals, cultural context, and permanent Spots into explainable recommendations.
Owned product strategy, UX architecture, consumer experience, admin tooling, AI ingestion workflow, governance model, and launch direction.
Why it matters
Angel Compass proves I can design both sides of an AI-native system: the consumer experience people trust, and the operator layer that keeps the intelligence reviewed, governed, and explainable.
Founder · Lead Product Designer · Systems Designer · Product Architect
Execution ScopeEnd-to-end product architecture, UI/UX systems design, technical data modeling, and release engineering.
The City-Information Problem
Standard navigation platforms and mapping services are architected around static listing data. Yelp, Google Maps, and directory guides tell users when a business is open, where it is located, and its cumulative review score.
However, the real-world utility of a city spot fluctuates dynamically. A neighborhood lounge that is cozy at 7:00 PM on a Tuesday becomes overcrowded during a concert let-out nearby at 9:30 PM on a Friday. A patio cafe is less viable when a sudden downpour hits, and a retro cocktail spot's appeal shifts based on travel distance, door policy, and the traveler's energy level.
The design problem was not simply displaying locations. It was constructing a living systems architecture that could capture, normalize, verify, and explain these shifting city conditions in real-time, helping users make decisions before committing to a trip.
Spot, Event, Moment, and Signal
To solve this, I modeled the city as a relationship between four structural primitives, transforming abstract data points into clear recommendations.
The static venue baseline (105+ curated spots in Atlanta). Holds location coordinates, neighborhood tags, acoustic profiles, and physical layout data.
A discrete, scheduled occurrence linked to a Spot (e.g., Friday Jazz, a concert, or a DJ set) defined by specific timing boundaries.
A dynamic overlay that flags temporal shifts (e.g., Event Surge, Patio Risk, Scene Shift, Transit Delay) affecting nearby Spots.
Physical data inputs (e.g., weather reports, road closures, wait times) crawled by the parser to trigger or modify active Moments.
The Consumer and Operator Split
When building location products, there is a dangerous temptation to build fully autonomous pipelines: letting web scrapers dump data straight to the user app, or letting an LLM publish signals on the fly.
This case study establishes a strict boundary: AI proposes and structures, but the human operator controls consequential publication.
To protect trust, the system architecture is separated into a consumer app and an operator console, enforced by server-side rules:
Public Trust Boundaries
A typecheck passing does not mean real-world behavior is verified. An HTTP 200 return code does not mean crawled content is useful.
Therefore, no Event or Moment candidate in storage is visible to users until an administrator has reviewed, verified, and explicitly promoted it.
Data Isolation
Row-Level Security (RLS) policies completely isolate the administrative candidate queue from public API reads.
The consumer client queries isolated database views that only contain active, approved, and chronologically valid records.
Governed Ingestion Architecture
The ingestion engine crawls trusted venue domains, formats unstructured text via a structured prompt parser, and delivers a sanitized payload to the gateway.
The ingestion pipeline enforces Deno-hosted endpoint security, parses metadata parameters, runs URL de-duplication routines, and isolates incoming content. The human-governed step provides the ultimate quality check on the database boundary, before anything reaches public client views.
Control Room, Ingestion, and Governance
I designed a unified administrative console—the Control Room—that gives operators complete operational visibility over the ingestion and publication engine. No crawled candidate or AI-structured condition is served to users until it has been inspected and promoted, ensuring strict editorial control over the city-intelligence graph.
System Event Publication Lifecycle (Workflow Model)
An Event candidate transitions through five structured publication lifecycle states to assure platform trust:
Pending Ingested, unverified candidate
↓
Approved Verified details, parent Spot linked
↓
Ready Scheduled, lookahead checks pass
↓
Published Active, visible in recommendations
↓
Expired / Archived Time window closes, archived
System Data Payload (Raw Ingestion Log)
"review_id": "rev-spot-uuid-high-museum",
"event_name": "Friday Jazz",
"parent_venue_name": "High Museum of Art",
"event_date": "2026-07-12",
"start_time": "18:00:00",
"status": "candidate",
"verification_status": "unverified",
"confidence": "high",
"needs_human_review": false,
"review_status": "pending_review",
"dedupe_key": "28d9f68f0cf0e5f987aa5286205133a...",
"source_health": {
"fetch_health": "good",
"content_health": "event_rich"
}
}
Shipped Control Room Interfaces
Consumer Intelligence and Routing
The consumer mobile application translates verified platform governance into a map interface. When a Moment is promoted by an operator, the map renders active influence fields (pulsing domes indicating surge or delay boundaries) rather than static pins.
Explore Map
Pulsing domes for active Moments
Route Generator
Tonight's Move multi-stop optimizer
Venue Profiles
Vibe metrics & timing windows
Contextual Influence
Vibe alerts & event impact around a Spot
Tonight’s Move Routing Optimizer
Instead of hijacking travel plans, Tonight’s Move uses a two-pass routing engine to generate itineraries structured by Warm-up, Prime, and After-hours stops.
The engine computes an absolute arrival timestamp, applying exponential decay curves to dynamic vibe scores based on distance travel times, closing warnings, and active Moments. If a patio risk is active, the first stop is penalized; if a concert surge is nearby, the prime stop receives a routing weight boost to align with high energy intent.
Data Boundaries & AI Limitations
To build a location product that respects trust, the systems architecture defines strict user-privacy and engineering constraints:
Public-Safe GPS Fallbacks
If the user denies foreground GPS permissions, the app does not break or lock up. It automatically falls back to base coordinates in Midtown Atlanta, keeping the search interface fully functional without compromising privacy.
Constrained Natural Language
The conversational chat interface (Ask Cheesy) is restricted from hallucinating recommendations. It converts raw natural-language queries into structured filters, querying only the verified, operator-approved venue graph database.
The systems design reflects a core architectural philosophy: AI assists the operator and processes context, but the human remains the final validator of truth.
System Outcomes
Measured Ingestion Audit (July 12, 2026 Run)
The performance of the ingestion-to-publication engine was audited across a lookahead sweep of the target venue graph.
Why This Matters
Angel Compass became an exercise in designing living systems rather than isolated screens. Every recommendation depends on data provenance, operator judgment, AI assistance, publication governance, and user trust. The consumer experience succeeds because the internal platform makes the intelligence maintainable, accountable, and explainable.
Reflection
Building Angel Compass changed how I think about AI products. The hardest challenge was not generating more recommendations. It was deciding which recommendations deserved to become product truth. Designing the operator experience became as important as designing the consumer experience, because trust is not created by AI alone. It is created by the systems that govern it.
Case Study Thesis
I designed the consumer experience, the platform that feeds it, and the governance that keeps both trustworthy.