MTS/MTO/ETO survived as a metric qualifier and two Best Practices, never as a process node — and circularity uses the identical mechanism, so the variants schema needs an overlay, not a second axis

The question

Verbatim, from the Notion Research Backlog:

"Did the make-to-stock / make-to-order / engineer-to-order substitutable-variant concept survive anywhere in SCOR DS (Level 3, Best Practice, or performance qualifier), and does OE13 Circular Supply Chain introduce a second orthogonal axis the variants schema would need?"

Context: this merges two open follow-ups filed by [[2026-08-22-scor-digital-standard-level2-process-types]], which established that M1 Make-to-Stock / M2 Make-to-Order / M3 Engineer-to-Order are absent from SCOR DS Level 2 but could not say whether the concept had gone anywhere else. Both legs bear on the proposed axis + variants frontmatter amendment to the Organizational Platform's motion pages.

Answer, in one line: the concept survived in exactly two places and both are non-structural — as a computation qualifier on three Level-2 cycle-time metrics (RS.2.2, RS.2.3, RS.2.4), and as two asymmetric Best Practices (BP.040 MTO, BP.158 MTS; engineer-to-order has no practice at all). It appears at zero process nodes at any level. OE13 Circular Supply Chain Management does NOT introduce a second axis — ASCM handled circularity with the same many-to-many practice-overlay mechanism (BP.282 Circular Economy links to 44 process nodes vs BP.040's 7), plus an enabler and two new performance attributes. All of the below is read directly from the live SCOR DS model data, ASCM's own SCOR DS/SCOR 12 crosswalk, and the v14 front matter.

What we already know (from the vault)

• [[2026-08-22-scor-digital-standard-level2-process-types]] verified from primary text that SCOR DS v14's Level-2 catalog contains no M codes at all — Make became Transform, re-cut on object type (T1 product / T2 service / T3 MRO) — and that "make-to-stock / make-to-order / engineer-to-order does not appear as a Level-2 category anywhere in SCOR DS." That finding is confirmed here and extended: it does not appear as a Level-1, Level-2 or Level-3 category either.
• That brief also flagged the axis-instability problem as the real strategic finding: "ASCM itself does not treat the Level-2 axis as canonical. It changed the axis, wholesale, within one version transition." This brief hands that argument a much stronger piece of evidence (ASCM's own crosswalk table, below).
• [[2026-08-17-gtm-motion-origins-industry-reference-models]] is the parent that proposed axis: substitutable | sub_function plus a variants: list on sub-function nodes, sourcing the pattern from SCOR 6.0's Level 2. It listed M1/M2/M3 at high confidence as the primary-verified motion catalog for core production, and used a Kwik Trip worked example — hot case and bakery are make-to-stock, the fresh-made sandwich is make-to-order — as proof the concept does non-obvious work on a live account. That worked example is still good; its citation needs to move.
• [[2026-08-26-org-map-sibling-homogeneity-scope-test]], the sibling promoted the same night, exhausted the two normative rules the platform borrowed from BIZBOK and found neither binds the org tree. It also recorded the live repo state: three authored tiers (10 functions, 36 motions, 80 roles), no L3 nodes, and DEFER.L3_EMERGENCE in spec/schemas/function-rules.yaml deferring Level 3 to first live use. That matters here, because the mechanism SCOR actually used is not a deeper tier.
• [[2026-08-21-apqc-pcf-80-channel-motion-leaves]] established the retrieval trick reused twice in this brief: a body's gated listing page and its open static asset are different things, and so are its gated UI and its open API.

What the web says

Three primary artifacts, all served by ASCM without authentication. Direct curl to ascm.org is now blocked by an Incapsula/Imperva bot gate (returns a 212-byte JS challenge stub, and WebFetch gets the same), so all three were retrieved through a real browser session — a retrieval note worth keeping, because the August 22 route no longer works.

1. The process layer: a complete, verified negative

The SCOR DS Quick Reference Guide contains every Level-0 through Level-3 process in the standard. Text-extracted and searched in full: zero occurrences of "make-to-stock," "make-to-order," "engineer-to-order," "assemble-to-order," "configure-to-order," "stocked," "decoupling," or "postponement." The same search over the v14 front matter returns zero.

Cross-checked against the live model data: of 314 distinct process nodes in SCOR DS, exactly one has any of those words in its name, and it is a false positive (O3.1 Generate Stock Transfer Order (STO)). The decoupling-point axis is gone from the process hierarchy without residue.

2. ASCM's own crosswalk shows the axis being substituted, not refined

The document [[2026-08-22-scor-digital-standard-level2-process-types]] listed as an unresolved follow-up — an old-to-new migration table — exists and is open-access: scor_crosswalk.pdf, "SCOR DS / SCOR 12 Comparison Document," CC BY-NC-ND 4.0, © 2025 ASCM. Its mapping rows are the sharpest evidence in this brief. Verbatim structure:

Read that carefully: every one of the three new Fulfill categories inherits all four old Deliver categories. This is not a re-mapping, it is an axis swap — the old distinction is projected away and a new one is projected in, at the same layer, on the same processes. At Level 3 the collapse is explicit and lossy: M1.1, M2.1 and M3.2 (three separate "Schedule Production Activities" steps, one per variant) all become the single T1.2 Schedule Production Activities. The redundancy the old axis created is exactly what ASCM removed.

The crosswalk's own summary of what changed leads with: "Supply chain is no longer seen as linear – double infinity loop graphic depicts the interconnected nature of supply chains which are infinitely in motion." Hold that sentence; it decides the OE13 half of the question.

3. Where the concept did survive, leg by leg

Level 3 — no. Covered above. One near-miss worth recording: the definition text of OE12.6 Define Operating Model Considerations to Support Competitive Requirements uses it as an illustration. Verbatim: "The process to define how we run the supply chain operations in a way that aligns with the supply chain strategy to support the market's competitive requirements. For example: MTO / MTS; Outsource or self-production; Forecasting methodology; Inventory Management Policies; Technology Utilization (e.g., VMI, EDI, automation)." So the choice is named — as one bullet in a worked example, inside an Orchestrate enabler, not as a node.

Best Practice — yes, and asymmetrically. SCOR DS carries 281 distinct BP. codes. Three are relevant:

• BP.040 Make-to-Order (MTO) Order Fulfillment Strategy. Definition: "MTO Order Fulfillment Strategy involves evaluating the potential to change an order fulfillment strategy from Make-to-Stock to MTO for a given stock keeping unit to offset the need to carry inventory because of infrequent or low demand… MTO is a production environment where a good or service can be made after receipt of a customer's order… Where options or accessories are stocked before customer orders arrive, the term assemble-to-order is frequently used." Linked to 7 processes (OE8.1, OE8.2, P1, P2, P4, T1, T2), 23 metrics, 13 skills, and two practice pillars (Process, Organization).
• BP.158 Make-to-Stock (MTS) Goods Receipt. Note the name: this is a Source-side receiving practice, linked to S2.4, S2.5, S3 — not a production strategy. Its definition is also internally garbled, ending "aka produce-to-stock, assemble-to-order, make-to-order" while defining make-to-stock. A genuine defect in the standard; do not quote it approvingly.
• BP.047 Finished Goods Inventory Postponement, whose definition carries the only occurrence of the word "decoupling" anywhere in the model: "This practice can be combined with additional opportunities, such as changing the order fulfillment strategy from Make-to-Stock to Make-to-Order and decoupling point analysis."

Engineer-to-order has no Best Practice. A name-search across all 281 practice titles returns nothing for ETO. The old trio survived as a pair, and the pair is not even symmetric — one is a production strategy, one is a goods-receipt procedure.

Performance qualifier — yes, and this is the strongest survival. Three Level-2 cycle-time metrics carry a Discussion section stating that their own roll-up formula changes depending on which variant is deployed. Verbatim, RS.2.3 Transform Cycle Time: "Level-3 metrics that are used to drive the calculation of Transform Cycle Time are taken from the applicable Transform process elements, depending on the possible strategies deployed by companies to fulfill orders (such as make-to-stock (MTS), make-to-order (MTO) or engineer-to-order (ETO)). When an MTS or MTO strategy is deployed, the metric Finalize Production Engineering Cycle Time (RS.3.13) is not used in the calculation." RS.2.2 Source Cycle Time and RS.2.4 Fulfill Cycle Time carry near-identical language, each naming a different Level-3 metric that drops out. RL.3.46 Fill Rate's definition is likewise conditional on MTS vs MTO. Sixteen sections model-wide mention the terms at all; these four are the only ones where the variant is load-bearing rather than illustrative.

4. OE13 and the circularity question

OE13 Circular Supply Chain Management is real, is entirely new (the crosswalk marks all of OE13.1–OE13.6 NEW PROCESS, no v12 antecedent), and its six children are: Assess the Use of Materials, Water and Energy · Minimize the Use of Materials, Water and Energy · Increase the Efficient Use of Fixed Assets · Reduce Waste · Extend the Product Lifecycle and Circular Utility · Maximize Recovery for Reuse and Repurpose. Its definition ends: "The subprocesses are in order of priority: (1) reduce (2) extend product lifecycle (3) recovery for reuse and repurpose."

But ASCM did not model circular-vs-linear as a fork anywhere. It used four non-structural mechanisms simultaneously:

1. An Orchestrate enabler (OE13) at Level 0, alongside OE12 Segmentation and eleven others — enablers apply to the whole chain, not to a branch of it.
2. A Best Practice with enormous fan-out. BP.282 Circular Economy — "an economic system intended to minimize waste and maximize the use of resources through a regenerative process… This is the opposite of a linear economy" — links to 44 process nodes, spanning every Level-1 process (P, O2, S, T, F, R), the Orchestrate parent itself, and specific Level-3 steps (T1.8, T2.13, T3.11 Disposition Waste or Surplus). Compare BP.040's 7 links. Same mechanism, six times the reach.
3. Two new performance attributes with Level-1 metrics — Environmental (EV.1.1–EV.1.5: materials, energy, water, GHG, waste) and Social (SC.1.1–SC.1.3) — plus Level-3 circularity metrics including EV.3.15 Percentage of Circularity and EV.3.13 Recovery Potential of Materials Used.
4. Level-3 process steps distributed into the existing tree rather than branched off it: T1.8 / T2.13 / T3.11 Disposition Waste or Surplus (Scrap, Recycle, Repurpose) sit inside the normal Transform flows, and the front matter's change log records "Added sustainability (circularity) practices, metrics, skills, competencies to all processes."

The crosswalk's headline bullet settles intent: supply chain "is no longer seen as linear." Circular is not one branch of a linear-vs-circular fork; it is the re-framing of the whole model. There is no linear counterpart node to pair it with, and that is deliberate.

Convergences and contradictions

• Convergence, and it resolves the question cleanly. The two things the question treats as separate problems — the surviving decoupling-point variant and the new circularity dimension — are handled by SCOR DS with one shared mechanism: a Practices layer whose members attach many-to-many to processes, metrics and skills, at any level, with unconstrained fan-out. The front matter names this outright: "A practice is a unique way to configure a process or a set of processes." That sentence is the true successor to SCOR 6.0's "configured-to-order at Level 2" line, and it locates configuration in a cross-cutting overlay, not in the hierarchy.
• Correction to a sibling brief, in its favour. [[2026-08-22-scor-digital-standard-level2-process-types]] concluded that the word "configuration" had moved out of Level 2 and into the Racetrack improvement methodology. That is true but incomplete. It moved into three places: the Racetrack step, the Practices definition above, and OE12 Segmentation, whose own definition reads "The process of designing and operating distinctly different end-to-end value chains (from customers to suppliers) that are optimized by a combination of unique customer value, product attributes, manufacturing and supply capabilities, and business value considerations," and which closes with "All metrics linked to OE12 should be applied at a segment level." OE12 is where the configuration decision lives now, and OE12.6 is where MTO/MTS is named as an example of it. This strengthens the sibling's conclusion rather than undercutting it.
• Contradiction with the parent brief's confidence tags, and it is narrow but real. [[2026-08-17-gtm-motion-origins-industry-reference-models]] tagged "make-to-order" and "engineer-to-order" as [REF-MODEL] SCOR M2/M3, primary verified, high confidence. Those codes are dead. Make-to-order re-cites cleanly to BP.040 and to RS.2.3's discussion; engineer-to-order does not re-cite at all in current SCOR — it survives only as an inline parenthetical inside three metric discussions and one skill definition (HS.0094 Procurement). Its confidence tag should drop from high to medium, and its citation should change from a process code to "named as a fulfilment strategy in the RS.2.x cycle-time metric discussions."
• A minor internal inconsistency in ASCM's own documents, worth knowing before we cite counts. The v14 front matter says SCOR recognizes "twenty-one classifications" of practice and three practice pillars; the Quick Reference Guide says "four practice pillars" and lists Analytics, Technology, Process, Organization as separate items; the live model's navigation exposes 19 categories and 3 pillars. Cite the practice mechanism, not the practice counts.

Synthesis for RDCO

The variants schema does not need a second axis. It needs to stop being a tree field. That is the finding, and it is a bigger correction to the proposed amendment than either of the two questions anticipated.

The axis + variants proposal in [[2026-08-17-gtm-motion-origins-industry-reference-models]] puts the substitutable set inside the node it belongs to — a variants: list in a sub-function page's frontmatter. SCOR DS is the only reference model in the quartet that ever had a real substitutable catalog, and when ASCM rebuilt the standard it moved that catalog out of the hierarchy entirely and into a separate element type linked many-to-many to processes, metrics and skills. The mechanism has three properties our inline list does not: a variant can attach to several nodes at once (BP.040 reaches P1, P2, P4, T1, T2 and two OE8 steps — Plan and Transform and Compliance, three different functions); a variant can attach at different depths simultaneously (BP.282 links to Level-1 letters, Level-2 codes and Level-3 steps in the same list); and a variant carries its own definition, its own metric set and its own required skills, independent of any one node. An inline variants: list under one sub-function can express none of that. The moment a real engagement has a variant that spans two functions — and the very first example ASCM ships does — the inline list forces a duplicate, and duplicates drift.

So the concrete schema recommendation changes shape. Rather than adding variants: to sub-function pages, add a fourth artifact type alongside the 10 function / 36 motion / 80 role pages: a variant page with its own id, a definition, a source citation, a confidence tag, and an applies_to: list of node ids. Motion and function pages then need no new field at all — the link is expressed from the variant's side, which is what makes many-to-many cheap. This is also the cheaper migration given where the repo actually is ([[2026-08-26-org-map-sibling-homogeneity-scope-test]] confirmed the tree is exactly three authored tiers with DEFER.L3_EMERGENCE holding L3 shut): a new sibling directory breaks no ids, touches no existing frontmatter, and does not force the L3 decision early. And it absorbs circularity, ESG, AI-enablement, or any future cross-cutting concern without a schema change, because in that shape orthogonal axes are not axes — they are just variants with wider applies_to lists. The linear-vs-circular question dissolves: BP.282's 44 links versus BP.040's 7 is the entire difference between "pervasive" and "local," and it is a data property, not a structural one.

The second finding is about where a variant earns its place, and it is a discipline we should copy verbatim. ASCM kept MTS/MTO/ETO in exactly one load-bearing spot: the Discussion on RS.2.2, RS.2.3 and RS.2.4, where the variant changes which Level-3 metrics roll up into the Level-2 number. Under MTS or MTO, RS.3.13 Finalize Production Engineering Cycle Time drops out of Transform Cycle Time; under ETO it does not. That is a variant doing arithmetic. Everywhere the variant was only a label — three parallel Schedule Production Activities steps differing in nothing but their prefix — ASCM deleted it and merged the nodes. That gives the Organizational Platform a falsifiable admission test for the variant catalog, replacing the softer substitutability-plus-selectivity pair from the parent brief: a variant is real if naming it changes a measurement, a role assignment, or a system boundary. If it only changes a label, it is a synonym and it gets merged. Applied honestly, that test will delete a meaningful fraction of the 36-node motion layer's proposed variant lists, which is the point — the current lists were assembled from practitioner vocabulary, and vocabulary is exactly what fails this test.

The third finding is a caution about citation, and it is the one that would embarrass us in front of a Kwik Trip audience. The parent brief's best worked example — a single c-store running make-to-stock and make-to-order simultaneously, hot case versus fresh-made sandwich — remains true and remains persuasive. Its citation does not. M1/M2 are dead codes; M2's live successor is BP.040, a Best Practice, and M1's is BP.158, a Source-side goods-receipt practice with a definition that contradicts its own title. Engineer-to-order has no current SCOR home at all. Any deck that puts "SCOR M1/M2" next to that example is quoting a 2017 standard to a supply-chain audience that can look up the 2025 one in a browser without logging in — because the full model, contrary to what we recorded on August 22, is not actually gated: scor.ascm.org renders behind an account wall, but https://scor.ascm.org/api/scor/cache/ returns the complete 7.3 MB model as JSON — 314 processes, 367 metrics, 281 practices, every definition and every cross-link — to an unauthenticated request. That is a standing research asset for the Org Map work, not just a citation for this brief.

Why this is in the vault

This closes both remaining SCOR follow-ups behind the Organizational Platform's axis + variants schema amendment, and it changes the recommendation: the amendment should become a separate variant artifact type with an applies_to: list, not a variants: frontmatter field on sub-function pages, before the 36 motion pages are written and the shape becomes expensive to change. It also supplies the admission test (does naming the variant change a measurement, a role, or a system boundary?) that the motion-page hand-section template needs, and it retires the M1/M2/M3 citations that [[2026-08-17-gtm-motion-origins-industry-reference-models]] tagged high-confidence and that are on track to reach a Kwik Trip audience.

Open follow-ups

• Does APQC's PCF or eTOM have any equivalent of SCOR's Practices layer — a separately-coded element type linked many-to-many onto the process tree — or is the cross-cutting overlay unique to SCOR among the quartet? A negative would make the overlay shape our own contribution rather than a borrow.
• OE12 Segmentation is entirely new in SCOR DS and its definition ("designing and operating distinctly different end-to-end value chains") is a closer match to the Org Map's motion concept than anything at Level 2. Should the Organizational Platform's motion layer be modelled on OE12 segmentation rather than on Level-2 process categories?
• The three RS.2.x cycle-time metrics are the only place a variant changes a calculation. Does the same "variant changes the arithmetic" pattern appear in APQC's PCF measure definitions, giving the admission test a second independent source?
• ASCM ships BP.158 with a definition that contradicts its own title, and its own documents disagree on the practice-classification and pillar counts. What is SCOR DS's published errata or revision process, and does the CC BY-NC-ND licence permit us to redistribute corrected extracts in a client deliverable?
• The full model is served unauthenticated at scor.ascm.org/api/scor/cache/ under CC BY-NC-ND 4.0. What exactly does the NoDerivatives clause permit for an internal knowledge-graph ingest of that JSON, versus a client-facing artifact derived from it?

Related

• [[2026-08-22-scor-digital-standard-level2-process-types]] — the direct parent; this brief closes two of its open follow-ups and extends, rather than contradicts, its "the axis is engagement-local" conclusion.
• [[2026-08-17-gtm-motion-origins-industry-reference-models]] — the grandparent that proposed axis + variants; its M1/M2/M3 citations are retired here and its schema shape is revised.
• [[2026-08-26-org-map-sibling-homogeneity-scope-test]] — the sibling promoted the same night; its live-repo read (three authored tiers, DEFER.L3_EMERGENCE) is what makes the separate-artifact recommendation the cheap option.
• [[2026-08-21-apqc-pcf-80-channel-motion-leaves]] — source of the gated-UI-versus-open-asset retrieval pattern, applied twice here.
• [[2026-08-17-apqc-pcf-function-motion-mapping]] — sibling in the reference-model quartet; the overlay finding bears on its function/motion verdicts.
• [[2026-08-23-etom-per-function-motion-catalog]] — the fourth member of the quartet; the "does anyone else have a Practices layer" follow-up above is addressed at it.
• [[2026-08-04-kwik-trip-ai-architecture-engagement-context]] — the live engagement whose MTS/MTO worked example keeps its substance and loses its citation.
• [[industry-process-reference-models]] — the round-level concept note this feeds.

Sources

Primary, fetched and read this session (2026-08-27):

• ASCM, SCOR Digital Standard — Quick Reference Guide (complete Level-0 to Level-3 process chart). https://www.ascm.org/globalassets/documents--files/corporate-transformation/scor-ds-digital-guide_final.pdf — retrieved via browser session, text-extracted locally, searched in full. Source of the complete-negative on MTS/MTO/ETO at the process layer, the OE1–OE13 enabler names, and the EV.3.x circularity metrics.
• ASCM, SCOR DS / SCOR 12 Comparison Document, CC BY-NC-ND 4.0, © 2025 ASCM. https://www.ascm.org/globalassets/ascm_website_assets/docs/scor/scor_crosswalk.pdf — the old-to-new crosswalk [[2026-08-22-scor-digital-standard-level2-process-types]] could not find. Source of the M1/M2/M3 → T1, S1/S2/S3 → S2, and D1/D2/D3/D4 → F1,F2,F3 mapping rows, the NEW PROCESS marking on all of OE12 and OE13, and the "supply chain is no longer seen as linear" change summary.
• ASCM, SCOR Digital Standard — Introduction and Front Matter, SCOR Version 14.0, CC BY-NC-ND 4.0, © 2025 ASCM. https://www.ascm.org/globalassets/ascm_website_assets/docs/scor/intro-and-front-matter-scor-digital-standard-2025.pdf — source of the Practices definition, the eight performance attributes, the Level-1 metric table, and the change-log line on sustainability added to all processes.
• ASCM, live SCOR DS full model. https://scor.ascm.org/api/scor/cache/ — 7.3 MB JSON, HTTP 200 to an unauthenticated request, parsed locally: 314 process nodes, 367 metric nodes, 281 BP. codes. Source of every definition, process link and metric link quoted for BP.040, BP.047, BP.158, BP.282, OE12, OE12.6, OE13, RS.2.2, RS.2.3, RS.2.4, RL.3.46.

Retrieval note / partial block:

• Direct curl and WebFetch to ascm.org now return a 212-byte Incapsula JS-challenge stub rather than the PDF. The August 22 retrieval route is dead; a browser session is required. Not a paywall — the assets remain free and CC-licensed once the bot gate is passed.
• apics.org (the SCOR v12.0 framework introduction PDF) remains HTTP 403 and was not retried. Not needed: the ASCM crosswalk supplies the v12 codes directly from ASCM.

Secondary:

• A web search surfaced the crosswalk PDF's existence and asserted the BP.040 and BP.047 codes before they were confirmed. Both were subsequently verified against the live model JSON; the search result is not load-bearing for any claim above.

Vault:

• ~/rdco-vault/06-reference/research/2026-08-22-scor-digital-standard-level2-process-types.md — see [[2026-08-22-scor-digital-standard-level2-process-types]]
• ~/rdco-vault/06-reference/research/2026-08-17-gtm-motion-origins-industry-reference-models.md — see [[2026-08-17-gtm-motion-origins-industry-reference-models]]
• ~/rdco-vault/06-reference/research/2026-08-26-org-map-sibling-homogeneity-scope-test.md — see [[2026-08-26-org-map-sibling-homogeneity-scope-test]]
• ~/rdco-vault/06-reference/research/2026-08-21-apqc-pcf-80-channel-motion-leaves.md — see [[2026-08-21-apqc-pcf-80-channel-motion-leaves]]
• ~/rdco-vault/06-reference/research/2026-08-17-apqc-pcf-function-motion-mapping.md — see [[2026-08-17-apqc-pcf-function-motion-mapping]]
• ~/rdco-vault/06-reference/research/2026-08-23-etom-per-function-motion-catalog.md — see [[2026-08-23-etom-per-function-motion-catalog]]

Confidence: High on every factual claim about SCOR DS content — the process-layer negative, the BP.040 / BP.047 / BP.158 / BP.282 definitions and link sets, the RS.2.x variant-conditional metric discussions, the absence of any engineer-to-order practice, the OE13 children, and the crosswalk mapping rows. All read directly from ASCM primary artifacts, most of them from the structured model data rather than from prose. High that OE13 does not introduce a fork ASCM itself models. Medium on the interpretive step from "SCOR uses a many-to-many practice overlay" to "the Organizational Platform should adopt a separate variant artifact type" — that is a design recommendation drawn from one precedent, and the APQC/eTOM follow-up above is the check on it. Medium-low on the practice-count figures (281 BP. codes, 19 categories), which disagree with ASCM's own front matter and should not be quoted externally.