Query "who's emerging" — not twelve incompatible sources.
16 independent signal kinds fused onto one identity primitive. ~2.2M artist clusters. Keyless preview, full dossiers behind the key.
The identity primitive: cluster_id
Every artist, label, and song in hosaka is a cluster, keyed by cluster_id — a bytea hash produced by pe-norm-v1. It is the sole identity key across every table, gate, and product in the system.
MusicBrainz IDs, Discogs IDs, and other external identifiers are nullable annotations on a cluster, never the key. You can join out to them when you have them. You should not build logic that assumes they exist, and you should never treat them as the spine.
That's not a compliance footnote — it's the point. Requiring an external ID before an artist "counts" filters out exactly the artists you'd want a detection system for: the ones an external catalogue hasn't caught up to yet. The unresolved tail — clusters with no MusicBrainz or Discogs ID — is where the freshest talent lives.
Our own genre lens is built cluster-native for this reason: 4,334,514 rows across 845,889 clusters, resolved with no dependency on MB or Discogs.
If you're integrating: resolve to cluster_id first, treat every external ID field as optional enrichment, and don't gate on ID presence. Note that cluster_id is nullable in the keyless preview — it's present when hosaka has resolved the artist to a cluster, absent when the name matches but resolution is still pending.
What a dossier draws on
A cluster's dossier is built from convergence across independent source kinds — currently 16: MusicBrainz releases, radio airplay, press, editorial mentions, DJ sets, RA bookings, underground retail, Bandcamp, festivals, SoundCloud reposts, RA reviews, general retail, RA podcasts, Shazam, live-demand signals, and RA recommended. No single source kind drives a verdict; the signal is in how many, and which, independent kinds line up on the same cluster.
We also carry a detection-time ledger — a bitemporal record of not just what we know about a cluster but when we came to know it (3,161,405 rows). This is what lets a dossier answer "was this visible early" rather than only "is this true now," and it's why we anchor everything to publish/observation dates rather than our own ingest timestamps — ingest timing is a crawler-ops artifact, not a signal about the artist.
See /method for the full source-kinds table with per-kind counts and methodology.
The API: crate
Crate — the consumer-facing product in the hosaka fleet — exposes cluster-keyed dossiers through /api/v2/aura. You request an artist or label by cluster_id and get back the merged view: the convergent signals behind it, the detection-time trail, and the identifiers we've been able to resolve out to (MB, Discogs, etc., where they exist).
There is also a keyless preview endpoint — GET /api/v2/preview/artist?q={name} — that requires no API key and allows 100 requests per hour per IP. It returns a capped subset of the dossier: emergence tier, an arc of up to 6 dated tier transitions, up to 3 booked_with co-appearances, and a press count. cluster_id is included when resolved (nullable — see above). It is meant for exploration and agent tooling; production integrations use the keyed /api/v2/aura surface.
Quickstart
No sign-up required for the preview endpoint. Run this to get a live dossier fragment:
curl -sL 'https://crate.hosaka.fm/api/v2/preview/artist?q=four+tet'Response shape (truncated)
The endpoint returns JSON. A real response for "four tet" (as of 2026-07-07):
{
"object": "artist.preview",
"present": true,
"display": "Four Tet",
"cluster_id": null,
"resolved_via": "discogs",
"emergence_tier": "steady",
"arc": [
{ "year": 1996, "tier": "press", "label": "first press mention" },
{ "year": 1998, "tier": "bandcamp", "label": "first release" },
{ "year": 2001, "tier": "radio", "label": "first radio airplay" },
{ "year": 2001, "tier": "booking", "label": "first festival" },
{ "year": 2013, "tier": "soundcloud","label": "first SoundCloud repost" },
{ "year": 2013, "tier": "booking", "label": "booked w/ Bill Patrick" }
],
"arc_truncated": true,
"booked_with": ["Ben UFO", "Floating Points", "Pearson Sound"],
"press_count": 50,
"note": "Education preview — a capped subset of the artist dossier. The full ~24-facet contract lives at GET /api/v2/artist/{key} (keyed).",
"generated_at": "2026-07-07T15:10:59.044Z"
}SDK
The typed SDK for production integrations: typed responses, auth helpers, retry/rate-limit handling. Full reference at crate-sdk.hosaka.fm.
The source is public and tagged at github.com/hosaka-fm/crate-sdk. There is no package registry entry — build it from source:
git clone https://github.com/hosaka-fm/crate-sdk.gitCLI — agents-first
The CLI is built for agent pipelines: piped stdout is untransformed API JSON, diagnostics go to stderr, and every exit code is defined (0 ok · 1 usage · 2 auth · 3 invalid · 4 rate-limited · 5 server · 6 network · 7 config).
The source is public and tagged at github.com/hosaka-fm/crate-cli. There is no package registry entry — build it from source, then:
# paste-ready agent handbook:
crate robot-docs
# machine contract JSON:
crate capabilities
# auth + health + next commands:
crate triage
# keyless preview (no key required):
crate preview "four tet"How consumption works
Hosaka runs on a producer-publishes, consumer-integrates contract model: each repo owns its own schema, and no repo writes into another repo's tables. If you're building against hosaka data, you read from a published surface — you don't get, and don't need, write access into the producer.
Published surfaces are pinned in contracts/published.yaml, one entry per table, each carrying its primary key, columns, and any invariants the producer guarantees. There are 67 published surfaces today. Pin your integration against the contract file's version, not against inferred schema — the contract is the source of truth, and changes to a published table land in the same PR as the contract update, so drift is visible at review time instead of at your integration's runtime.
Metered tiers
Metering is built into crate's API layer, and billing is scaffolded on top of it. We're not publishing price tiers yet — that's still being finalized, not a detail we're withholding for effect. If you need production access ahead of published pricing, talk to us directly rather than assuming a rate card exists.
Contact: mailto:hello@hosaka.fm
Where this stands
The substrate side of this is deep and live: ~2.2M distinct artist clusters on the appearance spine, drawn from the 16 source kinds above, with a working convergence signal — within the 119,095-cluster emergence cohort, multi-source overlap runs from 13,352 clusters at 2 independent source kinds through 1,733 at 3 and 257 at 4, down to 40 at 5+ — the highest-conviction cases. That part is not a prototype.
The commercial side — metered API access, billing, pricing tiers — is earlier: built and scaffolded, not yet running at repeatable revenue. If you're evaluating hosaka as an integration target, evaluate the data; ask us directly about commercial terms.
Production access: https://github.com/hosaka-fm · SDK docs · /agents for agent integration