Most supply chain solutions I've used were designed/tailored for specific products or industries: a finished good, a bill of materials (BoM), a lead time, a supplier confirming a date of goods receipt for PO number. The commodities industry is a completely different beast, and almost none of that is relevant (in terms of how supply chain tools are designed and configured. Some other logic still stays relevant).

There are many complex attributes that define the state of the commodity product: origin, grade, crop year, certification. Its quantity and quality are only final after sampling (e.g., a pre-shipment sample that gets sent to the customer for approval before cargo is loaded and leaves the port). The supply side follows a crop calendar rather than a production schedule that is applicable only for a small fraction of processing activities at origin (in case of soft commodities). And the date a shipment was promised is the date it is least likely to leave - welcome to the world of asymmetric supply chains that I covered in Heuristic 02.

Contract, allocation, sample, loading, departure and arrival on one line; origin and crop year are final at the contract, grade and quality once the lot is sampled, certification and quantity at loading, and the shipment date only when it leaves. — Figure 1 - When a commodity lot becomes final. By Aleks Sidorecs.

After some years in this industry, I've discovered the gap is never in the data. The trading system (e.g., CTRM) records every commercial transaction and volume allocation, with shipment periods normally expressed as specific weeks of the month. The freight management platform would monitor vessel bookings and every shipment milestone (e.g. gate-in, gate-out, departure and arrival, etc.). The gap is created by the absence of the specific layer capable of turning those records into a proper end-to-end supply chain plan: what we are short of, in which month, from which origin, and what it costs to bridge it (for example, from stocks somewhere in the warehouse).

In most cases, operations create that layer in spreadsheets (the second landscape I already covered in a separate publication about Citizen Developers in supply chain). It gets rebuilt every month (or day) by operators who knew the business too well to need a tool - until the complexity of the supply chain network and external variability outgrew human cognitive capabilities to manage it all (Heuristic 01 nails it down in the form of a specific rule).

Why the usual supply chain solutions are not so relevant for commodities

S&OP (Sales & Operations Planning) and S&OE (Sales & Operations Execution) are often delivered as two distinct modules or products. A monthly consensus plan via S&OP and a weekly or daily execution view with S&OE. The handover between the two is often missing or poorly calibrated (another word from commodities: calibrating with a client on product taste profile, bean screen size, etc.).

In (soft-) commodities, those two nodes are one problem that's nearly impossible to separate in time and space (I mean separating planning from execution activities).

The second issue is how standard tools treat the operational dynamics of commodity supply chains. Tools like SAP or MS Dynamics take a lead time and add a buffer. In commodities, a purchase contract usually doesn't arrive late by a fixed number of days because some lots (another unit of measure not captured by conventional technology) arrive on time, while others likely spread out over weeks and frequently get late (which means most contracts might be split into individual shipment orders that have different cycle times).

ERP logic: one PO, one receipt date, a lead time plus a buffer. Commodities: one contract splits into lots that leave from two weeks early to seven weeks late against the promised shipment week; there is no single lead time. — Figure 2 - One contract, N lots, N cycle times. By Aleks Sidorecs.

The final point is about trust. When a number changes, the planner tries to figure out the reason. Most often, the answer sits somewhere in a log file, or in a model nobody can replay. That's why planners tend to distrust the system's recommendations (e.g., APO) and do their own maths.

What is changing. Rules come first, and reliance on probabilities where the world is uncertain

In the Auspex project overview, I've reflected on the importance of knowing where a large language (or any other probabilistic...) model can really assist, and the critical aspects where we should keep it away, because most supply chain operations are high-stakes business. The rule I prefer to apply in developments like this is: keep it simple.

The same thinking explains why, in this project, netting, allocations, and compliance protocols will be deterministic by design: same inputs -> same repeatable result. For example, arrival dates and shipment delays are pure distributions and should be accessible so users can replay them. An LLM might explain the plan or create a draft email to chase shipping documents from the vendor, but every number in that text should come from the deterministic kernel.

The second design pattern is to avoid replicating what other systems already have. SCOPEC reads contracts, allocations, milestones and bookings from the CTRM (trading system) and the freight management platform and owns only what it decides, predicts or explains: plans, scenarios, parameters, exceptions and the record of every action. I just want to avoid learning while building a second trading system.

My expectations from the project

A planner/operator can oversee any position by origin and/or commodity grade for the defined period of months. They should be able to grasp working capital exposure quickly (e.g. inventory), navigate expected arrivals or shortfalls. At any moment, the person should decide what will cover gaps or customer fulfilment risks: own stock, then substitute grades (often at a discount), and, in the worst case, a new purchase from a third-party shipper. Operator clicks any number and tracks it back to the contracts, parameters, and algorithms that produced it.

The actor's position in the value chain, upstream (processing facility at origin) or downstream (final ingredient buyer), shapes how various physical facts are read or perceived. That's why the tool should run at least three operating views/perspectives through one kernel. A trader counts stock from shipment and plans against open sale contracts. A cocoa processor (for butter or liquid intermediate products) counts it at the plant, and plans against a production schedule programmed based on specific recipes that are analogous to a Bill of Materials. An ingredient buyer would plan against its own consumption forecast. Yes - to a certain extent, it's going to be the same data, but three completely different readings.

CTRM contracts and allocations, freight bookings and milestones and EUDR due diligence feed a deterministic kernel that reads them and never owns them; netting, allocation and compliance give the same result for the same inputs; trader, processor and ingredient buyer read the same data three ways; the kernel owns plans, scenarios, parameters, exceptions and the action record; the LLM and the agents sit at the edge, not in the kernel. — Figure 3 - One deterministic kernel, three readings. By Aleks Sidorecs.

Ah, nearly forgot this. I just updated the architecture plan (I'll publish it later, after I finish the Auspex part) because compliance is another important factor, and I should consider it as a real planning constraint. In 2026, several new regulations added additional constraints applicable to soft and hard commodities (e.g. EUDR, CBAM, PPWR etc.). For European Union-based companies (especially in the agri-food sector), we can meet demand only with valid due diligence data and legality assessments. Platforms that perform these validations produce the assessment results (e.g., Osapiens), so SCOPEC can apply those outcomes to the plan via API integrations.

I decided to put agents last in SCOPEC. Their autonomy to act and orchestrate will be earned, not granted by default (they will propose first). The mission of embedded agents is to take over the most boring part of the supply chain operator's work. Such work is represented by usual exceptions (a late shipment, rolled booking or a specific commodity-grade quality block) that the kernel would delegate to an assigned agent (e.g., escalator, coordinator, etc.). The signals will come from the deterministic solvers (in the form of the data), not the harness.

Autonomy of SCOPEC agents will be assigned per activity type/ID. The operator should be able to increase or reduce the level of autonomy (based on the agent's track record). I'm also considering action/decision rollback logic on top of the glass-box approach (when agents' decisions and actions can be reviewed and audited). Another roadmap item is connecting MCP (SCOPEC will have its own MCP server, so any external tool/agent can call it as well) to LangGraph, as I'm curious to explore how it works in practice.

How I will judge the completion

For the first phase of SCOPEC, I expect four things based on the sample data that will represent a synthetic company in the commodities sector before I will be able to call the project a success:

One kernel for both horizons: planning and execution to operate based on the same data stack to avoid segregation of S&OP and S&OE parts, as it's done in other industries (also the reason I don't reference them in the project title)
Outcome reproducibility: inputs should always return the same outputs, as stakes in operations are too high
Any action/decision/recommendation is explainable and reversible: operators should be able to understand what's and whys irrespective of their technology skills
Example of the synthetic company calibrated to real end-to-end commodities supply chain and operational realities.

I chose the name SCOPEC because it describes what I want to build: a test tool covering supply chain operations planning and execution in commodities.