TastePolicy
Your taste. Your rules. Any agent.
Qloo gives agents taste. TastePolicy gives that taste authority boundaries. It answers one question for any agent: is this subjective choice sufficiently justified for this person, in this context, right now?
It does not buy, book or pay, and it is not an access-control system. It decides whether a taste-based choice is justified.
How a choice is decided
- An agent proposes a choice. A hotel, a record, a brand. It asks first.
- Qloo supplies taste. Cultural evidence about the choice and about you, from your reviewed anchors.
- The Boundary sits between taste and permission. Taste can suggest. Only your rules can permit.
- TastePolicy decides. Allow, ask, reject, or “can’t tell”. Missing evidence is never a no.
- The agent gets a result it can prove. A short permission for one choice. It pauses when your information, your rules or the choice itself changes, as far as TastePolicy is told.
- Execution is a separate question. Preference authority complete. Execution authority required separately.
What you control
- Your rules: how far each agent may go, when it must ask, which choices need extra care, how fresh your taste information must be.
- What agents may do now: the permissions in force, and one button to stop them all.
- What happened, in order: every question, rule, permission and shared proof.
- Connected assistants: disconnect any of them at any time.
- Check a proof: anyone can verify what an agent shows them, without an account.
What exists today
Available now
- Decisions: allow, ask, reject, can't tell. One deterministic evaluator behind every door. Missing evidence is never a no.
- REST API, OpenAPI and TypeScript SDK. The SDK is a thin server-side client in this repository; it is not published to npm.
- Remote MCP server. Exercised with an MCP client library in tests. Not yet verified inside a hosted assistant.
- A2A agent card and authority-lifecycle extension. JSON-RPC binding, no streaming or push. Tested agent to agent in the repository; not verified with a third-party A2A product.
- OAuth account linking for hosted assistants. Authorization code with PKCE, rotating refresh tokens, consent screen.
- Owner rules: freshness, autonomy, temporary permissions. Versioned, simulated before publishing, every answer carries the rule that decided it.
- How far an agent may go: suggest to present as selected. A five-step ladder per agent and kind of choice. Going further than your limit asks you.
- Extra care for sensitive kinds of choice. You mark a kind of choice as sensitive. TastePolicy does not infer sensitivity from content.
- Short permissions (leases) with owner approval. Event-sourced, expiring, pausing on drift. A missing fact needs a new evaluation, not an approval.
- Choice and situation commitments. Canonical digests of the evaluated choice and situation. A change is noticed only if the agent presents the current one.
- Verifiable proofs with selective disclosure. Signed, short-lived, holder-bindable. A proof from an ended period of authority never becomes valid again.
- Third-party issuers. Discover, inspect, then explicitly trust. Discovery never grants trust. There is no web of trust.
- One history of what happened. A derived, private timeline of questions, rules, permissions and proofs.
- Organization ceiling. One organization per deployment, set by the operator. It can only lower what a person allows. No admin console, no SSO or SCIM.
Not yet verified
- Working inside ChatGPT, Claude or Gemini. Not claimed. Standards-based connection points exist; a recorded run in each product is required before this changes.
Roadmap
- Publishing the SDK to npm. Not done.
- Organization admin console, SSO, SCIM. Not done.
Not implemented
- Gemini Enterprise A2A. Not supported.
- Payment, booking, purchase or any execution authority. By design. Allowed means preference authority only.