EM-COM-04 · Subject model · W1
Customer inquiry and service request
External inquiry, service request, communications and resolution. An incident is a separate fact of disruption linked to many inquiries.
Partially published; research continues
Claude: complete-frozen-dossier-study; Grok: complete-browser-study.
Published results
Research note, in Russian: Parent canonical assurance and outgoing-relation approval; correction of the WM-KNW-014 CHILD/parent contradiction; confirmation of the WM-ACT-027 permission reference; standards and product crosswalks.
Subject boundary and candidate types
- CustomerCase
- ServiceRequest
- CaseInteraction
- CaseResolution
Deep research questions
- How to merge repeated inquiries without losing history?
- When does a request trigger an incident or work?
- What does closure mean from the customer's point of view?
Verifiable invariants
- An inquiry has a requester or an anonymous mode
- Closure does not prove customer agreement
- Several inquiries can reference one incident
End-to-end acceptance scenario
Model a mass outage with one hundred inquiries, individual responses and a single root-cause fix.
Negative case
One hundred complaints create one hundred independent technical incidents.
Approaches to compare
- TM Forum SID: party/customer/product/service
- OASIS UBL: trade documents and exchange
- CRM/CPQ/order management practice: stages and source boundaries
Candidates in the live catalogue
- WM-ACT-021 · Service Case / Ticket · 0.3.0-research.1 · installable
Semantic fit requires boundary research; a published model does not by itself complete this card.
Result requirements
Every card is executed together with the full research contract: definitions, fields and cardinalities, lifecycle, sources, data mastership, rights, the five object facets, at least eight invariants, positive and negative examples, dependencies, migration and applicability limits.