Sector · Supply chain and logistics
Physical AI for supply chain and logistics
These are the questions engineers ask first, answered from 3 published CodeNinja Atoms reference architectures.
- What does a physical AI system for supply chain and logistics look like?
- Which AI models can a supply chain and logistics operator run on its own hardware?
- How much compute and hardware does AI in supply chain and logistics need?
- Is it cheaper to own AI hardware or rent cloud GPUs in supply chain and logistics?
- What ontology or object model does a supply chain and logistics AI system need?
- Who approves the decisions an AI system makes in supply chain and logistics?
What does a physical AI system for supply chain and logistics look like?
A complete physical AI design for supply chain and logistics names what to sense, which existing systems to join, the object model that joins them, the models and hardware, the three-year cost and the person who approves every action. CodeNinja Atoms has published 3 such reference architectures for supply chain and logistics, each free to reuse under CC BY 4.0.
| Design | Country | What it does |
|---|---|---|
| Industrial Data Ontology for a Cold Chain From Plant to Store in the United States | United States | An open reference architecture for system design in physical AI, built as an industrial data ontology for a refrigerated and frozen food manufacturer in the United States that ships from its plants through its own and third party cold storage to retail distribution centers and stores, where owning the reasoning node that runs it costs about 591,000 US dollars over three years. When a retailer reports a soft case, or a regulator names a lot under the federal food traceability rule, the design joins the plant's lot, the warehouse's license plate, the carrier's reefer readings, the transport shipment line and the retailer's receipt into one journey, so the quality team can say within the hour which pallets shared a dock and a truck and produce the lot's whole record in hours instead of a week and three phone calls. The model runs entirely on the operator's own hardware inside the United States, with no third party model service. |
| Sovereign AI Architecture for a Freight Corridor and Customs Clearance in Saudi Arabia | Saudi Arabia | An open reference architecture for system design in physical AI, built for a national freight and logistics operator in Saudi Arabia that moves containers and bulk from seaports to dry ports and freight yards by rail and road across corridors of more than two thousand kilometres, where owning the inference node that runs it costs about 569,000 US dollars over three years. When a declaration stalls at the seaport while the road leg runs late for its train, the design joins the declaration, the container, the train and its handover slot, the road leg and the open customer case into one consignment story, so a corridor planner sees the stall, the connection it will cost and the customer who will call, and approves the chase and the re booking before the call comes. All reasoning runs on the operator's own hardware in the country under the national data protection law, the customs authority's interface terms and export control on the GPU node. |
| A Self-Improving AI System for Carrier Exception Handling in the United States | United States | An open reference architecture for system design in physical AI, built for a third party logistics provider in the United States that plans, tenders and tracks tens of thousands of truckload and less than truckload shipments a month for shippers across hundreds of contracted carriers, where owning the inference hardware that runs it costs about 606,000 US dollars over three years. When a truck breaks down on a multi stop load at night, the design joins the shipment and its stops, the live tracking, the appointment windows, the carrier's scorecard and contract, the claims record and the threads where the same exception was worked before into one argument, so the coordinator sees the cascade to the next stops, the carrier swap and the appointment changes drafted, and the shipper told before the first missed window. Every model runs on the operator's own hardware under the shippers' data terms, the carrier contracts, the federal hours of service rules and the applicable privacy law for driver data. |
Which AI models can a supply chain and logistics operator run on its own hardware?
Each published supply chain and logistics design names its models and why, and every model is open-weight or no model is used at all, so the operator can run it on hardware it owns.
| Design | Models |
|---|---|
| Industrial Data Ontology for a Cold Chain From Plant to Store in the United States | GLM 5.3, named by the operator, as the frontier class open weight work surface for the mapping, excursion and trace agents and the cited conversational interface, under a license whose attribution notice and managed service trigger counsel reviews before hosting; document reading and embedding entries by class on an air cooled PCIe server; no entry survived live verification on this run, so the register holds catalog entries and the commitment waits on a verified row; nothing is trained or fine tuned, improvement runs through the memory of confirmed joins |
| Sovereign AI Architecture for a Freight Corridor and Customs Clearance in Saudi Arabia | GLM 5.3 (class open weights, self hosted, frontier class) named by the requirement for the command center that answers questions about a consignment with citations, with GLM 5.2 under MIT as the licence fallback; the register commits no model row until a live verification passes; no third party model service, nothing trained into weights |
| A Self-Improving AI System for Carrier Exception Handling in the United States | GLM 5.3 (GLM-5.3 bespoke license, 753B at FP8) for the triage, recovery and review drafting, the command center's cited conversational interface and ontology maintenance; Qwen3.8 27B (Apache-2.0, FP8) at the site tier parsing years of threads and notes; Qwen3-Embedding 0.6B (Apache-2.0) for retrieval over threads, notes and resolutions; no third party model service, nothing trained into weights |
| Design | Choice | What was picked | Why |
|---|---|---|---|
| Industrial Data Ontology for a Cold Chain From Plant to Store in the United States | Reasoning model | GLM 5.3, named by the operator: frontier class open weights at FP8 (756 GB of weights as the sizing rule states it), served on vLLM on one node of the 141 GB class in the operator's existing server room in the United States | The operator names it, and FP8 on one node beats BF16 across two nodes and a mid size model that would thin the work surface; its license carries an attribution notice and a managed service trigger that internal use does not touch, reviewed by counsel before the weights are hosted; no register entry survived live verification on this run, so the commitment waits on a verified row (8.1, 9.5) |
| Industrial Data Ontology for a Cold Chain From Plant to Store in the United States | Document reading and embedding models | By class only: the document reading and embedding entries the design cites, fitting one to four cards of the 141 GB class on an air cooled PCIe server in the same room | Same discipline as the work surface: committed only when a verified entry stands in the register; nothing in the design is trained or fine tuned (7.1, 8.1) |
| Industrial Data Ontology for a Cold Chain From Plant to Store in the United States | Frontier hardware | 141 GB HBM GPU class, eight GPUs per node, one node (8 x 141 GB, about 10 kW) | Holds GLM 5.3's 756 GB of FP8 weights with about 280 GB of KV cache headroom for the command center's conversations and citations; the node count is derived only when a verified entry stands (7.1, Table 4) |
| Industrial Data Ontology for a Cold Chain From Plant to Store in the United States | Frontier footprint sizing rule | Frontier model GPU footprint sizing rule, vLLM and SGLang | A class and a sizing rule, never a part number; the alternatives weighed were BF16 across two nodes and a mid size model (7.1, 11.4) |
| Industrial Data Ontology for a Cold Chain From Plant to Store in the United States | Secondary server | Air cooled PCIe server class carrying one to four cards of the 141 GB class | Carries the document reading and embedding entries beside the reasoning node in the same room (7.1, 8.2) |
| Industrial Data Ontology for a Cold Chain From Plant to Store in the United States | Sensing | Cold chain sensing classes: no cameras or sensors are supplied; dock and reefer readings arrive as partner data on existing feeds, each stamped with a named measurement point (ambient, return air, supply air or product simulating) | The constraint is to read existing systems and partner feeds; naming the measurement point makes a dock reading and a reefer reading comparable rather than assumed to agree (4.2, 8.2, 11.4) |
| Industrial Data Ontology for a Cold Chain From Plant to Store in the United States | Serving runtime | vLLM (SGLang named beside it by the sizing rule) | Serves the FP8 weights within the KV cache headroom the sizing reserves |
| Industrial Data Ontology for a Cold Chain From Plant to Store in the United States | Event backbone | Apache Kafka 4.3 in KRaft mode with three dedicated controllers | Per key ordering by source key; at least once delivery with idempotent writes so a replayed event cannot create a second pallet or excursion; buffering absorbs the dock log's batch cadence (6.3) |
| Industrial Data Ontology for a Cold Chain From Plant to Store in the United States | Adapters | Integration adapter on Debezium change data capture; telemetry adapter for reefer and dock feeds; EDI adapter on Apache Camel routes | Three families normalise eight sources into one grammar, stamp every fact with its source system and key, expose no write path, and hold ingest until each partner's data terms are confirmed in writing (6.2) |
| Industrial Data Ontology for a Cold Chain From Plant to Store in the United States | Telemetry store | InfluxDB 3 Core or TimescaleDB class, chosen with the operator's database lead at design | Reefer and dock readings need a time series store beside the ontology (Table 7, 9.5) |
| Industrial Data Ontology for a Cold Chain From Plant to Store in the United States | Ontology store | Hyper Ontology v0.9 (semantics plus kinetics) | Holds the sixteen objects and their typed links as a projection over the eight systems of record (Table 7) |
| Industrial Data Ontology for a Cold Chain From Plant to Store in the United States | Identity | Keycloak | Every approval attaches to a named person (5.2) |
| Industrial Data Ontology for a Cold Chain From Plant to Store in the United States | Registry | Harbor, air gapped artifact and model registry | Artifacts and weights move only through the registry, so a bad update rolls back to the artifact that preceded it (7.3) |
| Industrial Data Ontology for a Cold Chain From Plant to Store in the United States | Time synchronisation | Chrony (NTP) | A join that depends on dock time depends on plant |
| Industrial Data Ontology for a Cold Chain From Plant to Store in the United States | Observability | Prometheus, Grafana and Loki | Observability of the running system (Table 7) |
| Industrial Data Ontology for a Cold Chain From Plant to Store in the United States | Power protection | Rack power and UPS managed with Network UPS Tools | Carries the room when power fails; a single node failure still halts the command center, so a rehearsed degraded mode is kept warm (7.3) |
| Industrial Data Ontology for a Cold Chain From Plant to Store in the United States | Pattern: memory | Memory of confirmed joins and excursion decisions, read before the next run, nothing trained into weights | The requirement rules out training a model on the fly; the second join is cheaper than the first because the first is remembered (5.2, 10.1) |
| Industrial Data Ontology for a Cold Chain From Plant to Store in the United States | Pattern: shadow mode | The mapping agent runs in shadow beside the quality managers, with a measured acceptance rate before any credit is taken | Entity resolution is first class work and the program's schedule risk, not a byproduct (9.2, 9.4) |
| Industrial Data Ontology for a Cold Chain From Plant to Store in the United States | Pattern: projection | The object model is a projection over the eight systems of record, never a shadow copy; no system is replaced, migrated or loaded | Several systems belong to partners and are not the operator's to modify (3.2, 4.1) |
| Industrial Data Ontology for a Cold Chain From Plant to Store in the United States | Pattern: boundary | The operator's own hardware in the United States; inbound read only feeds; no egress path and no third party model service; partner feeds gated on written data terms | Product, lot and partner data never leave the operator's control; a hold is a person's decision by law under the refrigerated storage rule (3.1, 3.3) |
| Sovereign AI Architecture for a Freight Corridor and Customs Clearance in Saudi Arabia | Reasoning model | GLM 5.3, class open weights, self hosted, frontier class, taken as 753B parameters at FP8 (about 756 GB of weights); named in the requirement, not yet committed in the register | The requirement names it; open weights on the owner's own hardware keep every answer in country; the register records the row as open work because no open weight model was verified live on this run, and weights are committed only when a verified model stands in the register |
| Sovereign AI Architecture for a Freight Corridor and Customs Clearance in Saudi Arabia | License fallback model | GLM 5.2 under MIT | Escapes the GLM 5.3 licence trigger for a corporate group running a Model as a Service business above 10 billion US dollars; the owner's corporate group is checked at phase zero |
| Sovereign AI Architecture for a Freight Corridor and Customs Clearance in Saudi Arabia | Frontier hardware | 141 GB HBM GPU class, eight GPUs per node, one node (about 1,038 GB of usable memory) | Holds about 756 GB of FP8 weights with about 280 GB of KV cache ceiling; phase one is sized on one node and the extension gates scale it; two 80 GB class nodes and BF16 on a 256 GB class node were set aside |
| Sovereign AI Architecture for a Freight Corridor and Customs Clearance in Saudi Arabia | Frontier footprint sizing rule | Model GPU footprint sizing rule, vLLM and SGLang | Fixes the node count from weights |
| Sovereign AI Architecture for a Freight Corridor and Customs Clearance in Saudi Arabia | Node count rule | GLM 5.3 node count by GPU class | One node of eight 141 GB class GPUs for the phase one corridor; scaling is decided at the extension gates rather than assumed |
| Sovereign AI Architecture for a Freight Corridor and Customs Clearance in Saudi Arabia | Export licence | Determination against ECCN 3A090 and 4A090 before any GPU class is quoted | Saudi Arabia sits in Country Groups D:3 and D:4; the 141 GB class ships only under licence; the checkpoint sits in phase zero before purchase |
| Sovereign AI Architecture for a Freight Corridor and Customs Clearance in Saudi Arabia | Event backbone | Apache Kafka 4.3 in KRaft mode | Carries every change the adapters emit in order; partitions keyed on the container number; at least once delivery with idempotent handlers; retained logs are the replay and recovery path |
| Sovereign AI Architecture for a Freight Corridor and Customs Clearance in Saudi Arabia | Adapters | Two families: the integration adapter on Debezium with Apache Camel, and the telemetry adapter for the haulier feeds | Every source enters behind one guarantee of lineage |
| Sovereign AI Architecture for a Freight Corridor and Customs Clearance in Saudi Arabia | Ontology store | Hyper Ontology v0.9 | Holds the corridor ontology as a projection over the seven systems of record |
| Sovereign AI Architecture for a Freight Corridor and Customs Clearance in Saudi Arabia | Time series store class | InfluxDB 3 Core, TimescaleDB or QuestDB, chosen later | The choice waits on the phase one corridor's measured event volumes |
| Sovereign AI Architecture for a Freight Corridor and Customs Clearance in Saudi Arabia | Registry | Harbor, air gapped artifact and model registry | Weights and artifacts enter only through the registry and are verified before anything is served |
| Sovereign AI Architecture for a Freight Corridor and Customs Clearance in Saudi Arabia | Identity | Keycloak | Permissions scoped to the three human roles; logistics data leaks from inside as well as outside |
| Sovereign AI Architecture for a Freight Corridor and Customs Clearance in Saudi Arabia | Time synchronisation | Chrony | Disciplines the clocks that event ordering depends on; a GNSS grandmaster class is added only if the software answer proves insufficient |
| Sovereign AI Architecture for a Freight Corridor and Customs Clearance in Saudi Arabia | Observability | Prometheus, Grafana and Loki | Observe the running system; staleness flags and the per interface cadence are published in the command center |
| Sovereign AI Architecture for a Freight Corridor and Customs Clearance in Saudi Arabia | Sensing | None; records and telematics only, no cameras and no new positioning hardware | The corridor is watched through declarations |
| Sovereign AI Architecture for a Freight Corridor and Customs Clearance in Saudi Arabia | Pattern: memory | A kept record of decisions and outcomes that the next decision reads, nothing trained into weights | The requirement asks for improvement without training a model on the fly; every confirmed stall cause and accepted re booking is kept |
| Sovereign AI Architecture for a Freight Corridor and Customs Clearance in Saudi Arabia | Pattern: join | Weekly join success gate at 95 per cent with failures triaged by source system | The container number is the one key that crosses all seven systems; a join failing silently is worse than no join |
| Sovereign AI Architecture for a Freight Corridor and Customs Clearance in Saudi Arabia | Pattern: boundary | The owner's own hardware in an in country data center; inbound reads only; no third party model service; egress monitoring at the boundary | Cargo |
| A Self-Improving AI System for Carrier Exception Handling in the United States | Reasoning model | GLM 5.3, filed at 753B parameters, FP8 (753 GB of weights), GLM-5.3 bespoke license, served on vLLM on one node in the operator's own facility in the United States | The model the requirement names; its license permits commercial use, fine tuning and redistribution, so the operator holds its own copy with no per token obligation; carries the triage and recovery drafting, the command center's cited conversational interface and ontology maintenance |
| A Self-Improving AI System for Carrier Exception Handling in the United States | Site tier parsing model | Qwen3.8 27B, dense, Apache-2.0, served at FP8 (about 31 GB of weights) on one 48 GB PCIe card in an air cooled server | High volume thread and note parsing over years of archived email and chat and the live threads, a throughput workload kept off the frontier node so coordinator sessions keep their concurrency; about 13 GB of KV ceiling on the card |
| A Self-Improving AI System for Carrier Exception Handling in the United States | Embedding model | Qwen3-Embedding 0.6B, Apache-2.0, about 1.2 GB at BF16 and about 0.6 GB at 8 bit, sharing the site tier server, 32K context window | Embeddings over threads, notes and resolutions so retrieval finds the past exception that matches this week's; permission aware, returning only what the asking coordinator could already open |
| A Self-Improving AI System for Carrier Exception Handling in the United States | Frontier hardware | 141 GB HBM GPU class, eight GPUs per node, one node (1,128 GB) | Holds 904 GB (753 GB of FP8 weights times the 1.2 planning factor) with about 280 GB of KV cache ceiling at the 0.92 utilization the sizing rule allows; about 15 kW of rack power per node with margin, 10 RU, 10 to 35 C inlet |
| A Self-Improving AI System for Carrier Exception Handling in the United States | Frontier footprint sizing rule | Frontier Model GPU Footprint Sizing Rule (vLLM, SGLang): parameters times one byte at FP8 times 1.2 | Turns filed parameter counts into a memory requirement before any workload is placed |
| A Self-Improving AI System for Carrier Exception Handling in the United States | Node count rule | GLM 5.3 node count by GPU class | One node of eight 141 GB GPUs; two nodes of the 80 GB class or BF16 serving (about 1.5 TB) rejected because they add a second node joined over an interconnect |
| A Self-Improving AI System for Carrier Exception Handling in the United States | Site tier hardware | 48 GB PCIe card class, one card, in an air cooled PCIe server the facility's server room already takes | Fits the parsing model's FP8 weights with KV ceiling to spare and carries the embedding model beside it without a second server |
| A Self-Improving AI System for Carrier Exception Handling in the United States | Serving runtime | vLLM | Serves the FP8 weights within the KV cache ceiling the sizing reserves |
| A Self-Improving AI System for Carrier Exception Handling in the United States | Registry | MLflow Model Registry on site | Pinned model images; serving restarts from pinned images with a rollback exercised once under observation; the desk never runs on an unobserved weight change |
| A Self-Improving AI System for Carrier Exception Handling in the United States | Event backbone | Apache Kafka (KRaft mode) | Ordering by offsets and per stream sequence numbers with each source's clock offset recorded, at least once delivery with idempotent projection, buffering in the retained log, replication inside the facility |
| A Self-Improving AI System for Carrier Exception Handling in the United States | Time series store | InfluxDB 3 Core | Tracking telemetry under the object model |
| A Self-Improving AI System for Carrier Exception Handling in the United States | Orchestration | Kubernetes | Containers for the services and the serving tier inside the facility |
| A Self-Improving AI System for Carrier Exception Handling in the United States | Identity | Keycloak | Federated identity for coordinators and permission aware retrieval scoped by each shipper's data terms |
| A Self-Improving AI System for Carrier Exception Handling in the United States | Observability | Prometheus | Observes the running system |
| A Self-Improving AI System for Carrier Exception Handling in the United States | Sensing | None; the existing carrier tracking and visibility feeds are read | Trucks are seen through feeds the operator already owns; no camera, positioning hardware or edge box is built |
| A Self-Improving AI System for Carrier Exception Handling in the United States | Pattern: memory | Memory loops over confirmed outcomes, nothing trained, fine tuned or distilled into weights | The requirement's own words: better every week without training a model on the fly; memory is auditable where weights are not |
| A Self-Improving AI System for Carrier Exception Handling in the United States | Pattern: approval | Every draft confirmed by a named coordinator; one gated write path into the scheduling tool | Confirmations logged as ground truth, with known answer probes and weekly sampling against rubber stamping |
| A Self-Improving AI System for Carrier Exception Handling in the United States | Pattern: baseline | The pilot lane group's exception measures are recorded before any coordinator sees a draft | Improvement is measured against evidence, not impression; the phase 1 gate reads time to resolve and repeat exceptions against that baseline |
| A Self-Improving AI System for Carrier Exception Handling in the United States | Pattern: boundary | The operator's own hardware in its own facility in the United States; no inference call, retrieval or draft leaves the building; only approved carrier messages and shipper notices cross | Shipper and carrier data never leave the operator's hardware, open weights only, no third party model service |
How much compute and hardware does AI in supply chain and logistics need?
The compute follows from the models: the published supply chain and logistics designs size it as follows, from no new hardware to a full GPU node.
| Design | Part | The design |
|---|---|---|
| Industrial Data Ontology for a Cold Chain From Plant to Store in the United States | Compute | One central tier in the operator's existing server room in the United States: one node of eight 141 GB HBM cards (1,128 GB) drawing about 10 kW, holding 756 GB of FP8 weights with about 280 GB of KV cache headroom; no compute in freezers, on docks or in trucks, because readings arrive as partner data; inbound feeds only, no egress path, updates through the Harbor registry |
| Sovereign AI Architecture for a Freight Corridor and Customs Clearance in Saudi Arabia | Compute | One node of eight 141 GB HBM cards in the operator's own in-country data center, holding about 756 GB of FP8 weights on about 1,038 GB of usable memory with about 280 GB of KV cache ceiling, planned at about ten kilowatts; no edge tier, no cameras, no new field sensing. The node is a 4A090 class item for a D:3 and D:4 destination, so an export licence determination against ECCN 3A090 and 4A090 is a phase zero checkpoint before any GPU class is quoted |
| A Self-Improving AI System for Carrier Exception Handling in the United States | Compute | One node of eight 141 GB HBM cards (1,128 GB) in the operator's own facility, holding 753 GB of FP8 weights with the 1.2 planning factor, 904 GB, and about 280 GB of KV ceiling for concurrent coordinator sessions; one 48 GB PCIe card in an air cooled server for the parsing and embedding models; no edge tier and no cameras, the trucks are seen through the tracking feeds the operator already owns |
Is it cheaper to own AI hardware or rent cloud GPUs in supply chain and logistics?
Each supply chain and logistics design prices three years of ownership in its Appendix A, with every price cited, against renting the same capacity from a cloud region at its deepest three-year commitment where hardware is bought.
| Design | Line | Three years |
|---|---|---|
| Industrial Data Ontology for a Cold Chain From Plant to Store in the United States | Three-year cost | About 591,000 US dollars to own the node for three years (a range of 546,000 to 615,000: node, support and power at the national average commercial or industrial price), against about 625,000 to rent the same eight cards on the deepest three year commitment in AWS US East (N. Virginia), so ownership costs about nine tenths of it, and about 1.66 million on demand, against which ownership costs about a third. Renting is a price reference only, because every rented option would carry product, lot and partner data out of the operator's hardware (Appendix A) |
| Sovereign AI Architecture for a Freight Corridor and Customs Clearance in Saudi Arabia | Three-year cost | About 569,000 US dollars to own the node for three years (a range of 541,000 to 594,000: server, support and power at the national commercial electricity tariff), against about 751,000 to rent the same eight cards on the deepest three year commitment in AWS Middle East (UAE), so ownership costs about three quarters of it, and about 2.00 million on demand, against which ownership costs a little over a quarter. Renting is a price reference only, because AWS listed no Saudi region on the day read and every rented option would carry cargo, customer and declaration data across the border (Appendix A) |
| A Self-Improving AI System for Carrier Exception Handling in the United States | Three-year cost | About 606,000 US dollars to own both tiers for three years (a range of 577,000 to 665,000: the node, the card, support and power at national average prices), of which the node is about 591,000, against about 644,000 to rent the same hardware on the deepest three year commitment in AWS US East (N. Virginia), so ownership costs about 94 percent of it, and about 1.71 million on demand, against which ownership costs about a third. Renting is a price reference only, because every rented option would carry shippers' freight data and the threads out of the operator's facility (Appendix A) |
What ontology or object model does a supply chain and logistics AI system need?
The object model is the part that makes the system an ontology rather than a pipeline: typed objects for the things in the supply chain and logistics operation, with properties, status values and typed links. Every published design ships its object model as hyper-ontology/1 JSON that loads into Hyper Ontology.
| Design | Size | Objects | Download |
|---|---|---|---|
| Industrial Data Ontology for a Cold Chain From Plant to Store in the United States | 16 objects, 13 links | Product, Lot, Pallet, Case, Critical tracking event, Custodian, Location, Dock, Truck, Reefer reading, Excursion, Hold, Release, Complaint, Receipt, Traceability record | objects.json |
| Sovereign AI Architecture for a Freight Corridor and Customs Clearance in Saudi Arabia | 15 objects, 11 links | Consignment, Container, Declaration, Train, Wagon, Road leg, Haulier, Terminal, Dry port, Handover slot, Exception, Customer case, Corridor planner, Yard controller, Service desk agent | objects.json |
| A Self-Improving AI System for Carrier Exception Handling in the United States | 16 objects, 13 links | Shipper, Order, Shipment, Stop, Appointment, Carrier, Driver, Tracking event, Exception, Exception type, Action, Resolution, Standing fix, Claim, Scorecard entry, Exception coordinator | objects.json |
Who approves the decisions an AI system makes in supply chain and logistics?
In every published supply chain and logistics design a named person makes the decision that changes the physical world; the system prepares it.
| Design | Human control |
|---|---|
| Industrial Data Ontology for a Cold Chain From Plant to Store in the United States | Agents draft and people decide, by name: the traceability analyst confirms every identifier join the mapping agent drafts, the quality manager approves every hold the excursion agent recommends and acts in the quality hold and release system, the regulatory affairs lead sends every trace record the trace agent drafts; no agent places or lifts a hold or sends a record to a regulator, an escalation view surfaces unacknowledged excursions, and every confirmed join is kept as memory the next join reads |
| Sovereign AI Architecture for a Freight Corridor and Customs Clearance in Saudi Arabia | Agents draft and people decide, by name: the corridor planner approves the stall chase and the revised handover slot, the yard controller approves every re booking, and the service desk agent sends the cited answer; approval authority is a property of the actor objects, a per shift alert budget is agreed before thresholds are set, the action rate is itself a gate, and every confirmed stall cause and accepted re booking is kept as memory the next plan reads |
| A Self-Improving AI System for Carrier Exception Handling in the United States | Agents draft and coordinators decide, by name: the exception coordinator confirms the triage draft and approves the carrier message, the appointment change and the shipper notice, the operations manager approves each standing fix, the approver is recorded on the action object, and confirmations are tested with known answer probes and a weekly sample so that ground truth is a decision and not a reflex; every confirmed outcome becomes memory the next exception reads |
Every answer on this page is drawn from the papers linked in it: each paper's At a glance table, model register and cost appendix. Full text for agents: llms-full.txt. Designed on Praxis; object models load into Hyper Ontology.
Want one of these designs for your own operation? Talk to us.