[Guest Contract]

Definition #

The per-visit Contract signed between operator and Guest at each arrival under [The Hospitality Contract]. The relational-form Contract that governs one specific visit — from arrival through departure — and compounds across visits into accumulated Guest tenure and Guest history.

Canonical, top-level, Guest-side. The [Guest Contract] is the per-visit instance of [The Hospitality Contract] running at the individual Guest arrival. It is what the Guest and operator co-sign — invisibly, without paperwork — across the relational touchpoints of the visit, and what the operation either honored, drifted from, or violated by the time the Guest walked out. Every Guest arrival opens a fresh Guest Contract instance. Every departure closes one, either as a Contract-honoring visit that compounds Guest tenure or as a Contract-defaulted visit that erodes the operation’s relational standing.

The Guest Contract contains three elements: offer (what the operator presents), acceptance (Guest chooses to engage), and Consideration (Road 2 form — deposited above compensation, accumulates across visits). Parties are the Guest and the operator, delivered through the cast in the room. The exchange (food, drink, service) is the vehicle; hosting is the point. Tech is operator plumbing, not a party to the Contract. Signed at every visit — each visit a fresh re-signing with the Guest evaluating whether the Contract’s terms have been honored since the last visit.

Mechanism #

The Contract opens with the relational ask, not with transactional signaling. The Guest arrives seeking hosting — presence, memory, recognition, care, standards. The Contract’s terms are shaped by that ask, and the ask is relational: to be seen, to be remembered where earned, to be hosted by cast whose posture reads as present rather than staged. Operations that read the Guest arrival and default to transactional execution misread the Contract’s opening terms and produce hospitality theater that reads as staged even when well-intentioned.

The Contract runs on produced hospitality delivered through developed cast. The relational touchpoints — the arrival greeting, the recognition of returning Guests where earned, the memory of prior visits, the presence sustained through the visit, the recovery when something breaks, the departure — are the mechanisms through which the Contract executes. Each touchpoint holds or defaults the Contract. But unlike the transactional Contract, the touchpoints are not standalone; they compose a relational arc across the visit, and the arc composes across visits into Guest tenure. Held touchpoints compound the Contract’s relational standing across visits; defaulted touchpoints leak it, and enough accumulated defaults terminate the Contract silently through Guest defection.

The Contract does not close at the check. This is the defining structural feature. The Guest Contract runs beyond the check because Consideration deposits above compensation and accumulates across visits. Compensation exchanges at the check; Consideration deposits into a relational bank the operator and Guest hold jointly across time. The next visit reopens with a balance already carried forward — Guest tenure, Guest history, Guest recognition, operator memory. Operators who read the Guest Contract as closing at the check are running Contract-form mismatch; the Contract closes at Guest tenure-out, not at check-close.

The Contract holds through moment-holding, not through predictability. Where the [Customer Contract] holds through predictability — the transaction the Customer expected, delivered at the timing they expected — the Guest Contract holds through the specific moment the Guest arrived to have held. The regular’s birthday visit. The couple’s anniversary. The Friday night after a hard week. The moment does not repeat. The operator’s job is to read the moment in real time and produce the hospitality the moment calls for. Predictability without moment-holding is Road 1 execution running under Road 2 marketing; moment-holding without predictability produces inconsistent hospitality that erodes the Contract by delivering hosting the Guest cannot count on.

Improvements convert to commitments at re-baseline. An improvement the operator introduces starts as a discretionary deposit — a perk, an enhancement, an upgrade the Guest was not contracted for. The Guest experiences it as Consideration above compensation. But the moment the operation re-baselines around the improvement — the improvement becomes the operating standard, Guests now expect it at every visit, the improvement enters the Guest’s mental model of what the operator produces — the improvement has converted from perk-status to Contract-status. It is now inside the terms the Guest is re-signing at each visit. Removing it is not a discretionary rollback; it is a Contract-breach.

Re-baseline is the conversion moment. Re-baseline happens when the improvement is no longer being noticed as an addition and starts being noticed only in its absence. The operator’s tell: the improvement has stopped generating “wow” reactions and started generating no reaction — until it fails or is removed, at which point it generates complaint, defection, or silent-churn signal. That silence is the conversion. The Guest has absorbed the improvement into their baseline expectation of the Guest Contract. It is now inside the Contract.

Once inside the Guest Contract, the improvement stays inside until re-baseline-out. The operator cannot remove a Contract-status improvement without either a new offer the Guest re-signs against at next visit or accepting the Contract-breach and its consequences. Re-baseline-out is possible but requires deliberate operator work: reduce the improvement gradually while introducing offsetting Consideration elsewhere, or restructure the offer so the Guest is re-signing a Contract that does not include the improvement. Neither is a discretionary rollback; both are Contract-work.

Cross-Guest asymmetry. Different Guests re-baseline at different rates. A first-visit Guest may still be in perk-appreciation mode while a monthly regular has fully re-baselined. The improvement is in Contract-status for the regular before it is in Contract-status for the first-time Guest. The operator’s read must distinguish which Guest-segment has re-baselined and which has not; Contract-status is Guest-segment-specific until universal re-baseline occurs.

The Contract terminates through defection, not through complaint. The Guest does not typically complain about a defaulted Contract; they simply do not return, and they tell others relationally — “it’s not what it used to be,” “they don’t know us anymore,” “the room felt different.” Defection is the termination mechanism. Every defaulted touchpoint accumulates relational debit the Guest registers even when they do not articulate it, and enough accumulated debit closes the Contract without a moment of confrontation. Silent churn is the honest signal on the relational side.

Load-Bearing Distinction #

Not [The Hospitality Contract]. The Hospitality Contract is the whole-business Contract form — the relational-form choice at the [Restaurant Contract Architecture] level. The Guest Contract is the per-visit instance the Hospitality Contract runs as, at one specific arrival, for one specific Guest, for one specific visit. The Hospitality Contract is architecture; the Guest Contract is execution. Operations that run the Hospitality Contract as their whole-business form and default the per-visit Guest Contract are running architecture without execution — a stated relational posture no individual Guest arrival actually experiences cleanly.

Not [The Customer Contract]. The Customer Contract is the paired opposite per-visit Contract on the transactional side. The two Contracts have different opening terms, different execution mechanisms, different closing points, different compounding outputs. The Guest Contract opens with a relational ask; the Customer Contract opens with a transactional ask. The Guest Contract holds through moment-holding; the Customer Contract holds through predictability. The Guest Contract does not close at the check; the Customer Contract closes at check-out. Operators who conflate the two lose the actor-plus-Contract-form structure the framework needs to read the operation correctly at the per-visit scale.

Not [The Cast Contract]. The Cast Contract is the counterparty Contract on the People-side of the [Restaurant Contract Architecture]. The Guest Contract is the counterparty Contract on the Guest-side. The two couple structurally — the cast is the execution instrument through which the Guest Contract runs, and a defaulted Cast Contract silently breaks every Guest Contract downstream — but they are distinct instruments running on distinct counterparties.

Not a discretionary rollback when a re-baselined improvement is removed. Once an improvement has converted to Contract-status at re-baseline, removing it is a Contract-breach with defection consequences, not a discretionary standard-adjustment. Operators who treat re-baselined improvements as still-discretionary conflate the perk-status window with the Contract-status window and produce silent Guest defection they cannot see.

Not a lesser Contract than the whole-business Hospitality Contract. The Guest Contract is not a diminished form of its parent. It is the per-visit instance where the parent’s terms actually meet the specific Guest. An operator running clean Guest Contracts across every Guest arrival is running the Hospitality Contract; an operator running defaulted Guest Contracts is not, regardless of what the marketing claims.

Not signed by the tech. Tech is operator plumbing behind the cast — reservation systems, POS, guest-recognition tools, ordering platforms. Tech can facilitate the cast delivering the Guest Contract but cannot deliver it itself. Only humans produce hospitality. Operations that outsource the Guest Contract to tech (tablet ordering as substitute for cast, algorithmic recognition as substitute for operator memory, automated follow-up as substitute for cast presence) are defaulting the Guest Contract while claiming to run it.

Not identical to Cast, Vendor, or Community Contracts. These are counterparty Contracts on the People-side, Vendor-side, and Community-side of the Restaurant Contract Architecture. The Guest Contract is the Guest-actor-side, relational-form per-visit instance. The counterparty Contracts couple structurally but are distinct instruments running on distinct counterparties.

This term is load-bearing because operators default to two errors at the Contract-instance scale: treating every Guest arrival as a transactional exchange (which imposes Road 1 execution on a Guest arrival and produces silent defection), or treating the whole-business Hospitality Contract as sufficient without engineering per-visit execution (which leaves the Guest Contract to whatever the shift produced). Naming the Guest Contract as a legitimate per-visit Contract with its own execution discipline is what forecloses both errors.

Diagnostic Tests #

Test One — The Ask-Match Test. For one recent Guest arrival, ask whether the Contract the operation produced matched the Contract the Guest arrived to sign. Guests signing the Guest Contract arrived for hosting, not transaction. If the operation delivered present, memory-carrying, moment-holding hospitality, the ask matched. If the operation defaulted to Road 1 transactional execution while the marketing claimed Road 2, the ask failed. The ask-match diagnostic is the per-visit read of whether the Contract-form architecture actually held at the specific arrival.

Test Two — The Moment-Holding Test. Name the specific moment the Guest arrived to have held on their most recent visit — the birthday, the anniversary, the reunion, the celebration, the recovery-from-hard-week, the ordinary Tuesday that mattered because they chose to spend it here. Then read whether the operation read the moment and produced hospitality the moment called for. Moments not read are Contract defaults even when the transactional execution ran clean.

Test Three — The Memory Test. For five recent returning Guest arrivals, name what the operation remembered from prior visits and reflected back to the Guest in this visit. Not through a CRM screen — through cast recognition, operator presence, and environmental continuity. Guests who returned and were treated as if it were their first visit have received a defaulted Guest Contract regardless of how the transaction ran. The memory test reads whether the Contract’s cross-visit continuity is executing.

Test Four — The Recovery Test. Name a recent visit where something broke — a wrong order, a delayed table, a service failure, a Guest complaint. Read whether the recovery preserved the relationship (Contract-honoring recovery) or settled the ticket (Contract-defaulted recovery). Recovery that reads as transactional under a Road 2 marketing frame is Contract-breach on top of the original break.

Test Five — The Re-Baseline Test. For each specific improvement the operation has introduced over the past two years — a new touchpoint, a raised standard, a service enhancement, a recognition practice, a hospitality investment — read whether the improvement is currently in perk-status or Contract-status. Guests who still notice the improvement as an addition and comment on it as extra are in perk-status. Guests who no longer notice it until it fails or is removed are in Contract-status. Improvements in Contract-status are inside the Guest Contract; their removal is a Contract-breach even if the marketing frames it as a discretionary rollback.

Test Six — The Consideration Bank Read. For the operation’s regular Guests, name the Consideration deposits the operator has made across visits above compensation — the recognition earned, the memory carried, the specific hospitality that composed across time. Then read whether the Guest is depositing Consideration back — presence, return-rhythm, referral behavior, willingness to reciprocate. Symmetric Consideration flow indicates a compounding Guest Contract; asymmetric flow indicates either operator over-investment against a defecting Guest or operator under-investment against a still-committed Guest.

Test Seven — The Silent-Churn Read. Read the retention curve for the past twelve months on Guests who arrived under Guest Contract framing (relational marketing, recognition-eligible, tenure-carrying). Silent defection with no complaint is the Guest Contract’s honest termination signal. Defection rate against Guest-Contract-eligible arrivals reads Guest Contract execution more accurately than complaint volume or Guest-satisfaction surveys.

Test Eight — The Cast-Contract Coupling Read. Ask whether the cast delivering the Guest Contract has themselves received Hospitality Contract terms — Road 2 wages, Road 2 development, Road 2 tenure investment. Cast running Road 1 Cast Contracts cannot produce Road 2 Guest Contracts because they have not received hospitality. The coupling read is the diagnostic for whether the Guest Contract can hold at all, regardless of intent.

Family Position #

Canonical, top-level, Guest-side. The [Guest Contract] is the per-visit instance term inside the [Restaurant Contract Architecture]. It sits under [The Hospitality Contract] as the per-visit form the relational Contract runs as, and it pairs with the [Guest Experience] as the Product whose execution produces the Contract’s terms. Every relational execution discipline, every moment-holding mechanism, and every Consideration-deposit instrument in the framework resolves against a clean read of the per-visit Guest Contract.

Perspective application. The Guest Contract is one of the operator’s central per-visit reads in Perspective, alongside the [Customer Contract]. Every operating principle the operator holds resolves against what each per-visit Contract requires from the operation on the specific arrival. Operators who read only the Guest Contract miss the Customer Contract executing daily and underserve the transactional-actor side. Operators who read only the Customer Contract miss the Guest Contract executing daily and underserve the relational-actor side. The Perspective read holds both Contracts as legitimate per-visit reads.

Product application. The Guest Contract is the Contract instance the [Guest Experience] execution produces. The GX is the relational Product; the Guest Contract is the relational Contract the GX produces. Product design serves the Guest Contract — every relational touchpoint engineered to hold the Contract’s terms across the visit and across visits. Operations engineering the GX without reading the Contract it produces are engineering components without the reference frame that composes them into a Contract-honoring visit.

People application. The cast is the execution instrument through which the per-visit Guest Contract runs. Role design, cast development, and lead structure include the relational read — how the cast identifies a Guest arrival, matches presence to the moment, executes the touchpoints against the standard, and holds recognition and memory across visits. The counterparty [Cast Contract] couples with the Guest Contract; a defaulted Cast Contract silently breaks every Guest Contract downstream. The People architecture holds both Contract-execution modes or drops both.

Performance application. The Guest Contract is a per-visit and cross-visit Performance read on relational metrics — Guest tenure, return-rhythm, referral behavior, moment-holding cadence, recovery-preserving recovery rate, re-baseline diagnostic sustainability. These metrics read Guest Contract execution correctly. In a Road 2 operation, these are the primary Performance reads. In a Road 1 operation, they read the mixed-actor Guest arrivals the operation happens to receive but does not primarily architect for. The Performance layer reads both Contract-execution modes simultaneously.

Profit application. The Guest Contract is the deposit mechanism for relational Consideration and long-run [Relational Compounding] profit. Every per-visit Contract executed cleanly compounds the operation’s relational standing and produces accumulated Guest tenure that funds long-run profit even in periods of transactional softening. Road 2 operations run on this compounding mechanism as their whole profit architecture. Both compounds — transactional reputation (Customer Contract) and relational tenure (Guest Contract) — are legitimate profit sources; neither substitutes for the other.

Cross-References To Locked IP #

Parent:

• [The Hospitality Contract] — the whole-business Contract form the Guest Contract is the per-visit instance of

Related:

• [Guest] — the actor signing the Contract

• [Customer] — the paired opposite actor; the Customer signs [The Customer Contract], not the Guest Contract

• [Guest Experience] — the Product whose execution produces the Contract’s terms

• [Customer Experience] — the paired opposite Product; produces the Customer Contract, not the Guest Contract

• [The Customer Contract] — the paired opposite per-visit Contract on the transactional side

• [Restaurant Contract Architecture] — the whole system of Contracts the Guest Contract sits inside

• [The Service Contract] — the paired opposite whole-business form

• [Two Roads] — the whole-business fork the Contract form choice runs on

• [Road 2] — the relational Road the Guest Contract is the native per-visit instance of

• [Customer-Guest Gap] — the diagnostic that reads when the Customer Contract runs for a Guest arrival by default

• [Reciprocity Test] — the Guest’s somatic read of Contract-honoring vs Contract-defaulting execution

• [Consent Erosion] — the mechanism by which the operator unilaterally shifts Contract terms without Guest re-signing

• [Consent Arbitrage] — the operator posture of extracting from the Contract without honoring its terms

• [2P Arbitrage] — the third-party mechanism that reshapes Guest Contract terms without Guest consent

• [Guest History] — the accumulated record of prior visits that composes into the Contract’s cross-visit continuity

• [Connection Floor] — the operator’s designed minimum below which the Guest Contract has been defaulted

• [Experiential Loop] — the cross-visit compounding pattern the Contract runs on when held

• [Relational Compounding] — the profit mechanism the Guest Contract deposits into

• [Native GX] — the operator-produced Guest Experience the Contract runs on when the parent form is honored

• [Lost Opportunity Tax] — the invisible cost of defaulted Guest Contracts compounding through silent churn

• [The Cast Contract] — the People-side counterparty Contract that couples with the Guest Contract

• [Operator Arbitrage] — the operator posture of extracting from Guest Contract framing while running Customer Contract execution

• [Never Treat A Guest Better Than An Employee] — the enforcement mechanism linking Cast Contract execution to Guest Contract sustainability

Opposing patterns:

• [Operator Arbitrage] — the operator posture of marketing Road 2 Guest Contracts while executing Road 1 Customer Contracts

• [Consent Erosion] — the unilateral operator shift of Contract terms that produces breach the Guest registers silently

• [Hacksterism] — the shortcut posture that mimics Guest Contract execution without producing hospitality

• [Substrate Seduction] — the misread that treats food or room quality as sufficient to honor the Guest Contract; ignores that the visit itself has architecture

• [Static Decline] — the operator condition of reading “the regulars keep coming back” as evidence the Contract is compounding, when accumulated Consideration deposits are running out and the current Contracts are not renewing

• [The Vocabulary Theft] — the industry misuse of “hospitality” and “guest” that obscures the Guest Contract’s actual architectural requirements

• [The Road 2 Equivocation] — the operator posture that claims hospitality supremacy while defaulting the Guest Contracts the operation’s long-run tenure depends on

Why This Matters #

Every operation with any Guest arrivals produces Guest Contracts — either designed and executed cleanly, or defaulted into whatever the shift produced. The Guest Contract is the relational Contract the operation’s long-run tenure runs on. In a Road 2 operation, the Guest Contract is the whole per-visit Contract, and executing it cleanly across visits is the operation’s whole compounding mechanism. In a Road 1 operation, the mixed-actor Guest arrivals still produce Guest Contracts the operation is either honoring or defaulting silently. Both Roads require the Guest Contract designed to a standard, not defaulted to instinct.

The industry’s default failure mode at the Guest Contract scale is [Operator Arbitrage] — marketing Road 2 to attract Guests and executing Road 1 in the room. The Guest arrives expecting the Contract the marketing signaled and receives the Contract the operation actually built. The gap is felt somatically by the Guest even when it is never articulated. Some complain (recovery cost line). Most defect silently (silent churn LTV bleed). The operator running arbitrage extends the runway with more marketing, and the acquisition treadmill funds the replacement of the Guests who felt the failure and did not return.

Naming the Guest Contract as a legitimate per-visit Contract with its own execution discipline forces the operator to design it. The operator cannot claim to serve Guests well when the Guest Contracts running daily have no engineered relational architecture, no moment-holding capacity, no cross-visit memory infrastructure, no cast development sufficient to produce the Contract. The naming produces the design obligation. Operators who accept the obligation run the Guest Contract cleanly and produce the relational tenure the operation’s long-run compounding requires. Operators who reject the obligation default the Guest Contract and lose Guests silently to whichever operation next door manifests the Contract at the level the marketing claimed.

This term is load-bearing across the whole framework because [The Hospitality Contract], [Restaurant Contract Architecture], [Two Roads], [Operator Arbitrage], [Consent Erosion], [Relational Compounding], [Lost Opportunity Tax], and every Road 2 compounding mechanism resolves against a clean read of what the Guest Contract is and whether it is executing or defaulting. Without the term named at the per-visit scale, the relational side collapses into marketing claim without operating expression, and the arbitrage runs on unchallenged. Clarity — the Guest Contract as a legitimate, engineered, per-visit relational Contract with its own compounding output — is the operating discipline the framework requires on the relational side.

Operating Consequence #

Legitimize the Guest Contract as a designed per-visit Contract. Every operation with Guest arrivals produces Guest Contracts daily — the mixed-actor arrivals include Guests on Guest visits, Customers on Guest visits, and every combination in between. The Guest Contract runs daily whenever a Guest arrives; the only question is whether it is designed or defaulted.

Engineer the relational touchpoints for moment-holding. Write down the observable relational standard at each touchpoint — arrival greeting for returning Guest recognition, memory-carrying protocol for regular Guests, moment-reading cadence for special-occasion visits, presence-holding standard through the visit, recovery-preserving recovery protocol when something breaks. These are not scripts. They are cast-executable behaviors the operator has designed the operation to produce.

Match the operation’s presence to the Guest ask. The Guest arrives for hosting. Train cast to read the arrival signal and match presence to the moment. Guests get present relational hosting; Customers get efficient competent execution. Cast that cannot distinguish the two are running both Contracts badly.

Refuse transactional shortcuts on Guest arrivals. When the arrival signal reads Guest, the operation delivers hosting, not transactional efficiency. Under-serving a Guest reads as indifference regardless of how clean the transaction ran. Efficiency without presence is Contract default on the relational side.

Refuse [Operator Arbitrage] as an operating posture. Marketing Road 2 while executing Road 1 is arbitrage running through the Guest Contract at every arrival. The Contract cannot hold under arbitrage. Either the marketing rescales to match the built architecture or the built architecture rescales to match the marketing. There is no third position.

Treat re-baselined improvements as Contract terms, not discretionary standards. Any improvement introduced to Guest-side execution — a recognition practice, a hospitality investment, an amenity added, a service enhancement, a moment-holding standard raised — carries a future-Contract cost the operator must accept at introduction. Once Guests re-baseline around the improvement, it has converted to Contract-status. Removing it is Contract-breach, not discretionary rollback. Before removing anything, run the perk-vs-Contract-status diagnostic on that specific improvement across Guest segments.

Read [VoG] as the Contract’s re-baseline signal system. The re-baseline conversion runs through Guest expectation shifts that show up in return-behavior, silence-where-comment-used-to-be, complaint-when-absent, and ask-when-degraded — not through announcement. The Voice of Guest reading discipline surfaces these signals; operations running Road 1 aggregate reads miss the conversion because the platform-mediated signal does not track the specific-Guest-signal shift.

Accept the cost of introducing an improvement is the cost of sustaining it. Introducing improvements the operation cannot sustain is Contract-fragility on the Guest side. The improvement enters Guest expectation, the operation cannot sustain it, and the rollback generates silent defection the operator cannot see. Either sustain what has been introduced or do not introduce it in the first place.

Instrument the return-rhythm and Consideration bank, not just complaint volume. Guest Contracts terminate through defection, not through complaint. Return-rhythm shifts, referral-behavior shifts, ask-behavior shifts, and Consideration-deposit asymmetry read the Contract’s silent termination before the retention curve records it. Complaint volume is lagging; return-rhythm is leading on the relational side.

Couple the Guest Contract with the [Cast Contract] deliberately. The cast is the execution instrument. A defaulted Cast Contract silently breaks every Guest Contract the cast executes. Operations under-investing in the cast while claiming clean Guest Contract execution are running incoherent counterparty Contracts — the Guest-side execution cannot hold when the People-side Contract is defaulted. Improvements-as-commitments on the Guest side without matching improvements-as-commitments on the Cast side is Cross-counterparty asymmetry that collapses both.

Design one Guest Contract touchpoint per period. Contract execution does not get rebuilt all at once. The operator picks the touchpoint carrying the most silent defection risk — the returning-Guest recognition moment, the moment-reading window at arrival, the memory-carrying protocol across visits, the recovery-preserving recovery cadence — and engineers the Contract-honoring behavior at that touchpoint. Named observable behavior. Developed cast. Enforced on the worst shift. Re-read next period. That is the Guest Contract improvement cadence.

What Changes Tomorrow #

Pick one Guest arrival this week — one specific returning Guest arriving on one specific visit — and read the Guest Contract from arrival through departure. Name the moment the Guest arrived to have held. Walk the relational touchpoints — arrival greeting, recognition, memory-carrying, presence-through-visit, recovery if anything broke, departure — and mark each one Held (Contract-honoring) or Defaulted (Contract-defaulted). Read whether the operation read the moment. Read whether the memory carried. Read whether the recovery preserved the relationship or settled the ticket.

Take the earliest Defaulted touchpoint on the visit — usually the recognition moment at arrival, the memory-carrying failure across visits, or the recovery-that-read-as-transactional — and write down in one sentence what the Contract-honoring observable behavior at that touchpoint looks like. Then write down what the operation defaulted to on this visit. The gap is the design brief for one Guest Contract execution touchpoint this month.

Add one more read to the same visit. List every relational standard the operation is currently holding on the Guest side that was NOT a Contract-standard two years ago. Recognition practices added over time. Memory-carrying infrastructure introduced. Moment-holding standards raised. Recovery protocols upgraded. Each of these is an improvement that has, at some point in the operation’s history, converted from perk-status to Contract-status. Name each and ask: is the operation currently sustaining this Contract-status improvement, or is the operation generating silent defection by allowing degradation from this Contract-standard? The list is the operation’s actual current Guest Contract on the relational-standard dimension — not the stated standard from the operating handbook, but the re-baselined standard Guest arrivals are actually re-signing against.

Engineer the Contract-honoring standard for the earliest Defaulted touchpoint first. Not the whole Contract. The one touchpoint where the Contract is leaking the earliest. Name the observable behavior in one sentence. Develop the cast on it. Enforce it on the worst shift with the least experienced cast under the most pressure. That is where the Guest Contract becomes an executed instrument rather than a defaulted output.

The operator’s read this week is the same read the framework asks every week: is the operation producing per-visit Guest Contracts that hold the relational standard, or per-visit visits that default the Contract while the architecture claims Contract discipline? The Guest Contract executes cleanly or leaks silently. Naming the per-visit Contract as the actual instrument is what makes executing it possible.