Work Taxonomies Should Preserve Overlap

GitHub's 23 July changelog added multi-select fields for Projects and Issues, so a single item can now hold more than one value in the same field. The examples are simple: tag an item as both Backend and API, assign several product areas, or mark multiple affected teams.

On the same day, GitHub shipped agent automation controls in GitHub Issues, showing reasons behind agent-suggested labels, types, assignments, and closures before they are applied. It also made Copilot cloud agent for Linear generally available, turning a Linear issue assignment into an asynchronous coding-agent handoff.

The useful pattern is not that issue trackers gained nicer metadata. It is that queue taxonomy now influences which people, agents, automations, reports, and release rules touch the work. If the taxonomy forces one label where reality has overlap, the operating system lies before anyone starts building.

The repeated angle to avoid

The last ten posts here covered file-upload workflows, agent work intake, spend-capable agents, model routing, AI credit chargeback, code-quality gates, review-agent environments, Copilot metrics, operational project views, and runtime credentials. Older overlapping posts covered feature-flag targeting, pull-request dashboards, agent audit trails, permission budgets, and analytics checks.

The weak version of this article would repeat the old X needs Y pattern: project boards need better labels. That is too shallow. The sharper thesis is that multi-value taxonomy is becoming a control surface because the same fields now feed search views, ownership, agent assignment, analytics, and release policy. The implementation question is not "what labels should we add?" It is "which dimensions must be allowed to overlap without hiding risk?"

Single-choice fields create operational blind spots

Small teams often start with one Area field because it keeps the board clean. The problem appears when real work refuses to fit the dropdown.

A checkout issue may affect payment, analytics, mobile UX, accessibility, and customer support. A local-service quote form bug may be about spam prevention, CRM routing, email deliverability, and conversion. A Shopify product-page change may touch structured data, image performance, merchandising, and app compatibility. If the field accepts only one value, the team must either choose the loudest owner or create duplicate tickets.

Both shortcuts distort operations:

• choosing one value hides secondary reviewers and tests;
• duplicating the item splits evidence across threads;
• dashboards undercount cross-functional risk;
• agents receive an artificially narrow task description;
• automation rules fire for the chosen label but miss the omitted ones.

Multi-select fields help because they let one work item retain a fuller map of its business surface. But they also create a governance problem: if every item gets every value, the field becomes noise.

Treat taxonomy dimensions differently

Not every field should become multi-select. Some dimensions need exactly one owner so a decision can be made. Others should allow overlap because the work genuinely crosses boundaries.

Field	Better shape	Why
Accountable owner	Single-select or user field	Someone must make the final trade-off.
Business surface	Multi-select	A bug can affect checkout, lead capture, analytics, and support at once.
Technical layer	Multi-select	One change may touch frontend, API, database, CI, and third-party app code.
Risk class	Multi-select with controlled values	Security, privacy, accessibility, revenue, and reliability risks can overlap.
Current status	Single-select	Work should have one current state, even if many teams care.
Release target	Usually single-select, sometimes multi-select	One normal release target is easier to operate; hotfix plus campaign exceptions should be explicit.
Agent eligibility	Single-select policy state	not_allowed, draft_only, read_only, or change_proposal should be unambiguous.

The rule is simple: use multi-select for descriptors that can be simultaneously true; use single-select for decisions that require one current answer.

Why this matters more when agents enter the queue

A human can sometimes compensate for weak taxonomy. They read the comments, remember the customer context, and know that a "frontend" issue is really a checkout-risk change. An agent is more likely to treat structured fields as instructions.

That is why the fresh GitHub updates belong together. Agent automation controls expose reasons for metadata changes. Linear assignment can hand work to Copilot cloud agent. Multi-select fields let the queue express overlapping surfaces. If those three capabilities mature together, the field schema becomes part of the agent safety model.

For example, a small ecommerce team might allow a coding agent to draft changes only when:

agent_eligibility = change_proposal
AND risk_class does not include payment_write
AND business_surface does not include live_checkout
AND technical_layer does not include secrets_or_auth

That rule fails if business_surface can hold only one value and someone chose product_page instead of also marking live_checkout. The agent did not misunderstand the work; the queue under-described it.

A field design checklist for operators

Before adding or migrating fields, run this checklist against recent issues and pull requests.

1. Sample messy work, not tidy work. Pick ten items that crossed teams, caused rework, affected customers, or required unusual review. Design for those, not the neat backlog examples.
2. Name the dimensions that drive action. If a field does not change reviewer choice, test plan, agent permission, reporting, or customer communication, it may be decoration.
3. Separate ownership from surfaces. One accountable owner can manage work that affects many surfaces.
4. Limit multi-select vocabularies. Multi-select does not mean unlimited tags. Use a controlled list with definitions.
5. Define automation semantics. Decide whether matching any selected value triggers a rule, whether all selected values are required, and which values override agent eligibility.
6. Keep a reason trail for automated changes. If an agent adds or removes a field value, the item should record the evidence it used.
7. Review stale combinations. A rare combination such as checkout, privacy, and third_party_app may deserve a release review even if no single field value looks unusual.

A practical schema for small web teams

This schema is intentionally modest. It works for a GitHub Project, Linear workspace, agency delivery board, or internal operations table.

work_item_taxonomy:
  accountable_owner: single_user_or_team
  current_status: todo | triage | ready | in_progress | review | blocked | done
  business_surface:
    type: multi_select
    values:
      - checkout
      - lead_capture
      - booking
      - product_page
      - analytics
      - crm
      - support
      - local_seo
      - content
  technical_layer:
    type: multi_select
    values:
      - frontend
      - backend
      - database
      - third_party_app
      - ci_cd
      - infrastructure
      - credentials
  risk_class:
    type: multi_select
    values:
      - revenue
      - privacy
      - security
      - accessibility
      - reliability
      - attribution
      - brand_trust
  agent_eligibility:
    type: single_select
    values:
      - not_allowed
      - read_only_investigation
      - draft_only
      - change_proposal
  required_evidence:
    type: multi_select
    values:
      - screenshot
      - failing_test
      - preview_url
      - analytics_diff
      - rollback_plan
      - customer_example

The important part is not the exact labels. It is the split between overlapping descriptors and single-answer controls. That split lets dashboards ask better questions and lets agent rules stay conservative.

Failure modes to avoid

Tag soup. A multi-select field with thirty loosely defined values will be ignored. Keep the list short enough that a new team member can apply it consistently.

Hidden priority inflation. If every surface label increases urgency, people will over-label to get attention. Priority should remain a separate decision.

Agent over-trust. Do not let an agent assign its own eligibility based only on fields it can edit. If field changes can increase authority, require review.

Dashboard false confidence. Multi-select reporting can double-count work. That is fine for risk visibility, but not for throughput totals unless the report explains the counting method.

Migration drift. When converting old single-select fields, do not mechanically copy the old value and call the job done. Review recent incidents and customer-path bugs to add the omitted secondary surfaces.

The decision rule

A field should become multi-select when omitting a second true value would change who reviews the work, which tests run, whether an agent can act, how a customer is informed, or how the business measures risk.

That is the new information surplus in these product updates. Multi-select fields are not merely tidier categorisation. They are a way to stop operational context from being compressed out of the queue before humans, dashboards, and agents make decisions from it.