Case study 1 – Process description from the semantic model
AI formulates the MQLS quality process as a coherent specification for the business domain: purpose, roles, context, flow, states and rules — derived from the semantic model.
Business purpose
The Material Quality Lot Submission (MQLS) is the central business object for assessing the quality of a material lot provided by a supplier. It gathers all information and evidence required to judge whether the material is suitable for further use.
This includes in particular:
- data about the material lot and the related part
- information about the supplier and manufacturing
- applicable quality requirements
- test results and further quality evidence
- documents and attachments
- release decisions and approvals
The MQLS controls the business lifecycle from creation by the supplier through customer-side review to final acceptance or rejection. A distinctive feature is that shipment may be authorised explicitly before final acceptance.
Roles involved
The process essentially distinguishes supplier side and customer side.
Quality Supplier — A user with this role can:
- create an MQLS for a part related to the supplier
- edit and publish business data
- forward the MQLS to the customer
- revise a returned MQLS and forward it again
- delete an MQLS in the states Created or Returned
Quality Customer and Quality Manager — Customer-side decisions may be taken by a user with the role Quality Customer who is also assigned as the responsible Quality Manager of the MQLS. This user can return a submitted MQLS to the supplier, authorise shipment, reject the MQLS, or declare final acceptance.
Assigning a responsible Quality Manager is therefore not only organisational information, but part of authorisation.
Quality Admin — Supports administration and selected publications where the model requires elevated rights.
Business context of the MQLS
The MQLS is embedded in a network of related contexts: supplier ownership, user context, part context, approval requests, attachments and notifications. These contexts carry meaning that a pure activity sequence cannot express on its own.
Business flow (overview)
On the supplier side an MQLS is created, completed, published and forwarded. On the customer side it can be returned for revision, rejected, authorised for shipment, or — after further checks — finally accepted or rejected.
Creating the MQLS
Creation requires the Quality Supplier role and available supplier ownership, user and part contexts. The MQLS enters the state Created and the domain event MQLS Created is published.
Work by the supplier
In Created, the supplier completes data, publishes updates and, when the MQLS is consistent and complete, forwards it to the customer. From Created the supplier may also delete the MQLS.
Customer-side review
In state Forwarded, the assigned Quality Manager can publish, return the MQLS for revision, reject it, or authorise shipment if data are consistent and correct.
After shipment authorisation
State Authorized for Shipment is a preliminary shipping decision, not final quality acceptance. From here the MQLS can still be rejected or finally accepted once approval and consistency conditions are met.
Final acceptance
With Accept Finally the Quality Manager confirms that the required quality conditions for the MQLS have been met. The model requires, among other things:
- at least one positively decided approval request
- a positive decision by a second approver where required by the guard
- consistent and correct MQLS data
- role Quality Customer
- assignment of the acting user as responsible Quality Manager
After a successful decision the MQLS enters Finally Accepted. Final acceptance also publishes the final status, finalises the MQLS context, closes remaining approval requests, finalises related approval, attachment and notification contexts, and derives a final letter and closing notification.
Final rejection after shipment authorisation
Even after shipment has been authorised, the MQLS can still be rejected. This makes clear that “Authorized for Shipment” is only a provisional shipping decision, not final quality acceptance. Rejection leads to state Rejected and finalises dependent contexts accordingly.
Deleting an MQLS
An MQLS can only be deleted on the supplier side in states Created or Returned. An MQLS already forwarded to the customer or authorised for shipment can no longer be deleted by the supplier. Deletion leads to state Deleted and deactivates the MQLS context including related approval requests, attachments and notifications.
Business takeaway
Event Storming surfaces the business reality. The semantic model then holds meaning, states, roles and rules so that process views, decision logic and technical artefacts can be derived consistently.