TastePolicy

Release authority: M10–M26 execution ledger. Canonical M6–M10 candidate: m10-m26-company-build; tree/lineage audit. Green CI and hosted preview acceptance do not establish production or real ChatGPT/Claude commissioning.

TastePolicy

The subjective authority layer for AI agents.

Qloo gives agents taste. TastePolicy gives that taste authority boundaries. Your taste. Your rules. Any agent.

An agent can technically recommend a hotel, a record or a brand. TastePolicy answers the question that comes next: should this agent make this subjective choice for this person, in this context, right now? The answer is one of ALLOW, ASK, REJECT or UNAVAILABLE, with the rule that decided it, a Cultural Receipt, and a bounded permission that ends when the facts change.

ALLOW is preference authority only. It never grants payment, booking, purchase, messaging, account, legal or any execution authority. Memory is not permission, Qloo affinity is not authorization, a recommendation is not authorization, UNAVAILABLE is not REJECT, and verifying a proof is not authorizing an action.

Qloo and TastePolicy

	Qloo	TastePolicy
Provides	Cultural evidence: affinities between entities, across domains	Authority over what an agent may do with a taste-based choice
Answers	"How well does this fit?"	"May this agent go this far with it, for this person, now?"
Failure mode	Provider unavailable	UNAVAILABLE: no judgement was possible. It is not a rejection and never a negative taste

How it fits together

Qloo cultural evidence
  → subject-owned preference state (immutable versions)
  → context + explicit constraints
  → one deterministic evaluator ─ ALLOW / ASK / REJECT / UNAVAILABLE ─ Cultural Receipt
  → owner policy (rules, action ladder, sensitive choices, temporary permissions)
  → bounded lease bound to commitments of the choice and situation
  → drift suspends it; a fresh evaluation is required to resume (new epoch)
  → signed, selectively disclosed proof another agent can verify
  → doors: REST · TypeScript SDK · remote MCP · A2A · OAuth account linking

There is exactly one policy evaluator. M6–M9 wrap and extend the accepted M1–M5 evaluator; they do not replace it.

The subjective-action ladder

How far an agent goes with a choice that fits your taste, from least to most:

Rung	Meaning
SUGGEST	mention it as one idea
RANK	order several options
SHORTLIST	narrow to a few
ADD_TO_DRAFT	put it in a plan you can still change
PRESENT_AS_SELECTED	show it as the choice made for you

The owner sets the furthest rung an agent may take without asking, globally, per kind of choice and per agent. A request beyond it turns an ALLOW into an ASK the owner can answer once. Hard blocks, saved limits, UNAVAILABLE and group vetoes are never changed by the ladder. Legacy clients keep their behaviour: recommend = SHORTLIST, add_to_draft = ADD_TO_DRAFT, and presenting something as selected always asks until the owner opts in. See ADR 0024.

Decisions, Passport, policies, leases, proofs

• Decisions. Deterministic, with a captured Cultural Receipt. ASK is typed: an authority confirmation (your own rule asks first) can wait for your answer; a clarification (a fact is missing, such as a price) cannot be approved, it needs a new evaluation.
• Passport. Your private state behind opaque references; scoped grants; hashed credentials; account sessions.
• Policies. Versioned, simulated before publishing, with freshness per evidence class, per-agent and per-kind rules, extra care for sensitive kinds of choice, temporary permissions and counterfactual explanations. Widening needs a recent sign-in.
• Leases. Short, event-sourced permissions for one exact choice. They pause when your information, your rules, a share, a temporary permission, or the choice or situation itself changes, as far as TastePolicy is told (agents present the current candidate and context on verify and checkpoint; a change nobody presents cannot be seen). See ADR 0025.
• Proofs. Signed SD-JWT proofs with selective disclosure, holder-key binding, replay protection, a Token Status List and per-audience authority epochs. When authority ends, that epoch's proofs are invalid for good; resuming starts a new epoch and old proofs never return. A verifier that passes its own choice and situation learns whether the proof is about them.
• Timeline. /account/timeline shows every question, rule change, permission and shared proof in order.

Use it

REST (credential scopes: PASSPORT_READ, TASTE_EVALUATE, RECEIPT_READ):

curl -sS https://YOUR_ORIGIN/api/v1/evaluate \
  -H "authorization: Bearer $TASTEPOLICY_KEY" -H "content-type: application/json" \
  -d '{"idempotencyKey":"trip-2026-001","passportRef":"tp_…","requestedAction":"ADD_TO_DRAFT",
       "proposal":{"agentId":"my-agent","expectedStateVersion":1,
         "candidate":{"id":"…","name":"Hotel Lisboa","type":"destination"},
         "context":{"key":"trip","domain":"destination","price":{"amount":120,"currency":"USD"}}}}'

TypeScript SDK (server-side, in this repository; not published to npm):

const tp = new TastePolicyClient({ baseUrl, credential });
const r = await tp.evaluate({
  passportRef,
  idempotencyKey,
  requestedAction: "SHORTLIST",
  proposal,
});
if (r.decision === "ALLOW") {
  const lease = await tp.lease({
    idempotencyKey,
    evaluationRef: r.evaluationRef,
  });
  // before relying on it, present the choice as it is now:
  await tp.leaseVerify(lease.leaseRef, { context: currentContext });
}

• Remote MCP at /api/mcp (Streamable HTTP). Tool descriptions say when to call: before you select, rank, recommend, shortlist, add to a draft, present as selected, or otherwise continue a subjective preference-sensitive choice for a person.
• A2A 1.0 Agent Card at /.well-known/agent-card.json, JSON-RPC at /api/a2a; opt-in authority-lifecycle extension for leases, proofs and handoff (ADR 0026).
• OAuth 2.1 for hosted assistants (authorization code + PKCE S256, client ID metadata or dynamic registration, rotating refresh tokens, MCP-only audience). See ADR 0022.
• OpenAPI at /api/v1/openapi. Verifier at /verify and POST /api/attest/verify (no credential). Issuer metadata at /.well-known/tastepolicy-issuer; third-party issuers are inspected and explicitly trusted, never auto-trusted (ADR 0027).

Security and privacy

Credentials and tokens are stored hashed; OAuth tokens are audience-bound and 15 minutes long; provider calls never run under a database transaction or lock; policy widening requires a recent sign-in; rate limits are shared through PostgreSQL where they must hold across instances (ADR 0028). Agents learn the answer, a short reason and how far they may go; receipts show the choice, the cultural evidence behind the match and the deciding rule; proofs by default disclose no taste, name or account reference. Threat model and review record: docs/security/threat-model.md, supply chain.

Local development

Node.js 24 and npm. npm ci && cp .env.example .env.local && npm run dev. Without credentials the app runs and reports unavailable states; it never invents Qloo results. Set QLOO_API_KEY (server-only), QLOO_API_BASE_URL and QLOO_AFFINITY_SCALE to use Qloo (setup). Persistence needs DATABASE_URL; account features need BETTER_AUTH_SECRET and BETTER_AUTH_URL; proofs need TASTEPOLICY_PUBLIC_ORIGIN and TASTEPOLICY_ATTESTATION_KEY. Apply the schema with npm run db:migrate:all (ledgered, idempotent; ADR 0030). See .env.example.

Tests, conformance, load

npm run verify               # format, lint, typecheck, unit tests, build
npm run test:e2e             # Playwright incl. axe accessibility checks
npm run conformance:compatible   # tastepolicy-compatible-v1 (110 checks)
npm run tastebench:validate      # evaluation methodology fixtures
TASTEPOLICY_TEST_DATABASE_URL=postgres://… npm test   # adds real-PostgreSQL suites
npm run load:local           # controlled contention probe (not a capacity claim)

Live deployment

Evidence is labelled by kind in docs/evaluation/r6-hosted-acceptance.md: LIVE, HOSTED, CONTROLLED, SYNTHETIC, LOCAL, CI, NOT EXECUTED, BLOCKED. Nothing in this README claims a vendor assistant (ChatGPT, Claude, Gemini) works with TastePolicy; the product pages list what is available, what is on the roadmap and what is not implemented.

Current limitations

• Commitment-based drift covers what an agent tells TastePolicy; it cannot observe the outside world.
• One organization ceiling per deployment, set by the operator; no multi-organization model, SSO/SCIM or admin console.
• Sensitive choices are declared by the owner per kind of choice; content is not classified.
• The authenticated MCP/A2A request budget is per instance.
• Federation is explicit trust only: no registry, no revocation propagation between issuers.
• Hosted acceptance with real Qloo and vendor connectors is documented in the R6 record; see its status.
• TasteBench thresholds are experimental and not population-calibrated.

History of earlier milestones and acceptance records: docs/history, docs/evaluation. Licence: Apache-2.0. Contributions: CONTRIBUTING.md.