Skip to content

Extension-Request Workflow

Escalation-and-disposition workflow — instantiates Layer-Appropriate Capability Placement

Routes a recurring need the embedded layer can't support up to the host owner for triage and disposition, so a real requirement is escalated rather than quietly rebuilt locally.

The Extension-Request Workflow is the intake and escalation path a narrow layer uses when it keeps being asked for something it wasn't built to do. Instead of the embedded team silently bolting on a local workaround each time, an unsupported requirement is filed against the host, its recurrence and variety are tracked, and — once the same gap shows up often enough — it is routed to the owner of the host layer for a real decision: build it into the host, expose an official extension point, sanction a bounded local shim, or decline. Its defining move is turning a stream of one-off "the platform can't do X" frustrations into a single governed queue whose accumulation is itself the signal that a capability may belong at a different layer.

Example

A studio ships a game with a modding API. Modders keep asking for a way to persist custom data across matches — something the API deliberately doesn't expose, so each popular mod ships its own fragile file-writing hack. The Extension-Request Workflow gives those asks a home: each request is logged with what the modder was trying to do and how they worked around it, and the platform team watches the queue rather than the individual tickets. When "persistent per-player storage" shows up in the fourth different top mod, the recurrence trips the promotion trigger and the request is escalated to the engine owners with evidence attached — four independent local hacks, all reimplementing the same missing primitive.

The engine team's disposition: add a small sanctioned save-data API in the next release, and mark the local hacks for retirement once it lands. What had been four shadow implementations becomes one host capability — because the workflow made the pattern visible instead of letting each mod solve it alone.

How it works

  • Capture, don't absorb. An unsupported need is filed as a request against the host, not quietly implemented in the subsystem; the workaround the team would otherwise ship is recorded as evidence, not merged.
  • Profile the variety. Requests are tagged by the capability they really want, so distinct one-offs and repeat instances of the same underlying gap can be told apart.
  • Trip on recurrence. When the same underlying need crosses a threshold of frequency or breadth, it is promoted from "ticket" to "candidate capability" and escalated.
  • Route to the owner for disposition. The host layer's owner triages and decides — host feature, official extension point, sanctioned shim, or decline — and the decision, with rationale, is returned to the requesters.

Tuning parameters

  • Promotion threshold — how many independent requests (or how much breadth) trips escalation. Low fires fast but floods the host owner with noise; high lets duplicate local hacks proliferate before anyone acts.
  • Intake friction — how much a requester must document. More context sharpens triage but discourages filing; too little buries the signal in vague tickets.
  • Default disposition — whether an un-triaged request defaults to "wait for the host" or "sanction a local shim now." Sets whether the system errs toward duplication or toward delay.
  • Queue ownership — whether embedded teams, the host owner, or a shared council runs triage; determines whose priorities the disposition reflects.
  • Feedback loop — whether requesters are told the outcome. Silence trains teams to stop filing and go build locally instead.

When it helps, and when it misleads

Its strength is that it converts scattered local pressure into one legible demand signal, so the host layer learns what it's missing before a dozen teams have each built their own version. It embodies subsidiarity — keep a need at the lowest layer that can actually serve it, and escalate only when that layer genuinely can't.[1]

Its failure mode is becoming a black hole: requests go in, nothing comes back, and teams rationally route around the workflow by building locally anyway — the very outcome it exists to prevent. It is also easily run as theatre, a queue that logs demand but never dispositions it, so the backlog becomes an alibi ("it's tracked") for inaction. The discipline that keeps it honest is a standing commitment to disposition every escalated request within a bounded time and to publish the outcome — a request that is neither built nor formally declined is the workflow failing silently.

How it implements the components

The Extension-Request Workflow fills the demand-intake side of the archetype — the components that surface and escalate a misplaced requirement:

  • incoming_requirement_variety_profile — the tagged, deduplicated request queue is the profile of what the embedded layer is being asked for and how varied those asks are.
  • capability_promotion_trigger — the recurrence-and-breadth threshold is the trigger that fires when a local need has proven it belongs at the host layer.

It surfaces and escalates demand but does not decide placement (that scoring is Layer-Placement Fitness Check), adjudicate the promotion (that's the sibling Capability-Promotion Review), or build the interface a disposition may call for (that's Host-Service API Delegation).

Notes

The workflow's job ends at escalation-with-evidence; the go / no-go on promoting a capability belongs to a separate review, deliberately. Fusing intake and decision would let the team loudest about a gap also grant its own request — the separation is what makes the accumulated demand signal trustworthy rather than self-serving.

References

[1] Subsidiarity — the principle that a function should be handled by the smallest or lowest-level unit capable of doing it well, and escalated to a higher level only when that unit genuinely cannot. Borrowed from political and organizational theory, it is the same logic that says a narrow layer should delegate upward rather than reconstruct the host. ↩