06-reference/research

etom lifecycle first org map spine

2026-09-03·research-brief·source: deep-research·by Ray Data Co (deep-research synthesis)
organizational-mapetomtaxonomy-designorganizational-intelligencereference-models

Is lifecycle-first a better spine for the Organizational Map than function-then-motion?

The question

"eTOM re-cut its Domains by lifecycle stage rather than by department — is lifecycle-first a better spine for the Organizational Map than function-then-motion, and has any vault brief actually tested that alternative?"

Context: filed HIGH out of [[2026-08-28-gb921-v24-sales-development-currency-check]] on the theory that a mature framework choosing a different spine is the strongest available challenge to the Org Map's function-first cut, and that it had to land before the 36-motion vocabulary locks. Both halves of that framing turned out to be wrong, in ways that are more useful than the answer to the question as asked.

What we already know (from the vault)

What the web says

Convergences and contradictions

Synthesis for RDCO

Keep function-then-motion. This should not block anything, and there is no lock to block.

The argument for switching rested on eTOM having chosen differently, and it did not. When you read eTOM's actual navigable tree rather than a diagram of it, 1.2 is the Product Domain and 1.2.2 is Capability Delivery — a functional container parenting a lifecycle stage. That is structurally the same decision the Org Map made. The strongest available external challenge to the spine turns out, on primary evidence, to be an endorsement of it. That is a genuinely useful result: it means the founder can defend function-first in a client room by pointing at the most mature process framework in existence, rather than by asserting that nobody does two axes.

The real difference is not the spine, it is the discipline of the second level — and that is where the actionable finding is. eTOM's Level 2 is one consistent, universal, declared axis applied identically across every domain: every domain gets a Capability Delivery cell, a Lifecycle Management cell, a Fulfilment cell. RDCO's Level 2 is not consistent. [[2026-08-28-multi-axis-decomposition-reference-models]] read the 36 motions as cut on at least five different axes — Sales by channel, Finance by work type, IT by managed asset, Operations by object, Supply Chain by supply-chain stage. That heterogeneity is probably correct for RDCO's purpose and it should stay, but it is currently undeclared, which means "motion" does not mean the same thing on two adjacent pages of the same artifact. eTOM's real lesson is not "change your spine." It is "name your axes in your definitions clause, the way we do." That is the cut_by: recommendation the sibling brief already made — ten edits, no id changes, fully reversible — and this brief independently confirms the precedent it rests on. That is the change worth making, and it is cheap.

The fit argument against lifecycle-first is stronger than the authority argument, and it should be the one on record. eTOM is a process framework for telecom operations; its Level 2 carries process content, so a lifecycle cut is natural there. The Org Map is not a process framework. The vault settled this twice, independently: APQC could not decompose physical vs. field vs. digital sales because the difference is staffing and economics, not process; BIZBOK's test says a motion is not a value stream. A motion exists to carry substitutability — which way could this function be run, and what does each way cost in headcount and rates. Re-parenting motions under lifecycle stages would replace an economics taxonomy with a process taxonomy, which is precisely the failure mode the "motion layer is built, not borrowed" verdict exists to prevent. It would also break the Map's anchoring rule that the client's department wins, which is what makes the artifact recognizable to the person being interviewed. Lifecycle-first would make the Map more elegant to a business architect and less useful to a phData consultant pricing a seat. Fit, not authority, is why the answer is no.

Migration cost, named, in case the founder disagrees with all of the above. A re-spine is not a schema edit. 138 authored pages sit on the current tree (10 functions, 36 motions, 80 roles, 12 archetypes). FN.<F>.<M> ids appear ~744 times across markdown, YAML, Python and HTML — 360 of those in clients/kwiktrip/ alone, plus 37 in tools/ across 16 Python builders (build_roles.py, resolve_rates.py, build_viewer.py, validate.py). The Kwik Trip engagement has 79 person pages and an OIP registry of 28 jobs, 28 workflows, 202 gaps and 81 use cases anchored to function/motion nodes. And the repo has no re-parenting safety net: [[2026-08-17-apqc-pcf-function-motion-mapping]] recommended stable concept-ids before any motion is re-parented, and that has not been done. Confidence that a re-spine is the wrong call: medium-high. Confidence that eTOM's spine is function-first: high, primary-sourced. Confidence about GB921 v24/v25 specifically: low — tmforum.org 403s and the guidebooks are member-gated, so my structural evidence is R18.5 (2018) with v21/v22 corroboration. The founder has far more lived context on what the Map is for than I do; if the Map's purpose has shifted from anchoring seats toward modeling flow, this analysis inverts and should be re-run.

What would have to be true for the answer to flip. (1) If GB921 v24+ genuinely abandoned the matrix and made lifecycle the sole parent axis, the precedent argument weakens — though the fit argument would still stand on its own. (2) If the Map's primary consumer becomes the OIP rather than seat-and-rate pricing — i.e. if the thing people navigate it to find is a workflow rather than a stakeholder — then the OIP's lifecycle chain is the natural spine and the Map should follow its consumer. (3) If a live engagement needs function and lifecycle queryable together rather than one primary plus a filter, the overlay is insufficient; the sibling brief already named the honest response there, which is re-deriving the motion layer as cells of both axes rather than nesting one under the other.

Why this is in the vault

It closes the open follow-up posed verbatim at line 146 of [[2026-08-28-gb921-v24-sales-development-currency-check]] and answers it in the negative with primary evidence, so the Organizational Platform's spec/00-template-decisions.md D-1 deferral can be closed as "single parent axis, deliberately, with a citation" rather than left open through the Kwik Trip engagement. It also retires a specific distortion — "eTOM re-cut its Domains by lifecycle stage rather than by department" — that was on track to be repeated as an argument, and corrects the unsourced "the 36-motion vocabulary is about to lock" claim that three briefs have now propagated without any decision record behind it.

Open follow-ups

Related

Sources

Primary (read directly):

Secondary (corroborating, flagged as such):

Blocked / not obtained:

Vault: