PROCESS

Here is How to Build

Design

Core

You inherit, more than you build

Most of this volume has described building a core from nothing: name it, direct it, deepen it, connect it, sign it off. That is the clean case, and it is the rare one. Far more often, a core already exists, because the business was running before any designer sat down to shape it, and the designer's task is not to create a core but to change one. A new system arrives, a new offer, a new market, a rule tightens, and the existing core must be redesigned to fit. Inheriting a core and redesigning it, not building one from a blank page, is the work most designers do most of the time.

And an inherited core must first be seen as it is, before it can be changed, which is harder than it sounds, because an inherited core is often not laid out at its levels. It may exist only as running practice, the thing people do, with no written direction above it and no clean backbone drawn. Or it may exist as scattered detail, a pile of instructions and procedures, with no agreed direction they add up to. In neither case can you safely change it, because you cannot change soundly what you cannot see whole. So the first work on an inherited core is to recover its levels: to find its real direction, the L1 it is actually running on whether or not anyone wrote it down, and its real backbone, the L3 of how it actually flows. Only when the inherited core is visible at its levels can a change be made to it with confidence.

This recovery is often revealing in itself. An inherited core run from habit, or held in one person's head, or buried under procedures no one has stepped back from, frequently turns out to have no clear direction at all, or a direction no one would agree to if it were stated plainly. Drawing out its levels surfaces that: it forces the question what is this core actually for, and which way does it actually go?, which the running core may never have been asked. Sometimes the change the designer was brought in to make is smaller than the thing the recovery uncovers. But whether or not it uncovers more, the rule holds: see the inherited core at its levels first, because every change you make to it will be made on that understanding, and an understanding that stops at scattered detail, with no direction recovered above it, is not enough to change a core soundly.

The highest possible standard is to treat the usual task as redesigning an inherited core rather than building a new one, and to recover the inherited core's real levels, its actual direction and its actual backbone, before changing it, because a core cannot be soundly changed until it can be seen whole at its levels.

Key Takeaway: Most of this volume built a core from nothing, but that is the rare case; far more often a core already exists and the designer's task is to change it, not create it, a new system, offer, market, or rule, and the existing core redesigned to fit. An inherited core must first be seen as it is, which is hard because it is often not laid out at its levels: it exists as running practice with no written direction, or scattered detail with no direction they add up to. So recover its levels first, its real L1 and L3, because you cannot soundly change what you cannot see whole, and the recovery often reveals the core had no clear direction at all.

The common task is redesigning an inherited core, not building one; recover its real levels first, because you cannot soundly change what you cannot see whole.

MarvinPro · PROCESS · Here is How to Build · Design · Core · Discipline 7: Inherited · Section: You inherit, more than you build

MarvinPro | September 2026

marvinpro.com

How far up the change reaches

With the inherited core seen at its levels, the next question is how far up the change reaches, because that decides how much of the core the redesign touches. Not every change reaches the same depth. A small change, a step that alters, a handoff that moves, a system that is replaced by another doing the same job, may touch only the backbone, the L3, leaving the direction untouched. A large change, a new offer, a new market, a shift in what the core is fundamentally for, may reach all the way up to the direction itself, reopening the L1 and cascading down through everything beneath it. So the designer reads the change first: how far up does this reach? And redesigns down from there, going up at least far enough to be sure the direction still holds.

And here is the discipline that saves the most grief: even for a change that looks small, start with a quick check at the direction before diving into the detail. It is tempting, with a small change to a core you know, to go straight to L3 and alter the step. But a quick pass at L1 first, does this change touch what the core is for, or which way it goes?, costs almost nothing and catches the dangerous case: the change that looked small but actually moves the direction. A change dressed as a detail can carry a shift in direction hidden inside it, and if you drop straight to L3 and build the detail without checking, you build it on a direction the change has quietly altered, and the fault surfaces later, expensively. The quick L1 check is cheap insurance: usually it confirms the direction holds and you drop to L3 and make the change; occasionally it catches the small change that was large, before any detail was built on the wrong direction.

So the rule is: go up before you go down, at least far enough to be sure. The only time to start at the backbone is when the core already has a sound L3 and the change is genuinely small, and even then the quick L1 check comes first. For anything larger, the direction must be re-examined, and perhaps re-set, before the detail beneath it is touched, because to redesign the backbone under a direction the change has altered is to rebuild the detail twice, the same cost-of-change arithmetic that set the direction first the first time, now applied to changing it. Read the change, go up far enough to be sure of the direction, and only then redesign down.

The highest possible standard is to let the size of the change decide how far up the levels the redesign reaches, always making a quick check at the direction first even for a small change, so that a change which secretly shifts the direction is caught before any detail is rebuilt beneath the wrong one.

Key Takeaway: How far up the change reaches decides how much the redesign touches. A small change may touch only the backbone (L3), leaving the direction untouched; a large one may reopen the direction (L1) and cascade down. So read the change first and go up far enough to be sure the direction still holds. And the discipline that saves the most: even for a small-looking change, make a quick L1 check first, cheap insurance that catches the change dressed as a detail but carrying a shift in direction, before you build detail on a direction the change has quietly altered. Start at the backbone only when L3 is sound and the change is genuinely small, and even then check L1 first.

Let the change's size decide how far up you go, and always make a quick L1 check first, so a change that secretly shifts the direction is caught before detail is rebuilt beneath the wrong one.

MarvinPro · PROCESS · Here is How to Build · Design · Core · Discipline 7: Inherited · Section: How far up the change reaches

MarvinPro | September 2026

marvinpro.com

Redesign, re-run the disciplines

Redesigning an inherited core is not a different method from building one. It is the same disciplines, re-run, at the depth the change requires. Where the change reopens the direction, the direction is re-set and re-agreed, exactly as it was agreed the first time, because a changed direction one person holds is no more a direction than an unagreed one ever was. Where the change reaches the backbone, the affected part is re-deepened, faithfully, as a deepening of the direction as it now stands. Where it touches a handoff, that handoff is re-checked with the area across the seam, because a handoff the change altered but the receiving area never re-agreed is once again an assumption waiting to break. The disciplines that built the core are the disciplines that change it; the redesign simply applies them to what the change touches, and no more.

And the change re-triggers sign-off, for the parts it touches. A redesigned core is not sanctioned by the sign-off the old core carried; that sign-off covered the old design, and the parts the change altered are no longer what was signed. So the changed parts must be signed off again, by the authorities whose parts they are, with the same honesty the first sign-off demanded, real sanction, not a formality waved through because the core was signed off once before. A change signed off as a formality, nodded past because the core is familiar, carries the same hidden fault as a first sign-off done carelessly, and surfaces it the same way, later and more expensively. What the change touches, the change must get re-sanctioned.

So the core is never truly finished. It is built, signed off, and run; and then a change comes, and it is seen afresh, reopened to the depth the change reaches, redesigned by the same disciplines, and re-signed-off where it changed; and it runs again, until the next change. This is not a failure of the design; it is the life of a core. A core that could never be changed would be a dead thing, fixed against a world that moves; a core that can be changed soundly, by re-running the disciplines to the depth each change requires, is a living one, kept sound through every change by the same method that made it sound at the start. The disciplines do not end when the core goes live. They are how it stays a good core, for as long as it runs.

The highest possible standard is to redesign an inherited core by re-running the same disciplines to the exact depth the change requires, re-setting the direction where the change reaches it, re-deepening and re-checking the handoffs it touches, and re-signing-off every changed part as true sanction, so the core stays sound through change rather than drifting from the design that was once agreed.

Key Takeaway: Redesign is not a different method but the same disciplines re-run at the depth the change requires: re-set and re-agree the direction where the change reopens it, re-deepen the affected backbone, re-check the handoffs it touches (a changed handoff the receiving area never re-agreed is again an assumption waiting to break). And the change re-triggers sign-off for the parts it touches, as true sanction, not a formality nodded past because the core is familiar, or it carries the same hidden fault. So a core is never finished: built, run, and reopened to the depth each change reaches, redesigned, re-signed-off, and run again. The disciplines that built it keep it sound through change.

Redesign by re-running the disciplines to the depth the change requires, and re-sign-off what it touches; a core is never finished, but kept sound through change by the same method that built it.

MarvinPro · PROCESS · Here is How to Build · Design · Core · Discipline 7: Inherited · Section: Redesign, re-run the disciplines

MarvinPro | September 2026

marvinpro.com

A real example

The software core did not stay still. It was built, signed off, and run, subscribe, activate, deliver, verify, and then the changes came, as they always do, and each had to be read for how far up it reached. First, before any change, the designer who took it over had to see it as it was: its direction was running but never written, its backbone half-captured in scattered procedures. So the levels were recovered, the real L1 drawn out from how the core actually ran, the real L3 assembled from the procedures and the practice, until the inherited core was visible whole. Only then could it be changed.

A small change came first: the delivery system was replaced by a new one that did the same job. A quick check at the direction, does this change what the core is for, or which way it goes?, confirmed it did not; deliver the software still stood. So the designer dropped to the backbone, redesigned the deliver step and its handoff to the new system, re-checked that handoff with the team that owned the new system, and re-signed-off the changed part with them. The direction was never reopened, because the change did not reach it, and the quick check had confirmed as much before any detail was touched. A small change, handled at the backbone, in the backbone's depth.

Then a large change came: the company added a usage-based tier beside the flat subscription. This looked, at first, like another backbone change, adjust verify to count usage. But the quick L1 check caught what the appearance hid: verify no longer meant only check that the subscription is active; it now meant meter what is used and charge for it, a change in what the core was for. The direction itself had moved. So the designer reopened L1, re-set the direction and re-agreed it with the subscription business Owner, then cascaded down, re-deepening the backbone, re-checking the handoffs to charging now that charging depended on metered usage, and re-signing-off each changed part with its Owner. Had the change been made at the backbone alone, as it first appeared, the new tier would have been built on a direction that no longer fit, and the fault would have surfaced in production. The quick L1 check caught the small-looking change that was large, and the core was redesigned to the depth it truly reached, and stayed sound.

The inherited core was seen at its levels, then changed at the depth each change reached: the small one at the backbone, the large one up to the direction, the quick L1 check catching the one that only looked small.

MarvinPro · PROCESS · Here is How to Build · Design · Core · Discipline 7: Inherited · A real example

MarvinPro | September 2026

marvinpro.com

Inherited

Most of this volume built a core from nothing, but that is the rare case. Far more often a core already exists, because the business ran before any designer shaped it, and the task is to change it, not create it: a new system, offer, market, or rule, and the existing core redesigned to fit. And an inherited core must first be seen as it is, which is hard, because it is often not laid out at its levels, existing only as running practice with no written direction, or scattered detail with no direction they add up to. So the first work is to recover its levels, its real direction and its real backbone, because a core cannot be soundly changed until it can be seen whole, and that recovery often reveals the core had no clear direction at all.

With the core seen at its levels, how far up the change reaches decides how much the redesign touches. A small change, a step, a handoff, a swapped system, may touch only the backbone; a large one, a new offer or market, may reopen the direction and cascade down. So read the change, and go up far enough to be sure the direction still holds. And even for a change that looks small, make a quick check at the direction first: it costs almost nothing and catches the change dressed as a detail but carrying a shift in direction, before you build the detail on a direction the change has quietly altered. Start at the backbone only when L3 is sound and the change is genuinely small, and even then check the direction first.

Redesign is not a different method; it is the same disciplines re-run at the depth the change requires. Re-set and re-agree the direction where the change reopens it; re-deepen the affected backbone; re-check the handoffs it touches, because a changed handoff the receiving area never re-agreed is again an assumption waiting to break. And the change re-triggers sign-off for the parts it touches, as true sanction, not a formality nodded past because the core is familiar, or it carries the same hidden fault, surfaced later and more expensively. What the change touches, the change must get re-sanctioned.

So the discipline is this: treat the common task as redesigning an inherited core; see it at its levels first, recovering its real direction and backbone; let the change's size decide how far up you go, always checking the direction first even for a small change; and redesign by re-running the disciplines to the depth the change reaches, re-signing-off what changed. Do this, and the core is never truly finished but never drifts: built, run, reopened to the depth each change requires, redesigned, re-signed-off, and run again, kept sound through every change by the same disciplines that made it sound at the start. A core that can be changed soundly is a living one, and keeping it so is the designer's work for as long as it runs.

Redesign an inherited core by seeing it at its levels, going up as far as the change reaches, and re-running the disciplines to that depth, so the core stays sound through every change.

MarvinPro · PROCESS · Here is How to Build · Design · Core · Discipline 7: Inherited and Redesigned · Chapter Outcome

MarvinPro | September 2026

marvinpro.com

Think Simple.