Blocpod system /
Velvet: a consumer preference platform with a governed AI recommender and a partner API
A taste-and-preference platform built for a live consumer event: anonymous sessions, server-owned consent, an inventory-aware recommender with an AI rerank behind cost ceilings and timeouts, Brand Studio analytics, and a versioned partner API.
- Automated tests
- 46 unit + 3 end-to-endvitest on in-process Postgres, Playwright e2e, CI on every push
- Catalogue
- 43 recipesintegrity-tested, every flavour tag covered
- Partner API
- v1recommendations, events, analytics; OpenAPI published for the integrating product
Bottleneck
A live event with real people scanning a QR code is the least forgiving environment for an AI feature. The recommender has to answer in seconds, honor what the guest actually has available, respect consent, and never blow through an API budget while a hundred phones hit it at once.
System
Velvet runs a deterministic, inventory-aware recommender with an optional model rerank. The rerank sits behind a timeout and falls back to the deterministic result, so a slow or failing provider degrades the experience by a few percentage points of quality, not to an error screen. Consumer sessions are anonymous and signed. Brand Studio reads database aggregates for flavour and occasion analytics. A second Blocpod product, TequilaTown, integrates through the same versioned partner API.
Control
- Consent and age are decided on the server.
- Cost has a ceiling. Guardrails enforce a rate limit and a daily spend cap in process.
- Partners are scoped. API keys are hashed, scoped to recommendations, event writes or analytics reads, and rate-limited per key.
Result
The thing a buyer should take from Velvet is not the cocktail catalogue. It is that a consumer-facing AI feature shipped with the same posture Blocpod applies to back-office workflows: bounded, measured, and safe to fail.
Evidence
Where these claims come from.
- github.com/Blocpod/Velvet ↗spec, plans and openapi.yaml in the repository