Section 0090 names the Read as the operating discipline the principle requires — continuous causal tracing, honest attribution, model-updating against observation. Section 0095 hands the operator the first small move. Between the Read as a discipline and the first move as an action, the operator needs a specific instrument that lets them run the discipline against any outcome in their operation and generate an operating verdict from the run. That instrument is the design trace.
The design trace is three questions, run in order, against any outcome the operator is examining. For any outcome:
What was constructed to produce this outcome. Why was it constructed. What alternatives were considered and rejected.
If the operator can answer all three questions with operational specifics, the outcome is designed. If the operator cannot answer all three with operational specifics, the outcome is defaulted. That is the trace. Three questions, one verdict.
The instrument is deceptively simple. Its simplicity is what makes it operable — the operator can run it on any outcome in any moment without preparation, without instruments beyond their own knowledge of the operation. But underneath the simplicity, each question is carrying specific diagnostic weight, and the weight has to be named for the operator running the trace to run it accurately.
The first question — what was constructed to produce this outcome — separates outcomes from the conditions that produced them. Every outcome in an operation is downstream of some condition. The condition may be a hiring criterion, a training protocol, a scheduling structure, an accountability mechanism, a comp arrangement, a Guest recovery process, a supply chain relationship, a menu engineering choice, a physical layout decision, or any of hundreds of other structural elements that shape what the operation produces. The question asks the operator to name the structural element that produced the outcome under examination. Not to describe the outcome again. Not to describe the operation in general. To name the specific constructed condition upstream of the specific outcome.
An operator who has designed operationally answers this question with specifics. A cast member who executes well produced their execution because of a specific hiring criterion applied when they were hired, a specific onboarding protocol they went through, a specific set of standards installed in training, and specific accountability mechanisms enforced during their tenure. Each of those is nameable. The operator can point to the criterion, describe the protocol, cite the standards, and name the accountability structure. The construction is traceable because the construction is real.
An operator who has defaulted answers this question with restatement or with externalization. Restatement sounds like: “she executes well because she’s a good server.” That describes the outcome; it does not name the construction. Externalization sounds like: “she executes well because she came in with good training from her previous job.” That relocates the construction outside the current operation — which may be true, but does not answer what the current operation constructed to produce the outcome. Both restatement and externalization are the answers of an operator who has not constructed the condition upstream of the outcome. The outcome exists; the outcome is favorable; but the operator did not build the condition that produced it. The outcome is defaulted, not designed.
The first question is not asking whether the outcome is good or bad. It is asking whether the operator constructed the condition that produced it. Favorable outcomes can be defaulted — the cast member who executes well because she arrived that way, not because the operation built her. Unfavorable outcomes can also be defaulted — the cast member who executes poorly because the operation never installed the criteria, protocols, and standards that would have shaped her execution. The verdict of the first question is about construction, not about outcome quality.
The second question — why was it constructed — separates construction with intent from construction by accident. Operators sometimes build conditions unintentionally. A scheduling structure that happens to produce a specific cast rotation pattern was not necessarily built to produce that pattern; it may have emerged from other constraints and produced the pattern as an emergent consequence. A comp arrangement that happens to reward specific behaviors was not necessarily built to reward those behaviors; it may have been copied from another operation and produced its reward pattern without the current operator’s engineering. The second question asks the operator to name the intent behind the construction.
The intent has to be specific. “We built it because it works” is not intent — that is retrospective satisfaction with the construction, not the intent that produced the construction. “We built it because the industry standard is this way” is not intent — that is inheritance of a construction from outside the operation, without the operator’s own decision-making applied. Intent sounds like: “We built this hiring criterion because we determined that Guest recognition compounds when the same cast members return over multi-year horizons, and the criterion filters for candidates whose life circumstances predict multi-year tenure with our operation.” That is intent. It names the outcome the construction was designed to produce, and it names the causal logic connecting the construction to the outcome.
An operator running vocabulary design fails the second question distinctively. They can name a construction — often a construction that has been in place for years — and they can restate the vocabulary that surrounds it, but they cannot name the specific intent that produced the construction. The construction is there; the intent is missing. This is one of the most common patterns the design trace surfaces. Operators inherit constructions from prior operators, from industry defaults, from consultants, from earlier phases of their own operation, and they carry the constructions forward without ever engineering their own intent through them. The construction exists. The construction produces outcomes. But the operator did not decide the construction should produce those outcomes. The construction is running default at the intent layer even though it looks designed at the artifact layer.
The third question — what alternatives were considered and rejected — separates decisions from adoptions. A decision was made by weighing options and choosing one. An adoption was made by taking the first available option or the inherited option without weighing. The third question asks the operator to name the alternatives that were on the table when the construction was installed, and to name the specific reasons the alternatives were rejected in favor of the current construction.
If the operator can name the alternatives with specifics, and can name the specific reasons for the rejection, the construction was a decision. If the operator cannot name the alternatives, the construction was an adoption. Adoptions can look identical to decisions from outside, but they carry different design weight. A decision has been tested against alternatives and survives the test with articulable reasons; an adoption has never been tested and continues to run because nothing has forced it to be re-examined.
An operator whose hiring criterion is a decision can name three or five other criteria they considered and can explain why each of the alternatives was rejected — not with vague dismissal but with specific consequence-tracing. “We considered filtering primarily for restaurant experience but rejected it because the criterion selects for candidates whose habits were installed by defaulted operations, and re-installing habits is more expensive than installing them fresh in candidates without prior restaurant conditioning.” That is decision-mode. An operator whose hiring criterion is an adoption cannot name the alternatives with specifics because no alternatives were weighed at the point the criterion was installed. The criterion is the industry default the operator inherited, or the criterion the previous management used, or the criterion that emerged from other pressures without the operator’s engineered attention.
The three questions run in order because the order matters. If the operator cannot answer the first question, the outcome is defaulted regardless of what happens with questions two and three. If they answer the first but not the second, the outcome is a construction without intent — an artifact-level design that is defaulted at the intent layer. If they answer the first and second but not the third, the outcome is a constructed and intentional adoption — the operator inherited a construction, then developed retrospective intent for it, but never tested the construction against alternatives to determine if it was the right construction for the intent. If they answer all three, the outcome is designed at every layer — construction, intent, and decision.
The design trace has practical properties that make it operable in daily operation.
The first property is speed. The trace runs in the time it takes to ask three questions and hear the operator’s own answer. The operator running through the operation can trace an outcome in seconds. This makes the trace a continuous instrument rather than an episodic one. The operator does not have to schedule a trace, prepare for a trace, or set aside time for a trace. The trace runs during the Read.
The second property is universality. The trace works on any outcome the operation produces. Cast outcomes, Guest outcomes, financial outcomes, operational outcomes, positioning outcomes, cultural outcomes. The same three questions apply to all of them. The operator does not need to switch instruments as they move across dimensions of the operation. One instrument, run repeatedly, across every dimension the Read touches.
The third property is honesty enforcement. The trace is difficult to fake because the answers are operational rather than rhetorical. An operator who tries to answer the first question with vocabulary rather than construction knows immediately, in themselves, that they have not named a construction. The trace’s simplicity is its honesty mechanism. The operator either can name the construction, intent, and alternatives with operational specifics, or they cannot. There is no middle ground the operator can hide inside. This is why the trace is uncomfortable to run early in an operator’s practice — it surfaces the defaulted dimensions the operator has been carrying under design vocabulary, and the surfacing is immediate and specific.
The fourth property is that the trace can be run on the operator’s own operation by the operator themselves, without external instruments and without external observers. The operator asks themselves the three questions. The operator hears their own answers. The operator generates the verdict. This is the disciplined-Read version of the trace — the operator running the instrument against themselves as the ongoing operating discipline. External observers running the trace on the operation from outside can produce useful triangulation, but the primary user of the trace is the operator, running it on their own operation continuously.
The fifth property is that the trace produces action, not just diagnosis. When a dimension surfaces as defaulted through the trace, the operator now has a specific gap to work on — the missing construction, the missing intent, or the missing decision. The trace does not just tell the operator that a dimension is defaulted; it tells the operator which specific component is missing. Missing construction means the operator has to build the condition upstream of the outcome. Missing intent means the operator has to engineer their own intent through an existing inherited construction. Missing decision means the operator has to test the current construction against alternatives and either confirm the current construction with articulable reasons or install a different construction based on the test.
The trace has failure modes that need to be named so the operator running it does not misapply the instrument.
The first failure mode is running the trace only against unfavorable outcomes. Operators naturally want to trace the problems, not the successes. But favorable defaulted outcomes are as diagnostically valuable as unfavorable defaulted outcomes. A cast member who executes well because she arrived that way is a favorable defaulted outcome, and knowing that the favorable outcome is defaulted tells the operator that the outcome is not replicable through their operational architecture. When the cast member leaves, the operation has no built condition capable of producing another like her. The trace applied to favorable outcomes surfaces the fragility hidden inside successes.
The second failure mode is stopping at the artifact layer of construction. An operator asks the first question, points to a hiring criterion, and moves on without asking the second and third questions. The construction exists; the operator has named it; but the intent and decision layers remain untraced. The trace has to run all three questions to produce a valid verdict. Stopping early produces a false positive — the operator concludes design is running when only the artifact layer is designed.
The third failure mode is accepting vague answers from oneself. The trace’s honesty enforcement depends on the operator refusing to accept restatement, externalization, or vocabulary substitution as answers. The operator who is willing to accept “we built it because it works” as an answer to the second question is not running the trace; they are running theater. The trace requires the operator to hold themselves to operational specifics. The discipline of the trace is the discipline of not letting oneself off the hook when the specifics are missing.
The fourth failure mode is running the trace so intensively that the Read becomes performative rather than operating. The trace is an instrument to be run when the operator is examining specific outcomes. It is not a mantra to be recited over every event in the operation. The operator selects outcomes worth tracing based on their operational significance, runs the trace against those outcomes, generates verdicts, and acts on the gaps. Continuous performative tracing produces the sensation of design work without the actual design work — a vocabulary-design failure mode applied to the diagnostic instrument itself.
The trace connects directly to the sections around it. Section 0090’s Read is the ongoing operating discipline that produces the observations the trace runs against. The trace is what the Read does with those observations when the operator wants to generate a verdict on a specific outcome. Section 0095’s first small move for the operator is now more concretely specified — the operator’s first move can be to run the trace against one outcome the operator has been carrying assumptions about, and to act on whatever gap the trace surfaces. The trace bridges the discipline of the Read into the specific action of the first move.
The trace also connects to section 0072 on the recursion. The trace, run at the operator layer against the operator’s own operating patterns, is how the operator diagnoses the direction the recursion is running. If the operator runs the trace against their own operator-layer decisions — their own time allocation, their own draw structure, their own compounding investments, their own maintenance disciplines — and cannot answer the three questions with operational specifics for a majority of dimensions, the operator layer is defaulted and the recursion is regenerating default downstream at every cycle. If the operator can answer all three questions across their operator-layer dimensions, the operator layer is designed and the recursion is regenerating design downstream. The trace applied at the operator layer is the primary diagnostic for the direction the entire operation is running.
The trace also connects to section 0042 on vocabulary design versus operational design. The answerability test named in 0042 is a specialized application of the design trace. When the operator suspects vocabulary design is running at a specific dimension, the trace’s three questions run against that dimension will produce the diagnosis. Vocabulary design produces trace failures — construction may or may not be nameable, but intent and decision will not be — because vocabulary design is precisely the state where language substitutes for the operational architecture the trace requires.
The trace is not a novel instrument the operator has to develop. Operators already ask themselves versions of these questions, informally, when they encounter surprising outcomes. What the design trace does is formalize the questions, put them in order, and name the verdict the answers produce. The formalization is what makes the trace runnable continuously against every outcome the operation produces, rather than only against surprising outcomes.
The operator running the principle runs the trace as part of their operating routine. Every meaningful outcome the operation produces — a hire, a departure, a Guest recovery, a Guest defection, a shift result, a period result, a positioning shift, a positioning drift — gets traced. The verdicts accumulate. Over cycles, the operator builds a map of which dimensions of their operation are designed, which are defaulted, which have construction but not intent, which have intent but not decision. That map is the operator’s actual read of their own operation, and the map is where the next round of design work gets targeted.
The trace is the instrument. Three questions. One verdict. Run continuously. Apply the verdict to the design work that follows.
Updated on August 10, 2026
44 years. 200+ independent operators coached. 34 restaurants opened from scratch.
I work with restaurant operators who know something is wrong and are ready to find out what it actually is — and with leaders who are ready to build something that lasts.
The complete framework is in my new book: The Operator’s Playbook
Call or text: +1-817-797-2929 Email: Jeffrey@JeffreySummers.com
