Request a Moving Quote

Why is this a Capability MLE? It has an independent purpose (a move gets presented for a quote), a determinable outcome (accepted, rejected, or needs-more-information), and stays meaningful regardless of which provider realizes it.

What does this example teach? The basic capability boundary and multiple Interaction Contract MLEs in a human-facing flow — draft, validate, submit — without conflating the reusable capability with any one provider's implementation.

Evidence status: illustrative / synthetic — written to teach the model, not extracted from a real moving-quote provider.

Identity and core meaning

NameRequest a moving quote

DefinitionEnable a prospective customer or authorized caller to submit sufficient moving details for a provider to begin the quote process.

Capability purposeEnable a move to be presented to a provider for quote consideration.

Meaningful outcomeA quote request is accepted for processing, rejected with an intelligible reason, or identified as requiring more information.

IncludesCollecting and submitting move details; validating the request; communicating the immediate submission outcome.

ExcludesCalculating final price; accepting a quote; scheduling a move; payment; ongoing quote-status tracking.

Interaction Contract MLEs

Create draft quote request

Actor: Prospective customer or authorized agent
Command / intent: Begin a quote request
Current state: No draft request exists for this interaction
Policies / invariants: None specified in this illustrative example
Transition: No request → draft quote request
Result: Draft request available for completion
Events / effects: QuoteRequestDraftCreated example event
Unknowns: Draft retention and identity requirements

Validate quote request

Actor: Prospective customer, authorized agent, or system
Command / intent: Validate supplied move details
Current state: Draft quote request
Policies / invariants: Required contact information and sufficient move details; serviceable route policy if applicable
Transition: Draft request remains draft, with validation result
Result: Valid · missing information · unsupported move
Events / effects: None known
Unknowns: Exact required fields and service-area definition

Submit quote request

Actor: Prospective customer or authorized agent
Command / intent: Submit a valid quote request
Current state: Valid draft quote request
Policies / invariants: The request must satisfy applicable validation rules
Transition: Valid draft → submitted request
Result: Submission confirmation or intelligible rejection
Events / effects: QuoteRequestSubmitted; confirmation delivery may be requested
Unknowns: Idempotency, routing, and confirmation channel

Rules and defaults

Rules / invariants

A submission requires sufficient information to identify the requester and proposed move. Example.
A provider may reject a route it does not serve. Example.

Recommended defaults

Preserve a draft when validation finds missing information rather than discarding entered details. Example.
Explain what information is missing in the validation result. Example.

Unknown / unresolved

Exact data schema
Provider rules
Authorization model
Operational workflow

Illustrative operational realization

ExposureResponsive web form, customer-service tool, API, and agent tool.

Operational constraintA particular provider may serve only configured geographic areas.

Implementation choiceAn API may expose separate draft, validation, and submission endpoints.

Rationale / intentA provider may implement this to obtain qualified leads; this is not part of the reusable capability purpose.

Related MLEs by Dimension

Traceability only — a dimension with no genuine content in this illustrative example is omitted rather than filled. Interaction/Behaviour and API/Interoperability are omitted here: the three Interaction Contract MLEs above already are this capability's behaviour, and no API shape is stated firmly enough to trace to (the operational realization only says an API "may" expose separate endpoints — a possibility, not a traceable reference). Operations is also omitted: nothing in this illustrative example states a monitoring, scheduling, or operational-runbook fact to trace to.

Dimension	Relationship	Ref	Notes
Business/Domain	constrains	Serviceable-route rejection rule ("a provider may reject a route it does not serve")	Example.
UX/Experience	supports	Draft → validate → submit flow; preserve-draft-on-missing-information default
Communication	defines	Quote Request Submitted Confirmation	See below.
Frontend/Interface	supports	Quote request form (draft/validate/submit)	Implementation choice.
Backend/Execution	implements	CreateDraftQuoteRequest, ValidateQuoteRequest, SubmitQuoteRequest use cases	Implementation choice.
Data/Information	implements	QuoteRequest, ServiceableRoute entities	Implementation choice.
Agentic	supports	`moving-quote-assistant` skill; `submit-quote-request` tool	Already declared elsewhere in this CRD; referenced here rather than restated.
Verification	verifies	"A submission is never accepted without sufficient identifying information"; "an unsupported route is rejected, not silently accepted"

Communication MLE: Quote Request Submitted Confirmation

Purpose: Confirm that the request was received and set an honest expectation for what happens next.
Trigger: Submit quote request succeeds (QuoteRequestSubmitted).
Audience: The prospective customer or authorized caller who submitted the request.
Required meaning: The submission succeeded; the request is now stored; no further action is currently required from the requester; there is a next step, even if its exact timing is unknown.
Terminology: Call it a "quote request," not an "application" or "order." Example.
Tone / style: Clear, calm, concise — a routine acknowledgement, not a sales pitch. Example.
Rule: Must not promise a specific response time unless a realization's operational commitment actually guarantees it. Implementation requirement — mirrors the capability's own "intelligible rejection" standard.
Recommended default: If no guaranteed response time exists, say something like "we'll be in touch soon" rather than inventing a number. Example.
Possible realizations: Inline confirmation screen; email; SMS; agent response.
Example copy: "Thanks — your moving quote request has been received. We'll be in touch soon." Example.

This is the second worked trial of the Related MLEs by Dimension / Communication MLE model (the first, on reconcile payments, tested an internal capability with no direct UI). This one is customer-facing and confirms the model holds for that case too: the confirmation's required meaning is owned entirely by this capability's own Submit quote request contract, while the terminology convention ("quote request," never "application") is the kind of cross-cutting rule a Source Context Reference would hold if this illustrative provider had one.

Provenance

All statements here are illustrative examples. They must be replaced or confirmed when used for an actual service.