Restaurant Contract Architecture is the whole system of contracts the restaurant runs. Not a single contract. The architecture that holds every contract the operation runs with every counterparty, organized by form, ordered by counterparty, and coupled across the whole business.
It sits at the Perspective spine of the operation. It is upstream of every discipline. The choice of form the architecture is running in is the whole-business choice Two Roads names.
Family: Canon MAJOR, top-level parent. Perspective spine. Parent to the two contract forms and, through them, to every counterparty contract the operation runs.
Structure:
- [Transactional Contract] — Road 1 form
- [Customer Contract] — Guest-side counterparty under transactional form
- [Staff Contract] — People-side counterparty under transactional form
- [Relational Contract] — Road 2 form
- [Guest Contract] — Guest-side counterparty under relational form
- [Cast Contract] — People-side counterparty under relational form
The Architecture Is A Whole-Business Choice
The operator does not choose form per counterparty. The operator chooses form for the architecture, and every counterparty contract inherits the form the architecture is running in.
This is the mechanical claim Two Roads has been making at the philosophical level. The choice is architectural. The operator running a Relational Contract with Guests while running a Transactional Contract with staff is not running mixed forms. They are running a broken architecture. The forms couple.
Staff under transactional form cannot produce the relational output Guests under relational form require. Guest-side relational expectations cannot be met by a People side running spot wage-for-hours. The contracts reinforce each other or they undermine each other. There is no stable middle.
Sustained over time, the architecture collapses toward the lower register. Transactional form always wins over relational form when both are running, because transactional form is cheaper to execute. The operator who does not choose the architecture defaults into it, and the default is always transactional.
The Two Forms
The architecture runs in one of two forms. Not both. Not sometimes-both. One.
Transactional Contract. Spot form. Present-tense exchange settled at close-out. Nothing accumulates. Contract terminates at the transaction boundary. The verb is EXECUTE. Road 1. What a business designed for throughput and settled exchange runs.
Relational Contract. Relational form. Consideration deposited above compensation. Accumulates across engagements. Contract exists AS the relationship. The verb is PRODUCE. Road 2. What a business designed for belonging and compounded return runs.
Same three elements in both forms — offer, acceptance, compensation. Same temporal mechanic of re-signing at every engagement. The structural difference is what happens above compensation. Nothing, or consideration. That is where the two forms diverge, and every downstream consequence follows from that split.
The Counterparties
The architecture runs contracts with every party who enters the operation’s orbit.
Guest-side counterparty. The party the operation serves through its offer. In transactional form, this party is a Customer and the contract is a Customer Contract. In relational form, this party is a Guest and the contract is a Guest Contract.
People-side counterparty. The party the operation runs through to deliver the offer. In transactional form, this party is staff and the contract is a Staff Contract. In relational form, this party is cast and the contract is a Cast Contract.
The word carries the form. Customer and Staff are transactional-register counterparty names. Guest and Cast are relational-register counterparty names. Using a word from one register while running a contract from the other is vocabulary theft, and the counterparty audits the mismatch.
Additional counterparty contracts exist and enter canon later: Vendor Contract, Community Contract, Owner Contract. Each has its transactional and relational form. All inherit from the architecture’s form choice.
The Coupling
The counterparty contracts couple. This is the mechanical claim that makes the architecture a whole-business choice rather than a per-relationship choice.
Guest-side relational contracts require People-side relational contracts to sustain. A cast that is not being invested in cannot produce the hospitality a Guest under relational contract expects. Consideration deposited into the Cast Contract is what the cast then deposits into the Guest Contract across the shift. Break one and the other breaks with it.
People-side transactional contracts push Guest-side toward transactional as well. Staff running spot wage-for-hours have no structural reason to invest above the shift. What compensation covers is what they deliver. What they deliver is what the Guest receives. The Guest receives transactional execution, and the Guest Contract drifts into Customer Contract territory within a season.
The architecture holds the coupling. That is what the architecture IS — the recognition that the operator cannot run one form on one side of the business and the other form on the other side sustained over time.
How The Architecture Fails
The most common failure is not choosing a form deliberately. The operator inherits a transactional architecture from the industry default, adds hospitality signaling on top, and wonders why the counterparties audit the mismatch.
The signal is loud. The delivery is transactional. The counterparties feel the gap. Guests read as customers. Cast reads as staff. The Guest Contract the operator thought they were running was never actually built, because the architecture underneath it was transactional.
Another failure is running one form on the Guest side and the other on the People side. This produces the doom-loop pattern: relational-signaling Guest side, transactional-execution People side, cast burning out because the labor asked of them is relational while the compensation is transactional, Guests drifting because the hospitality signaling is not matched by the delivery, and the operator increasing pressure on the cast to close the gap, which accelerates the collapse.
A third failure is downgrading the architecture under pressure. Financial stress or throughput demand pushes the operator to strip consideration out of the Relational Contract without formally downgrading it to a Transactional Contract. The signaling stays relational. The delivery goes transactional. The counterparties audit and leave.
How The Architecture Compounds
A Relational Contract architecture compounds when it is chosen deliberately and held under pressure.
Consideration deposited into every counterparty contract simultaneously creates a business where Guest returns compound, cast tenure compounds, vendor relationships hold under supply pressure, community embeddedness deepens across years. Each compounding effect reinforces the others. The Relational Compounding mechanism runs across the entire architecture, not just within one counterparty contract.
A Transactional Contract architecture, run well, compounds reputation for reliability at the market level. This is a real form of compounding. Reliable execution across thousands of transactions builds a market position competitors cannot cheaply match. But it does not compound relationships with specific counterparties. Different mechanism. Different economics.
Load-Bearing Sentence
The choice of contract form is a whole-business choice. The operator does not choose per counterparty. The operator chooses for the architecture, and every counterparty contract inherits the form the architecture is running in. The forms couple. There is no stable middle.
What Changes Tomorrow
The operator audits which form the architecture is actually running in. Not the marketing claim. Not the training material. What the operation is doing across every counterparty relationship right now. If consideration is being deposited above compensation across Guest-side, People-side, and vendor-side simultaneously, the architecture is relational. If any side is running transactional while the others are running relational, the architecture is broken and drifting toward transactional. If nothing is being deposited above compensation anywhere, the architecture is transactional whether the operator named it that way or not. Naming the current architecture honestly is the first move. Deciding which architecture the business is designed to run is the second. Building the coupling that holds the chosen form under pressure is the third.



