PROCESS

Here is How to Build

Design

Core

Whose core

There is no core process in the abstract. A core process is always the core of something, a company, a department, a team, and that something is its frame. Before you can name a core, you must name the frame it belongs to, because the core is the flow that delivers that frame's core business, and change the frame and you change the business, and so change the core. The question is never simply "what is the core process?" It is "whose core, at what frame?"

The frame can be the whole company, or any part of it. A company is a frame: its core business is what the company sells, and its core process is the flow that delivers it. But a department is also a frame, with its own core business and its own core process; and a team within that department is a frame too. Each is a frame at its own scale, and each has a core defined by the core business of that frame. So the same organisation holds many frames, nested one inside another, and a core process exists at every one of them, the company's core, the department's core, the team's core, each real, each the core of its own frame.

This is why naming the frame comes first, and why skipping it causes the confusion designers fall into most. Ask "is this a core process?" without fixing the frame, and there is no answer, because the same process is core at one frame and not at another. Fix the frame first, name its core business, and the core follows without argument. The discipline is small but decisive: say whose core you are asking about before you ask what it is. Name the frame, and the question becomes answerable.

The highest possible standard is to name the frame before naming the core, fixing whether you mean the company, a department, or a team, because a core process is always the core of a particular frame, and the question of what is core has no answer until the frame it belongs to is named.

Key Takeaway: There is no core process in the abstract; a core is always the core of a frame, a company, a department, a team. Name the frame before the core, because the core delivers that frame's core business, and changing the frame changes the core. The frame can be the whole company or any part of it, and an organisation holds many frames nested one inside another, each with its own core. This is why skipping the frame causes the confusion designers fall into most: "is this core?" has no answer until you fix whose core you mean.

A core process is always the core of a frame; name the frame first, and the question of what is core becomes answerable.

MarvinPro · PROCESS · Here is How to Build · Design · Core · Discipline 2: The Frame · Section: Whose core

MarvinPro | September 2026

marvinpro.com

How many

A frame does not always have just one core process. It has one for each core activity it performs. A company whose whole business is selling software by subscription has a single core: the flow that delivers the subscription. But a company that both sells software and runs a professional-services arm alongside it has two core businesses, and so two core processes, one delivering the software, one delivering the services. Each is core, because each delivers a core business of the frame. There is no rule that a frame must have exactly one core; it has as many as it has core activities, no more and no fewer.

Telling them apart is done the same way a single core is found: by the core business each delivers. Two core processes are two because they deliver two different core businesses, not because they are large or complex or run by different teams. If you cannot name two distinct core businesses, you do not have two cores; you have one core seen in two parts, or a core and a sub mistaken for a second core. So the count of cores follows the count of core businesses, and the designer establishes it the same way, by naming the businesses the frame is for, and finding the flow that delivers each.

This matters because a frame with several cores must have each designed, and each connected to the others where they meet. A company with a software core and a services core has two spines, and the design of the whole is not one spine but two, related, each delivering its own business, each with its own rules, exceptions, and sub-processes. To treat such a frame as if it had one core is to leave one of its core businesses undesigned, or to force two different flows into a single shape that fits neither. Count the cores by counting the core businesses, and design each as the spine it is.

The highest possible standard is to count a frame's core processes by counting its core businesses, designing one core for each core activity the frame performs, neither forcing several into one nor mistaking a sub for a core, so that every core business the frame is for has a spine of its own.

Key Takeaway: A frame has one core process for each core activity it performs, no more, no fewer. A company that only sells subscriptions has one core; one that also runs professional services has two, one per core business. Tell them apart the same way you find a single core: by the distinct core business each delivers, not by size or team. If you cannot name two distinct core businesses, you do not have two cores. A frame with several cores must have each designed and connected where they meet, so no core business is left without a spine.

A frame has one core process for each core business it delivers; count the cores by counting the core businesses.

MarvinPro · PROCESS · Here is How to Build · Design · Core · Discipline 2: The Frame · Section: How many

MarvinPro | September 2026

marvinpro.com

Core here, sub there

Because a core is always the core of a frame, the same process can be a core in one frame and a support process, a sub, in another. This is not a contradiction; it is the plain consequence of frame-relativity, and it is the single thing designers most often get wrong. A support department's core process is support: from the frame of that department, keeping the rest of the company running is the core business, and the process that delivers it is the department's spine. But from the frame of the company, that same support process is not the core; it is a sub, a support around the company's own core business. Both are true. The process did not change. The frame did.

Nothing shows this more plainly than the process you know well and own yourself. A designer who has spent years shaping, say, a roadside-assistance process experiences it as core, and rightly, because at the frame of that work it is the core: the core business of that frame is getting a stranded customer moving, and the process delivers it. Yet step out to the company's frame, where the core business is mobility itself, and the same roadside-assistance process is a sub, one the company's core connects to when a car breaks down. The designer's experience of it as core is not wrong; it is the truth at their frame. It is simply not the whole truth, because at a wider frame the same process sits differently. A designer must hold both: this is the core of my frame, and my frame's core is a sub of a wider one.

This grows more important as the company grows. A small company may have one designer who sees every frame at once and holds the whole core-and-sub picture in a single head. A large one has many designers, each owning a frame, each rightly treating their frame's core as core, and no one of them seeing the whole. That is not a fault; it is how scale works. But it means someone must hold the company-level frame, the view in which the many frames' cores line up as cores and subs of the whole, or the architecture fragments into a set of local cores that do not connect. So the discipline for the designer is twofold: design your frame's core as excellently as if it were the only core there is, because at your frame it is; and know where your frame sits in the wider architecture, so your core connects out correctly to the cores and subs around it, and the whole holds together.

The highest possible standard is to hold both truths at once, that your frame's core is genuinely the core of your frame, and that at a wider frame it may be a sub, designing it excellently either way while knowing where it sits, so that as the company grows and the frames multiply, the many local cores still connect into one coherent whole.

Key Takeaway: Because a core is always the core of a frame, the same process is a core in one frame and a sub in another, the thing designers most often get wrong. A support department's core is support; from the company's frame that same process is a sub. A roadside-assistance process is the core of its own frame and a sub of the company's, both true, the frame changed, not the process. This grows harder with size: many designers, each owning a frame, none seeing the whole, so someone must hold the company frame or the architecture fragments. Design your frame's core excellently, and know where it sits.

The same process is a core in one frame and a sub in another; design your frame's core well, and know where it sits in the wider whole.

MarvinPro · PROCESS · Here is How to Build · Design · Core · Discipline 2: The Frame · Section: Core here, sub there

MarvinPro | September 2026

marvinpro.com

A real example

Return to the software company, and notice how many frames it holds. At the frame of the whole company, the core business is the software subscription, and the core process is the spine you have already met: subscribe, activate, deliver, verify. That is the company's core. But the company is not one frame; it is many, nested inside it.

Take the support team, the one whose communication process filled the earlier volumes. At the frame of that team, their core business is support: answering trouble well, keeping customers informed and steady when something breaks. The communication process is their core, their spine, the flow that delivers what their frame is for. They design it, own it, and rightly treat it as core. Yet at the company's frame, that same communication process is a sub, a support around the subscription core, reached when the core falters. Core at the team's frame; sub at the company's. The process is one; the frame decides its name. The same holds for finance: at the finance department's frame, charging and collecting are core, their spine; at the company's frame, they are sub-processes the subscription core connects to when money must move.

So the software company is not one core with some lesser processes hanging off it. It is a nest of frames, each with its own core: the company's subscription core, the support team's communication core, the finance department's charging core, and more besides. Each designer, at each frame, designs their core as the spine it is. And someone, at the company's frame, holds the view in which all of them line up, the subscription core at the centre, the others its subs and supports, so the whole connects. That is what naming the frame reveals: not a single core and its servants, but many cores, each real at its own frame, assembled into one design.

The software company is a nest of frames, each with its own core; the same process is a core at one frame and a sub at another, and the whole holds only when someone names the frames and lines them up.

MarvinPro · PROCESS · Here is How to Build · Design · Core · Discipline 2: The Frame · A real example

MarvinPro | September 2026

marvinpro.com

The Frame

There is no core process in the abstract. A core is always the core of a frame, a company, a department, a team, and the frame can be the whole company or any part of it. So before you name a core, name the frame it belongs to, because the core delivers that frame's core business, and change the frame and you change the core. The question is never "what is the core process?" but "whose core, at what frame?" Name the frame first, and the question becomes answerable; skip it, and you fall into the confusion designers fall into most, arguing whether a process is core when the answer depends on a frame no one has named.

A frame does not always have one core. It has one for each core business it delivers: a company that only sells subscriptions has a single core; one that also runs professional services has two. Count the cores by counting the core businesses, not by size or team, and if you cannot name two distinct core businesses, you do not have two cores. Each core a frame has must be designed as its own spine, and connected to the others where they meet, so no core business the frame is for is left without one.

And because a core is always the core of a frame, the same process is a core in one frame and a sub in another. A support department's core is support; from the company's frame that same process is a sub. A roadside-assistance process is the core of its own frame and a sub of the company's, both true, the frame changed, not the process. A designer must hold both: this is the core of my frame, designed as excellently as if it were the only core there is, and my frame's core is a sub of a wider one, connected out correctly to what surrounds it.

This grows with the company. A small frame has one designer who sees the whole; a large one has many, each owning a frame, each rightly treating their core as core, and none seeing all of it. So someone must hold the company's frame, the view in which the many cores line up as cores and subs of the whole, or the architecture fragments into local cores that do not connect. So the discipline is this: name the frame before the core; count the cores by the core businesses; and hold both truths, that your frame's core is truly core, and that at a wider frame it may be a sub, so the many frames of a growing company still assemble into one design that holds.

Name the frame, and the core becomes clear: whose core, how many, and where each sits among the cores and subs around it.

MarvinPro · PROCESS · Here is How to Build · Design · Core · Discipline 2: The Frame · Chapter Outcome

MarvinPro | September 2026

marvinpro.com

Think Simple.