MusicList is our own public directory for Canada’s music industry. People can search artists, professionals, and companies, open a profile, follow its official links, and request a correction or ownership claim. This story follows that public journey and the implementation decisions behind it.
Help someone find the right record
Imagine a musician looking for a recording studio in British Columbia. A list of names is a starting point, but they still need to narrow the location, distinguish a company from a person, and reach a useful contact route. The search experience has to reflect those questions.
In the public product, we searched for “studio,” selected British Columbia, and limited the type to Companies. The results show a name, role, location, and trust label before someone opens a profile. The query, province, and type appear in the URL, so another person can return to the same search configuration.
The implementation keeps those filters, sorting, and pagination in URL parameters and resets the page when a filter changes. That makes the view shareable without pretending that its results are frozen: the catalog can change between visits. A saved search configuration and a permanent copy of its results are different promises.
Show what the listing is based on
We opened the 604 Studios result. Its profile identifies it as Sourced, says it was compiled from official public sources, and displays a last-checked date. It offers an official website link and a separate Sources & Provenance section. Someone can inspect the underlying public page rather than rely entirely on the directory’s description.
MusicList distinguishes basic unclaimed listings, sourced records checked against public information, and verified profiles confirmed by their owner. These states describe different evidence. A sourced profile does not establish that its owner has joined the product or endorsed every sentence. An owner verification badge does not make the information current forever.
The date matters alongside the badge. The captured profile was last checked on September 15, 2026; the screenshot was taken on October 11. We preserve both dates because observing the interface today is not the same as rechecking all of its source facts today.
A correction and an ownership claim are different jobs
A reader can notice an outdated fact without being entitled to control the whole profile. MusicList gives the profile separate actions for suggesting a correction and claiming ownership. That separation lets the product receive useful information while keeping the ownership question explicit.
Following Claim this profile carries the selected record into the claim form. The form asks for the person’s name, role, work email, and a way to establish their connection: a controlled social page, a public contact page, or an email domain matching the official website. It says claims are confirmed through official channels before a profile is handed over.
We inspected that route without submitting a claim. In the implementation, issuing an ownership invitation requires an authorized operator, recorded verification evidence, an eligible claim, and a matching entity. Invitation issuance and the owner workspace also have feature gates. Those checks are implementation evidence; this read-only review does not establish the current live configuration or demonstrate a completed ownership transfer.
Publication needs checks before a record becomes public
Catalog maintenance has a second boundary: information gathered during enrichment should not become a public profile just because a draft exists. The artist publication code checks a candidate’s publication readiness before constructing the public record. The scoring implementation includes evidence coverage, unresolved conflicts, location, freshness, translation validation, and approval of the public payload.
Approval can follow a recorded automation policy; it is not accurate to say that every candidate is manually reviewed. The useful distinction is between collecting information, establishing whether it meets a defined publication policy, and publishing the permitted fields. A generated description alone does not establish any of those facts.
The artist publisher assigns Sourced status to the resulting record. Passing publication checks therefore does not grant owner verification. Keeping those meanings separate lets the directory grow through public research without presenting that research as an ownership claim. We reviewed this boundary in committed source; we did not publish a candidate or verify every deployed enrichment process.
Keeping a catalog available creates a freshness tradeoff
A directory needs to remain usable when an update source is unavailable. The implementation can serve a bundled public snapshot and apply more recent changes when they are available. It also reads a single profile separately, rather than require every profile visit to fetch the whole catalog.
That approach preserves a browsing path, but it adds a question the interface has to answer: how recent is the information being shown? During our initial unfiltered search, the live page displayed “Directory updates are temporarily unavailable. These listings may be out of date.” The warning was absent in the later filtered view. That observation does not establish that the underlying issue was fixed; we did not diagnose the production service.
Duplicate-looking records were also visible: two Afterlife Studios entries appeared with different profile URLs and location wording. We have not established whether those records should be merged. They show why a growing catalog needs entity reconciliation as well as publication checks. A valid individual record does not prove that the catalog has no duplicates.
What this public product establishes
The public journey demonstrates filtering a directory, opening a sourced profile, following its evidence, and reaching a claim form tied to that record. Source review establishes implemented publication checks and ownership-invitation boundaries. These are concrete product decisions we can discuss when a custom application needs discovery, permissions, and maintained records.
This story does not establish adoption, time saved, successful ownership transfers, or perfect catalog accuracy. The initial update warning and duplicate-looking results remain part of the evidence. A screenshot records one moment in a changing public product.
For another application, the work would begin with its own records, users, and responsibilities. We would ask what makes a result useful, what its status actually proves, how a correction is reviewed, and who maintains it after launch. Those decisions shape the screens and integrations before adding an assistant or further automation.
Where this fits a custom software project
Directories, supplier catalogs, staff portals, and knowledge libraries share a similar job: help someone find a record, understand its reliability, and know how it can change. We would start with one real record and follow that journey.
- Discovery
- What people search for, which filters narrow the result, and what they need to do after finding it.
- Evidence
- Which facts have sources, when they were checked, and how missing or stale information is shown.
- Ownership
- Who can propose a change, who can approve it, and what establishes the right to control a record.
- Maintenance
- How updates arrive, how duplicates are resolved, and how people continue when a connected system is unavailable.
See the product for yourself.
We checked the public product pages and the implementation behind the workflows on October 11, 2026. These links let you explore the public experience.