The careful one

Own stack. Own keys. Structurally contained.

taste is the hosaka fleet’s only PII-bearing service — by design. It runs in its own repository, its own database, and its own encryption keys. The rest of the fleet is a no-PII zone: crate, the hosaka map, and every other fleet service operate on music metadata only and hold no personal identifiers.

That separation is structural, not a policy. An incident in taste cannot reach the rest of the fleet — there is no shared database, no shared credential, no code path that crosses the boundary carrying personal data. A CI gate (required check on every change) asserts that no personal identifier ever leaves taste toward the fleet.

Infra: own encrypted database with hardware-backed keys decryptable only by the runtime role; WAF in front; alarms on anomalous key usage.

Recorded before the import. Receipted since July 2026.

Consent is recorded per source before any import queue entry is written — there is no import without a prior consent record. The consent ledger is part of your profile and is included in your DSR export.

Since July 2026, every consent-ledger action mints a receipt with the prefix rcpt_v1_. Receipts appear in your export. You can see exactly when you consented to each source and whether it has been withdrawn.

Receipt signing (a cryptographic signature over the receipt body so it is independently verifiable) is planned for a future stage and is not live yet.

DELETE /api/v1/me — everything, in one cascade.

Self-serve erasure is DELETE /api/v1/me with your bearer token. It runs the same irreversible two-class erasure the operator console uses: Class A personal data (sources, imports, resolutions, consent ledger, token) erased via a single database CASCADE; Class B non-personal aggregates (anonymous resolution statistics) retained.

The bearer token you called it with stops working the moment the CASCADE completes — the person record it was keyed to no longer exists. Not a flag, not a soft delete, not a queue — a cascade that runs to completion before the 204 returns.

This is rehearsed in CI. The erasure drill is a required check on every change: a test spins up a profile, calls DELETE /api/v1/me, and asserts that the token is immediately invalid and that no personal row remains. If the drill fails, the change does not merge.

One call. All of it.

The DSR export returns everything taste holds about you: connected sources, imported items, resolution results, and the consent ledger (including rcpt_v1_ receipts). There are no separate export tiers — one call, all of it.

Export and erasure are rights, not features. They are implemented as API endpoints and tested in CI because that is the only way to be confident they work when needed.

In memory, then gone.

When you upload a screenshot or PDF — a Bandcamp purchase history, a listening export, anything via the capture flow — the image bytes are read into memory, run through OCR extraction, and then discarded. The original image is never written to a database column, never written to a temporary file, never stored anywhere.

The zero-write property is asserted by a test. If a code change causes the image to be written to disk at any point in the pipeline, the test fails and the change does not merge.

The extracted candidates (artist names, release titles, track names) land in a pending state. Nothing enters your profile until you review and confirm the batch — you see what was extracted before it is resolved. Unticked rows are rejected and never reach resolution.

Limits: 15 MiB per file; PNG, JPEG, WebP, PDF accepted; unreadable files return an honest empty candidates list, never a 500.

taste_v1_ — 90-day sliding, read-only, revocable.

Bearer tokens use the prefix taste_v1_. They are hashed at rest — the plaintext is returned exactly once, at POST /api/v1/me/token (the code exchange step after connect), and is never retrievable again. If you lose it, connect again.

Scope is profile:read only — a token can read your profile; it cannot modify your data (that requires explicit actions like capture confirm or deletion). Expiry is 90 days, sliding: using the token resets the clock. Revoke a specific token (e.g., if a device is lost) via DELETE /api/v1/me/token with that token as the credential.

Every response on the /api/v1/me/* surface — including 401 errors — carries Cache-Control: no-store. Your profile can never sit in a CDN edge cache, even if the network infrastructure tries.

sub_v1_ — pairwise, derived, never stored.

Consumer apps (like NINSEI) never see your email or any persistent cross-app identifier. Instead, the token exchange response contains a pairwise pseudonymous subject — prefix sub_v1_ — that is HMAC-derived from your identity and the consuming app, on the fly.

The same person has a different sub_v1_ in every consumer. Two apps cannot correlate their user bases via taste identifiers — that correlation is impossible by construction, not by policy. The derived value is returned to the consumer and used as their per-user primary key; taste does not store the derivation output.

Email is never an account key. taste uses magic-link email for first-party sign-in (early access while in dub-plate); it is a delivery channel for the link, nothing more.

Scene chips describe artists, not you.

taste holds no user location data. The geographic scene chip on a recommendation row (a suggested artist might carry a “Glasgow” chip) describes where that artist plays and has been documented — sourced from the hosaka map’s 448 scene areas — not where you are or where you want to go.

Any future “near me” or location-aware feature would require a separate, explicit consent decision — it is not built in, not planned for near-term, and not something taste would add silently.

No ads, no data sales, no trackers.

• No ads. taste has no advertising business. Your listening profile is not used for targeting.
• No selling or sharing of taste data. Your profile data is not sold, rented, or shared with third parties. Consumer apps receive only what you authorised via the connect flow, scoped to their sub_v1_ view.
• No cross-app profiles. Pairwise subjects ( sub_v1_) structurally prevent consumer apps from correlating their user bases through taste.
• No third-party trackers on this site. This marketing site carries no analytics scripts, no ad pixels, no social widgets.
• No server-side scraping of services that forbid it. Bandcamp enters taste only as your own screenshots or exports — taste never scrapes Bandcamp server-side. Services that require OAuth (like Spotify and Apple Music) are on the roadmap only if the ToS allows the use case; they are not live.

What a consumer app can reach is exactly the published surface — CORS allowlists and token scope enforce it. Read it at /contracts/v1.

If you are building a product on taste and want to understand these properties from an integration perspective, see For developers.