Table of Contents
            Introduction
            Perspectives
                    02 - Mechanic Value Stream
                    03 - Planned Order
                    03a - Related to: Planned Order V5
                    05 - Order Confirmation
            Detailed Assertions
            Responsibilities


Introduction:

---

The Order Entry Example Assertion Model is intended to provide a detailed example of Order Entry. It is intended to generate specifications that can be used (automatically or by hand) to create software that supports Order Entry using a Bounded Context, DDD approach. The model is intended to provide a balance between typical over-simplified descriptions of order entry, and a fully articulated description of a very complex business domain. It has been sized to present some typical challenges of automating the complexity. Its scope is described in the Domain Summary below.

A consistent language for 'order entry' has been attempted. That can only be validated by subject matter experts. Trying to establish accurate language as part of this example should be minimized to concentrate on understanding and developing strong specification.

This example also includes the business challenge of categorizing parts. This categorization is implemented as business rules, and their role in assertion modeling, and in implementation, must be addressed head-on. ..

Business Architecture Perspective
This example spans or touches the followng Business Capabilities

• Customer Management, Order Management, Product Management


• Inventory Management


• Fulfillment


• Billing and Invoicing


• and Payment Processing

Typical broader strategies are at play in this example.
They are - Customer-Centric Positioning and - Content Marketing
As a result of this focus the initiative is to build capability to capture an order for a customer. The custome pain point is finding the right product at the right price. And having the Customer understanding enough about the product that they are pleased with the purchase.
This emphasis is reflected by providing search capability to directly support the customer and which present the sellers products. and it is to provide wnough information to avoid returns or customer dissatisfaction.

To do this information feeds into the customers decision to shortlist or.....


Domain Summary:
This domain will encompass a part of the sales function within a medium sized auto parts supplier named Parts Partner(PP).
Assume this is an auto parts supplier with 30 outlets across 5 regions. Parts are stocked at outlets and can be ordered online or at the counter. There are about 30 part suppliers who ship to the outlets. Other pertinent functions in the organization are Marketing, Finance and Procurement.
To bound this model, all parts are picked up at the warehouse by the customer.
PP is considering partnering with shippers to support home delivery. This will be a future modeling challenge. For the supply side PP tries to avoid parts outages in warehouses and tracks stock levels for ordering. This aspect is recognized but not fully articulated.
A competative advantage of PP is to support mechanics by helping them identify needed parts. If PP can help potential cuistomers troubleshoot, they are much more likely to get an order.
The customer journey is important to PP. The perspective 'Mechanic Value Stream' shows the decisions a mechanic makes and where PP aims to provide its software to support the mechanics decisions. PP aims to automate some of these mecanic assertions.
Model limitations and scope:-
- For this pass we will assume there is no purchase on account(No Billing).
- A partnership with a payments organization is assumed. Payments will be established before a contract is confirmed.
- Assume no purchase orders are accepted for this version.
- Assume no Back Orders (needs more modeling).
- This model does not recognize groups of parts packaged and sold separately.
- Pricing and Billing are not included in this model.
- Refunds are not considered.

---------------------------------------
The Story:
The Parts Manager decides the parts to be carried, how they are named and their categoties.
The Sales Manager decides on Prices.
THe Warehoue Manager is responsible for the parts in theri warehouse.They track incoming and outgoing.
The Wa
Designer Note: These notes are used to assist the modeler in managing the configuration of the model. They do not constitute the model itself, and would probably not be exposed to users who would validate the model.
The modeling challenge will be to provide perspectives and implementations that are managable.
A major decision is whether this SW is custom buit within an organization, or is a general purpose SW product to be sold or licenced to retail organizations. Or is it targeted spcifically to autoparts.
This model has surfaced issues like the shopper who is a potential customer being allowed to shop.
And the ability to persist assertion configurations.
This model aims to include the extended environment of order entry information to assist in how contexts are identified.
The model should propose some BCs that mighjt fit DDD.
Note that AM is automatic, augmented, and manual.
The role of Envronment is coming to the forefront. and how it relates to BCs.
This has an example where for an order to be taken by PP payment confirmation must be executed. In Implementation this represents interaction outsid BCs and is good for the test. It also provides an implementation tesing scenario where, perhaps, surrogate testing interfaces must be established.
As a proofing model this also includes the challenge of authentication.

Also some suggestions for Bounded Contexts (BC) should be suggested as Perspectives. There should be the included Assertions and related assertions to show interactions.
External should show change in financial position and sales reporting feeding out. Nice to have something feeding in. Nice would be perhaps a business rule for size of order. (EG when a warehouse is cleaned out of a regular stock item that serves many ongoing customer needs)

All this complexity in this trial model is real. If it is not captured here then it is kicked over the fence to the agile team to discover verbally in meetings.

From Capability to Code: How the assertion model connects th

Version: 06           Modeler: Richard Lay


Perspectives

---

Perspectives provide a good way of isolating various business concerns out of the fully aligned business model itself.

01 - Model Contribution excluded



  02 - Mechanic Value Stream

---

This is a quick sketch to understand Customer viewpoint. The basic order is comitted by ME05 and it is this cubicle that PartsP will provide to Mechanic as a PPApp Client. At some point when the Mechanic (who has stepped into the Customer Authority) will bcCommit . The crux of PPApp design is the configuration capabilities provided to te Customer. At the basic level the customer browses a printed catalog and fils in an order entry form. At the other ned of the specturm, the PPCustomer uses a PPApp capability to plug in behavior and get suggested actions and parts. Understanding this spectrum can be an indicator of how PPApp might be expected to change over time as more features are added. Lets annotate this as a scenario. Start with ME03 where the Mechanic identifies a need for a specific part. In ME05 the Mech starts the search for tht needed part. (either uising a manual process or using a cubicle provided by PPart. If we assume the Cubicle is provided by PPApp then it must provide browsing and searching of PPParts Catalog. And an ability to build the output config that comprises the order. The output ( a collection of parts and how well tey meet the needs Including cost and delivery. eventually result in a config including current price that meets the need and the Mech (as individual) or Customer as logged in, will commit to te order. Payment details may be invoked if not part of customer. The final cost delivery etc is stated in ME05. And the Contract accepted in ME06. This is an intermediate milesone in the Mechanics Value Stream. And the start of a Fulfillment Value Stream for PP,
ModelNote
Just to support realistic PartsP App. As of 25-07-24 this is sketched out. to assist in understanding ME05 and ME06. Support for ME04 might be valuable. ME06 is Shipper and PP decisions. In this Perspective it is necessary for the Mechanic to bind to the Customer Role. This ties in with a more complex Mechanic Model that includes financial committments. Out of scope for now.


      ME00       ME02       ME07       ME06       ME05       ME01       ME04       ME03                   Diagram Name is: PI_78b66faa-2e64-4282-99d9-5b8c6124cd3a.png


  03 - Planned Order

---

This implementation perspective shows the domains and bounded contexts that will implement the Order Entry Application. On the right are three contexts in the Sales Domain. The Client UI Context will be implemented in a different Environment, here in the UI Environment. Dashed lines indicate that the information it passes will be pulled with a read. Solid lines indicate the information is sent(pushed) to another component. Assertions that are automatic ( they are determined from a script or rules engine defined by the authority) have a black border. Assertions that require the authority make the decision themselves are shown with an orange border. Three manual assertions are implemented in the Client UI. The dashed line from OE19 indicates that the Customer will request a filtered set of parts. This information is pulled from OE18r and will be displayed in the client UI.
ModelNote
TODO: There should be an additional manual assertion in the Client UI that shows the filtered Parts. TODO: the connectors for 18 r must be reviewed ! The suffix (pr) on the name indicates this is persistent and a retrieval. The suffix (pu) on the name indicates this is an persistent and a create, update, or delete.


      OE06       OE07       OE04       OE11       OE12       OE18r       OE19       OE29       BR02                   Diagram Name is: PI_05dd380d-dedb-404b-83af-2524ca37aa44.png


  03a - Related to: Planned Order V5

---

showing the original and related assertions
ModelNote
This was generated


      OE06       OE07       OE04       OE05       OE10       OE11       OE12       ME02       OE18r       OE19       OE29       OE28       BR02       OE16                   Diagram Name is: PI_708ff8a9-cf2c-4357-ac93-f628ac35c951.png


  05 - Order Confirmation

---

Assertions that cement the contract for a parts purchase. Order Confirmation It is necessary for an individual to provide credentials ( in OE09 Authority Identity) to establish an identity as a Customer. Then the OE10 Pending Order can be updated as being for a particular customer. Then a Customer can step into OE25 Intended Order to start completing the order. They will have to also step into OE26 as a Credit Cart Holder to identify Card credentials. Then the Sales Manager can automatically initiate a Sales Request with card credentials to the Payment Broker. PB01 will respond with confirmation details (or a refusal initiating perhaps OE25 to be reevaluated) When the Broker confirms the Payment the Sales Manager will confirm by informing the Mechanic (ME06), the Warehouse (OE24), and the Sales Department (FN01). The latter will initiate an accounting transaction, as will PB01 to reconcile it (within the financial records)
ModelNote
When the order is finally confirmed, which requires order items, customer, payments, then the customer is informed, the warehouse is informed and finance is informed. Currently the BCs and FE are not identified


      OE08       OE09       OE10       OE07       PB01       ME06       OE23       OE25       OE27       OE24       FN01       OE26                   Diagram Name is: PI_f733c0c6-9444-49ea-b745-2253fd66428e.png


Assertions

---

Assertions Tables of Contents
By SpecID: BR02 - Order Total Costs FN01 - Adjust Sales MD01 - This Model Value Proposition MD02 - Synergy From WAM and OrdEnt MD03 - Clear AM Possibilities for DDD MD04 - Opportunities for Modelers MD05 - Professionalism of WAM and OrdEnd ME00 - Indication of Normal and Abnormal Function ME01 - Vehicle Behavior ME02 - Test Actions ME03 - Resolution Proposal ME04 - Parts Source ME05 - Parts Order ME06 - Parts Delivery ME07 - Parts Replacement OE04 - Customer OE05 - Customer Purchase (a) OE06 - Part (pr) OE07 - Planned Order OE08 - Customer Identity (a) OE09 - Authority Identity (a) OE10 - Pending Order Cart (a) OE11 - Submitted Order OE12 - Full Sales Order (pu) OE14 - Payment Request OE16 - Warehouse Inventory (pr) OE18r - Available Parts List (pr) OE19 - Parts Filter OE20 - Order Items (p) OE21 - Payment Request OE22 - Payment Broker Authentication OE23 - Confirmed Order OE24 - Parts Committed OE25 - Intended Order OE26 - Payment Details OE27 - Payment Request OE28 - Category (pr) OE29 - Parts Category Items (pr) OE31 - Persisted Planned Order (pr) PB01 - Payment Confirmation PB02 - Payment Collected PR01 - Current Categories	By Name: FN01 - Adjust Sales OE09 - Authority Identity (a) OE18r - Available Parts List (pr) OE28 - Category (pr) MD03 - Clear AM Possibilities for DDD OE23 - Confirmed Order PR01 - Current Categories OE04 - Customer OE08 - Customer Identity (a) OE05 - Customer Purchase (a) OE12 - Full Sales Order (pu) ME00 - Indication of Normal and Abnormal Function OE25 - Intended Order MD04 - Opportunities for Modelers OE20 - Order Items (p) BR02 - Order Total Costs OE06 - Part (pr) OE29 - Parts Category Items (pr) OE24 - Parts Committed ME06 - Parts Delivery OE19 - Parts Filter ME05 - Parts Order ME07 - Parts Replacement ME04 - Parts Source OE22 - Payment Broker Authentication PB02 - Payment Collected PB01 - Payment Confirmation OE26 - Payment Details OE14 - Payment Request OE21 - Payment Request OE27 - Payment Request OE10 - Pending Order Cart (a) OE31 - Persisted Planned Order (pr) OE07 - Planned Order MD05 - Professionalism of WAM and OrdEnd ME03 - Resolution Proposal OE11 - Submitted Order MD02 - Synergy From WAM and OrdEnt ME02 - Test Actions MD01 - This Model Value Proposition ME01 - Vehicle Behavior OE16 - Warehouse Inventory (pr)	By Date Created: FN01 - Adjust Sales OE09 - Authority Identity (a) OE18r - Available Parts List (pr) OE28 - Category (pr) MD03 - Clear AM Possibilities for DDD OE23 - Confirmed Order PR01 - Current Categories OE04 - Customer OE08 - Customer Identity (a) OE05 - Customer Purchase (a) OE12 - Full Sales Order (pu) ME00 - Indication of Normal and Abnormal Function OE25 - Intended Order MD04 - Opportunities for Modelers OE20 - Order Items (p) BR02 - Order Total Costs OE06 - Part (pr) OE29 - Parts Category Items (pr) OE24 - Parts Committed ME06 - Parts Delivery OE19 - Parts Filter ME05 - Parts Order ME07 - Parts Replacement ME04 - Parts Source OE22 - Payment Broker Authentication PB02 - Payment Collected PB01 - Payment Confirmation OE26 - Payment Details OE14 - Payment Request OE21 - Payment Request OE27 - Payment Request OE10 - Pending Order Cart (a) OE31 - Persisted Planned Order (pr) OE07 - Planned Order MD05 - Professionalism of WAM and OrdEnd ME03 - Resolution Proposal OE11 - Submitted Order MD02 - Synergy From WAM and OrdEnt ME02 - Test Actions MD01 - This Model Value Proposition ME01 - Vehicle Behavior OE16 - Warehouse Inventory (pr)

Details for each assertion including its frame .
OE08 - Customer Identity (a)

Customer Identity (a) A statement that provides a populated set of criteria that an individual can provide to uniqely identify them as a Customer Updated: Sun Oct 26 2025 08:06:09 GMT-0700 (Pacific Daylight Time)	Top Authority: Marketing Automatic: null Activity Type: null
Sizing         Hours to comlete: null     Why: null         Yearly Repeat: null   Why: null Information Management        OE08 creates Standard Information Other Information Sources (ad hoc): undefined	Specification (business rules) : null UI Function : undefined Modeling Status: ATTR ModelNote: This is where manually or automatically a new Customer record is created.If automated this mans that an individual can establish an Authority in an Environment with credentials. And then access cubicles for that Authority in that Environment. Using or supplying that Customer Context.This lmust be investigated wrt the Personal boolean.it also BUILDS SECURITY INTO THE BUSINESS DESIGN!

Inputs: from: OE09 Authority Identity (a) - From OE09 -Authority Identity (a) Password STRING Will be stored as token prototype value: General Values null -desc- prototype value: example value Email STRING -- New Desc -- prototype value:

Out General Notes null -desc- prototype value: Customer ID STRING -- New Desc -- prototype value: PPC3351 Customer First Name STRING -- New Desc -- prototype value: Customer Last Name STRING -- New Desc -- prototype value: Customer Address STRING -- New Desc -- prototype value: LoginID STRING probably Email prototype value: Login Token STRING -- New Desc -- prototype value: To: OE10 Pending Order Cart (a) To: OE23 Confirmed Order

OE04 - Customer

Customer Retrieve Customer details for a given Customer ID. Implemented in Customer Entity. Initiated by the Planned Order UI. Updated: Wed Dec 10 2025 12:04:57 GMT-0800 (Pacific Standard Time)	Top Authority: Sales Manager Automatic: TRUE Activity Type: RETRIEVAL
Sizing         Hours to comlete: 0     Why:         Yearly Repeat: 20000   Why: Information Management        OE04 creates   Personal Information Other Information Sources (ad hoc):	Specification (business rules) : Method: GET GetCustomerDetailsForCustomerID Return a single record for a Customer UI Function : None Automatic Modeling Status: IMP1 ModelNote: This retrieval is used to add the customer address when they make an order. This can be simply tested using PostMan with a customerID.

Inputs: -

Out Customer Number STRING Unique identity for external identification prototype value: PPC342 First Name null Customer First name prototype value: Mo Last Name STRING Customer last name prototype value: Jones Full Address STRING Delivery address to support courier delivery. Validation: text to identify location. prototype value: 1234 Any St., Ohioville, PA To: OE11 Submitted Order

OE05 - Customer Purchase (a)

Customer Purchase (a) A statement by the sales manager that comitts the organization to a financial contract. In this case a acceptance of an order. Updated: Wed Jul 23 2025 08:49:56 GMT-0700 (Pacific Daylight Time)	Top Authority: Sales Manager Automatic: TRUE Activity Type: null
Sizing         Hours to comlete: null     Why: null         Yearly Repeat: null   Why: null Information Management        OE05 creates   Financial Information Other Information Sources (ad hoc): undefined	Specification (business rules) : Confirm that the purchaser is a recognized customer. Has presented a payment or a suitable expectatin of payment. That the purchaser is properly informed of their contractual obligations and that parts, location and delivery are specified. UI Function : undefined Modeling Status: INIT ModelNote: This is a spectacular automatic from an AM viewpoint. All the pieces for a contract must be in place and an automatic asserions completes a contract and informs other assertions.

Inputs: from: OE11 Submitted Order - From OE11 -Submitted Order customerID UUID Internal UUID for customer prototype value: )76uuyt&*6i orderID null The cart these items belong to. prototype value: example value Product ID STRING Non internal Prodct ID from catalog prototype value: &67t%455uT6% Unit Price CURRENCY Populated from the part selected prototype value: 23.89 Quantity INTEGER Order quantity prototype value: 7 Shipping Address STRING Text from customer record. prototype value: 234 Kansas Drive, Kansas

Out FullOrderItem STRING Quantity and PartID and Warehouse and When prototype value: Attribute Note null A design attribute prototype value: The purchase assertion includes a wide range of information. It is either referred to by using IDs or is extracted for the decision itself. This assn is designed from the ground up to be automatic. And it will return a confirmation of contract acceptance that feeds many other asserions( like, finance, performance, customer, warehouse) And it will initiate a delivery request to a Shipper (who has already comitted to a delivery) Customer ID STRING Might need a chek of valid CCard. prototype value: PPC00123 Warehouse ID STRING WH may have 'held' parts as part of SBasket prototype value: PPW21 Order Items STRING explore Types - rich OE incl delivery prototype value:

OE10 - Pending Order Cart (a)

Pending Order Cart (a) A pending state for a Planned Order that may be taken up by an anonymous (cookie identified) browser or a customer (ID identified). A set of order items that includes expected price and delivery. Updated: Sat Oct 25 2025 09:14:05 GMT-0700 (Pacific Daylight Time)	Top Authority: Sales Manager Automatic: TRUE Activity Type: DECISION
Sizing         Hours to comlete: 1     Why:         Yearly Repeat: 10000   Why: May be tens of thousands of searchers Information Management        OE10 creates Standard Information Other Information Sources (ad hoc): undefined	Specification (business rules) : Present the pending order for an identified browser of customer UI Function : No ui capabilites needed. Modeling Status: BC1 ModelNote: A browser configures a potential order and then returns.It may be necessary to revise delivery/availability and price when picked up.This is iAuthorized by the Sales Manager. Why, because they specify the automatic specification for this automated assertion.

Inputs: from: OE08 Customer Identity (a) from: OE07 Planned Order - From OE08 -Customer Identity (a) General Notes null -desc- prototype value: Customer ID STRING -- New Desc -- prototype value: PPC3351 Customer First Name STRING -- New Desc -- prototype value: Customer Last Name STRING -- New Desc -- prototype value: Customer Address STRING -- New Desc -- prototype value: LoginID STRING probably Email prototype value: Login Token STRING -- New Desc -- prototype value: From OE07 -Planned Order Context_UserToken STRING A token that controls access to the cubicle and the messages it manages prototype value: 33098&9775 orderId STRING The cart these items belong to. Validation: auto generated on creation. prototype value: (*98&88YT customerId UUID Internal UUID for customer. Validation: auto generated on creation. prototype value: (8778J7&* Product ID STRING Populated from the part selected. Validation: Must be in the Product list prototype value: PPP23 Quantity STRING Stated by the shopper. Validation: Orders over 100 of one part are not allowed. prototype value: 6 Price STRING Populated from the part selected. Validation: must be the price in the Product Catalog The unit price of the part when added to cart. prototype value: $41.89

Out Browse Identity STRING ID associated with a set of browse parameters (ie viewed parts) prototype value: PPC3386 Part ID STRING Must be from parts catalog prototype value: PPP876 Appearance ID STRING Must be from parts catalog prototype value: WH ID STRING Must be from WH catalog prototype value: PPA886 Current Price STRING [br- Must be from the Product Catlog when selected from the Available Products List] prototype value: Price Date STRING [br-Must be the date the record was pulled from the Available Products] prototype value: Order Quantity STRING Value specified by cart owner in the cart order items. [br- there may be prototype value: 4 General Notes null Not one of the attributes. prototype value: This Frame is Complex. It contains information about the Customer Cart and what they have in it. When Types are fully implemented the Items will be included as a complex attribute that is a collection of items. Authentification Criteria for Customer STRING Not one of the attributes foe now. Needed to find existing prototype value: This to be identified from Customer Login To: ME05 Parts Order To: OE23 Confirmed Order To: OE25 Intended Order

OE12 - Full Sales Order (pu)

Full Sales Order (pu) Retain the Sales Order submitted by the Customer. A Create for the Full Sales Order Aggregate. Updated: Thu Nov 13 2025 07:22:17 GMT-0800 (Pacific Standard Time)	Top Authority: Sales Manager Automatic: TRUE Activity Type: PERSIST
Sizing         Hours to comlete: 0     Why:         Yearly Repeat: 20000   Why: There were 20000 purchases last year Information Management        OE12 creates   Personal  Financial  Corporate Record Information Other Information Sources (ad hoc):	Specification (business rules) : Method: Create aggregate Validate and persist the Sales Order including Order Items. UI Function : No UI Modeling Status: IMP1 ModelNote: This represents an acceptance by the customer of the offer by the Product organization. A contract is created. As such, its information is Financial, Personal, and an organizatinal Record. From the Comitted Sales Order OE11. The aggregate record is presented for persistence because the Customer has submitted the Order. Some feedback is needed to confirm the order. (not currently shown)

Inputs: from: OE11 Submitted Order - From OE11 -Submitted Order customerID UUID Internal UUID for customer prototype value: )76uuyt&*6i orderID null The cart these items belong to. prototype value: example value Product ID STRING Non internal Prodct ID from catalog prototype value: &67t%455uT6% Unit Price CURRENCY Populated from the part selected prototype value: 23.89 Quantity INTEGER Order quantity prototype value: 7 Shipping Address STRING Text from customer record. prototype value: 234 Kansas Drive, Kansas

Out CustomerID null Internal UUID for customer Validation: Must be an existing id from Customer Entity prototype value: )76uuyt&*6i OrderId STRING The customer order these items belong to. Validation: Must be a an existing OrderID for all but create. prototype value: (77U77FFdeetS7768(7 ShippingAddress STRING Text from customer record. Validation: Must be deliverable prototype value: 432 Kansas Drive, Kansas City, Kansas

OE20 - Order Items (p)

Order Items (p) List of Pending Order Items Updated: Wed Nov 12 2025 15:48:32 GMT-0800 (Pacific Standard Time)	Top Authority: Sales Manager Automatic: TRUE Activity Type: null
Sizing         Hours to comlete: 1     Why: null         Yearly Repeat: 10000   Why: Information Management        OE20 creates Standard Information Other Information Sources (ad hoc): undefined	Specification (business rules) : Add and remove item availabilities to shortlist a potential order. UI Function : undefined Modeling Status: ATTR ModelNote: This is the Datastore that holds the items that have been left in carts. Ready to be resumed.If a part is available in 2 warehouses this should have 2 rows.Usage is for a Mechanic to have a termporary list of prospective parts as they plan a solution.This has the Sales Manager as the Authority because they have the responsibility of storing and recovering this for an anonymous browser. When someone registers as a Customer then this will be identified by the Customer ID and Order ID.

Inputs: -

Out PartID STRING Unique for PartsP prototype value: PPP876 OrderID DATE identifier of order this belongs to. FK to Order prototype value: Quantity INTEGER Quantity needed for this order prototype value: 4 Price CURRENCY From Parts List when added prototype value: $34.40 PriceDate DATE Date when Price was established from Parts List prototype value: 2025-08-14

OE23 - Confirmed Order

Confirmed Order Contractural acceptance by PartsP that a customer order has been agreed to. Updated: Wed Aug 27 2025 09:02:46 GMT-0700 (Pacific Daylight Time)	Top Authority: Sales Manager Automatic: null Activity Type: DECISION
Sizing         Hours to comlete: null     Why: null         Yearly Repeat: null   Why: null Information Management        OE23 creates   Financial  Corporate Record Information Other Information Sources (ad hoc): undefined	Specification (business rules) : State the Customer ID, Order ID, Amount, Order Items etc. UI Function : undefined Modeling Status: INIT ModelNote: This informs the warehouse of the sale. And it informs the Finance Department to reconcile with the Payment Broker. This most closely matches the simplified Order Entry idea.But it recognizes that for PartsP an order is not an order until payed.

Inputs: from: PB01 Payment Confirmation from: OE08 Customer Identity (a) from: OE10 Pending Order Cart (a) - From PB01 -Payment Confirmation General Values null -desc- prototype value: example value From OE08 -Customer Identity (a) General Notes null -desc- prototype value: Customer ID STRING -- New Desc -- prototype value: PPC3351 Customer First Name STRING -- New Desc -- prototype value: Customer Last Name STRING -- New Desc -- prototype value: Customer Address STRING -- New Desc -- prototype value: LoginID STRING probably Email prototype value: Login Token STRING -- New Desc -- prototype value: From OE10 -Pending Order Cart (a) Browse Identity STRING ID associated with a set of browse parameters (ie viewed parts) prototype value: PPC3386 Part ID STRING Must be from parts catalog prototype value: PPP876 Appearance ID STRING Must be from parts catalog prototype value: WH ID STRING Must be from WH catalog prototype value: PPA886 Current Price STRING [br- Must be from the Product Catlog when selected from the Available Products List] prototype value: Price Date STRING [br-Must be the date the record was pulled from the Available Products] prototype value: Order Quantity STRING Value specified by cart owner in the cart order items. [br- there may be prototype value: 4 General Notes null Not one of the attributes. prototype value: This Frame is Complex. It contains information about the Customer Cart and what they have in it. When Types are fully implemented the Items will be included as a complex attribute that is a collection of items. Authentification Criteria for Customer STRING Not one of the attributes foe now. Needed to find existing prototype value: This to be identified from Customer Login

Out To: OE24 Parts Committed To: ME06 Parts Delivery To: FN01 Adjust Sales

OE27 - Payment Request

Payment Request Details of Card Credentials and Amount Updated: Fri Aug 08 2025 08:01:18 GMT-0700 (Pacific Daylight Time)	Top Authority: Sales Manager Automatic: null Activity Type: null
Sizing         Hours to comlete: null     Why: null         Yearly Repeat: 5000   Why: null Information Management        OE27 creates Standard Information Other Information Sources (ad hoc): undefined	Specification (business rules) : Request (on Customers behalf ) that payment be made. UI Function : undefined Modeling Status: INIT ModelNote: null

Inputs: from: OE26 Payment Details from: OE25 Intended Order - From OE26 -Payment Details General Notes null -desc- prototype value: example value PPPCustomer ID STRING -- New Desc -- prototype value: Credit Card Number STRING assumes PP collects this. prototype value: Expiry STRING -- New Desc -- prototype value: 02/26 Security Code STRING -- New Desc -- prototype value: 02/26 Amount CURRENCY To be paid prototype value: $99.97 Payee ID STRING identity known by visa for PP prototype value: From OE25 -Intended Order General Notes null prototype value: To be fully attributed from other frames.

Out To: PB01 Payment Confirmation

PR01 - Current Categories

Current Categories The collection of categories used to filter parts Updated: Mon Sep 29 2025 08:04:16 GMT-0700 (Pacific Daylight Time)	Top Authority: Sales Manager Automatic: TRUE Activity Type: nv-Entity
Sizing         Hours to comlete: null     Why: null         Yearly Repeat: null   Why: null Information Management        PR01 creates Standard Information Other Information Sources (ad hoc): undefined	Specification (business rules) : Provide values for designing code UI Function : undefined Modeling Status: INIT ModelNote: This is the retreive for an NVEntityGenerated by endpoint CreateAssnForSModel

Inputs: -

Out CategoryUUID STRING null prototype value: 349789 CategoryName TEXT null prototype value: Vehicle Type

BR02 - Order Total Costs

Order Total Costs A result of the application of the business rule that calculates taxes, shipping, and totals for an order and its items. Updated: Sun Dec 07 2025 17:22:12 GMT-0800 (Pacific Standard Time)	Top Authority: Sales Manager Automatic: TRUE Activity Type: CALCULATION
Sizing         Hours to comlete: 0     Why:         Yearly Repeat: 20,000   Why: when the total cost is shown customers may not submit the order. Information Management        BR02 creates   Financial Information Other Information Sources (ad hoc):	Specification (business rules) : Tax is 5% of the total. Shipping(is taxed) is 10% of the total, or 8% for orders over $1000. UI Function : Modeling Status: IMP1 ModelNote: This business rule is the responsibility of the Sales Manger. This is currently specified by text. but when implemented a function would automatically calculate the values. This can be a separate bindable component? Is this a Value Item? This is definitely a business rule. But where does this 'reside'? Is it passed to the FE to execute or does each time the items change does the FE ask the aggregate for values? A CHALLENGE QUESTION FOR IMPLEMENTATION DESIGN

Inputs: from: OE07 Planned Order - From OE07 -Planned Order Context_UserToken STRING A token that controls access to the cubicle and the messages it manages prototype value: 33098&9775 orderId STRING The cart these items belong to. Validation: auto generated on creation. prototype value: (*98&88YT customerId UUID Internal UUID for customer. Validation: auto generated on creation. prototype value: (8778J7&* Product ID STRING Populated from the part selected. Validation: Must be in the Product list prototype value: PPP23 Quantity STRING Stated by the shopper. Validation: Orders over 100 of one part are not allowed. prototype value: 6 Price STRING Populated from the part selected. Validation: must be the price in the Product Catalog The unit price of the part when added to cart. prototype value: $41.89

Out Total Ordered Items CURRENCY Sum of quantity * unit price prototype value: $5234 Shipping STRING 10% (if total is > $1000 - 8%) prototype value: $320 Total With Shipping STRING -- New Desc -- prototype value: $5789 Tax STRING 5% prototype value: $289 Total Payable STRING Items + Shipping + Tax prototype value: $5976 To: OE11 Submitted Order

OE31 - Persisted Planned Order (pr)

Persisted Planned Order (pr) The current planned order delivered from persistence. Updated: Sun Oct 19 2025 11:09:02 GMT-0700 (Pacific Daylight Time)	Top Authority: Sales Manager Automatic: TRUE Activity Type: RETRIEVAL
Sizing         Hours to comlete: null     Why: null         Yearly Repeat: null   Why: null Information Management        OE31 creates Standard Information Other Information Sources (ad hoc): null	Specification (business rules) : For a customerID return the Planned Order as last persisted. UI Function : null Modeling Status: SIMPLE ModelNote: This has a update sibling.

Inputs: -

Out

OE06 - Part (pr)

Part (pr) Retrieve details about the Part to support the Planned Order UI. -- An Entity retrieval. -- Initiated from Parts Filter UI Updated: Sat Oct 25 2025 15:55:38 GMT-0700 (Pacific Daylight Time)	Top Authority: Catalog Manager Automatic: TRUE Activity Type: RETRIEVAL
Sizing         Hours to comlete: 0     Why:         Yearly Repeat: 20000   Why: May adjustments to Planned Order Information Management        OE06 creates Standard Information Other Information Sources (ad hoc):	Specification (business rules) : Method: POST: GetDetailsForPartIDs- Return all parts details for the PartID UI Function : None: Automatic. Modeling Status: IMPL1 ModelNote: Although automatic, the Catalog Manager is responsible for maintining the catalog and this assertion that deliivers it. This is a second retrieval from the Parts Entity (similar to OE18r) This retrieves by PartIDs. This can be simply tested using PostMan with a filter. The filter is provided in the body of the HTTP request. This is used by Planned Order using a PULL connection.

Inputs: -

Out productid UUID Internal UUID for persistent integrity prototype value: 43099&99aj categoryId STRING Category for filtering. Vallidation: Must be listed in the Category Entity prototype value: 3099u75i3 Name STRING Short identifying name to support search and match to physical product. Validation: Unique within Products. prototype value: Part Description(description) STRING Semi structured narrative of use of part and installation details. prototype value: A wing mirror that can be fitted to any vehicle. unitPrice CURRENCY Price in CAD. Validation: Must be dollar amount. Validation: Cannot be set to zero. prototype value: 12.99 SKU STRING Stock Keeping Unit. Identifier, unique within this organization. Validation: Must be unique. Integer ascending by datetime. prototype value: 3387 To: OE18r Available Parts List (pr) To: OE07 Planned Order

OE18r - Available Parts List (pr)

Available Parts List (pr) Retrieve the set of Parts that satisfy filter criteria, and the details for each Updated: Tue Nov 11 2025 07:46:14 GMT-0800 (Pacific Standard Time)	Top Authority: Catalog Manager Automatic: TRUE Activity Type: RETRIEVAL
Sizing         Hours to comlete: 0     Why:         Yearly Repeat: 40000   Why: automatic Information Management        OE18r creates Standard Information Other Information Sources (ad hoc):	Specification (business rules) : Method: Post GetAvailablePartsForFilter Select all parts that match any of the filter items. UI Function : None: Auto Modeling Status: IMP1 ModelNote: Although automatic, the Sales Manager is responsible for maintining the catalog and this assertion that filters it. Warehouse is not included in IMP1. Assumption that this is a Part entity, described by the attribute of the assertion. This can be simply tested using PostMan with a filter. The filter is provided in the body of the HTTP request. This is used by Planned Order using a PULL connection. The AM identifies a separate connection for the request but this can be implemented as a simple retrieve.

Inputs: from: OE19 Parts Filter from: OE06 Part (pr) from: OE16 Warehouse Inventory (pr) - From OE19 -Parts Filter CategoryName STRING Identity for which catefory this shopper has identified a search item prototype value: VehicleType SelectedCategoryItem STRING Value from enumeration of Items for a category prototype value: SUV From OE06 -Part (pr) productid UUID Internal UUID for persistent integrity prototype value: 43099&99aj categoryId STRING Category for filtering. Vallidation: Must be listed in the Category Entity prototype value: 3099u75i3 Name STRING Short identifying name to support search and match to physical product. Validation: Unique within Products. prototype value: Part Description(description) STRING Semi structured narrative of use of part and installation details. prototype value: A wing mirror that can be fitted to any vehicle. unitPrice CURRENCY Price in CAD. Validation: Must be dollar amount. Validation: Cannot be set to zero. prototype value: 12.99 SKU STRING Stock Keeping Unit. Identifier, unique within this organization. Validation: Must be unique. Integer ascending by datetime. prototype value: 3387 From OE16 -Warehouse Inventory (pr) WarehouseID STRING Unique prototype value: PPW78 PartID STRING -- New Desc -- prototype value: PPP348 VariantID STRING -- New Desc -- prototype value: PPA45 Quantity STRING Integer in Warehouse prototype value: 37

Out PartUUID STRING EntityID prototype value: part1 PartID STRING Interchangable ID prototype value: PPP334 PartName STRING -- New Desc -- prototype value: BrakeMaster ShortDescription STRING Short Description by PP prototype value: Brake Pad for Truck UnitPrice STRING Price as of start of Cart prototype value: $45.00 To: OE07 Planned Order

OE28 - Category (pr)

Category (pr) All parts are categorized to facilitate searching. These are the categories and the valid values and descriptions for them.Although it is in the data model I do not think that the Category Entity needs to be queried. Updated: Sat Oct 25 2025 09:15:57 GMT-0700 (Pacific Daylight Time)	Top Authority: Catalog Manager Automatic: TRUE Activity Type: RETRIEVAL
Sizing         Hours to comlete: 5     Why: null         Yearly Repeat: 2   Why: null Information Management        OE28 creates   Corporate Record Information Other Information Sources (ad hoc): undefined	Specification (business rules) : State the selection of category items that a part may be included in. UI Function : undefined Modeling Status: SIMPLE ModelNote: This is a classic business rule. And it might be slow changing. This is included to ensure that real life situations that threaten easy implementation are firmly faced in business design before they are implemented.The inclusion of this 'wrinkle' supports careful consideration of how slow changing business rules may need be hard coded(causing complexity), or anticipated (causing complexity).This has been simplified for a single category. (Otherwise a composit entity is needed in the simple data model)This delivers either a pick list for the Product Manager to assign a part into. Or a list for validation of Product

Inputs: -

Out categoryId null internal UUID Validation: must be uuid prototype value: 3099u75i3 Name STRING Short text to identify the category item. Validation: Less that 12 characters prototype value: DRIVE TRAIN Description STRING Summary of the kind of product included in this category. Validation: Less than 1000 characters. No images. prototype value: Any parts for drive train To: OE29 Parts Category Items (pr)

OE29 - Parts Category Items (pr)

Parts Category Items (pr) Retrieve all the Category and Category Items to support the Planned Order UI Updated: Mon Dec 08 2025 08:27:34 GMT-0800 (Pacific Standard Time)	Top Authority: Catalog Manager Automatic: TRUE Activity Type: RETRIEVAL
Sizing         Hours to comlete: 0     Why:         Yearly Repeat: 50000   Why: many searches Information Management        OE29 creates Standard Information Other Information Sources (ad hoc):	Specification (business rules) : Mrthod: GET GetAllCategoryItems - select all rows in the CategoryItem table. UI Function : None: Automatic Modeling Status: IMP1 ModelNote: This is used by the Client OE19 Parts Filter to provide choices to search the parts catlog for parts that (for example) are just for Mercedes Trucks. This is the CategoryItems Entity decribed by the attributes of this assertion. This can be simply unit tested using PostMan with a filter. The filter is provided in the body of the HTTP request. This is used by Planned Order in the Client using a PULL connection.

Inputs: from: OE28 Category (pr) - From OE28 -Category (pr) categoryId null internal UUID Validation: must be uuid prototype value: 3099u75i3 Name STRING Short text to identify the category item. Validation: Less that 12 characters prototype value: DRIVE TRAIN Description STRING Summary of the kind of product included in this category. Validation: Less than 1000 characters. No images. prototype value: Any parts for drive train

Out Category Name STRING Name of one of the ways Parts are characterized. prototype value: Vehicle Type Category Item Description STRING -- New Desc -- prototype value: Part fits any of the F150 line. Category Item Description STRING Assistance in deciding if the part fits the individual item choice. prototype value: Has a truck bed, wide wheelbase and low gearing. Category Description STRING Details on how this categorization is determined. prototype value: Characeristics like truck bed, number of doors, 2 or 4 wheel, weight Category Item Name STRING A short identifier for the category item prototype value: Truck General Comments null prototype value: This Frame is included here as a composite. When a part is characterized this way (F150) the part fits an F150. To: OE19 Parts Filter

OE09 - Authority Identity (a)

Authority Identity (a) An Individual provides credentials for an Authority within an Environment. This automatic (or manual) passes these credentials to 'Marketing' ( the Customer Authority) for assessment. Practically this 'Authority Binding' probably returns a token that is passed for access to Authority Cubicles. Updated: Mon Aug 11 2025 08:30:51 GMT-0700 (Pacific Daylight Time)	Top Authority: Individual Automatic: null Activity Type: null
Sizing         Hours to comlete: null     Why: null         Yearly Repeat: null   Why: null Information Management        OE09 creates Standard Information Other Information Sources (ad hoc): undefined	Specification (business rules) : null UI Function : undefined Modeling Status: ATTR ModelNote: null

Inputs: -

Out Password STRING Will be stored as token prototype value: General Values null -desc- prototype value: example value Email STRING -- New Desc -- prototype value: To: OE08 Customer Identity (a)

OE22 - Payment Broker Authentication

Payment Broker Authentication The individual who provides credentials is given authorization ( access to Cubicles as an Authority) to use Cubicles Updated: Thu Aug 07 2025 07:37:53 GMT-0700 (Pacific Daylight Time)	Top Authority: Individual Automatic: null Activity Type: null
Sizing         Hours to comlete: 1     Why: null         Yearly Repeat: 5000   Why: Just for PartsP Information Management        OE22 creates Standard Information Other Information Sources (ad hoc): undefined	Specification (business rules) : Compare supplied Payment Broker credentials to Broker memberlist to identify user.State (or navigate) access to subsequent Cubicles UI Function : undefined Modeling Status: INIT ModelNote: When a Customer from PartsP arrives they must show credentials (IE Visa details) to be recognized. Then the Broker can initiate financial transactions in the Visa system on behalf of the PartsPClient to invoke payment.This assertion just esablishes that Visa Authority.ASIDE:This really emphasizes the veracity concepts in AM. An Order Purchase initiates a chain of statements by trusted Authorities to affect external accounts.

Inputs: -

Out To: PB01 Payment Confirmation

ME00 - Indication of Normal and Abnormal Function

Indication of Normal and Abnormal Function A vehicle behaves in a way the indicates malfunction. Updated: Sat Jul 26 2025 04:13:35 GMT-0700 (Pacific Daylight Time)	Top Authority: Vehicle Automatic: null Activity Type: null
Sizing         Hours to comlete: null     Why: null         Yearly Repeat: null   Why: null Information Management        ME00 creates Standard Information Other Information Sources (ad hoc): undefined	Specification (business rules) : Make a noise or refuse to operate. UI Function : undefined Modeling Status: INIT ModelNote: This is an example of a physical assertion.Does it make sense to represent the Vehicle as an Authority?? No Person can assume that Authority. But the Behavior of an assertion that represents the vehicle can be ObSERVED. And a Mechanic can make statements that capture that exhibited behavior. And that behavior can suggest a physical assertion ( such as changing out a part) that can affect the observable state of affairs from the vehicle.This is Assertion Thinking at its best.

Inputs: from: ME02 Test Actions from: ME07 Parts Replacement - From ME02 -Test Actions From ME07 -Parts Replacement

Out To: ME01 Vehicle Behavior

ME02 - Test Actions

Test Actions Identify a set of actions and observations to isolate problem cause.is this the actions or the result of the actions. ( no ME01 is the result of the actions) Updated: Fri Jul 25 2025 16:43:03 GMT-0700 (Pacific Daylight Time)	Top Authority: Mechanic Automatic: null Activity Type: null
Sizing         Hours to comlete: null     Why: null         Yearly Repeat: null   Why: null Information Management        ME02 creates Standard Information Other Information Sources (ad hoc): undefined	Specification (business rules) : null UI Function : undefined Modeling Status: INIT ModelNote: This might be informed by suggestions from PP!

Inputs: from: ME01 Vehicle Behavior from: OE07 Planned Order - From ME01 -Vehicle Behavior From OE07 -Planned Order Context_UserToken STRING A token that controls access to the cubicle and the messages it manages prototype value: 33098&9775 orderId STRING The cart these items belong to. Validation: auto generated on creation. prototype value: (*98&88YT customerId UUID Internal UUID for customer. Validation: auto generated on creation. prototype value: (8778J7&* Product ID STRING Populated from the part selected. Validation: Must be in the Product list prototype value: PPP23 Quantity STRING Stated by the shopper. Validation: Orders over 100 of one part are not allowed. prototype value: 6 Price STRING Populated from the part selected. Validation: must be the price in the Product Catalog The unit price of the part when added to cart. prototype value: $41.89

Out To: ME00 Indication of Normal and Abnormal Function

ME03 - Resolution Proposal

Resolution Proposal A set of actions and parts that are likely to resolve malfunction. Updated: Wed Jul 30 2025 09:18:09 GMT-0700 (Pacific Daylight Time)	Top Authority: Mechanic Automatic: null Activity Type: null
Sizing         Hours to comlete: null     Why: null         Yearly Repeat: null   Why: null Information Management        ME03 creates Standard Information Other Information Sources (ad hoc): undefined	Specification (business rules) : Specify arguement for resolution and needed parts and actions. UI Function : undefined Modeling Status: null ModelNote: null

Inputs: from: ME01 Vehicle Behavior - From ME01 -Vehicle Behavior

Out General Values null -desc- prototype value: example value Resolution Plan STRING Plan for resolving the issue including parts prototype value: If I afix my cellphone to the dash it will stop falling off. So I must find a part that does this. To: ME04 Parts Source

ME04 - Parts Source

Parts Source Develop a list of candidate part sources for comparison. For each needed part(identified by mechanic) there may be some candidates that would fulfil. Each will have an evaluation.The result of this 'sources assessment will support the final decision where one (or more) suppliers will be comitted to. Updated: Wed Oct 08 2025 17:22:42 GMT-0700 (Pacific Daylight Time)	Top Authority: Mechanic Automatic: null Activity Type: ASSESSMENT
Sizing         Hours to comlete: 2     Why: null         Yearly Repeat: 10   Why: Information Management        ME04 creates Standard Information Other Information Sources (ad hoc): undefined	Specification (business rules) : List all the parts and quantities for this fix job. UI Function : undefined Modeling Status: ATTR1 ModelNote: The Mechanic may do this by hand. Or more easily by using a PartsP tool.newline---newline---and more

Inputs: from: ME03 Resolution Proposal - From ME03 -Resolution Proposal General Values null -desc- prototype value: example value Resolution Plan STRING Plan for resolving the issue including parts prototype value: If I afix my cellphone to the dash it will stop falling off. So I must find a part that does this.

Out General Values null -desc- prototype value: This list shows where wach part is coming from and how much. Mechanic Part Name STRING Name and details by Mechanic prototype value: Way to hold my phone Supplier Part Number STRING The identifier the suppler uses to identify the part in theri system prototype value: PPP33198 Quantity STRING How many of these needed ( Left and Right are separate parts) prototype value: 3 Mechanic Job ID STRING Identifier of the job ( prototype value: Prep for Uber. Supplier Unit Price STRING In USD prototype value: $42.99 Mechanic Part ID STRING Identifier for Mechanic prototype value: Left Dashboard Bracket Supplier Name STRING Name of potential supplier prototype value: Partner Parts Supplier Part Description STRING Text provided on the part they supply. prototype value: Acme cellphone holder Supplier Delivery Expectation STRING When expected ( date or text) prototype value: 2025-10-12 To: ME05 Parts Order

ME07 - Parts Replacement

Parts Replacement Physically replace parts Updated: Thu Jul 24 2025 07:51:52 GMT-0700 (Pacific Daylight Time)	Top Authority: Mechanic Automatic: null Activity Type: null
Sizing         Hours to comlete: null     Why: null         Yearly Repeat: null   Why: null Information Management        ME07 creates Standard Information Other Information Sources (ad hoc): undefined	Specification (business rules) : null UI Function : undefined Modeling Status: INIT ModelNote: null

Inputs: from: ME06 Parts Delivery - From ME06 -Parts Delivery

Out To: ME00 Indication of Normal and Abnormal Function

ME05 - Parts Order

Parts Order Commit to Parts Retailer for purchase and delivery. Updated: Wed Nov 19 2025 16:02:06 GMT-0800 (Pacific Standard Time)	Top Authority: Mechanic Automatic: null Activity Type: null
Sizing         Hours to comlete:     Why: null         Yearly Repeat:    Why: Information Management        ME05 creates Standard Information Other Information Sources (ad hoc): undefined	Specification (business rules) : Use information about source and perhaps PP Customer Cart to decide on order.this informs the Customer (who is same person) to invoke the order itself UI Function : undefined Modeling Status: INIT ModelNote: What is this Authority? Mechanic or Customer. So Authority is dependent.The Mechanic is required to take on a PP Authority, as Customer, to Order!

Inputs: from: ME04 Parts Source from: OE10 Pending Order Cart (a) - From ME04 -Parts Source General Values null -desc- prototype value: This list shows where wach part is coming from and how much. Mechanic Part Name STRING Name and details by Mechanic prototype value: Way to hold my phone Supplier Part Number STRING The identifier the suppler uses to identify the part in theri system prototype value: PPP33198 Quantity STRING How many of these needed ( Left and Right are separate parts) prototype value: 3 Mechanic Job ID STRING Identifier of the job ( prototype value: Prep for Uber. Supplier Unit Price STRING In USD prototype value: $42.99 Mechanic Part ID STRING Identifier for Mechanic prototype value: Left Dashboard Bracket Supplier Name STRING Name of potential supplier prototype value: Partner Parts Supplier Part Description STRING Text provided on the part they supply. prototype value: Acme cellphone holder Supplier Delivery Expectation STRING When expected ( date or text) prototype value: 2025-10-12 From OE10 -Pending Order Cart (a) Browse Identity STRING ID associated with a set of browse parameters (ie viewed parts) prototype value: PPC3386 Part ID STRING Must be from parts catalog prototype value: PPP876 Appearance ID STRING Must be from parts catalog prototype value: WH ID STRING Must be from WH catalog prototype value: PPA886 Current Price STRING [br- Must be from the Product Catlog when selected from the Available Products List] prototype value: Price Date STRING [br-Must be the date the record was pulled from the Available Products] prototype value: Order Quantity STRING Value specified by cart owner in the cart order items. [br- there may be prototype value: 4 General Notes null Not one of the attributes. prototype value: This Frame is Complex. It contains information about the Customer Cart and what they have in it. When Types are fully implemented the Items will be included as a complex attribute that is a collection of items. Authentification Criteria for Customer STRING Not one of the attributes foe now. Needed to find existing prototype value: This to be identified from Customer Login

Out General Values null -desc- prototype value: example value To: ME06 Parts Delivery

ME06 - Parts Delivery

Parts Delivery -- Updated: Thu Aug 07 2025 08:55:38 GMT-0700 (Pacific Daylight Time)	Top Authority: Mechanic Automatic: null Activity Type: null
Sizing         Hours to comlete: null     Why: null         Yearly Repeat: null   Why: null Information Management        ME06 creates Standard Information Other Information Sources (ad hoc): undefined	Specification (business rules) : null UI Function : undefined Modeling Status: null ModelNote: Does PP make this statement or an intermediary Shipper.I think a Shipper needs to be recognized in this model. They make statements on promised delivery that PP and Mechanic have to rely on. PP may represent them partially.

Inputs: from: ME05 Parts Order from: OE23 Confirmed Order - From ME05 -Parts Order General Values null -desc- prototype value: example value From OE23 -Confirmed Order

Out To: ME07 Parts Replacement

ME01 - Vehicle Behavior

Vehicle Behavior Observation of behavior of a vehicle Updated: Sat Jul 26 2025 04:19:11 GMT-0700 (Pacific Daylight Time)	Top Authority: Mechanic Automatic: null Activity Type: DETECTION
Sizing         Hours to comlete: null     Why: null         Yearly Repeat: null   Why: null Information Management        ME01 creates Standard Information Other Information Sources (ad hoc): undefined	Specification (business rules) : State observed behaviors of a vehicle that may be normal expected or abnormal. UI Function : undefined Modeling Status: INIT ModelNote: Over time a number of typical behaviors can manifest. And the cycle of actions that resolve those malfunctions including parts, can form a body of knowledge to accessed.

Inputs: from: ME00 Indication of Normal and Abnormal Function - From ME00 -Indication of Normal and Abnormal Function

Out To: ME02 Test Actions To: ME03 Resolution Proposal

OE07 - Planned Order

Planned Order A collection of Planned Part Items for a Customer. Implemented in the UI and used to determine total costs. Updated: Sun Dec 07 2025 17:16:31 GMT-0800 (Pacific Standard Time)	Top Authority: Customer(Sales) Automatic: null Activity Type: CONFIGURATION
Sizing         Hours to comlete: 1     Why:         Yearly Repeat: 20000   Why: Many potential customers will start to shop Information Management        OE07 creates Standard Information Other Information Sources (ad hoc): The shopper may be looking at competitor parts sources, and the user manual of the machine being repaired.	Specification (business rules) : The Customer must inspect the Product Catlog in order to determine Product capabilities, fit, and prices. For this Simple example we assume they have a way of inspecting available parts subsetted by category items. ---Customer must decide to add an order item to the Planned Order (they have not comitted to buy yet). They can submit this information to the business rule that automatically determines total costs and shipping. UI Function : Provide the ability to filter the full product catalog by category. Modeling Status: SIMPLE ModelNote: This is a list of Products and quantities that a customer intends to order. For Assertum this is a complex type and needs some additional finishing of the types concept. TBD: The frame needs compex types.

Inputs: from: OE06 Part (pr) from: OE18r Available Parts List (pr) - From OE06 -Part (pr) productid UUID Internal UUID for persistent integrity prototype value: 43099&99aj categoryId STRING Category for filtering. Vallidation: Must be listed in the Category Entity prototype value: 3099u75i3 Name STRING Short identifying name to support search and match to physical product. Validation: Unique within Products. prototype value: Part Description(description) STRING Semi structured narrative of use of part and installation details. prototype value: A wing mirror that can be fitted to any vehicle. unitPrice CURRENCY Price in CAD. Validation: Must be dollar amount. Validation: Cannot be set to zero. prototype value: 12.99 SKU STRING Stock Keeping Unit. Identifier, unique within this organization. Validation: Must be unique. Integer ascending by datetime. prototype value: 3387 From OE18r -Available Parts List (pr) PartUUID STRING EntityID prototype value: part1 PartID STRING Interchangable ID prototype value: PPP334 PartName STRING -- New Desc -- prototype value: BrakeMaster ShortDescription STRING Short Description by PP prototype value: Brake Pad for Truck UnitPrice STRING Price as of start of Cart prototype value: $45.00

Out Context_UserToken STRING A token that controls access to the cubicle and the messages it manages prototype value: 33098&9775 orderId STRING The cart these items belong to. Validation: auto generated on creation. prototype value: (*98&88YT customerId UUID Internal UUID for customer. Validation: auto generated on creation. prototype value: (8778J7&* Product ID STRING Populated from the part selected. Validation: Must be in the Product list prototype value: PPP23 Quantity STRING Stated by the shopper. Validation: Orders over 100 of one part are not allowed. prototype value: 6 Price STRING Populated from the part selected. Validation: must be the price in the Product Catalog The unit price of the part when added to cart. prototype value: $41.89 To: ME02 Test Actions To: OE10 Pending Order Cart (a) To: BR02 Order Total Costs

OE11 - Submitted Order

Submitted Order Submit the decision to purchase an Order and its Items. Updated: Sun Dec 07 2025 17:17:43 GMT-0800 (Pacific Standard Time)	Top Authority: Customer(Sales) Automatic: null Activity Type: INTENT
Sizing         Hours to comlete: 1     Why:         Yearly Repeat: 10000   Why: Last years orders Information Management        OE11 creates   Personal  Financial  Corporate Record Information Other Information Sources (ad hoc):	Specification (business rules) : Populate the Shipping details from the Customer Record and and the current order from Planned Order. The customer is presented with the full details of the order and committs with an acceptance (contractural). UI Function : Modeling Status: SIMPLE ModelNote: An interesting assertion. Might be only an emit. This is the sales order as it is persisted. It is necessary that the order have automatic business rules applied before it is persisted. This is a business decision. The alternative is that the BR is applied on retrieval. An interesting design point.And this is interesting because it might be modeled with a recursive business rule but the assertion should not emit unless fully populated.If this is customer it is only items and not populated??Once comitted by customer it is persisted. (when received by pu)This is manual because the customer has to inspect it to make the comittment (contractural acceptance).

Inputs: from: BR02 Order Total Costs from: OE04 Customer - From BR02 -Order Total Costs Total Ordered Items CURRENCY Sum of quantity * unit price prototype value: $5234 Shipping STRING 10% (if total is > $1000 - 8%) prototype value: $320 Total With Shipping STRING -- New Desc -- prototype value: $5789 Tax STRING 5% prototype value: $289 Total Payable STRING Items + Shipping + Tax prototype value: $5976 From OE04 -Customer Customer Number STRING Unique identity for external identification prototype value: PPC342 First Name null Customer First name prototype value: Mo Last Name STRING Customer last name prototype value: Jones Full Address STRING Delivery address to support courier delivery. Validation: text to identify location. prototype value: 1234 Any St., Ohioville, PA

Out customerID UUID Internal UUID for customer prototype value: )76uuyt&*6i orderID null The cart these items belong to. prototype value: example value Product ID STRING Non internal Prodct ID from catalog prototype value: &67t%455uT6% Unit Price CURRENCY Populated from the part selected prototype value: 23.89 Quantity INTEGER Order quantity prototype value: 7 Shipping Address STRING Text from customer record. prototype value: 234 Kansas Drive, Kansas To: OE05 Customer Purchase (a) To: OE12 Full Sales Order (pu)

OE19 - Parts Filter

Parts Filter A UI Request to find a set of Parts that make up a Filter. Implemented in the UI. Updated: Sun Dec 14 2025 07:57:08 GMT-0800 (Pacific Standard Time)	Top Authority: Customer(Sales) Automatic: FALSE Activity Type: DECISION
Sizing         Hours to comlete: 0     Why:         Yearly Repeat: 182500   Why: Currently PP gets 50 orders a day. assume twice as many shoppers and 5 filters each. 365x50x2x5 Information Management        OE19 creates Standard Information Other Information Sources (ad hoc): The Customer may be inspecting other parts suppliers websites to help inform this decision.	Specification (business rules) : List the shopper, the category, and a category item to be included in a search. UI Function : The UI presents a multiselect of all the possible filter values, with an indicator showing those currently selected. The current set of the selected category values is emitted to query the parts and return a filtered parts display. Modeling Status: ASPECV2 ModelNote: See the categories Entity for sturcture of possible categories and thier values.This Entity retains the state of the shoppers filter.They adjust the filter ie their set of categories and values until they are ready to ask for the list of available parts. Example: Choose one or more manufacturers from this list (Tesla, Toyota,Ferrari,BMW). Choose Vehicle Type from this list (Automobile, MotorCycle, Scooter, Truck, Bus, Van). The input includes information about the categories and their items. (this is not required for the initial demonstration.

Inputs: from: OE29 Parts Category Items (pr) - From OE29 -Parts Category Items (pr) Category Name STRING Name of one of the ways Parts are characterized. prototype value: Vehicle Type Category Item Description STRING -- New Desc -- prototype value: Part fits any of the F150 line. Category Item Description STRING Assistance in deciding if the part fits the individual item choice. prototype value: Has a truck bed, wide wheelbase and low gearing. Category Description STRING Details on how this categorization is determined. prototype value: Characeristics like truck bed, number of doors, 2 or 4 wheel, weight Category Item Name STRING A short identifier for the category item prototype value: Truck General Comments null prototype value: This Frame is included here as a composite. When a part is characterized this way (F150) the part fits an F150.

Out CategoryName STRING Identity for which catefory this shopper has identified a search item prototype value: VehicleType SelectedCategoryItem STRING Value from enumeration of Items for a category prototype value: SUV To: OE18r Available Parts List (pr)

OE21 - Payment Request

Payment Request A Customer decides to pay using a third party payment service (like Stripe) Updated: Thu Aug 07 2025 07:06:48 GMT-0700 (Pacific Daylight Time)	Top Authority: Customer(Sales) Automatic: null Activity Type: null
Sizing         Hours to comlete: 1     Why: null         Yearly Repeat: 5000   Why: null Information Management        OE21 creates Standard Information Other Information Sources (ad hoc): undefined	Specification (business rules) : State the Order ID Amount payment method. UI Function : undefined Modeling Status: INIT ModelNote: A Navigation statement (by and large) This is facilitated by the implementation where the order details including amout are passed. It may be initiated by a button push.This will navigate the initiator to the payment service and return .

Inputs: -

Out General Values null -desc- prototype value: example value To: PB01 Payment Confirmation

OE25 - Intended Order

Intended Order Customer states intent to order. Updated: Mon Aug 11 2025 08:39:02 GMT-0700 (Pacific Daylight Time)	Top Authority: Customer(Sales) Automatic: null Activity Type: null
Sizing         Hours to comlete: 1     Why: null         Yearly Repeat: 5000   Why: null Information Management        OE25 creates Standard Information Other Information Sources (ad hoc): undefined	Specification (business rules) : Provide Cart, Customer ID, Payment Provider UI Function : undefined Modeling Status: ATTR? ModelNote: The formal offer to purchase.

Inputs: from: OE10 Pending Order Cart (a) - From OE10 -Pending Order Cart (a) Browse Identity STRING ID associated with a set of browse parameters (ie viewed parts) prototype value: PPC3386 Part ID STRING Must be from parts catalog prototype value: PPP876 Appearance ID STRING Must be from parts catalog prototype value: WH ID STRING Must be from WH catalog prototype value: PPA886 Current Price STRING [br- Must be from the Product Catlog when selected from the Available Products List] prototype value: Price Date STRING [br-Must be the date the record was pulled from the Available Products] prototype value: Order Quantity STRING Value specified by cart owner in the cart order items. [br- there may be prototype value: 4 General Notes null Not one of the attributes. prototype value: This Frame is Complex. It contains information about the Customer Cart and what they have in it. When Types are fully implemented the Items will be included as a complex attribute that is a collection of items. Authentification Criteria for Customer STRING Not one of the attributes foe now. Needed to find existing prototype value: This to be identified from Customer Login

Out General Notes null prototype value: To be fully attributed from other frames. To: OE27 Payment Request

PB01 - Payment Confirmation

Payment Confirmation A result form VISA that the payment has been confirmed by the bank.Or that it has been refused. Updated: Thu Aug 07 2025 08:09:54 GMT-0700 (Pacific Daylight Time)	Top Authority: Payment Broker Automatic: null Activity Type: null
Sizing         Hours to comlete: null     Why: null         Yearly Repeat: null   Why: null Information Management        PB01 creates Standard Information Other Information Sources (ad hoc): undefined	Specification (business rules) : null UI Function : undefined Modeling Status: INIT ModelNote: There is probably either immediately or periodically a confirmation to PP Finance that this has been collected. And at some time this payment will be made to PP. Currently beyond scope. But the confirmation must be fed to Finance.- Transaction ID- Payment status (e.g., Completed, Pending, Failed)- Buyer’s verified shipping address- Confirmation of payment method used- Fraud screening results (if applicable)

Inputs: from: OE21 Payment Request from: OE22 Payment Broker Authentication from: OE27 Payment Request - From OE21 -Payment Request General Values null -desc- prototype value: example value From OE22 -Payment Broker Authentication From OE27 -Payment Request

Out General Values null -desc- prototype value: example value To: PB02 Payment Collected To: OE23 Confirmed Order

PB02 - Payment Collected

Payment Collected A payment has been collected on behalf of a PB Client and their payments account must be credited. Updated: Thu Aug 07 2025 08:09:39 GMT-0700 (Pacific Daylight Time)	Top Authority: Payment Broker Automatic: null Activity Type: FINDING
Sizing         Hours to comlete: null     Why: null         Yearly Repeat: null   Why: null Information Management        PB02 creates   Financial  Corporate Record Information Other Information Sources (ad hoc): undefined	Specification (business rules) : State the PB Client ID, the amount and the Visa (or otherwise confirmation code) UI Function : undefined Modeling Status: INIT ModelNote: A good example of a financial transaction.The confirmation of payment is also handled in PartsP as a financial transaction that 'goes' to Finance.

Inputs: from: PB01 Payment Confirmation - From PB01 -Payment Confirmation General Values null -desc- prototype value: example value

Out

OE16 - Warehouse Inventory (pr)

Warehouse Inventory (pr) Quantity of each catalog part in a given warehouse available for sale. Total in WH include sold items still in the WH and tracked in Shipment Parts(tbd). Updated: Sat Oct 25 2025 09:14:38 GMT-0700 (Pacific Daylight Time)	Top Authority: Warehouse Manager Automatic: TRUE Activity Type: EXTRACTION
Sizing         Hours to comlete:     Why: null         Yearly Repeat: 2000000   Why: constant searching of where parts are. Information Management        OE16 creates Standard Information Other Information Sources (ad hoc): undefined	Specification (business rules) : Return the quantity of available specified parts in a specified warehouse UI Function : undefined Modeling Status: ASPECV2 ModelNote: Persistent and queryable.This is essentially the Inventory composite table.Changes to these quantities can be automated by removing sets of parts to sold while they are still in the warehouse.Changes to inventory occur when an oder is committed and the parts are included in the Shipment Part.OE16 should be tagged (a). From OrdEnt point of view it is just accessed as part of other BCs because it is only read(get). Do I create a WH aggregate to recognize this?Is it necessary to implement the aggregate to use a table?

Inputs: -

Out WarehouseID STRING Unique prototype value: PPW78 PartID STRING -- New Desc -- prototype value: PPP348 VariantID STRING -- New Desc -- prototype value: PPA45 Quantity STRING Integer in Warehouse prototype value: 37 To: OE18r Available Parts List (pr)

OE24 - Parts Committed

Parts Committed The order items to be provided to the customer by a given date. Updated: Thu Aug 07 2025 08:44:04 GMT-0700 (Pacific Daylight Time)	Top Authority: Warehouse Manager Automatic: null Activity Type: FINDING
Sizing         Hours to comlete: 1     Why: null         Yearly Repeat: 800   Why: null Information Management        OE24 creates Standard Information Other Information Sources (ad hoc): undefined	Specification (business rules) : State the quantity and PartID and Apearance ID so they can be reserved. UI Function : undefined Modeling Status: INIT ModelNote: This is determined by the WManager to ensure the parts will be available.How this is done is currently out of scope.

Inputs: from: OE23 Confirmed Order - From OE23 -Confirmed Order

Out

OE26 - Payment Details

Payment Details Payment Credentials for a given order. Updated: Mon Aug 11 2025 08:46:38 GMT-0700 (Pacific Daylight Time)	Top Authority: Credit Card Holder Automatic: null Activity Type: CONFIRMATION
Sizing         Hours to comlete: null     Why: null         Yearly Repeat: null   Why: null Information Management        OE26 creates Standard Information Other Information Sources (ad hoc): undefined	Specification (business rules) : Provide (for example) card number, expiry, security code, Amount and payee. UI Function : undefined Modeling Status: ATTR ModelNote: Who provides the cubicle for this assertion??It could be the retailer as a surrogate for the Card Company.Or it could be the Card Company itself to an end for the retailer ! This is interesting..

Inputs: -

Out General Notes null -desc- prototype value: example value PPPCustomer ID STRING -- New Desc -- prototype value: Credit Card Number STRING assumes PP collects this. prototype value: Expiry STRING -- New Desc -- prototype value: 02/26 Security Code STRING -- New Desc -- prototype value: 02/26 Amount CURRENCY To be paid prototype value: $99.97 Payee ID STRING identity known by visa for PP prototype value: To: OE27 Payment Request

OE14 - Payment Request

Payment Request A request of authorization from Visa for the payment for an Order Updated: Thu Dec 04 2025 15:56:15 GMT-0800 (Pacific Standard Time)	Top Authority: Finance Automatic: null Activity Type: null
Sizing         Hours to comlete: null     Why: null         Yearly Repeat: null   Why: null Information Management        OE14 creates Standard Information Other Information Sources (ad hoc): undefined	Specification (business rules) : - Card number- Expiration date- Cardholder name- CVV/CVC code (security code on the back of the card)- Billing address (used for Address Verification Service)- Authorization from the card issuer via VisaNet UI Function : undefined Modeling Status: INIT ModelNote: This is made as part of the confirmation of order.Who is the Authority for this? and is this Authority a Visa auth or a PP auth.No it is a PPAuth that is sent to a Visa assertion.

Inputs: -

Out

FN01 - Adjust Sales

Adjust Sales Post the Sales Order to the Sales Account Updated: Wed Nov 19 2025 15:19:08 GMT-0800 (Pacific Standard Time)	Top Authority: Finance Automatic: null Activity Type: FINDING
Sizing         Hours to comlete: 1     Why: null         Yearly Repeat: 5000   Why: null Information Management        FN01 creates Standard Information Other Information Sources (ad hoc): undefined	Specification (business rules) : Add the transaction UI Function : undefined Modeling Status: INIT ModelNote: null

Inputs: from: OE23 Confirmed Order - From OE23 -Confirmed Order

Out

MD01 - This Model Value Proposition

This Model Value Proposition An assessment of how well this model as a whole meets its stated objectives. Updated: Wed Dec 10 2025 08:40:01 GMT-0800 (Pacific Standard Time)	Top Authority: Modeler Automatic: null Activity Type: ASSESSMENT
Sizing         Hours to comlete: 1     Why: null         Yearly Repeat: 12   Why: Monthly retrospective Information Management        MD01 creates Standard Information Other Information Sources (ad hoc): null	Specification (business rules) : Summarize how well the model as a whole satisfies the original objectives. UI Function : Unlikely Modeling Status: INIT ModelNote: null

Inputs: from: MD02 Synergy From WAM and OrdEnt from: MD03 Clear AM Possibilities for DDD from: MD04 Opportunities for Modelers from: MD05 Professionalism of WAM and OrdEnd - From MD02 -Synergy From WAM and OrdEnt Summary null -desc- prototype value: Two sections in WAM (Example and Concepts-Methods-DDD) are in progress. WAM needs some work in edit and navigation and completeness. Places in the Specs should be found to point to concepts and DDD methods From MD03 -Clear AM Possibilities for DDD General null -desc- prototype value: The Specs are being generated and designed with mapping in mind. WAM section on DDD Methodology explains mapping. From MD04 -Opportunities for Modelers General Values null -desc- prototype value: example value From MD05 -Professionalism of WAM and OrdEnd General null -desc- prototype value: Model and WAM are in progress QA applied where possible and pass for Minimum Showable eXample(MSX) for QA to be done ( maybe point AI at output!

Out Success STRING prototype value: This model is successful when:- - It demonstrates DDD and BArch - A reader can review this without being confused or overwhelmed. - A reader is clear 'where' they are. - The order entry business is clear and concise. - The scope of OrdEnt is clear - A reader receives a depth of understanding so that they want to fine tune the model. - A DDD team wants to try to generate DDDSpecs - Parts of the model can be pointed to from WAM and vice-versa. General Values null prototype value: The intent is to have an example that would demonstrate the wide range of capabilites of assertion modeling. It should reveal to users how complete it is, and how it covers all the bases. In this context it should be judged by its ability to inform without confusing or overloading readers. Readers should come away with a sense that some of their current activities would be simplified and shortened by using AM. If it overwhelms readers they will stop reading. Hopefully reader concerns such as how to manage requirements, how to track stakeholders, etc should be addressed. Reading one perspective should show that a particular concern that the have can be easily captured and displayed, while maintaining the overall coherence of the model. To this end the model itself should stand alone but it will still need supporting descriptions in assertions.ca to fully meet expectations. Thus links out of the specific model should be added to help a reader grasp the intent of various sections with a specific problem perspective.

MD02 - Synergy From WAM and OrdEnt

Synergy From WAM and OrdEnt The Web AM site at assertions.ca (WAM) and The order Entry example reinforce each other Updated: Thu Dec 11 2025 06:41:37 GMT-0800 (Pacific Standard Time)	Top Authority: Modeler Automatic: null Activity Type: ASSESSMENT
Sizing         Hours to comlete: 1     Why: null         Yearly Repeat: 6   Why: Bi monthly Information Management        MD02 creates Standard Information Other Information Sources (ad hoc): null	Specification (business rules) : Assess how WAM is used to aid understanding of OrdEnt. Assess key capabilities of AM and ANZR are showcased. Assess how key capabilities are showcased in WAM or OrdEnd UI Function : null Modeling Status: INIT ModelNote: null

Inputs: -

Out Summary null -desc- prototype value: Two sections in WAM (Example and Concepts-Methods-DDD) are in progress. WAM needs some work in edit and navigation and completeness. Places in the Specs should be found to point to concepts and DDD methods To: MD01 This Model Value Proposition

MD03 - Clear AM Possibilities for DDD

Clear AM Possibilities for DDD Assess how DDD Specs support mapping. Clear Demonstration of Implementation Design in AM Updated: Thu Dec 11 2025 06:51:47 GMT-0800 (Pacific Standard Time)	Top Authority: Modeler Automatic: null Activity Type: ASSESSMENT
Sizing         Hours to comlete: null     Why: null         Yearly Repeat: null   Why: null Information Management        MD03 creates Standard Information Other Information Sources (ad hoc): null	Specification (business rules) : Assess how DDD Specs support mapping. Clear Demonstration of Implementation Design in AM UI Function : null Modeling Status: INIT ModelNote: null

Inputs: -

Out General null -desc- prototype value: The Specs are being generated and designed with mapping in mind. WAM section on DDD Methodology explains mapping. To: MD01 This Model Value Proposition

MD04 - Opportunities for Modelers

Opportunities for Modelers Assess how well AM and ANZR appear to support 'business description professionals' Updated: Thu Dec 11 2025 06:57:59 GMT-0800 (Pacific Standard Time)	Top Authority: Modeler Automatic: null Activity Type: ASSESSMENT
Sizing         Hours to comlete: null     Why: null         Yearly Repeat: null   Why: null Information Management        MD04 creates Standard Information Other Information Sources (ad hoc): null	Specification (business rules) : null UI Function : null Modeling Status: INIT ModelNote: null

Inputs: -

Out General Values null -desc- prototype value: example value To: MD01 This Model Value Proposition

MD05 - Professionalism of WAM and OrdEnd

Professionalism of WAM and OrdEnd Assess navigation, story, section focus, spelling, consistent naming etc. Updated: Thu Dec 11 2025 07:01:21 GMT-0800 (Pacific Standard Time)	Top Authority: Modeler Automatic: null Activity Type: ASSESSMENT
Sizing         Hours to comlete: null     Why: null         Yearly Repeat: null   Why: null Information Management        MD05 creates Standard Information Other Information Sources (ad hoc): null	Specification (business rules) : null UI Function : null Modeling Status: null ModelNote: null

Inputs: -

Out General null -desc- prototype value: Model and WAM are in progress QA applied where possible and pass for Minimum Showable eXample(MSX) for QA to be done ( maybe point AI at output! To: MD01 This Model Value Proposition

Responsibilities

---

Each of the Authorities ( Stakeholders) are included and for each the Assertions they are authorized to execute. The specification for that Assertion is included to indicate what the Authority is responsible for.


tbd   Default Authority
            Responsible to make the following determinations:

Determine

Calculate

Steering Committee   Responsible for advancing closer coupling between business and software development
            Responsible to make the following determinations:

Determine

Calculate

Marketing   Responsible for managing Customers and potential Customers
            Responsible to make the following determinations:

Determine
	OE08 - Customer Identity (a)   ------ null
Calculate

Sales Manager   Responsible for Sales Contracts
            Responsible to make the following determinations:

Determine
	OE23 - Confirmed Order   ------ State the Customer ID, Order ID, Amount, Order Items etc.
	OE27 - Payment Request   ------ Request (on Customers behalf ) that payment be made.
Calculate
	PR01 - Current Categories   ------ Provide values for designing code
	OE04 - Customer   ------ Method: GET GetCustomerDetailsForCustomerID Return a single record for a Customer
	OE05 - Customer Purchase (a)   ------ Confirm that the purchaser is a recognized customer. Has presented a payment or a suitable expectatin of payment. That the purchaser is properly informed of their contractual obligations and that parts, location and delivery are specified.
	OE12 - Full Sales Order (pu)   ------ Method: Create aggregate Validate and persist the Sales Order including Order Items.
	OE20 - Order Items (p)   ------ Add and remove item availabilities to shortlist a potential order.
	BR02 - Order Total Costs   ------ Tax is 5% of the total. Shipping(is taxed) is 10% of the total, or 8% for orders over $1000.
	OE10 - Pending Order Cart (a)   ------ Present the pending order for an identified browser of customer
	OE31 - Persisted Planned Order (pr)   ------ For a customerID return the Planned Order as last persisted.

Catalog Manager   Responsible for identifying, purchasing and cataloging the offered parts
            Responsible to make the following determinations:

Determine
Calculate
	OE18r - Available Parts List (pr)   ------ Method: Post GetAvailablePartsForFilter Select all parts that match any of the filter items.
	OE28 - Category (pr)   ------ State the selection of category items that a part may be included in.
	OE06 - Part (pr)   ------ Method: POST: GetDetailsForPartIDs- Return all parts details for the PartID
	OE29 - Parts Category Items (pr)   ------ Mrthod: GET GetAllCategoryItems - select all rows in the CategoryItem table.

Purchaser   Responsible for selecting a possible order. May be anonymous until identified as a Customer.
            Responsible to make the following determinations:

Determine

Calculate

Individual   A public authority that will have access to Cubicles that assign identity in environments.
            Responsible to make the following determinations:

Determine
	OE09 - Authority Identity (a)   ------ null
	OE22 - Payment Broker Authentication   ------ Compare supplied Payment Broker credentials to Broker memberlist to identify user.State (or navigate) access to subsequent Cubicles
Calculate

Vehicle   Responsible for exhibiting signs of failure ( See, this supports physical assertions)
            Responsible to make the following determinations:

Determine
	ME00 - Indication of Normal and Abnormal Function   ------ Make a noise or refuse to operate.
Calculate

Mechanic   Responsible for observing vehicle operation and identifying reolutions to malfunction.
            Responsible to make the following determinations:

Determine
	ME06 - Parts Delivery   ------ null
	ME05 - Parts Order   ------ Use information about source and perhaps PP Customer Cart to decide on order.this informs the Customer (who is same person) to invoke the order itself
	ME07 - Parts Replacement   ------ null
	ME04 - Parts Source   ------ List all the parts and quantities for this fix job.
	ME03 - Resolution Proposal   ------ Specify arguement for resolution and needed parts and actions.
	ME02 - Test Actions   ------ null
	ME01 - Vehicle Behavior   ------ State observed behaviors of a vehicle that may be normal expected or abnormal.
Calculate

Customer(Sales)   Responsible for commiting to a purchase and paying for it.
            Responsible to make the following determinations:

Determine
	OE25 - Intended Order   ------ Provide Cart, Customer ID, Payment Provider
	OE19 - Parts Filter   ------ List the shopper, the category, and a category item to be included in a search.
	OE21 - Payment Request   ------ State the Order ID Amount payment method.
	OE07 - Planned Order   ------ The Customer must inspect the Product Catlog in order to determine Product capabilities, fit, and prices. For this Simple example we assume they have a way of inspecting available parts subsetted by category items. ---Customer must decide to add an order item to the Planned Order (they have not comitted to buy yet). They can submit this information to the business rule that automatically determines total costs and shipping.
	OE11 - Submitted Order   ------ Populate the Shipping details from the Customer Record and and the current order from Planned Order. The customer is presented with the full details of the order and committs with an acceptance (contractural).
Calculate

Payment Broker   Like VISA will collect a Payment and provide confirmation
            Responsible to make the following determinations:

Determine
	PB02 - Payment Collected   ------ State the PB Client ID, the amount and the Visa (or otherwise confirmation code)
	PB01 - Payment Confirmation   ------ null
Calculate

Warehouse Manager   Responsible for tracking and protection of parts in a warehouse
            Responsible to make the following determinations:

Determine
	OE24 - Parts Committed   ------ State the quantity and PartID and Apearance ID so they can be reserved.
Calculate
	OE16 - Warehouse Inventory (pr)   ------ Return the quantity of available specified parts in a specified warehouse

Credit Card Holder   Responsible for initiating payments (and paying)
            Responsible to make the following determinations:

Determine
	OE26 - Payment Details   ------ Provide (for example) card number, expiry, security code, Amount and payee.
Calculate

Collaboration Team   Responsible for joint efforts to advance individual goals
            Responsible to make the following determinations:

Determine

Calculate

Shopper(Sales)   A person who wants to find and purchasse parts
            Responsible to make the following determinations:

Determine

Calculate

Developer   Responsible for creating prototype code
            Responsible to make the following determinations:

Determine

Calculate

Finance   Responsible for Purchase Accounts
            Responsible to make the following determinations:

Determine
	FN01 - Adjust Sales   ------ Add the transaction
	OE14 - Payment Request   ------ - Card number- Expiration date- Cardholder name- CVV/CVC code (security code on the back of the card)- Billing address (used for Address Verification Service)- Authorization from the card issuer via VisaNet
Calculate

Modeler   Responsible for building a model that addresses the expectations of the model itself
            Responsible to make the following determinations:

Determine
	MD03 - Clear AM Possibilities for DDD   ------ Assess how DDD Specs support mapping. Clear Demonstration of Implementation Design in AM
	MD04 - Opportunities for Modelers   ------ null
	MD05 - Professionalism of WAM and OrdEnd   ------ null
	MD02 - Synergy From WAM and OrdEnt   ------ Assess how WAM is used to aid understanding of OrdEnt. Assess key capabilities of AM and ANZR are showcased. Assess how key capabilities are showcased in WAM or OrdEnd
	MD01 - This Model Value Proposition   ------ Summarize how well the model as a whole satisfies the original objectives.
Calculate