Status types track lifecycle

Everything you manage is going somewhere

Open any tool you use to manage work. Look at the columns, the labels, the dropdown menus. You'll find statuses everywhere: "To Do," "In Progress," "Done." "Draft," "Under Review," "Published." "Pending," "Approved," "Rejected." These aren't arbitrary labels. They're instances of one of the most powerful classification patterns in existence: the status type.

A status type assigns an object to a position within a defined lifecycle. Unlike a category that describes what something is, a status type describes where something is in a process of becoming. The blog post is still a blog post whether it's a draft or published. The order is still an order whether it's confirmed or shipped. The identity stays fixed. The status moves.

This distinction matters because status types don't just describe — they constrain. A well-designed status system tells you not only where an object is, but what can happen to it next. And that constraint is where workflow lives.

The mathematics underneath: finite state machines

Status tracking has a formal foundation that predates software. In the theory of computation, a finite state machine (FSM) is a mathematical model defined by a finite set of states, a set of inputs, a transition function that determines the next state given the current state and input, and an initial state. The machine is always in exactly one state at a time, and transitions between states follow deterministic rules.

Two variants emerged in the 1950s. A Moore machine, named after Edward F. Moore, produces output based solely on its current state — the output is a function of where you are, not what just happened. A Mealy machine, named after George H. Mealy, produces output based on both the current state and the current input — the output depends on both where you are and what event triggered the transition.

This distinction has practical implications beyond computer science. When you check the status of a package — "shipped" — and that status alone tells you what to expect (it's in transit, you wait), that's Moore-like behavior. When a customer service agent looks at the same status but responds differently depending on why you're calling (lost package vs. delivery estimate), that's Mealy-like behavior. The state is the same, but the response depends on the input.

In 1987, David Harel extended flat state machines into statecharts — a visual formalism that added hierarchy, concurrency, and communication to state diagrams. Harel's statecharts could represent complex systems where states contained sub-states, multiple state machines ran in parallel, and transitions could broadcast events across components. His paper in Science of Computer Programming became one of the most cited works in software engineering, and statecharts were later incorporated into UML, the industry-standard language for modeling software systems.

The takeaway for personal epistemology: status tracking isn't a convenience feature bolted onto project management tools. It's a formalization of how processes actually work — with states, transitions, and rules about what's allowed to happen when.

Status types in the wild

Status types appear in nearly every domain humans have organized. The patterns repeat because the underlying structure is universal.

Software development: Kanban and workflow states

The simplest modern workflow system is the Kanban board: three columns labeled "To Do," "In Progress," and "Done." Taiichi Ohno developed kanban at Toyota in the 1950s as a scheduling system for just-in-time manufacturing. Each card (kanban) represented a unit of work, and its position on the board represented its status.

Today's implementations are more nuanced. Jira, the dominant project management tool in software teams, uses three status categories — To Do, In Progress, and Done — but supports arbitrary custom statuses within each category. A typical software team might define: Backlog, Selected for Development, In Progress, In Code Review, QA Testing, and Done. Each status has valid transitions. You can't move a task from Backlog directly to Done without passing through the intermediate states, because each intermediate state represents work that actually needs to happen.

The constraint is the point. If a developer marks something "Done" that never passed through "Code Review," the status system flags the violation. The lifecycle becomes executable.

E-commerce: order fulfillment states

E-commerce platforms implement some of the most carefully designed status systems in production software. A typical order lifecycle moves through: Pending (order placed but not confirmed), Confirmed (payment validated, order accepted), Processing (items being picked and packed), Shipped (handed to carrier, tracking number generated), Delivered (confirmed at destination), and potentially Returned or Cancelled.

Each transition triggers specific operations. Confirmation triggers payment capture. Shipping triggers tracking notification. Delivery triggers the review-request email. Cancellation triggers refund processing. The status isn't a label — it's a trigger for the next action in the pipeline.

There's also a subtlety here: Partially Fulfilled. When an order contains items from multiple warehouses, some ship before others. The system needs a status that represents an in-between state — not fully shipped, not still processing. This is where naive binary status models (ordered vs. delivered) break down. Reality demands the intermediate states.

HTTP: the web's status language

HTTP response status codes, defined in the original HTTP specification and refined through RFC 2616, organize the entire web's communication into status categories. The 1xx codes (Informational) indicate a request is still being processed. The 2xx codes (Success) indicate the request was fulfilled — 200 OK, 201 Created, 204 No Content. The 3xx codes (Redirection) indicate the client needs to take additional action. The 4xx codes (Client Error) indicate the request was invalid. The 5xx codes (Server Error) indicate the server failed.

The design is instructive because it shows how status types encode responsibility. A 4xx status tells the client: the problem is on your end, fix it and retry. A 5xx status tells the client: the problem is on our end, you did nothing wrong. The status code doesn't just describe what happened — it assigns accountability and prescribes next action.

HTTP 202 Accepted is particularly interesting: it means "I received your request and it's valid, but I haven't finished processing it yet." This is a status that represents a legitimate in-between state — acknowledged but incomplete. Many real-world processes need this same concept, and most personal tracking systems lack it entirely.

Document management: the publishing lifecycle

Content management systems formalize the document lifecycle into explicit status types. A common pattern: Draft (author is writing, content is incomplete and private), In Review (submitted for editorial or peer review), Approved (review passed, awaiting publication), Published (live and visible), Archived (no longer current, preserved for reference).

The Gang of Four State design pattern, published in Design Patterns: Elements of Reusable Object-Oriented Software (1994), formalizes this approach in software. Each state is represented as an object with its own behavior. A Document in Draft state allows editing but not publishing. A Document in Published state allows archiving but not editing. The operations available to you change depending on the current state. In their example, the publish method in the Draft state moves the document to moderation, while the same method in the Published state does nothing or archives. The state object controls what's possible.

This is the deepest insight about status types: they don't just track where something is. They define what you're allowed to do next.

Status as a theory of development

Status types aren't unique to engineering. Developmental psychology uses them to model human growth.

Jean Piaget's theory of cognitive development (1936) proposed four stages: Sensorimotor (birth to ~2 years), Preoperational (~2-7 years), Concrete Operational (~7-11 years), and Formal Operational (~11+ years). Each stage represents a qualitatively different way of thinking about the world. A child in the Preoperational stage cannot perform conservation tasks (understanding that quantity doesn't change when shape does). The stage defines what cognitive operations are available — just like a status type defines what transitions are valid.

Erik Erikson's psychosocial development model (1950) extended this to the entire lifespan across eight stages, each defined by a central conflict: Trust vs. Mistrust, Autonomy vs. Shame, Initiative vs. Guilt, Industry vs. Inferiority, Identity vs. Role Confusion, Intimacy vs. Isolation, Generativity vs. Stagnation, and Integrity vs. Despair. Resolution of each conflict determines the "output" at each stage — a pattern that maps directly onto Moore machine behavior, where the current state determines what the system produces.

The controversial aspect of stage theories is the implied linearity: you pass through stages in order, and you don't skip. Piaget's critics have shown that development is often more fluid than the stage model suggests — children may show formal operational thinking in some domains while remaining preoperational in others. This mirrors a real problem in status tracking: the assumption that all objects follow the same linear path through the same sequence of states. Sometimes they don't. Sometimes they need parallel tracks or conditional branches. Harel's statecharts were invented precisely to handle this kind of complexity.

The AI lifecycle: status types at industrial scale

Modern AI and machine learning systems implement one of the most rigorous status-tracking pipelines in existence. IBM defines the machine learning pipeline as a series of automated steps covering data collection, preprocessing, model training, evaluation, deployment, and monitoring.

Each stage has strict entry and exit criteria:

• Data Collection: Raw data gathered from sources. Exit criterion: sufficient volume and coverage.
• Data Preprocessing: Cleaning, normalization, feature engineering. Exit criterion: validated data quality, no missing values in critical fields.
• Training: Model learns from prepared data. Exit criterion: convergence metrics met, loss below threshold.
• Evaluation: Model tested against held-out data. Exit criterion: accuracy, precision, and recall meet minimum thresholds.
• Deployment: Model serves predictions in production. Exit criterion: latency and reliability SLAs met.
• Monitoring: Continuous observation for drift, degradation, and anomalies. Trigger: performance drops below threshold, loop back to data collection or training.

The monitoring stage is particularly instructive because it introduces a cyclic transition: when performance degrades (data drift, concept drift, distribution shift), the model's status moves backward from Deployed to needs-retraining, which loops back through the pipeline. Status types don't have to be linear. The lifecycle can contain loops, branches, and conditional returns to earlier states.

This is the Third Brain insight: when you externalize your thinking into a structured system — a personal knowledge base, a decision journal, a project tracker — every object in that system has a lifecycle. An idea moves from captured to developed to tested to integrated or discarded. A belief moves from assumed to examined to confirmed or revised. If you don't track these statuses explicitly, you lose the ability to know where your thinking actually stands. You end up with a pile of notes at unknown stages of development, which is the cognitive equivalent of a warehouse where shipped and unshipped orders sit in the same bin.

Why implicit status tracking fails

Most people track status implicitly. They "know" which projects are active and which are stalled. They "remember" which ideas they've validated and which are still hypotheses. They "feel" which relationships need attention.

This fails for three reasons:

Working memory can't hold lifecycle positions for multiple objects. If you're managing five projects, three personal goals, and two important relationships, that's ten objects whose statuses you need to track simultaneously. Cowan's research on working memory (2001) established the limit at roughly four items. You're dropping at least six.

Implicit status has no transition rules. When status lives in your head, anything can follow anything. A project can feel "active" on Monday and "abandoned" on Friday without any deliberate transition. There was no review, no decision, no transition event. The status just... shifted. Without explicit transition rules, status changes happen to you rather than being chosen by you.

Implicit status can't be audited. You can't look back and ask: "When did this project move from active to stalled? What triggered the transition? Was that transition valid?" Without a status log, you have no process history. And without process history, you can't improve your process.

Designing status types that work

A well-designed status system has four properties:

Completeness. Every possible state of the object maps to exactly one status. If your document can exist in a state that none of your statuses describe — say, "reviewed but changes requested" — your system has a gap. The MECE principle from L-0227 applies directly here: your status types should be mutually exclusive (an object is in exactly one status at a time) and collectively exhaustive (every possible state is represented).

Valid transitions. Not every status can follow every other status. Define which transitions are allowed and which are prohibited. A task can move from "In Progress" to "In Review" but not from "Not Started" to "Done." The transition rules are your workflow.

Transition triggers. Each transition should have a defined trigger — an event, a decision, or a condition that causes the move. "Done" isn't a status you assign arbitrarily. It's a status you earn when specific completion criteria are met. If you can't name the trigger, the transition is underspecified.

Minimal cardinality. Use the fewest statuses that capture meaningful distinctions. Three statuses (Not Started, In Progress, Done) work for simple tasks. A publishing pipeline might need five or six. But fifteen statuses for a grocery list is pathological. The number of statuses should match the number of genuinely different behavioral regimes the object passes through — points where what you can or should do next actually changes.

Protocol: build a lifecycle map

Here is how to implement status tracking in your own epistemic infrastructure:

1. Choose an object type. Start with something you manage repeatedly: tasks, writing projects, ideas, learning goals.

2. List the actual states. Not the states you wish it had or the states a tool suggests. The states it actually passes through. Watch one complete lifecycle from beginning to end and record each distinct phase.

3. Define transitions. For each state, list what states can follow it and what event triggers each transition. Draw this as a diagram: circles for states, arrows for transitions, labels on each arrow for the trigger.

4. Identify the terminal states. Which statuses represent endpoints where no further transitions occur? "Completed," "Archived," "Cancelled" — these are absorbing states. Every lifecycle needs at least one, or objects accumulate forever.

5. Check for missing states. The most common gap is the "waiting" state — objects that are neither active nor complete but blocked on an external dependency. If you don't have a status for this, these objects will masquerade as "in progress" indefinitely, polluting your active queue.

6. Implement and track. Assign statuses explicitly. Record transitions with timestamps. Review periodically: which objects have been in the same status longest? Those are your bottlenecks and your process failures.

The typing constraint from L-0228 told you that types restrict what operations are valid. Status types are the dynamic version of that principle: they restrict what operations are valid right now, based on where the object sits in its lifecycle. And once you can see where everything stands, you can build the priority system that L-0230 introduces — because you can't triage what you can't locate in its own process.

---

Sources:

1. Harel, D. (1987). "Statecharts: A visual formalism for complex systems." Science of Computer Programming, 8(3), 231-274.
2. Gamma, E., Helm, R., Johnson, R., & Vlissides, J. (1994). Design Patterns: Elements of Reusable Object-Oriented Software. Addison-Wesley. (State pattern)
3. Piaget, J. (1936). Origins of Intelligence in the Child. Routledge & Kegan Paul.
4. Erikson, E. H. (1950). Childhood and Society. W. W. Norton & Company.
5. IBM. "What Is a Machine Learning Pipeline?" IBM Think. https://www.ibm.com/think/topics/machine-learning-pipeline
6. Fielding, R. et al. (1999). RFC 2616: "Hypertext Transfer Protocol -- HTTP/1.1." Section 10: Status Code Definitions. W3C/IETF.
7. Cowan, N. (2001). "The magical number 4 in short-term memory: A reconsideration of mental storage capacity." Behavioral and Brain Sciences, 24(1), 87-114.