What TastePolicy does
Autonomous agents are getting better at knowing what a person may like, but liking something is not the same as authorizing an agent to act on that preference.
TastePolicy is a preference-authorization layer for autonomous agents. Qloo supplies real cultural intelligence; TastePolicy decides whether a specific taste-sensitive proposal is justified for a person in the current context.
Qloo gives agents taste. TastePolicy gives that taste authority boundaries.
A proposal is evaluated into one of four deterministic outcomes:
- ALLOW — the preference choice is justified; the agent may continue with a bounded recommendation/draft action.
- ASK — one explicit piece of context is missing, so the agent must ask before continuing.
- REJECT — an explicit user boundary blocks the choice; the agent must not proceed and may offer a bounded, separately verified repair.
- UNAVAILABLE — cultural evidence is unavailable; the agent pauses instead of pretending that missing evidence means dislike.
TastePolicy deliberately does not grant booking, purchase, payment, account, or other execution authority. The same agent can continue after a preference decision, but those next actions require their own permission layer.
Why Qloo is essential
The project starts from five explicit, cross-domain taste signals — currently Nils Frahm, Perfect Days, Muji, Piranesi, and Severance — and resolves them through Qloo. Qloo then provides entity identity, cross-domain cultural relationships, and candidate-specific evidence for real place discovery.
TastePolicy does not reproduce or replace Qloo's graph. Instead it adds an authorization boundary around Qloo-grounded taste evidence. A strong cultural match can support a choice, but it cannot override an explicit exclusion or another applicable user rule.
The live Win Gate acceptance used the official Qloo Agentic Hackathon API (/v2/insights) to resolve/discover real candidates and evaluate them through the existing TastePolicy policy path.
Judge-facing experience
The public Consumer Arena is a staged journey rather than a developer dashboard:
- Taste — review five explicit taste signals.
- Discover — Qloo finds real candidate places through those signals.
- Check — TastePolicy evaluates the selected candidate against saved preference state, context, and constraints.
- Decision — the product returns ALLOW, ASK, REJECT, or UNAVAILABLE with evidence and a bounded next action.
The visual system intentionally separates expressive taste from precise permission through a recurring “Boundary” motif. Licensed Wikimedia location-context photography is used where safely attributable; otherwise authored illustrative taste images are clearly labeled as presentation-only and never enter authorization evidence.
Stateful preference boundaries
TastePolicy preserves explicit user state in PostgreSQL. The demo can:
- save a context-scoped budget;
- ask for a missing price rather than guessing;
- capture an explicit clarification answer without rewriting the durable preference state;
- save a durable candidate exclusion;
- refuse a candidate when that exclusion applies;
- search for a bounded replacement;
- require a fresh authorization evaluation before a replacement is treated as allowed.
A repair proposal is never itself authorization.
The implementation also refuses to fake a successful budget-aware replacement when authoritative replacement-price evidence is missing. In that case it returns NO_VERIFIABLE_REPAIR and keeps the user's rules intact.
Auditable evidence
Each authorization path produces captured state/evaluation evidence and a Cultural Receipt with provenance. Qloo evidence and TastePolicy policy evidence remain visibly separate: Qloo explains cultural fit; TastePolicy owns subject state, explicit constraints, deterministic authorization, and the continuation boundary.
The project also includes a separate-process agent-obedience proof showing that an external caller can consume the existing TastePolicy decision/continuation contract and stop correctly on ASK, REJECT, or UNAVAILABLE. That controlled proof is labeled honestly and is not presented as a live commercial-agent integration.
Validation
The Win Gate branch has passed the full repository verification suite, including unit/integration tests, PostgreSQL tests, Playwright browser tests, strict TypeScript, production build, TasteBench validation/contract/report checks, credential/client-bundle scans, and production dependency audit.
A blinded descriptive human pilot was completed with 10 genuine participants and 180 judgments. It is reported as descriptive evaluation evidence, not population-level safety or scientific validation; no policy threshold was tuned to the held-out responses.
Architecture
- Next.js / React / TypeScript
- server-only Qloo API integration
- PostgreSQL / Neon durable state
- deterministic preference evaluator
- scoped feedback and constraints
- captured clarification and bounded repair
- Cultural Receipts and provenance
- Vercel-hosted public demo
- Playwright + unit/integration + PostgreSQL verification
TastePolicy's central idea is simple: knowing someone's taste is not permission to act on everything you know about them. As agents become more autonomous, preference-sensitive actions need an auditable stop/ask/proceed boundary before separate execution authority begins.
Built With
- neon
- next.js
- playwright
- postgresql
- qloo-api
- react
- typescript
- vercel