Forty-seven items, zero structure
You open your task manager. Forty-seven items stare back. Some are from last week, some from this morning, some from a meeting you barely remember. A few feel urgent. Several feel important. Most feel vaguely obligatory. You scan the list, your eyes jumping between items, trying to calculate which one to do first.
This is the moment most people experience as "being overwhelmed." But the problem is not that you have too many tasks. The problem is that your tasks have no types. Every item exists in the same undifferentiated mass, and your brain is being asked to perform a fresh comparison across all 47 items every time you need to pick the next one. That is not a motivation failure. It is a classification failure.
Priority types solve this by converting a flat list into a layered structure. Instead of asking "which of these 47 things should I do next?" you ask "do I have any critical items?" — and if so, those go first, without deliberation. The comparison set drops from 47 to perhaps 3. You do not think harder. You think less, because the type system already encodes the decision logic.
This is triage: the practice of sorting items into priority categories so that action follows from classification rather than from moment-to-moment judgment. And it was invented not in a productivity seminar but on a battlefield, under conditions where getting the sorting wrong meant people died.
The invention of triage: sorting under pressure
In the 1790s, during the French Revolutionary Wars, a surgeon named Dominique Jean Larrey confronted a problem that would be familiar to anyone with an overloaded inbox — except his inbox was wounded soldiers. Before Larrey, the standard practice was to treat officers first, then soldiers, then enemy combatants. Treatment order was determined by rank, not by medical need. The result was predictable: soldiers with survivable wounds bled out while surgeons attended to officers with minor injuries.
Larrey's innovation was to replace status-based ordering with severity-based typing. He declared: "We would always start with the most dangerously wounded without regard to rank or distinction." Soldiers were sorted into categories based on the urgency and severity of their injuries. Those with immediately life-threatening wounds received treatment first. Those less severely wounded waited until the critical cases were addressed. This was not compassion in the abstract — it was a classification system that maximized lives saved per unit of surgical time.
The operational results were dramatic. Before Larrey's system, wounded soldiers waited 24 to 36 hours for medical attention. After implementing triage combined with his "flying ambulances" — mobile surgical units positioned near the front lines — that delay dropped to roughly one hour. Mortality from amputation fell from over 90% to less than 25% when performed promptly. The same surgeons, the same tools, the same injuries — but a different classification system produced radically different outcomes.
The word "triage" itself comes from the French trier, meaning to sort or to select. It entered medicine through Larrey's work and has since become standard practice in every emergency department in the world. But the underlying principle is not medical. It is epistemic: when you type items by priority before acting on them, you replace continuous judgment with categorical action, and you allocate resources where they produce the most impact.
Why flat lists force you to re-decide everything
The cognitive cost of an untyped list is not intuitive until you understand what your brain is doing when you scan one. Roy Baumeister's research on ego depletion — first published in 1998 and expanded over two decades — established that decision-making draws from a finite pool of self-regulatory resources. Each choice you make, no matter how small, depletes that pool slightly. Baumeister's metaphor is muscular: willpower fatigues like a muscle after exertion.
More recent work has refined this into the concept of decision fatigue. Research published in Frontiers in Psychology (Pignatiello et al., 2018) estimates that adults make approximately 35,000 decisions per day, most of them automatic. But each time you scan a flat task list and ask "what should I do next?", you force a non-automatic, deliberative comparison. You are recruiting your System 2 — Kahneman's slow, effortful, resource-hungry reasoning process — to perform what should be a categorical lookup.
The evidence shows up in unexpected places. Judges making parole decisions show measurably more lenient rulings right after meal breaks than at the end of long decision sessions. Gastroenterologists detect fewer polyps as the day progresses. Air traffic controllers show performance decline across shifts. The mechanism is consistent: repeated decisions degrade the quality of subsequent decisions, not because people get stupider but because the cognitive resources required for careful evaluation become depleted.
Priority types short-circuit this process. When your tasks are pre-classified — when "critical" means "do this before anything else" and "low" means "only if everything else is done" — the decision of what to do next requires no comparison at all. You look at the top type. If something is there, you do it. If not, you move to the next type. The classification was made once, at the moment of capture or during a dedicated review, and it carries forward without consuming fresh cognitive resources every time you consult the list.
The Eisenhower Matrix: typing by two dimensions
The most widely known priority type system uses two dimensions rather than a single ranking. Dwight Eisenhower — before he was president, while managing the complexity of Supreme Allied Commander during World War II — articulated a distinction that Stephen Covey later popularized in The 7 Habits of Highly Effective People: the difference between urgent and important.
The Eisenhower Matrix produces four types from these two dimensions:
Urgent and Important — crises, hard deadlines, emergencies. These demand immediate action. A production outage. A client deliverable due tomorrow. Your child's fever at 3 AM.
Important but Not Urgent — strategic work, skill development, relationship building, health maintenance. These are the items that compound over time but never scream for attention. Writing that architecture document. Exercising. Having the difficult conversation with your cofounder before it becomes a crisis.
Urgent but Not Important — interruptions that feel pressing but do not advance your core objectives. Most emails. Most meetings. Most Slack notifications. Someone else's emergency that does not require your specific involvement.
Neither Urgent nor Important — activities that consume time without producing value. Mindless scrolling. Organizing files that no one accesses. Attending a meeting because "you've always attended."
The power of the matrix is not the four quadrants themselves but the typing behavior it enforces. Without it, urgency dominates. Research by Zhu et al., published in the Journal of Consumer Research (2018) and expanded in a subsequent analysis in Academic Medicine (2023), identified what they call the "mere urgency effect": people systematically choose urgent tasks over important ones, even when the important tasks offer objectively greater rewards. The mechanism is psychological — shorter deadlines create discomfort, and completing urgent tasks resolves that discomfort immediately, producing a small dopamine reward that reinforces the bias.
The Eisenhower Matrix overrides this bias by forcing you to type each item along both dimensions before acting. The Quadrant 2 items — important but not urgent — are precisely the items the mere urgency effect causes you to ignore. By making "important but not urgent" an explicit type, you create a structural counterweight to the cognitive bias that would otherwise bury those items indefinitely.
MoSCoW: priority types for collaborative decisions
In 1994, Dai Clegg at Oracle confronted a different version of the priority problem: not personal task management but group requirements negotiation. When a team is building software, everyone has a list of features they believe are essential. Without a shared type system, every requirement is positioned as critical by its advocate, and priority becomes a political contest rather than a technical classification.
Clegg's solution was the MoSCoW method — an acronym for Must have, Should have, Could have, and Won't have (this time). The lowercase "o"s are inserted for pronounceability, not meaning. The four types map to clear decision rules:
Must have — the delivery fails without it. If this feature is missing, the product does not ship. These are non-negotiable.
Should have — important but not fatal to omit. The product is significantly degraded without it, but workarounds exist.
Could have — desirable if time and resources permit. Improves the experience but does not impair core functionality.
Won't have (this time) — explicitly out of scope for this delivery. Not rejected permanently, but deferred by agreement.
The critical design feature of MoSCoW is the last category. By making "Won't have" an explicit, named type — rather than simply leaving items off the list — teams create a visible record of what was deliberately excluded. This prevents the backlog churn where deferred items resurface in every planning session because no one remembers why they were deprioritized.
MoSCoW also embeds a constraint that prevents type inflation: the Agile Business Consortium recommends that Must-have items should not exceed 60% of the total effort in any timebox. If everything is a Must, the type system has failed — you are back to an undifferentiated list wearing priority labels.
Engineering severity: P0 through P4
Software engineering has converged on one of the most precise priority type systems in common use: incident severity levels. While implementations vary across organizations, the standard five-tier system illustrates how priority types translate directly into response protocols.
P0 (Critical) — Total system outage, data breach, or revenue-impacting failure. Response time: immediate. The on-call engineer is woken up at 3 AM. All other work stops. Communication goes to executive leadership. Resolution is measured in minutes to hours.
P1 (High) — Major functionality impaired for a significant subset of users, but the system is not completely down. Response within one hour during business hours. A dedicated team is assigned.
P2 (Moderate) — Important functionality degraded, workarounds exist. Scheduled for the current sprint or maintenance window. Addressed within days.
P3 (Low) — Minor issues, cosmetic bugs, small improvements. Placed in the backlog. Addressed when higher-priority items are cleared.
P4 (Informational) — Enhancement requests, technical debt notes, documentation gaps. Tracked but not actively scheduled. Addressed during dedicated cleanup cycles or not at all.
What makes this system effective is not the labels but the response protocols attached to each type. A P0 does not mean "this is bad" — it means a specific chain of actions is triggered automatically: page the on-call, open an incident channel, notify stakeholders, post status updates every 30 minutes. The priority type is not a description; it is an instruction set.
This is the deeper principle: a priority type is only useful if it carries behavioral implications. A type that says "high priority" but triggers the same response as "medium priority" is not a real type. It is a label masquerading as a classification.
The anatomy of a working priority type system
Across medical triage, the Eisenhower Matrix, MoSCoW, and engineering severity, the effective priority type systems share four structural properties:
1. Small number of types. Larrey used three categories. Eisenhower used four. MoSCoW uses four. Engineering severity uses four to five. No working system uses seven or more. The reason is cognitive: Miller's research (1956) and Cowan's refinements (2001) establish that working memory handles roughly four distinct categories reliably. A seven-tier priority system requires consulting a reference chart every time you classify, which reintroduces the decision overhead the system was supposed to eliminate.
2. Clear decision boundaries. Each type has a rule that determines membership. "Must have" means the delivery fails without it. P0 means total system failure. "Important but not urgent" means it matters for long-term goals but has no external deadline. Fuzzy boundaries — "sort of high priority" — collapse the type system because they require the same deliberative judgment as having no types at all.
3. Differential action protocols. Each type triggers a different behavior. P0 items get immediate response. P3 items go to the backlog. Quadrant 4 items get deleted. If all types lead to the same action, the classification provides no leverage.
4. Explicit inclusion of the lowest tier. Every effective system has a type for "not now" or "not this." Larrey had a category for the slightly wounded who could wait. MoSCoW has "Won't have." Engineering severity has P4. Without this tier, items that should be deferred accumulate in the "medium" category, inflating it until it becomes the new undifferentiated list.
Your Third Brain: how AI performs triage at scale
If priority types enable humans to sort a list of 47 items, attention mechanisms enable transformers to sort sequences of thousands to millions of tokens — and the underlying logic is structurally identical.
In a transformer model, every input token competes for influence over the output. The attention mechanism computes a relevance score between each token and every other token in the sequence. Tokens with high relevance scores receive high attention weights; tokens with low relevance scores receive weights approaching zero. The result is a form of automated triage: the model allocates its finite computational resources — its "attention" — to the tokens that matter most for the current context.
The scoring function works through three learned projections: queries (what am I looking for?), keys (what do I contain?), and values (what do I contribute?). The dot product between a query and a key produces an alignment score. High alignment means high relevance; low alignment means the token is effectively deprioritized. After a softmax normalization, the weights form a probability distribution — a priority ranking over the entire input sequence.
Recent research has pushed this further. A 2025 paper in Scientific Reports introduced contextual priority attention, where each token receives a single priority score reflecting its relevance to the global context, rather than requiring pairwise comparisons between all tokens. This reduces the computational cost from quadratic (n-squared) to linear (n) — the equivalent of moving from scanning every pair of items on your list to classifying each item once against a fixed rubric.
The parallel to human triage is direct. Token pruning methods in vision transformers identify and remove irrelevant tokens early in processing, just as a well-designed priority system lets you skip your P3 items entirely when P0 items exist. Retrieval-augmented generation systems use relevance scoring to decide which documents to include in context, performing triage on the knowledge base before the model even begins generating.
When you build a personal priority type system and externalize it — writing your P0 through P3 definitions, maintaining a typed backlog — you create the structured input that AI tools can operate on. An AI assistant can scan your typed backlog and surface items whose priority may have shifted based on deadlines, dependencies, or new information. It can flag P2 items that have silently become P0 because a deadline moved. It can identify patterns in what you classify as critical versus what actually demanded immediate action, helping you calibrate your type boundaries over time.
But this only works if the types exist as explicit, structured data. An untyped list is opaque to both human cognition and machine processing. Priority types make your commitments legible — to yourself, to collaborators, and to the tools that extend your cognitive infrastructure.
The protocol: building your personal triage system
Step 1: Define exactly four types. Use whatever labels fit your context — P0/P1/P2/P3, Critical/High/Normal/Low, Now/This Week/This Month/Someday. The labels matter less than the count. Four types is enough to differentiate action without requiring deliberation about which tier an item belongs to.
Step 2: Write a one-sentence decision rule for each type. Not a description — a rule. "P0: if I do not complete this today, something measurably breaks." "P1: completing this within the week prevents downstream problems." "P2: improves a process or output, no external deadline." "P3: worth capturing, no current reason to act." If you cannot write the rule in one sentence, the type boundary is not clear enough.
Step 3: Apply the types to your current backlog. Go through every item once and assign a type. This is a batch operation — do it in a single session, not spread across days. The goal is to type the entire list so that future interactions with the list require no re-evaluation.
Step 4: Work the types, not the list. When you sit down to work, look only at your P0 items. If none exist, look at P1. Never scan the full list. The type system exists to prevent full-list scanning.
Step 5: Review and recalibrate weekly. Priority types are not permanent — they are temporal classifications. A P2 item whose deadline moved to this week becomes P1. A P0 item whose dependency was removed may drop to P2. The weekly review is where you reclassify, not where you rebuild. If you find yourself reclassifying more than 20% of items each week, your type definitions are too vague.
Priority types do not make you more productive. They make you more decisive — by moving the cognitive work of comparison from the moment of action to the moment of classification. You decide once what something is, and the type tells you what to do about it. That is what triage means: sorting before acting, so that action becomes a function of structure rather than a function of anxiety.