Pillar — Task Intake & Routing

Prefix: TIR- Catalog: v1.1 deltas (additive to v1.0 Task Intake & Routing). What it measures: whether work entering a product portfolio names the application it belongs to, carries fields an agent can fill, and reaches an owner before the triage window expires.

v1.0 already covers issue templates, a pull-request template, documented labels, a triage convention, and structured intake files. These v1.1 criteria close the gaps that appear once an agent is filing and routing work across several applications that share one backlog.

Criteria in this pillar

TIR-100 — Intake names the application

Level: 3 · Scope: portfolio · Check: deterministic
Issue and pull-request templates (TIR-010, TIR-020) require an application (or slice) identifier drawn from the portfolio's published application list. A template that only describes the repository as a whole does not satisfy this criterion.
Rationale: TIR-010 gives agents a structured bug report; it does not tell them which application in a multi-application product owns the bug. Unscoped intake lands in the wrong tree and never reaches the people who can act.
Evidence expected: a required template field, dropdown, or label whose allowed values match the portfolio application list; a lint of templates fails a missing application field; sample recent issues carry the identifier.

TIR-110 — Intake forms are machine-fillable

Level: 3 · Scope: repository · Check: deterministic
Intake uses structured forms (YAML issue forms or equivalent) with named required fields, not free-form Markdown headings alone. Required fields include summary, type, related issue or none, and the application identifier from TIR-100.
Rationale: TIR-050 asks that templates exist. An agent cannot reliably fill a prose template whose sections are optional headings. Named fields are the contract the agent is allowed to complete.
Evidence expected: a form schema with required keys; a sample filled payload parses against that schema; Markdown-only templates are not the only intake path.

TIR-120 — Portfolio label taxonomy published

Level: 3 · Scope: portfolio · Check: deterministic
The portfolio publishes one label taxonomy covering application, type, and priority (or equivalent). Every application consumes that taxonomy. Per-application forks are enumerated, justified, and owned.
Rationale: TIR-030's per-repository labels do not compose. Agents filtering "bug + this application" across a product cannot trust ad-hoc names that mean different things in each tree.
Evidence expected: a committed taxonomy (labels.yml or equivalent); label-sync configured; exception list empty or owned with a reason.

TIR-130 — Routed work has an application owner

Level: 4 · Scope: portfolio · Check: deterministic
An issue or pull request that names an application (TIR-100) is assigned, or requests review, from that application's owners — a path-based CODEOWNERS rule, an equivalent routing table, or automation that applies the same map. Unrouted items older than the triage SLA appear on a failing report.
Rationale: templates without routing still dump work on a shared inbox. Agents filing a slice-scoped change need an owning reviewer on the other end, not a hope that someone notices.
Evidence expected: a routing table or CODEOWNERS paths per application; automation that applies assignees or reviewers from that map; a sample of recent items showing the route; unrouted-over-SLA count is zero or explained.

TIR-140 — Triage SLA visible per application

Level: 4 · Scope: portfolio · Check: manual
The triage convention (TIR-040) is measured as k/n applications meeting the SLA window. A blended backlog that hides a dead slice does not satisfy this criterion. A newly added application is on the report within one cadence or is marked not_applicable with a one-line justification.
Rationale: organization-scope triage is necessary and not sufficient. Portfolio scoring (CSPC-31) is the unit; one untriaged application is where agent-delegated work goes to die.
Evidence expected: a report or dashboard with per-application SLA plus k/n; cadence stated; not_applicable entries justified.

v1.0 Task Intake & Routing — the published TIR-010 through TIR-050 criteria.
v1.1 pillars — draft catalog, including these deltas and the six new pillar stubs.
v1.0 specification — the published standard.

Criteria in this pillar

Level: 3 · Scope: portfolio · Check: deterministic

Issue and pull-request templates (TIR-010, TIR-020) require an application (or slice) identifier drawn from the portfolio's published application list. A template that only describes the repository as a whole does not satisfy this criterion.

Rationale: TIR-010 gives agents a structured bug report; it does not tell them which application in a multi-application product owns the bug. Unscoped intake lands in the wrong tree and never reaches the people who can act.

Evidence expected: a required template field, dropdown, or label whose allowed values match the portfolio application list; a lint of templates fails a missing application field; sample recent issues carry the identifier.

Level: 3 · Scope: repository · Check: deterministic

Intake uses structured forms (YAML issue forms or equivalent) with named required fields, not free-form Markdown headings alone. Required fields include summary, type, related issue or none, and the application identifier from TIR-100.

Rationale: TIR-050 asks that templates exist. An agent cannot reliably fill a prose template whose sections are optional headings. Named fields are the contract the agent is allowed to complete.

Evidence expected: a form schema with required keys; a sample filled payload parses against that schema; Markdown-only templates are not the only intake path.

Level: 3 · Scope: portfolio · Check: deterministic

The portfolio publishes one label taxonomy covering application, type, and priority (or equivalent). Every application consumes that taxonomy. Per-application forks are enumerated, justified, and owned.

Rationale: TIR-030's per-repository labels do not compose. Agents filtering "bug + this application" across a product cannot trust ad-hoc names that mean different things in each tree.

Evidence expected: a committed taxonomy (labels.yml or equivalent); label-sync configured; exception list empty or owned with a reason.

Level: 4 · Scope: portfolio · Check: deterministic

An issue or pull request that names an application (TIR-100) is assigned, or requests review, from that application's owners — a path-based CODEOWNERS rule, an equivalent routing table, or automation that applies the same map. Unrouted items older than the triage SLA appear on a failing report.

Rationale: templates without routing still dump work on a shared inbox. Agents filing a slice-scoped change need an owning reviewer on the other end, not a hope that someone notices.

Evidence expected: a routing table or CODEOWNERS paths per application; automation that applies assignees or reviewers from that map; a sample of recent items showing the route; unrouted-over-SLA count is zero or explained.

Level: 4 · Scope: portfolio · Check: manual

The triage convention (TIR-040) is measured as k/n applications meeting the SLA window. A blended backlog that hides a dead slice does not satisfy this criterion. A newly added application is on the report within one cadence or is marked not_applicable with a one-line justification.

Rationale: organization-scope triage is necessary and not sufficient. Portfolio scoring (CSPC-31) is the unit; one untriaged application is where agent-delegated work goes to die.

Evidence expected: a report or dashboard with per-application SLA plus k/n; cadence stated; not_applicable entries justified.