Need visibility
A reliable view of the supplier's physical raw-material inventory is required.
One possible use / SCM inventory
WHAT ISREALLYTHERE.
From an information need to a verified view of the supplier's physical raw-material inventory.
This example shows one possible use after handover: AI can use the Semantic Reality to clarify a suspected stock discrepancy in business terms. The required states, roles, approvals, policies and follow-up steps are explicit. What remains open is only how this business logic is integrated into the concrete technical environment.
The agent's reasoning path
Think first.
Act when valid.
The question is concrete: what quantity of raw material is physically present at the supplier site right now?
AI uses the Semantic Reality to understand the business context. It can derive not only that a physical count is required, but can accompany the business clarification step by step: from Request for Inventory through approval, counting and reconciliation to a reliable completion. Roles, states and approvals constrain the valid action space at every point.
Check context
Material, supplier and the available inventory information are reviewed.
Assess certainty
The agent determines whether the available information is sufficient or a physical count is needed.
Discover the action
The valid Request for Inventory action and its required information are identified.
Derive the next step
The agent prepares the Request for Inventory in the valid business context and triggers it once the modelled prerequisites are satisfied.
Interpret the result
If verified quantities later become available, the AI can interpret them again in semantic context and use them for further tasks.
Agentic execution
How the agent carries out
the stock clarification.
The agent deliberately does not jump from “stock looks wrong” to “correct the stock”. It follows the effect chain described in the model and respects states, roles, approvals and business endpoints.
Where a human or business role must decide, the agent waits for that decision or prepares the next valid step. It does not invent missing approvals and does not bypass authorisation.
Request a targeted inventory
When a discrepancy is suspected, a Request for Inventory is created for exactly the affected Customer-Supplied Raw Material Stock. Supplier, material stock, Requested Result Due Date and Inventory Request Reason are set. This is valid only if the stock belongs to the supplier, the acting context is Material Responsible and the due date is at least one calendar day in the future.
Start and await approval
Start Processing Request for Inventory moves the request from Created to Under Approval. An Approval Request is created automatically, forwarded for this usage and work is created for the Assigned Approvers. A negative decision ends the request as Rejected; only a positive decision starts execution.
Create inventory and count scope
After positive approval, the request moves to In Process. The model creates an Interim Inventory Plan and then a Supplier Inventory. The requested material is automatically included as Material Participation = Selected. Because the request already defines the scope, the Supplier Inventory proceeds directly to Counting.
Have the physical count performed
A Supplier Inventory Count is created. An authorised Supplier Inventory Count User records the physical stock. The model covers Raw Material Stock, Finished Goods Stock, Work In Progress Stock, Scrap Stock and Transport Stock; stock categories not provided are treated as zero.
Reconcile count and recorded stock
After Submit Supplier Inventory Count, the Supplier Inventory automatically enters Reconciliation. A Supplier Inventory Material Reconciliation is created. The core comparison is: Counted Total Quantity – Recorded Total Stock Quantity = Stock Difference. The Recorded Stock Level must match the material and the relevant reference time.
Assess the result
If the discrepancy is plausible and exactly one matching Recorded Stock Level exists, the Material Responsible can complete the Material Reconciliation. It becomes Completed; its projection is finalised and the Absolute Stock Difference Value is retained immutably. This produces a reliable, quantified result.
Trigger revision if needed
If the result is not plausible, the reconciliation is moved to RevisionMarked. The Inventory Responsible is notified and can execute Request Supplier Inventory Count Revision. The supplier corrects or repeats the count and resubmits it. The reconciliation becomes Active again and is assessed again. The cycle can repeat.
Formally complete the clarification
Once all Material Reconciliations are finalised, at least Inventory Responsible Approval and Team Lead Approval must be approved. Above a total absolute discrepancy of EUR 30,000, Department Head Approval is additionally required; above EUR 100,000, Division Head Approval is also required. If a required approval is missing, the agent stops at this business endpoint and does not invent an Approval Request. Only then can the Supplier Inventory move to Reporting and be completed; the original Request for Inventory is completed automatically.
Important boundary
Clarifying stock is not correcting stock.
The described policy chain finalises the reconciliation and stores the identified stock discrepancy. It does not contain a direct policy that automatically overwrites the recorded Customer-Supplied Raw Material Stock with the counted value. Any stock update is therefore a separate business step.
Show the original agent output · English translation
Original output · English translationThe original output was created by GPT-5.6 Sol in German. The text below is a faithful English translation, reproduced in full and without editorial summarisation.
# Agentic Approach to Stock Clarification
## 1. Initial situation and business objective
I am the **Material Responsible** for a specific **Customer-Supplied Raw Material Stock** at a supplier.
There is a suspicion that the currently reported stock does not correspond to the physical stock actually present at the supplier.
The business objective is therefore initially **not the immediate correction of the reported stock**, but the reliable determination of the actual stock and its comparison with the stock recorded for the relevant point in time.
To achieve this, a targeted inventory count of the affected material must be initiated.
---
## 2. Create a Request for Inventory
As Material Responsible, I create a **Request for Inventory** for exactly the affected Customer-Supplied Raw Material Stock.
The following are specified:
- the affected Supplier,
- the Customer-Supplied Raw Material Stock to be checked,
- the desired **Requested Result Due Date**,
- the **Inventory Request Reason**, in this case the suspected stock discrepancy.
Creation is only permitted if the selected material stock belongs to the selected Supplier and I myself am the **Material Responsible** for this stock. The Requested Result Due Date must be at least one calendar day in the future.
Executing **Create Request for Inventory** creates a request in the state:
`Request for Inventory = Created`
I am stored as the **Requester** of the request.
---
## 3. Start processing the request
Because I am the Requester of the request, I then execute **Start Processing Request for Inventory**.
This changes the request from:
`Created → Under Approval`
This transition produces the event **Request for Inventory Processing Started**.
This event triggers the policy **Create Approval Request When Processing Starts**.
As a result, exactly one **Approval Request** is created for my Request for Inventory. The **Potential Inventory Representatives** form the Approver context.
---
## 4. Approval Request is forwarded automatically
For the specific Approval Usage **Request for Inventory**, the usage configuration
`Forward Created Approval Requests = true`
is set.
This satisfies the corresponding prerequisite for the general Approval policy.
The newly created Approval Request therefore does not remain in `Created`. The policy **Approval Request Policy Forward Created** becomes applicable and executes the transition **Forward Created Approval Request**:
`Approval Request: Created → In Process`
The resulting Forwarded event in turn triggers the policy **Approval Request Forwarded Work**.
This creates **Work for the Assigned Approvers**.
The chain of effects therefore explicitly does not end with the creation of the Approval Request.
---
## 5. Await and evaluate the Approval decision
The next business event is the decision of an authorised Approver.
This creates two different branches.
### Negative Approval decision
If the Approval Request is decided negatively, the policy **Reject Request When Approval Is Negative** becomes relevant.
As a result, the Request for Inventory is set to:
`Rejected`
The requested inventory count is not carried out on the basis of this request.
For this branch, the business endpoint has therefore been reached.
### Positive Approval decision
If the Approval decision is positive, the policy **Start Execution When Approval Is Positive** is triggered.
The Request for Inventory changes from:
`Under Approval → In Process`
This begins the actual execution of the requested stock clarification.
---
## 6. Create the inventory from the approved request
The start of execution triggers further policies.
First, **Create Interim Inventory Plan When Execution Starts** creates an **Interim Inventory Plan** for the approved request.
The approving User is taken into account as the **Inventory Representative** of the plan.
In parallel, the Requester is informed that the request is now **In Process**.
From the Interim Inventory Plan created for the request, **Create Supplier Inventory for Approved Request** then creates a **Supplier Inventory** for exactly the affected Supplier.
The Supplier Inventory retains the explicit relationship to the original Request for Inventory.
---
## 7. The requested material is automatically included in the counting scope
Because the Supplier Inventory was created from an approved Request for Inventory, the requested Customer-Supplied Raw Material Stock is automatically included as a **Material Participation**.
The policy **Add Requested Material Participation** causes exactly the material stock whose stock is to be clarified to be moved into the state:
`Material Participation = Selected`
One prerequisite, among others, is that the material stock remains active and belongs to the Supplier of the Supplier Inventory.
This means that the counting scope for this request is already clearly defined.
---
## 8. Supplier Inventory moves directly into Counting
Because this is a Supplier Inventory created from an approved Request for Inventory, the normal preceding scope-building process is skipped.
The policy **Start Requested Supplier Inventory Counting** moves the Supplier Inventory directly from:
`Active → Counting`
The phases for normal verification or preparation of the counting scope are not required here because the approved request already defines exactly which material is to be counted.
The start of Counting in turn triggers several business consequences:
A **Supplier Inventory Count** in the state `Active` is created, and the Supplier is informed that the stock count is to be carried out.
---
## 9. Supplier records the physical stock
An authorised **Supplier Inventory Count User** of the relevant Supplier records a **Supplier Inventory Material Count** for the selected Material Participation.
The Material Count contains the Count Date and the stock quantities actually counted.
The model takes quantities into account in the stock categories:
`Raw Material Stock`
`Finished Goods Stock`
`Work In Progress Stock`
`Scrap Stock`
`Transport Stock`
Stock categories that are not specified are taken into account with a quantity of zero.
For the stock clarification, this results in the physically counted total quantity of the material.
---
## 10. Supplier submits the count result
The Supplier Inventory Count can only be submitted with **Submit Supplier Inventory Count** if a corresponding Material Count exists for every selected Material Participation.
Because the Request for Inventory specifically brought the affected material stock into the Count Scope, a count result must in particular exist for this material stock.
Upon submission, the Supplier Inventory Count changes from:
`Active → Submitted`
The associated Material Count positions are also set to `Submitted`.
At the same time, the submission triggers the policy **Start Reconciliation When Count Submitted**.
The Supplier Inventory therefore changes automatically from:
`Counting → Reconciliation`
---
## 11. Material Responsible is involved in Reconciliation
When the Supplier Inventory enters `Reconciliation`, the policy **Notify Reconciliation Participants When Reconciliation Starts** is triggered.
The people involved in the Reconciliation are informed, in particular:
the Material Responsibles of the selected Material Participations, the Inventory Responsible, and the Inventory Representative.
As Material Responsible, I am therefore informed that the count result for my material is ready for business review and alignment.
---
## 12. Perform Material Reconciliation
A **Supplier Inventory Material Reconciliation** is created for the submitted Material Count.
The Material Reconciliation connects:
the physical material stock reported by the Supplier with the recorded **Customer-Supplied Raw Material Stock** for the relevant reference time.
The key business value is the:
**Stock Difference**
It is calculated as:
`Counted Total Quantity – Recorded Total Stock Quantity`
The Counted Total Quantity includes the physically recorded quantities across the relevant stock categories.
The Recorded Total Stock Quantity comes from the **Recorded Stock Level**, which must match both the Customer-Supplied Raw Material Stock under consideration and the **Relevant Reference Time** of the Reconciliation.
This turns the original suspicion into a quantitatively substantiated stock discrepancy, or into the determination that no corresponding discrepancy exists.
---
## 13. Evaluate the count result from a business perspective
As Material Responsible, I now evaluate the result of the Material Reconciliation.
There are two business possibilities.
### Count result is credible
If the count result is reliable and exactly one matching Recorded Stock Level is available for the relevant material stock and reference time, I can, as Material Responsible, execute **Complete Material Reconciliation**.
Only the Material Responsible of the relevant Material Participation is authorised to complete it.
The Material Reconciliation changes from:
`Active → Completed`
As a result, the associated Material Reconciliation projection of the Supplier Inventory is set to **Finalized**, and the determined **Absolute Stock Difference Value** is adopted immutably.
This provides a business-complete and quantified result of the stock clarification for this material.
### Count result is not plausible or a recount is required
If doubts about the count result remain, I do not complete the Material Reconciliation.
Instead, as Material Responsible, I execute **Mark Material Reconciliation For Revision**.
The Material Reconciliation changes from:
`Active → RevisionMarked`
This makes the policy **Notify Inventory Responsible About Revision Mark** relevant.
The **Inventory Responsible** is informed that a revision or recount is required for this material.
---
## 14. Request a recount
The actual revision of the Supplier Inventory Count may not be started by the Material Responsible.
Only the **Inventory Responsible** can execute **Request Supplier Inventory Count Revision**.
A prerequisite is that at least one associated Material Reconciliation is in `RevisionMarked`.
Requesting the revision changes the Supplier Inventory Count from:
`Submitted → Revision`
At the same time, the marked Material Reconciliation and the associated Material Count are moved into the revision state.
The Supplier can then correct or repeat the affected count.
---
## 15. Recheck the revised count result
The Supplier then resubmits the corrected Supplier Inventory Count using **Submit Supplier Inventory Count Revision**.
The Supplier Inventory Count returns to:
`Submitted`
The affected Material Reconciliation receives the revised count data and automatically returns from:
`Revision → Active`
It is therefore once again available for business evaluation by the Material Responsible.
I review the updated result again.
If the result is still not reliable, the Reconciliation can again be marked for Revision.
If the result is reliable and exactly one matching Recorded Stock Level exists, I complete the Material Reconciliation.
This creates a business-modelled repetition cycle:
`Active`
→ `RevisionMarked`
→ `Count Revision`
→ `Supplier corrects Count`
→ `Revision`
→ `Active`
→ `review again`
until a reliable stock clarification is available.
---
## 16. Result of the stock clarification
With completion of the Material Reconciliation, the following has been established for the affected material from a business perspective:
- the total quantity physically reported by the Supplier,
- the Recorded Stock Level for the relevant reference time,
- the resulting **Stock Difference**,
- and the **Absolute Stock Difference Value** that is authoritative for the further Supplier Inventory.
An important point is:
The effect of a completed Material Reconciliation described in the Semantic Book consists of **finalising the Reconciliation and storing the stock discrepancy**.
By contrast, the policy chain followed here contains **no direct policy that, as a result of completing the Material Reconciliation, automatically overwrites the reported Customer-Supplied Raw Material Stock with the counted value**.
Stock clarification and any stock update that may subsequently be required must therefore be distinguished from one another from a business perspective.
---
## 17. Complete Supplier Inventory Reconciliation
Once all Material Reconciliations have been finalised, the Supplier Inventory can leave Reconciliation.
This may only be performed by the Supplier's **Inventory Responsible** using **Finish Supplier Inventory Reconciliation**.
For this, all Material Reconciliations of the Supplier Inventory must be `Finalized`.
In addition, the model requires the applicable approved Approval Requests.
During `Reconciliation`, the following are always required:
**Inventory Responsible Approval** and
**Team Lead Approval**.
In addition, if the total absolute discrepancy value exceeds **EUR 30,000**, a **Department Head Approval** is required.
If it exceeds **EUR 100,000**, a **Division Head Approval** is additionally required.
Positive and negative material discrepancies are taken into account at their absolute value for these thresholds and do not offset one another.
Only when the required Approvals are present as `Approved` can the Inventory Responsible execute:
`Supplier Inventory: Reconciliation → Reporting`
The Semantic Book defines these Approved Approval Requests as a prerequisite for completing Reconciliation. However, in the chain of effects followed here, there is no unambiguous subsequent policy modelled that automatically creates the corresponding Approval Requests solely because these Approval-Required situations occur. The agent must therefore not independently add or assume their creation.
If the required Approved Approval Requests are not yet available, this point is a business endpoint due to an unmet prerequisite.
---
## 18. Complete Supplier Inventory and Request
When the Supplier Inventory is in `Reporting`, it can be completed by the **Inventory Representative** of the associated Inventory Plan.
By executing:
`Complete Supplier Inventory`
the Supplier Inventory changes to:
`Completed`
This result triggers further policies.
In particular, the **Request for Inventory** that belongs exactly to this Supplier Inventory is completed automatically:
`Request for Inventory: In Process → Completed`
In addition, the associated Supplier Inventory Count is automatically moved into its terminal state `Completed`.
Completion of the Request for Inventory informs the Requester that the request has been completed.
This also formally completes the original assignment to clarify the stock.
---
# Overall agentic logic
The agent therefore does not behave according to the pattern:
`Stock appears incorrect → correct stock`
but instead:
`Stock discrepancy suspected`
→ `request targeted inventory count`
→ `perform Approval`
→ `create physical count`
→ `compare count result with Recorded Stock Level`
→ `request recount if there are doubts`
→ `finalise reliable result`
→ `complete Supplier Inventory`
→ `complete Request for Inventory`
The central responsibility of the Material Responsible lies in particular in initiating the stock clarification and evaluating the material-related Reconciliation result from a business perspective.
---
# Complete policy chain
`Suspected discrepancy in Customer-Supplied Raw Material Stock`
→ `Create Request for Inventory`
→ `Request = Created`
→ `Start Processing Request for Inventory`
→ `Request = Under Approval`
→ `Create Approval Request When Processing Starts`
→ `Approval Request = Created`
→ `Forward Created Approval Requests = true`
→ `Approval Request Policy Forward Created`
→ `Approval Request = In Process`
→ `Approval Request Forwarded Work`
→ `Work for Assigned Approvers`
→ `{Negative Approval → Reject Request → Request = Rejected → Endpoint | Positive Approval → Start Execution}`
→ `Request = In Process`
→ `{Requester Notification | Create Interim Inventory Plan}`
→ `Create Supplier Inventory for Approved Request`
→ `Add Requested Material Participation`
→ `Material Participation = Selected`
→ `Start Requested Supplier Inventory Counting`
→ `Supplier Inventory = Counting`
→ `{Create Supplier Inventory Count | Notify Supplier}`
→ `Supplier creates Material Count`
→ `Submit Supplier Inventory Count`
→ `{Material Count = Submitted | Start Reconciliation}`
→ `Supplier Inventory = Reconciliation`
→ `Notify Reconciliation Participants`
→ `Create Material Reconciliation`
→ `Stock comparison: Counted Total Quantity – Recorded Total Stock Quantity`
→ `{plausible → Complete Material Reconciliation | not plausible → Mark For Revision}`
→ if Revision: `Notify Inventory Responsible`
→ `Request Supplier Inventory Count Revision`
→ `Supplier Inventory Count = Revision`
→ `Supplier corrects Count`
→ `Submit Supplier Inventory Count Revision`
→ `Material Reconciliation = Active`
→ `business review again`
→ if necessary, repeat Revision
→ `Complete Material Reconciliation`
→ `Material Reconciliation Projection = Finalized + Absolute Stock Difference Value`
→ `required Supplier Inventory Approvals must be Approved`
→ `Finish Supplier Inventory Reconciliation`
→ `Supplier Inventory = Reporting`
→ `Complete Supplier Inventory`
→ `{Request for Inventory = Completed | Supplier Inventory Count = Completed | Supplier Inventory Projection = Finalized}`
→ `Notify Requester`
→ **Endpoint**
What SemanticMind provides
The model describes
what should hold in the business.
SemanticMind does not provide the inventory application here. It provides the explicit business representation behind it: action, prerequisites, approvals, follow-up effects and expected result remain traceably connected.
That semantic foundation is the product. It can be used with AI of choice for this scenario — or for other questions and applications derived from the same business reality.
Request for Inventory
SemanticMind describes which business action is needed and which information — supplier, date and reason — is required for it.
Make approval explicit
The model describes when approval is required, which role may decide and which states follow from a positive or negative decision.
Understand dependencies
Interim Inventory Plan, Supplier Inventory, Material Participation and Counting become visible as connected business consequences.
Define Completed clearly
The model describes when the inventory is complete in business terms and which verified quantities are then available as reliable facts.
One possible use
The product stays the same.
Its use is open.
The SCM scenario is one possible interpretation of the Semantic Reality, not a prescribed operating model. The same foundation can be used with a different AI, different questions and different outputs.
UseDefines the purpose.
Questions, the AI used and the handling of results depend on the respective need.
AI / agentInterprets the Semantic Reality.
Uses the explicit context to answer questions, assess options, derive outputs or prepare further steps.
Semantic RealityPreserves the business meaning.
Connects meaning, situations, rules, responsibility and possible effects as the semantic representation of the business area in scope.
Kernaussage
The agent develops the reasoning.
The model protects the business.
The outcome is not an assumption about what may have been delivered. It is a verified statement of what raw material is physically present at the supplier site. The agent can use that fact as the basis for the next business decision.
→Next: MQLS deep dive