Cleaning the ALIVE CAST route surface
Why the user-facing route moved to /alive-cast while the internal subject model remains stable for ALIVE ME and ALIVE CAST.
The public route language becomes clear while the internal subject model stays general enough for ALIVE ME and ALIVE CAST.
The public language should be clear. The internal model should stay general enough to scale.
The naming decision
XALIVE now uses two user-facing lines: ALIVE ME for the user's own self and ALIVE CAST for another self created from a person, character, artist, IP, brand, or historical figure.
Older names such as ALIVE plus variants were removed from the user-facing surface. The site, app shell, documentation, and creation flow now use ALIVE CAST consistently.
This matters because the product is not only a prototype anymore. The names have to survive the landing page, authenticated app, investor materials, onboarding, settings, source review, partner conversations, and future mobile surfaces. A name that works in one menu but breaks in the business model is not stable enough.
ALIVE ME and ALIVE CAST are now the two public-facing lines. They are easy to explain, visually distinct, and flexible enough for personal, creator, studio, brand, and historical use cases.
Why subject remains internal
Internally, both ALIVE ME and ALIVE CAST are still subjects. Renaming every database and API concept to match a marketing label would make the system less flexible.
The cleaner structure is to keep subject as the domain model, keep Builder as the workflow, and expose /alive-cast as the canonical public route. The old /cast route remains only as a compatibility redirect.
This is the right split between brand and architecture. The database should describe the durable object. The UI should describe the thing the user understands. A subject can be self, cast, private, published, rights-cleared, paused, or erased. That generality is useful.
The route layer is different. URLs are user-facing. They appear in browser history, shared links, QA scripts, documentation, analytics, and support conversations. For that layer, /alive-cast is clearer than /cast because it carries the full product term.
Compatibility without confusion
The old /cast route is not deleted immediately. It redirects to the canonical ALIVE CAST surface so existing references do not break during development. The same idea applies to API wrappers: old endpoints can remain thin compatibility layers while the canonical implementation lives under /api/alive-cast.
This lets the project move forward without a risky all-at-once rename. The public language becomes clean now. Internal consumers keep working while the team gradually moves tests, scripts, dashboards, and documentation to the new route.
- /alive-cast is the canonical page route.
- /api/alive-cast is the canonical API route.
- /cast remains a legacy redirect only.
- The internal subject model remains shared by ALIVE ME and ALIVE CAST.
What this improves
The cleanup reduces ambiguity across the Web UI, Main runtime, and OME channels. When someone says ALIVE CAST, it now means the other-self line. When a developer sees subject, it means the underlying domain model. When a route starts with /alive-cast, it is a user-facing call or relationship surface.
This also helps future mobile and partner work. A clean public route can become a stable product path. A general internal model can support more subject types without forcing another naming migration.