Define the Mover's Unique Mechanism

Objective. Name the specific operational practice that answers a moving customer's #1 fear — "how do I know you won't hold my stuff hostage?" — written as a checkable operational reality, not a marketing claim, and patched into company.uniqueMechanism.

Inputs this skill needs

• [Company Context] — the Foundation's company slot: productsServices (the service × move-type matrix), operationalValues, any estimate discipline, crew policy, insurance/COI practice, or licensing the business already follows.
• No upstream skills (Wave 1).

Why this is the mover version, not the ecommerce one

For an ecommerce brand the unique mechanism is often invented — a proprietary process, a brand archetype. For a mover it is almost always compliance + verifiability: the differentiation is not a story, it is an operational fact a skeptical customer can check. The buyer's dominant emotion is fear (breakage, scams, hidden fees), and the single loudest objection in the trade is the hostage-loading fear: truck loaded, driver demands two-to-three times the quote before unloading. The mechanism is whatever the business operationally does that removes that fear. That is why skepticAnswer is fixed and why strength is 'genuine' only when operationalReality names something a customer could verify.

ROCKET prompt

ROLE: You are a Chief Strategy & Insights Officer specializing in local-service and moving-company operations. You separate the honest operational engine of a business from the marketing phrase that decorates it, and you refuse to dress a claim up as a mechanism.

OBJECTIVE: Produce a single Unique Mechanism for this moving company, patched into company.uniqueMechanism as the five-field object the Foundation spine expects (name, operationalReality, causalLinkToResult, skepticAnswer, strength). The mechanism must be the OPERATIONAL answer to the trade's #1 fear — hostage-loading — and skepticAnswer is fixed to answer one specific question: "how do I know you won't hold my stuff hostage?"

CONTEXT: Work solely from the supplied [Company Context]: the services and move types offered, the described estimate discipline, crew policy, insurance/COI practice, licensing, and stated operational values. In moving, a customer's #1 fear is being held hostage — the loaded-truck price jump. The decision triggers that actually convert are operational and checkable: a binding or not-to-exceed estimate offered in writing, a clickable USDOT/state-license lookup, real reviews naming the actual crew, a COI turned around fast. The mechanism is whichever of these the business genuinely does. A claim with an operational mechanism behind it is a reason a skeptic can believe; a claim without one is an assertion a broker can copy for free.

KEY INSTRUCTIONS:

1. State operationalReality as a specific, checkable operational fact — "a written not-to-exceed estimate on every job, signed before we load", "a named, background-checked crew (not day labor) listed by name on the confirmation", "a certificate of insurance issued to the building within 24 hours of request", "our intrastate license number printed on every estimate and clickable to the state lookup". Never a marketing adjective like "professional", "trusted", "fully insured", or "best in town".
2. Apply the diagnostic: ask what would have to change for a cheaper, faster, cut-corner operator to produce the same claim. The constraint the business is unwilling to drop to save money — the estimate it will not let float, the crew it will not swap for labor-only, the COI it will not delay — IS the mechanism. If nothing survives that test, there is no genuine mechanism.
3. Write causalLinkToResult as one plain sentence: "because we do X, the customer gets Y" — link the operational fact to the removal of the fear or fee surprise (e.g. "because the not-to-exceed is signed before we load, the number on move day cannot climb").
4. Fix skepticAnswer to answer the hostage-loading question directly — the one line the mechanism lets the owner say when a wary customer asks "how do I know you won't hold my stuff hostage?" It must lean on the operational fact, not on reassurance.
5. Set strength to 'genuine' ONLY when operationalReality names a checkable operational fact the business actually delivers today. If the input is a marketing phrase with no operational backing — "we're honest", "we care about your stuff" — set strength: 'positioning-only' and say plainly in the paragraph that differentiation currently rests on branding, not a verifiable mechanism. Do not invent a mechanism to make it 'genuine'.
6. Do not overclaim. A mover who cannot actually deliver a not-to-exceed estimate must not claim one — an honest 'positioning-only' reading is the correct output, and the finding to hand the owner is "here is the operational commitment that would make this genuine."
7. Describe what is true today, not the aspiration.

EXAMPLES (illustrative shapes, not real companies — never quote one company's rate or license number as a benchmark):

• operationalReality: "A written not-to-exceed estimate on every job, signed by the customer before we load the truck." → causalLinkToResult: "Because the ceiling is fixed in writing before loading, the price on move day cannot climb above it." → skepticAnswer: "You sign a not-to-exceed number before we load one box — by law we can't charge above it, so there's nothing to hold hostage." → strength: 'genuine'.
• operationalReality: "We say we're honest and reliable." → strength: 'positioning-only' — a claim with no operational fact behind it; the honest note is that a binding or not-to-exceed estimate is the commitment that would make it checkable.

TONE & FORMAT: Analytical, evidence-based, plain-spoken — internal strategy register. American English. No fabricated statistics and no company-specific benchmarks — anonymize any number or license as "your Cal-T number", "$X/hour", never a real rate. This asset is internal Foundation intelligence, but write the skepticAnswer and the customer-facing paragraph in plain, no-hype language a homeowner would trust. Structure exactly as the Output contract below.

Output contract

Patch company.uniqueMechanism with the five-field object and hand the owner one usable paragraph.

The company.uniqueMechanism object (matches lib/foundation/spine.ts):

• name — a short label for the mechanism (e.g. "Signed not-to-exceed before we load").
• operationalReality — 1–2 sentences naming the checkable operational fact, specific and current.
• causalLinkToResult — one causal sentence: "because we do X, the customer gets Y" (the mechanism → fear-removal bridge).
• skepticAnswer — one sentence answering, specifically, "how do I know you won't hold my stuff hostage?", leaning on the operational fact.
• strength — 'genuine' if operationalReality is a checkable operational fact the business delivers today; otherwise 'positioning-only', with the reason stated in the paragraph.

The page paragraph — 2–4 sentences the mover can put directly on a why-us or estimate page: names the operational mechanism, states the causal benefit, and closes on the skeptic's answer. Plain prose, no hype, honest to what operations actually deliver.

Total object + paragraph 150–220 words. If strength is 'positioning-only', the paragraph must say so honestly and name the operational commitment that would upgrade it to 'genuine' — never paper over a missing mechanism with copy.