The older surface

The older tools,
and what happens to them.

Studio grew out of an earlier tool, and the earlier tool is still running. The code says so in one line, and this page exists so that the line is somewhere a customer can read it rather than somewhere only we can.

See all fifteen, and the decision for each Read the product docs

Fifteen old routes, fifteen decisions: eight keep answering, one migrates, three are absorbed into the pipeline, two are promoted to a product feature, one is deprecated with no replacement, and one retires on purpose.

The line this page is built on “a Flask blueprint inside the existing app; every old route stays as it was.” That is the first line of the Studio's own web module, written when the new surface was added to the old application rather than replacing it. It is a promise about compatibility, and it is the reason a link somebody bookmarked two years ago still resolves today.

And the older project model underneath it Fifteen legacy routes have no home in the new interface. Not because they are broken, but because the new information architecture does not have a screen for them. Each one therefore needed a decision rather than being left to rot: keep it, migrate it, absorb it, surface it, or retire it and say so.

What the decisions add up to

Nothing was deleted. Five things changed shape.

The count is exact: fifteen routes, fifteen decisions. Eight keep doing exactly what they do now, one migrates onto the new project model, three are absorbed into the pipeline, two are promoted to a product feature, and one is deprecated because it has no equivalent.

Kept Eight routes keep answering exactly as they do now. Six of them are unlisted — moved under settings or left as an API with no screen — because they are machine-facing or owner-facing rather than customer-facing. unlisted, not removed

Migrated The project endpoints move onto the Studio's own project model. The old JSON is imported once, and the one pair of endpoints with no equivalent — attaching a media range to a project — is documented as deprecated rather than quietly dropped. one import, then the new model

Absorbed Transcription, preview rendering and export are no longer things you ask for. They are stages that run on their own inside every job, and the old routes stay as aliases so existing scripts and links keep working. the work moved, the URLs did not

Surfaced One family of routes was a genuine product feature hiding as plumbing: finding stock footage for a shot with no footage, and generating an image when there is none. It gets a name and a place in the interface instead of a URL nobody knew about. the AI media finder

All fifteen

The route, what it did, and the decision.

Scroll sideways on a phone. Every decision below is the decision recorded in the product inventory — this page is a rendering of that table, not a summary of it.

The fifteen legacy routes, what each one does, and the decision taken for each
Route	What it did	Decision
`GET /`	The old “Video Editor with Transcript” page — the whole product on one screen, with the transcript down one side.	retired It becomes the new landing page. The classic editor does not disappear: it moves to `/classic`.
`GET /diagnostics`	A diagnostics page: server state, pipeline health, the things an owner looks at.	kept, unlisted Moves to `/settings/diagnostics`, visible to the owner only.
`/projects*` list, create, get, update, delete, duplicate	The older project model: a JSON document per project, created and duplicated over HTTP.	migrated The Studio's own project model supersedes it and the old JSON is imported once.
`/projects/<id>/assets` POST and DELETE	Attach and remove media ranges on a project — the older way of saying “use this part of that file”.	deprecated The asset-range model has no equivalent in the new pipeline and is documented as deprecated rather than replaced.
`/ingest-brief` `/context/<id>` `/plan-contextual-media`	The machine-facing intake: take a brief, store it as a context, and plan media from that context.	kept as an API, hidden from the UI This is how a machine briefs the Studio. The new navigation adds a single Brief entry that posts to `/ingest-brief`.
`POST /transcribe`	Transcribe a recording, on request, as a separate step.	absorbed It is the “Hear every word” stage of the pipeline and now runs automatically. The route stays for existing scripts; there is no screen for it.
`POST /generate-preview` `POST /export-video`	Render a preview, and export the finished video.	absorbed Replaced by the job's own video and compare endpoints, and kept as aliases so old links do not break.
`POST /auto-generate-media` `POST /auto-generate-media-one`	v0.2 AI media: turn a keyword into a stock video, and fall back to a generated image.	surfaced as a product feature The AI media finder — how it finds and generates visuals.
`POST /jobs/ingest-folder` `POST /jobs/<id>/run` `POST /jobs/<id>/retry-low-confidence`	The older job runner: ingest a whole folder, run the job, re-run only the parts the transcription was unsure about.	kept as an API Folder ingestion is the agency workflow and belongs on Studio Business — what a client folder does.
`GET /media-status` `GET /health` `GET /test-ai-generation`	Status, health and a test hook for the AI generation path.	kept, unlisted They feed the status page and the owner's overview rather than a customer screen — what they report.
`GET /media/<path>`	Serve a media file out of a project directory.	kept, unlisted Still the file-serving path; no interface of its own.

Route list and decisions — FEATURE-INVENTORY.md §12 and §14. The inventory groups the CRUD endpoints, the two asset endpoints and the three job endpoints into families; this table keeps those groupings and counts them the same way, which is why eleven rows hold fifteen routes.

The one that becomes a real feature

When a shot has no footage, Studio goes and finds some.

Two routes were doing something customers would pay for and nobody could find them. They get a name in the interface instead: the AI media finder.

It looks for stock footage first The words spoken around the shot become a search, and the search runs against Pexels for a clip that fits what is being said. A real clip of a real thing, used without being filmed by you. Pexels stock video · app.py — /auto-generate-media

Only then does it generate an image If the search finds nothing usable, an image is generated with Pollinations and used as that shot's visual. It is the fallback, not the first move, because footage of the real thing beats a picture of it. Pollinations image · fallback only

And it is labeled as generated A generated image is generated, not filmed, and the interface says so on the shot. You can always tell which visuals came from your camera, which were found, and which were drawn. marked in the decision log, per shot

Why this was invisible, and why it should not have been

It was reachable only by calling two POST endpoints with a keyword. Genuine capability, no door. It is now the answer to the most common dead end in editing — the sentence that needs a picture and has no footage behind it — and it is the same engine that already existed.

Why nothing was deleted

Because the endpoints are the contract, not the screens.

Every one of these routes is somebody's integration, somebody's bookmark or somebody's cron job. A redesign that breaks a single endpoint is not a redesign, it is an outage with better typography.

Three rules decided every row of the table above. One: an existing link keeps working — if a URL is genuinely being replaced, it becomes an alias rather than a 404. Two: an old route the new interface cannot show becomes an API and stops pretending to be a page, which is honest about who it is for. Three: a route that is only reachable by calling it is either given a screen or documented — and the AI media finder was the one that earned a screen.

The cost of this is real and worth stating: the old surface has to keep being tested even though almost nobody looks at it. That is the price of never breaking a customer's link, and it is cheaper than the support conversation that follows a broken one.

“a Flask blueprint inside the existing app; every old route stays as it was” — studio/web.py:1 · the migration rule for the project model — FEATURE-INVENTORY.md §14

What is being retired, and when

Exactly one route: GET /. And “retired” here means reassigned rather than switched off — that address becomes the marketing landing page, which is what a visitor typing the bare domain should get.

Retired with a replacement: GET /. The classic editor is preserved at /classic, so nothing a customer used is taken away.
Deprecated, no replacement: /projects/<id>/assets. The only route with no equivalent — stated rather than hidden.
Everything else: still answering, under the same path or as an alias, on the day this page goes live.

The honest part about timing

This is a design decision with a date still to be set. The retirement of GET / lands with the new landing page, and the aliases ship in the same release so no window exists in which an old link fails. Until that release, every route on this page behaves exactly as it does today — including GET /.

If one of these routes is load-bearing for you, tell us which one and it gets a migration note rather than a redirect.

The old tools are documented. The new ones are free to try.

Your first 30 minutes of footage cost nothing, on the new surface or through the API. If you are still on the earlier tool, an account can import your projects once and you keep working — the old JSON comes across rather than being abandoned.

Start free Read the docs

Already have an account? Sign in and check the status page, which is fed by the same health routes listed above.

Where to go next

The AI media finder Folder ingest for agencies What the health routes report Where your footage goes