"'Add live prices' is a rejected feature, not a backlog item."
A constraint that comes from next door
The market data plan allows one live streaming connection per asset class, and the portfolio sibling's serving process already holds it. That app is running, in production, using that connection to do its job.
So Touchstone is REST-only against that provider — permanently. Not "until we upgrade the plan", not "until we build a shared connection broker". The architecture doc spells out the consequence in the strongest available terms, and the wording is the lesson: a rejected feature, not a backlog item.
The difference is not tone
A backlog item is a promise with the date left blank. It sits in a list, it gets re-estimated, and every few months someone asks whether now is the time. It shapes design too: people leave seams for it, write abstractions "so we can swap this later", and defend those seams in review against people who correctly point out that nothing uses them.
A rejected feature is a closed question. It changes what you build: no streaming seam, no adapter interface with one implementation, no configuration flag reserved for the day it arrives. And crucially, it changes what happens when someone proposes it — the answer is not "good idea, it's in the backlog", it is "here is why that is somebody else's connection."
Resource ownership between sibling apps
The general pattern is worth extracting, because it shows up wherever a group of small applications shares an external allowance: one paid seat, one API rate limit, one webhook registration, one OAuth app, one outbound IP on an allowlist.
The failure mode is quiet and specific. Nobody writes down who owns it, two apps use it, and the second one appears to work — right up until the first one's connection gets dropped by the provider because a newer session claimed the slot. The symptom lands on the app that did nothing wrong, which is the worst possible place for a symptom to land, because it is the one place nobody will be looking for a cause.
The fix is cheap and has to be done early: name the owner in the architecture document of both apps, and state the consequence for the non-owner. Here the non-owner's line is unambiguous — REST-only, permanently, against that provider.