The Status Set

What you'll learn

• Why m18t uses one shared, ordered status set across every kind of entity.
• The ten seeded statuses and what each one means.
• How per-type display aliases let "Production" read as "Published" on a blog post and "Indexed" on a sitemap.
• What m18t does and does not enforce about moving between statuses.

The concept: one shared vocabulary

Most tools let every team invent its own statuses. Marketing makes a column called "Editing", engineering makes one called "Doing", support makes one called "Investigating". They all describe the same underlying idea — active work is happening — but the software can't tell, so it can't roll progress up across them.

m18t takes the opposite default. It seeds one ordered status set and uses it everywhere: a blog post, a PD feature, an asset, an event, a cron job — they all draw from the same statuses table. Because the set is shared and ordered, m18t can compare across entity types and roll child statuses up to parents (a feature can show the spread of its models' statuses, a content type can show the spread of its pieces').

The set is opinionated, refined over years of running real product teams. It's also the default, not a cage — you can add your own statuses if you genuinely need one (see the FAQ). The recommendation is to live inside the shared ten first, because the shared vocabulary is what makes cross-entity rollups meaningful.

The ten seeded statuses

The set is ordered, lowest to highest, from "being removed" to "live". The order is what lets m18t sort and roll up — it isn't a 0–100 scale, just a defined sequence.

1. Deprecate — being removed, unpublished, or scrubbed. (Lowest in the order.)
2. Default — the base state of something that exists but has no active lifecycle yet.
3. Icebox — acknowledged but parked. No active work planned. (Often shown as "Backlog".)
4. Planning — being scoped, researched, or outlined.
5. Idle — planned, but sitting in a queue. (Often shown as "Archived".)
6. To Do — next up; waiting for someone to start.
7. Doing — active, hands-on work.
8. Done — the work is finished but not yet validated or reviewed.
9. Testing — being reviewed, QA'd, or scheduled for publish.
10. Production — live, published, or deployed. (The top of the order.)

Per-type display aliases

A rigid shared set creates a wording problem: a marketer doesn't call a published blog post "Production", and a sitemap that's live isn't "Published", it's "Indexed". m18t solves this with per-type display aliases baked into the status set.

Each status carries an alias per content type. The underlying status stays the same; only the label shown changes:

• For a blog post, Production displays as Published and Testing as Scheduled.
• For a sitemap, Production displays as Indexed and To Do as Pending.
• For a vacancy, Production displays as Hired and Doing as Open.

So the same ordered status drives rollups and filtering, while each surface speaks its own language.

Managing statuses

The status set is managed at Statuses Configuration in the Studio sidebar (/studio/config/statuses). There you can see each status with its color, slug, sort order, and how many content, asset, and event records currently use it. You can edit a status, toggle it active/inactive, and create a new one with Create Status. The core anchors — Planning, Deprecate, and Production — are protected from deletion because too much of the platform depends on them.

FAQ

Can I add my own status? Yes. Use Create Status on the Statuses Configuration page. The shared ten are the recommended default because cross-entity rollups assume them, but the set is extendable when you have a real need. Planning, Deprecate, and Production can't be deleted.

Does m18t stop me from skipping statuses? No. There's no enforced state machine today — any transition is allowed. The status set is a shared vocabulary and an ordering, not a gate. A legal-transitions layer is on the roadmap, not live.

Why does the same status show different words in different places? That's the per-type alias system. The status is identical underneath; the displayed label is type-specific (e.g. Production → "Published" on a blog post, "Indexed" on a sitemap).

How does this relate to publishing my content? Setting a piece to a "live" status does not by itself push it anywhere — publishing is a separate, manual action. See Scheduling vs. Publishing.

What's next

• The Unified Content Table
• Scheduling vs. Publishing
• The Product Development Concept