Hospitality Behavioural Intelligence Platform

Overview

This was Polynovea’s first product: a behavioural intelligence platform for food, beverage and nightlife venues in the Mumbai metropolitan region. It had three parts that shared one data model:

1. Acquisition intelligenceReads public reviews and turns them into a behavioural profile of each venue: who comes, why, and what drives their spend.
2. Field operations and show engineeringOperators observe venues in person and run structured, measured interventions during live service.
3. Client portalVenue operators see their profile, competitors, show plans, trading figures and guest feedback in one place.

The platform is now being re-architected. What it taught us about evidence and behaviour fed directly into Polynovea’s research direction.

The problem

A venue owner knows their covers and their rating. They don’t know why people come, which kinds of people come, what makes them stay or spend more, or which customers they could be winning. Review platforms give stars and sentiment, and two equally positive reviews can describe completely different reasons for a visit.

Live entertainment has the same blind spot. Venues change the music, lighting or staff behaviour on instinct, with no record of what actually changed in the room as a result.

Constraints

• Unstructured, noisy evidence. Reviews are short, inconsistent and often contradictory.
• Clean data must stay clean. Observations taken while an intervention is running must never contaminate the baseline that describes a venue naturally.
• Real operating conditions. Operators log data on a phone mid-service, so state must survive reloads and patchy connections.
• Research has to become action. Findings from crowd psychology and music perception are useless to a venue team unless they turn into a concrete plan for tonight.

My role

I designed the whole platform: the system architecture and data contracts, the behavioural framework, the acquisition intelligence pipeline, the field-operations module and show engineering, and the client portal’s product and interface. The code was written with Claude. As founder I also shaped the product: which questions it answered and for whom.

Reasoning and architecture

Behaviour, not sentiment. The acquisition pipeline doesn’t classify reviews as positive or negative. It detects which behavioural mechanisms were operating during a visit, using a framework of 54 behavioural primitives, 6 customer segments and 11 venue archetypes drawn from research on consumer behaviour in hospitality. Each detected signal is a structured evidence object with a confidence score, evidence weight, inference type and counts of corroborating and contradicting mentions. Contradictions are kept as data, not discarded as errors.

1. Collect
2. Extract signals
3. Cluster
4. Validate
5. Score
6. Compare
7. Recommend

Natural versus engineered observations. In the field module, every reading is stamped with its observation state at the moment it is captured: natural (no intervention active), engineered (an intervention is running) or settling (one ended in the last fifteen minutes). Only natural readings describe the venue. Engineered and settling readings go to a separate intervention-efficacy layer. That stamp is what keeps clean and manipulated data from ever mixing.

Implementation

Acquisition intelligence. Python collection pipelines across Google Places, review scraping and a second review platform; a six-step extraction and scoring pipeline; a blend layer that weights sources into one venue record; a FastAPI backend with eleven routers; and a Next.js analyst application. Venues get a health score, five fitness dimensions (office lunch, repeat habit, social dwell, group energy, destination visit), an audience breakdown, a competitor map, transformation suggestions, marketing briefs and a venue-specific AI assistant backed by retrieval.

Show engineering. A corpus of 24 research syntheses on crowd psychology, tempo and entrainment, harmony, lighting, staff behaviour, acoustic fatigue and Indian music psychology was run through an extraction pipeline into a structured knowledge graph: 693 causal relationships, 104 interventions, 485 evidence objects and 416 recorded contradictions in the general ontology, plus BPM, chord, rhythm and raga prescriptions specific to show engineering. A seven-agent model council turns that knowledge, plus the venue’s history, into a phase-by-phase show plan streamed to the operator: target tempo, harmonic register, lighting and staff cues, and what to watch for.

Operator dashboard and client portal. React and TypeScript apps with persistent state, an intervention bar that timestamps every lever pulled, QR-code guest surveys, and a multi-tenant client portal with per-client feature gating.

Live ML layer. A Kalman filter for latent crowd energy and fatigue, FFT band analysis, a Gaussian-process tempo optimiser and Bayesian venue priors. This layer ran on simulated inputs; it was never wired to production sensors.

Evidence and outcomes

• Three working applications on a shared backend, with versioned show plans, post-show outcome capture and a closed observation loop.
• Coverage of over 6,000 venues across four cities in the Mumbai region.
• Full technical documentation for every module, including its known gaps.

The platform reached working prototype stage, not proven commercial outcomes. The live ML layer was simulation-only, and parts of the research knowledge graph were not yet fused into the live council path.

Verdict

• Keep: stamping every observation as natural, engineered or settling at the moment it’s captured. Clean and manipulated data never mix, and that discipline now underpins Polynovea’s research.
• Change: explicit contracts between systems from the first day instead of cross-database writes; real sensor input in place of the simulated ML layer; and the research knowledge graph wired directly into live show planning.
• Next: the platform is being re-architected.