Which responsibilities survive materially different workloads without becoming one mandatory stack?
Use unrelated owners and applications to distinguish genuinely recurring responsibility boundaries from repository-local packaging or a frozen Host→Harness→Runtime architecture.
01 / Current position
A hypothesis is not the current judgment.
The dossier preserves the live research position. Dated articles preserve the complete evidence and argument that changed it.
Recurring invariants such as work continuity, consequence identity, explicit uncertainty, owner-native evidence, and replacement can transfer across domains while their lowest correct owner and implementation packaging differ.
Reframed and answered at the responsibility level. Game, Finance, Security, World, Web, Host, Harness, and Runtime now provide materially different consumers and deletion tests. The recurring result is not a universal Host→Harness→Runtime stack: Computing's canonical Core explicitly treats subsystem names as non-invariants and retains only responsibilities that remain unowned after mature mechanisms and owner-native composition. Cross-domain pressure has repeatedly localized, deleted, or kept different packages while preserving a smaller set of ownership/identity/currentness/recovery distinctions.
02 / Decision boundary
What keeps this Question alive?
A shared contract or subsystem that only explains the workload that produced it is documentation or local packaging, not a durable computing boundary; equally, forcing every later workload through the same package stack can manufacture false generality.
Use ‘which second materially different workload needs this invariant?’ as an admission/deletion test for each future shared proposal. Do not reopen a generic stack-transfer programme unless a named recurring responsibility cannot be placed cleanly in existing owners or mature substrate.
A future shared candidate repeatedly requires the same invariant across materially different owners and simpler owner-local/mature baselines cannot preserve it without duplicated ambiguity or unrecoverable state; that should pressure the specific responsibility, not automatically the old package stack.
03 / Supporting publications
Complete arguments connected to this Question.
1 dated publication currently document this research line.
04 / Source discipline
The dossier is an index, not the evidence authority.
Owns the current judgment, next test, and deletion condition.
Own complete dated arguments, limitations, comparisons, and source links.
Own exact code, tests, releases, receipts, and machine evidence.