Studio
Brand & Content
Creative strategy, content and production that bring your brand to life and make it unforgettable.
- Branding
- Commercial Execution
- Video Production
- Content Production
- Creative Campaigns
- Motion Design
- AI Content Production
Case study · Allumi
Allumi. A personal intelligence platform, engineered end to end.
Allumi captures what a person actually does — the applications and windows they work in, the media they consume, what they eat and drink, how their body is performing — and turns that raw signal into structured, queryable understanding. We built it as one system: a web platform, a Windows desktop tracker, the integrations and an AI layer, all on a single governed data core.
- Client
- Allumi · allumi.ai
- Product
- Personal intelligence platform
- Surfaces
- Web · Windows · Android · Integrations
- Year
- 2026
- Database tables
- 76
- Server functions
- 89
- Security policies
- 238
- Source modules
- 687
Figures from the Allumi platform engineering dossier, September 2026.
The brief
Not an app. A platform with one data core.
A web platform, a Windows desktop tracker, an Android client, a calendar and health integration layer and an AI reasoning layer — all sharing the same strongly governed data. Every subsystem was designed around the hard part: high-frequency ingestion that never loses a record, and privacy isolation that holds even when the data is being read by machines.
Continuous telemetry
Second-level application and media session capture from desktop and mobile, on an append-only session protocol that never merges or discards a switch.
Reasoning layer
A conversational AI with full, permissioned access to the user’s own history, plus background analysers that categorise, summarise and surface patterns unprompted.
Health and nutrition
Photographic meal analysis down to individual micronutrients, alongside hydration, biometrics and longitudinal trend analytics.
Goals and social
Personal, automatically tracked and shared goals, friend graphs, competitions and real-time progress synchronisation between participants.
Architecture
Four clients. One way in.
Four client surfaces feed a single stateless function layer, and that layer is the only path to the data core. No client reaches storage without passing the per-row policy engine.
Clients
- Web platform React · Vite
- Windows tracker .NET agent
- Android client Kotlin
- Integrations Google · Health
Function layer · 89 endpoints
- Ingestion & sync
- Auth & device pairing
- AI orchestration
- Analytics
- Admin & ops
Data core
- PostgreSQL · 76 tables · 961 columns Row-level security on every table · 238 policies · 53 procedures · 45 triggers · 235 indexes · real-time change streams
- Object storage Meal imagery, installers and generated assets, isolated per user by bucket policy
Intelligence layer
- Conversational AI auto / extended reasoning
- Classifiers activity & media taxonomy
- Proactive engine nudges · overviews · goals
The function layer is the only writer.
Clients hold no privileged credentials; every mutation passes authentication, validation and per-row policy evaluation.
Ingestion is cheap, analysis is deferred.
Sync endpoints do nothing but validate and persist. Classification and reasoning run asynchronously, so a device sync never times out.
Failure is expected.
Analytics and AI paths are wrapped and degrade silently — a model outage can never take down tracking or the interface.
The hard part
Thousands of events a day. None lost, none merged.
A desktop agent produces an event every time the user changes window — from machines that go offline, sleep, get rebooted or reinstalled. The sync engine is built so that nothing is lost, duplicated or silently merged.
Start
Session opens, Identifier assigned
Buffer
Queued locally, Survives offline
Final
Same identifier, Duration sealed
Upsert
Matched server-side, One row per session
Discrete by rule
Every application switch is its own record. Sessions are never collapsed or de-duplicated, because the value of the data is in the granularity.
Idempotent writes
The closing message carries the same identifier as the opening one and is matched server-side, so a retried or duplicated upload cannot create phantom time.
Durable queue
Clients persist unsent events locally and discard them only after a confirmed write — tolerating days of lost connectivity and killed processes.
Constant-time authentication
Device credentials are matched by hash lookup rather than by decrypting and comparing every stored key: the difference between a sync that completes in milliseconds and one that times out.
Idle discrimination
Active and idle seconds are tracked separately, so a window left open overnight is not counted as work.
Paired without a password
The web platform issues a short-lived, single-use session token; the device exchanges it for a long-lived, scoped API key held in the platform’s encrypted keystore. Revocation is immediate and server-side.
Removed without losing a day
Removing a device is a soft delete. Its history is kept and relabelled with the retired device’s name; only the credentials are destroyed — so a machine can be reinstalled without losing a single day.
Security
Access control lives in the database.
The platform holds an unusually intimate dataset: everything a person does on their machines, what they eat, where they are, how their body is performing. So access control is not implemented in the application. It is implemented in the database, where it holds regardless of which client, function or query reaches the data.
- Tables under row-level security
- 76 of 76
- Explicit access policies
- 238
- Triggers
- 45
- Procedures
- 53
| Control | Implementation |
|---|---|
| Isolation at the row | Row-level security on all 76 tables, with 238 explicit policies scoped to the authenticated identity. |
| Role separation | Roles live in a dedicated table and are evaluated through a security-definer function, which removes the escalation path that role-on-profile designs create. |
| Credential handling | Device API keys stored encrypted and matched by hash; third-party tokens encrypted at rest and decrypted only inside privileged procedures. |
| Secret management | Service credentials held in a managed secret store and injected into the function runtime — never present in client code or in the database. |
| Schema-injection defence | Every database function pins its search path, so a procedure cannot be hijacked by a shadowed object. |
| Audit trail | A dedicated audit log records access to sensitive resources. |
| Data preservation | Destructive operations are soft deletes by default; history survives device removal and reinstallation. |
| Input validation | Schema validation with hard field caps at every ingestion endpoint, bounding both payload size and record counts. |
A compromised client, a mistaken query or a new developer cannot read another user’s data. The database itself refuses.
Data model
Seventy-six tables, grouped by what they mean.
Nine domain enumerations and 961 columns model the whole of a person’s day. The schema is grouped by domain rather than by screen, so a new client surface inherits the full model without a migration.
| Domain | Tables | What they hold |
|---|---|---|
| AI | 16 | Conversations, messages, reactions, drafts, memories, nudges, feedback, behavioural insights, daily overviews |
| Social | 12 | Friend graph, privacy settings, activity feed, competitions, participants, seasonal and location challenges |
| Analytics & admin | 12 | Web sessions, page views, events, roles, audit log, dashboard widgets, support, waitlist |
| Goals | 11 | Personal goals, milestones, progress history, AI-managed goals, templates, shared goals with participants and check-ins |
| Activity & devices | 9 | Application and window sessions, media playback, registered devices, pairing tokens, diagnostics |
| Context | 7 | Calendar events and sync state, locations, weather cache, flow sessions |
| Health & biometrics | 5 | Health metrics, biometric samples, wearable connections, platform health imports |
| Nutrition | 4 | Meals, individual food items with full macro and micronutrient breakdown, hydration, pending imagery |
| Total | 76 tables |
Domain grouping, not screen grouping
Tables model concepts — a meal, a session, a goal — so a new interface or client reads the same model without a migration.
Append-only history
Telemetry, meals and check-ins are written as immutable records. Corrections are new state rather than overwrites, which keeps trend analysis honest.
Identity without coupling
User-owned rows reference a profile record rather than the authentication store, so account internals stay isolated from product data.
Derived state stays derived
Scores, streaks and summaries are computed and stored deliberately — never recomputed inconsistently across clients.
Intelligence
Most of the intelligence is never asked for.
The AI reads the same governed tables the interface reads, under the same policies. It answers on demand, and it runs on its own schedule — writing structured insight back into the data model, so the interface and the assistant read from the same conclusions.
| Process | What it does | Cadence |
|---|---|---|
| Activity classification | Assigns category, productivity signal and content taxonomy to incoming sessions, with a deterministic fallback when the model is unavailable. | Continuous |
| Media analysis | Identifies what was actually watched or listened to, and derives type and mood from playback metadata. | Continuous |
| Category specialists | Dedicated analysers for deep work, productivity, communication and health, each maintaining its own domain state. | Event-driven |
| Daily overview | Synthesises the full multi-modal day into a written narrative with scores and highlights. | Nightly |
| Nudge engine | Generates context-aware, actionable prompts governed by per-user preference and quiet hours. | Scheduled |
| Goal tracking | Resolves goal progress through pattern matching first, direct data mapping second, and model inference only as a fallback. | Tiered |
| Behavioural profiling | Derives long-run personality and pattern insight from observed behaviour rather than questionnaires. | Periodic |
Cost-routed by task
Routine, high-volume classification runs on fast, inexpensive models; heavyweight reasoning is reserved for the cases that genuinely need it.
Deterministic fallbacks
Every model-dependent path has a rule-based fallback, so classification continues even when a provider is unavailable.
No heavy abstractions
Services call model APIs directly rather than through orchestration frameworks, which keeps cold starts low and behaviour inspectable.
Feedback captured
Users rate responses on tone and usefulness, and that signal is stored as structured feedback against the interaction.
Product depth
From a photograph to forty fields.
Nutrition is the deepest single feature in the platform. A user photographs a meal; the system returns a structured record precise enough to drive goals and long-term trend analysis.
Capture
Photo or gallery
Compress
WebP, size-bounded
Analyse
Vision model
Itemise
Per-food breakdown
Persist
40-column record
Trend
Goals and charts
Micronutrient depth
Beyond calories and macros: the B-vitamin group, minerals, omega fatty acids, choline and sugar — 40 fields per food item, 45 per meal.
Correction by conversation
If the analysis is wrong, the user says so in plain language or by voice, and the record is amended in one step — validated before it is written.
Cross-device continuity
A photo taken on a phone is staged in storage and resolves on whichever device the user finishes the entry.
Goals that track themselves.
The system already knows what happened, so most goals need no manual logging at all.
| Tier | Mechanism | Used when |
|---|---|---|
| 1 · Pattern match | Deterministic rules resolve the goal directly against known signals. | The goal maps to a tracked concept — focus hours, steps. |
| 2 · Data mapping | The goal is bound to a specific table and aggregation. | Calories, protein, hydration, sessions, page activity. |
| 3 · Model inference | A language model interprets an open-ended objective and estimates progress. | Only when the first two tiers cannot resolve it. |
Update frequency follows each goal’s urgency, so active goals refresh often and dormant ones cost nothing.
Interface
Sixty-four screens from one token layer.
Colour, spacing, radius and typography are declared once and consumed by role. That is what keeps a 64-screen product coherent, and what lets it theme light and dark from a single definition.
Typefaces
- Sora Display and headings · tight tracking
- Manrope Body, interface and data · high legibility
Core palette
- Ink
#0B0B0C - Electric Blue
#2563EB - Muted
#6E7178 - Surface
#F3F3F1 - Canvas
#FBFBFA
Semantic tokens only
Components reference roles, never literal colours, so the whole platform themes from one definition.
Relative sizing throughout
No fixed pixel dimensions, so the interface scales with the user’s and the system’s preferences.
Purpose-built mobile rendering
Below the breakpoint the application renders its own mobile composition — with native gestures for drag ordering, long-press and swipe — rather than reflowing the desktop one.
Bento composition
Dashboards are built from a reorderable, resizable panel system, with layouts persisted per user.
Delivered scope
The platform, as built.
Clients, ingestion, data model, access control, intelligence layer and interface — designed, built and operated as one system.
| Area | Delivered | Scale |
|---|---|---|
| Web platform | The full application and the public marketing site — dashboard, timeline, sessions, nutrition, health, goals, friends, insights, settings, admin. | 64 screens |
| Component library | A themed component system across 48 feature groups. | 687 modules |
| Backend services | Ingestion, authentication, device pairing, AI orchestration, analytics, scheduled jobs, administration, transactional email. | 89 functions |
| Data model | A domain-grouped relational schema with enumerations, procedures, triggers and indexes. | 76 tables · 961 columns |
| Access control | Per-row policies on every table, plus role and audit infrastructure. | 238 policies |
| Desktop client | A Windows tracking agent speaking the session protocol. | Continuous capture |
| Mobile client | An Android telemetry client with QR pairing, a foreground service, a durable queue and media capture. | Specified & integrated |
| Integrations | Google Calendar with webhooks, Google location, wearable and platform health data, weather, speech and vision models. | 8+ services |
| Administration | Live user analytics, cohort and journey analysis, conversation monitoring, storage browser, role management, security scanning. | 20 admin endpoints |
- Tables under row-level security
- 76
- Governed data columns
- 961
- Deployed server functions
- 89
- Row-level access policies
- 238
- Database procedures
- 53
- Query indexes
- 235
- Application screens
- 64
- TypeScript source modules
- 687
Real-time by default
Change streams push activity, goals, reactions and shared progress to every open client, without polling.
Degrades gracefully
Analytics and model calls are isolated; no secondary system can take down capture or the interface.
Built to extend
A new client surface inherits the entire data model and policy set without a schema change.
Operationally observable
Structured function logs, device diagnostics reporting and an internal security scanner.
Services on this project
Next project
MetmeeHave a similar challenge?
Tell us what you want to change. We’ll discuss the work that would support it.
Discuss your projectRecommended for you
Since you’re exploring Digital, you might also need this.
Combine technology with creative execution to unlock even bigger results — from strategy to scale, all in one place.
Digital / Explore / What’s nextDifferent expertise. A stronger tomorrow.