Velveteen is our own public music platform for artists, labels, and teams. Its catalog connects releases, tracks, artists, and contributors. We checked the public product tour and committed readiness and submission code to explain how a draft becomes reviewable, where an assistant can help, and what a successful check does not establish.
A catalog is a set of relationships.
A release contains tracks, but the people attached to it can appear across many releases. Artwork, identifiers, contributor details, and dates have different owners and purposes. Flattening everything into one upload form would make those relationships harder to maintain.
The public catalog tour groups releases and displays live, pending, and draft states. Its artwork, counts, stream figures, and statuses are illustrative. They show the interface’s organisation; they are not evidence of catalog performance or successful distribution.
A relationship matters when someone edits it. Changing a track’s metadata should not require retyping an artist profile. Equally, an artist appearing on a release does not automatically give every team member permission to submit that release. The data model and the action boundary need to work together.
Readiness explains what is missing.
The committed validator returns release-level errors and track-level errors separately. It checks required release information, artwork presence, artist relationships, identifiers, date relationships, outstanding invitations, and track requirements. The result includes a readiness flag and an error count.
That structure lets a screen distinguish “this release needs a date” from “this track needs information”. A useful correction has a location, a reason, and an owner. A red badge without those details tells someone that work remains without helping them finish it.
These checks enforce the application’s current rules. They cannot establish the truth of every supplied credit or ownership declaration, or guarantee acceptance by an external music service.
Checking is different from submitting.
The submission route checks the signed-in user, release permissions, account requirements, and the release’s eligible state. It then performs server-side readiness checks. A blocked request returns an explanation instead of moving the release forward.
When those checks pass, the route calls a database transition to move the release to pending review with submission evidence. That is a platform review state. It does not mean that the release is live, that every external destination has accepted it, or that a pitch has received an editorial placement.
The distinction gives the workflow several meaningful finish lines: the draft is complete, it has been submitted, it has been reviewed, and a downstream delivery has been confirmed. The correct one depends on the job a person is trying to finish.
An assistant needs the same boundaries.
Vee’s committed tools distinguish validating a release from submitting it. Their descriptions explicitly treat “check”, “review”, and “is it ready” as readiness requests; submission is a separate action. That is a useful product decision because ordinary conversational language can otherwise conceal a consequential change.
The screenshot below is the public site’s scripted conversation, not a live exchange we performed. We inspected the tool definitions and validation paths separately. The transcript’s claims about audio, updates, and store confirmations are not demonstrations of those actions.
The product lesson is a checkable handoff.
For a custom application, the transferable pattern is to keep related records connected, return actionable blockers, and require the server to check an action when it happens. An assistant can explain the work while the application retains control of its state.
We inspected committed implementation and public illustrations, not a live artist’s draft-to-delivery journey. The public site also describes its iOS companion as private beta; this story covers the web workflow and makes no App Store availability claim. We have not measured fewer errors, faster release preparation, or artist earnings.
What should “ready” mean in your application?
Start with the state transition and the evidence needed to allow it.
- Records
- Which related records must agree before the next action?
- Blockers
- What can a person correct, and where do they make that correction?
- Authority
- Who can request the transition, and what must the server recheck?
- Outcome
- Does the new state mean reviewed, delivered, or actually available?
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.