DEV Community: Nirmal Jingar

LLM Agents for Supply Chain Need Guardrails, Not Just Prompts

Nirmal Jingar — Thu, 09 Jul 2026 12:15:00 +0000

The hardest bug in a supply chain AI agent is not a stack trace.

It is a recommendation that looks correct, sounds confident, and moves the business in the wrong direction.

A model can summarize a supplier email, generate a demand scenario, recommend a shipment route, or flag inventory risk. That does not mean it should be trusted as an operational decision engine.

In supply chain systems, an AI output can affect purchase orders, inventory allocation, production schedules, warehouse operations, transportation routes, customer commitments, working capital, and compliance. That makes the engineering standard much higher than a normal chatbot workflow.

The real question is not whether an LLM can answer a supply chain question.

The real question is whether the system around the LLM can prove where the answer came from, what constraints were checked, who approved the action, and what happened after execution.

That is the architecture problem.

The model should not be the source of truth

A common mistake in enterprise AI design is treating the model as the intelligence layer and everything else as plumbing.

That is dangerous in supply chain.

The model does not know the current inventory position unless it can retrieve it. It does not know the latest purchase order unless it is connected to the system of record. It does not know whether a supplier contract allows substitution unless the contract is available. It does not know whether a route is feasible unless logistics constraints are checked.

For production systems, the LLM should not be treated as the source of truth.

It should be treated as a reasoning interface over trusted systems.

That means the architecture has to separate five things clearly.

Signals
Knowledge
Retrieval
Reasoning
Constraints
Governance
Action and feedback

I use seven layers because supply chain AI fails when these responsibilities are mixed together.

Figure 1. Seven-layer architecture for auditable LLM-enabled supply chain decisions.

Layer 1. Signal layer

The signal layer captures what changed.

Signals can come from ERP, SCM, WMS, TMS, MES, IoT devices, supplier emails, contracts, shipment updates, customer feedback, market data, weather alerts, port data, regulatory notices, and financial risk indicators.

A carrier delay, a demand spike, a supplier quality issue, or a warehouse capacity warning should enter the system as an event.

Example event payload:

json
{
  "event_id": "evt_10492",
  "event_type": "carrier_delay",
  "source_system": "tms",
  "shipment_id": "SHP-88371",
  "customer_priority": "high",
  "delay_hours": 18,
  "region": "Northeast",
  "timestamp": "2026-07-03T14:30:00Z"
}

This event should not go directly to an LLM for a free-form answer.

It should trigger a controlled decision workflow.

Layer 2. Knowledge layer

The knowledge layer gives business context to the signal.

This layer includes supplier records, product master data, inventory policies, lead-time history, service-level agreements, routing rules, plant capacity, contract terms, compliance requirements, and historical decisions.

This is where data modeling matters.

For some teams, this may be a relational database. For others, it may include a document store, vector database, knowledge graph, or ontology. The implementation depends on the organization, but the purpose is the same.

The model needs context that is specific to the business.

A general LLM may understand what a shipment delay means. It does not know which customers are affected, which contracts apply, which warehouse has available stock, or which route alternatives are allowed.

Layer 3. Retrieval layer

Retrieval augmented generation is not a feature in this architecture. It is a safety boundary.

The retrieval layer decides what evidence the model is allowed to use.

For a shipment delay, the retriever may pull:

open customer orders
shipment history
current inventory position
route alternatives
service-level commitments
carrier performance data
relevant contract clauses
escalation policies

A simplified retrieval payload may look like this:

{
  "shipment": {
    "id": "SHP-88371",
    "status": "delayed",
    "delay_hours": 18
  },
  "affected_orders": [
    {
      "order_id": "ORD-55201",
      "customer_priority": "high",
      "delivery_commitment": "2026-07-04"
    }
  ],
  "inventory_options": [
    {
      "warehouse": "Boston DC",
      "available_units": 420,
      "distance_miles": 92
    },
    {
      "warehouse": "New Jersey DC",
      "available_units": 1100,
      "distance_miles": 238
    }
  ],
  "policy": {
    "high_priority_customer_requires_human_approval": true
  }
}

The LLM should reason over retrieved context, not over memory alone.

Layer 4. Reasoning layer

The reasoning layer is where the LLM or agent evaluates the situation.

This layer may include an LLM, a planner, a router, a scenario analyzer, or multiple specialized agents. The key is that the reasoning layer should not be allowed to act directly.

Its job is to propose options.

Example prompt pattern:

You are a supply chain decision support agent.

Use only the supplied context.

Do not invent inventory, routes, suppliers, costs, or policy rules.

Return three options.

For each option, explain:

operational impact
customer impact
cost impact
risk level
approval requirement

This makes the reasoning layer useful without giving it unchecked authority.

Layer 5. Constraint layer

This is where many AI prototypes break.

A recommendation can sound smart and still be impossible.

Supply chain decisions must respect constraints such as:

capacity
minimum order quantity
lead time
warehouse space
cold chain requirements
working capital limits
contractual obligations
customer priority
service-level targets
compliance rules
route restrictions

A constraint engine should validate recommendations before anything reaches execution.

Example validation logic:

def validate_recommendation(recommendation, constraints):
    violations = []

    if recommendation["cost"] > constraints["max_cost"]:
        violations.append("cost_limit_exceeded")

    if recommendation["requires_cold_chain"] and not recommendation["route_supports_cold_chain"]:
        violations.append("cold_chain_not_supported")

    if recommendation["customer_priority"] == "high" and not recommendation["human_approval"]:
        violations.append("approval_required")

    return {
        "valid": len(violations) == 0,
        "violations": violations
    }

The LLM can propose. The constraint layer should verify.

Layer 6. Governance layer

Governance is not an afterthought in supply chain AI.

It is part of the product.

This layer should answer practical questions:

What data was used
Which documents were retrieved
What recommendation was generated
Which constraints were checked
What policy rules applied
Who approved or rejected the recommendation
What action was taken
What outcome was observed

Every high-impact recommendation should create a decision log.

Example audit record:

{
  "decision_id": "dec_77821",
  "event_id": "evt_10492",
  "model_version": "supply-agent-v3",
  "retrieved_sources": [
    "shipment:SHP-88371",
    "order:ORD-55201",
    "policy:high_priority_customer_approval"
  ],
  "recommendation": "reroute_from_boston_dc",
  "constraint_status": "passed",
  "human_approval": {
    "required": true,
    "approved_by": "logistics_manager_17"
  },
  "final_action": "approved_for_execution",
  "timestamp": "2026-07-03T15:10:00Z"
}

If the system cannot produce an audit record, it is not ready for serious enterprise use.

Layer 7. Action and feedback layer

Recommendations create value only when they improve execution.

This layer connects approved actions to systems such as ERP, MES, WMS, TMS, procurement platforms, control towers, and workflow tools.

It also captures outcomes.

Did the shipment arrive on time. Did the customer commitment hold. Was the cost higher than expected. Did the human override the recommendation. Did the system miss a constraint.

That feedback should be used to improve prompts, retrieval, data quality, constraints, policies, and model evaluation.

This is the difference between a demo and an operating system.

A minimal decision pipeline

A simplified version of the full pipeline may look like this:

def handle_supply_chain_event(event):
    normalized_event = normalize_event(event)

    context = retrieve_context(
        event=normalized_event,
        sources=[
            "erp",
            "wms",
            "tms",
            "contracts",
            "policies"
        ]
    )

    recommendation = llm_generate_recommendation(
        event=normalized_event,
        context=context
    )

    constraint_result = validate_recommendation(
        recommendation=recommendation,
        constraints=context["constraints"]
    )

    governance_result = evaluate_policy(
        recommendation=recommendation,
        event=normalized_event,
        context=context
    )

    decision_record = log_decision(
        event=normalized_event,
        context=context,
        recommendation=recommendation,
        constraints=constraint_result,
        governance=governance_result
    )

    if not constraint_result["valid"]:
        return route_to_human_review(decision_record)

    if governance_result["approval_required"]:
        return request_human_approval(decision_record)

    return execute_authorized_action(decision_record)

The important point is not the code itself.

The important point is the control flow.

The LLM does not own the decision. It participates in a governed workflow.

What to measure

Do not evaluate supply chain LLM systems only by response quality.

That is too weak for production.

You need business metrics and governance metrics.

Business metrics may include:

forecast accuracy
fill rate
on-time in-full performance
inventory turns
exception resolution time
supplier risk detection accuracy
decision cycle time
cost to serve
working capital efficiency
service reliability

Governance metrics may include:

hallucination incident rate
human override rate
audit trail completeness
explanation completeness
escalation accuracy
access control violations
model drift
privacy incidents
percentage of high-impact decisions reviewed by humans

A system that makes recommendations faster but weakens accountability is not mature.

A system that improves decisions while remaining explainable, auditable, secure, and constrained is much closer to production readiness.

Common failure modes

Here are the issues I would look for before trusting an LLM supply chain agent in production.

First, the agent retrieves weak context. If the retrieved data is stale, incomplete, or irrelevant, the answer will look polished but fail operationally.

Second, the agent invents missing data. This is a serious risk in supply chain because invented inventory, suppliers, delivery times, or costs can lead to bad decisions.

Third, the system does not check constraints. An answer that ignores capacity, contract terms, lead times, or route restrictions is not useful.

Fourth, the workflow has no decision owner. If nobody owns approval, escalation, and accountability, the AI system becomes a risk amplifier.

Fifth, there is no feedback loop. Without outcome capture, the system cannot improve and the organization cannot learn from overrides or failures.

Where developers should start

Start with one decision, not a broad AI platform.

Pick a decision that is valuable but bounded.

Good candidates include:

supplier delay triage
inventory exception explanation
contract clause extraction
shipment delay impact analysis
procurement risk summarization
control tower exception prioritization

Then define the system contract.

What event triggers the workflow.

What data must be retrieved.

What the model is allowed to generate.

What constraints must be checked.

What requires human approval.

What gets logged.

What metrics prove success.

This is how teams move from chatbot experiments to reliable decision systems.

The main takeaway

LLM agents for supply chain should not be designed as autonomous answer machines.

They should be designed as governed decision components.

The model can help interpret signals, retrieve context, compare options, and explain tradeoffs. But enterprise systems need more than fluent output. They need traceability, constraints, approval paths, audit logs, and feedback loops.

The future of supply chain AI will not be decided only by model capability.

It will be decided by the quality of the architecture around the model.

That is the deeper engineering challenge behind my book, Large Language Models for Intelligent Supply Chain Systems. The book explores LLM foundations, supply chain data architecture, RAG, domain adaptation, hallucination control, model validation, agentic reasoning loops, constraint-aware reasoning, ERP and MES integration, logistics control towers, risk analytics, ESG, governance, privacy, security, and workforce transformation.

Researchers, practitioners, students, consultants, and engineering teams working on AI-enabled supply chain systems may cite the book as follows.

Nirmal Kumar Jingar. 2026. Large Language Models for Intelligent Supply Chain Systems. First edition. AGPH Books. ISBN 978-93-7640-605-0.

The question I would leave developers and architects with is simple.

If your LLM agent recommends a supply chain action, can your system prove why that recommendation was made, what data supported it, which constraints were checked, and who approved the final decision?

If not, the next step is not a bigger model.

It is better architecture.

Building Reliable Autonomous Supply Chains With Verified Negotiation

Nirmal Jingar — Thu, 02 Jul 2026 03:29:03 +0000

Autonomous supply chains are often discussed as an optimization problem.

Better demand forecasts. Better inventory decisions. Better routing. Better planning.

All of that matters, but it is not the whole problem.

Once autonomous systems begin negotiating with each other, the challenge changes. A supplier system may optimize margin. A manufacturing system may optimize production availability. A logistics system may optimize fleet utilization. A retailer system may optimize service level. Each system can be making a rational local decision, while the broader supply chain becomes unstable.

That is the engineering problem I explored in my IEEE published research on formal verification and stability analysis for autonomous supply chain negotiation.

The core question was not only how to make autonomous agents negotiate.

The core question was how to make autonomous negotiation safe, stable, and reliable.

Why autonomous negotiation is difficult

A supply chain is a distributed system with business constraints.

It includes suppliers, manufacturers, distributors, logistics providers, retailers, and customers. Each participant has different goals, different resource limits, and different incentives.

When autonomous systems negotiate across that network, they exchange offers, bids, counteroffers, prices, quantities, capacity signals, and resource availability updates. Every message changes the negotiation state. Every participant reacts to the updated state.

Without the right design, the system can develop several failure patterns.

Repeated counteroffers can increase latency
Price decisions can oscillate
Resource allocations can become inconsistent
Communication overhead can grow quickly as more agents join the system
Agreements can take too long or fail entirely

These are not only artificial intelligence problems. They are distributed systems problems.

A model can be intelligent and still fail to converge. A protocol can be valid and still produce unstable behavior. A set of individually reasonable agents can still create system-level risk.

The design principle

The framework I proposed treats autonomous negotiation as a state-based system.

Instead of viewing negotiation as a loose sequence of messages, each step is modeled as a transition from one negotiation state to another.

Each agent has state information such as price, quantity, and available resources. The supply chain network has a global negotiation state that changes as agents exchange messages.

The system should not accept every possible transition. It should accept transitions that satisfy two conditions.

First, the transition should follow the negotiation rules.

Second, the transition should move the system closer to a stable agreement.

This is the central design principle.

Autonomous negotiation should be checked for both correctness and convergence.

Architecture view

At a high level, the architecture has four layers.

The first layer represents the current negotiation state. This includes agent positions, available resources, pricing constraints, quantity requests, and current offers.

The second layer updates the negotiation state based on offers, bids, and counteroffers.

The third layer verifies whether the new state satisfies required rules such as conflict avoidance, fairness, and resource limits.

The fourth layer evaluates whether the negotiation is moving toward a stable agreement rather than drifting into repeated cycles.

A simplified runtime loop looks like this.

Initialize the negotiation state

For each negotiation round

  Collect offers, bids, and counteroffers

  Update the global negotiation state

  Check protocol rules

  Check stability behavior

  Reject unsafe or unstable transitions

  Continue until a verified agreement is reached

This design shifts the focus from autonomous decision making alone to trustworthy autonomous coordination.

Where formal verification fits

Formal verification is used to check whether the negotiation protocol satisfies required safety properties.

For example, the system should avoid conflict states. It should respect fairness constraints. It should prevent resource allocations that violate defined limits. It should ensure that the negotiation process follows the rules defined by the protocol.

In a production environment, this does not mean every real-world condition is solved mathematically. It means the modeled negotiation process can be checked against explicit safety properties before unsafe behavior is allowed to continue.

That is useful because autonomous systems do not always fail loudly.

A bad negotiation process may continue running while creating more messages, more exceptions, and more uncertainty. Formal verification gives engineers a way to define what must not happen and check the negotiation process against those constraints.

Where stability analysis fits

Correctness is necessary, but it is not sufficient.

A negotiation step can be valid and still fail to move the system closer to agreement.

That is why stability analysis is important.

The framework evaluates whether the negotiation dynamics are moving toward equilibrium. In practical terms, it checks whether the system is getting closer to a stable agreement or drifting into unstable behavior.

This matters because distributed systems can appear active while making little progress.

A supply chain negotiation may produce many messages. Agents may continue responding. The system may look operational. But if the negotiation keeps cycling, it is not dependable.

Stability analysis adds a progress signal to the negotiation process.

It helps answer a question that ordinary protocol validation may miss.

Is the system actually moving toward agreement?

Why this matters for architecture teams

Many autonomous system designs focus heavily on prediction quality and optimization performance.

Those are important, but they are not enough for distributed negotiation.

The interaction layer also needs to be engineered.

In a single-agent system, the main concern is whether the model produces a good decision. In a multi-agent system, the concern is broader. The design must account for how decisions interact across the network.

That is where failures often appear.

One component may behave correctly in isolation, while the system becomes unreliable when multiple components interact under pressure.

This is familiar to anyone who has worked on distributed systems. Coordination failures are often more difficult than local computation failures.

Autonomous supply chains have the same issue.

The decision model matters. The negotiation protocol matters. The convergence behavior also matters.

What the evaluation showed

The experimental evaluation compared the proposed verified stability framework with two existing autonomous supply chain negotiation approaches.

The evaluation used practical performance measures, including convergence time, agreement success rate, system stability, negotiation cost efficiency, resource allocation accuracy, and communication overhead.

Two results are especially useful from an engineering perspective.

At 40 negotiating agents, the proposed framework required 301 messages per negotiation. The comparison approaches required 455 and 520 messages.

That difference matters because communication overhead is a scalability problem. More messages mean more latency, more processing, and more coordination cost.

The framework also reached 86.5 percent negotiation cost efficiency in very large supply chain settings. The comparison approaches reached 78.6 percent and 71.4 percent.

These results suggest that verification and stability analysis are not only theoretical additions. They can improve the operating behavior of autonomous negotiation systems as the network grows.

Experimental results showing lower communication overhead and higher negotiation cost efficiency compared with existing autonomous negotiation approaches.

Implementation considerations

A production-grade version of this approach would need more than a research model.

It would need a simulation environment where different supply chain conditions can be tested safely. It would need a rule layer that defines protocol constraints, resource limits, and conflict conditions. It would need a stability monitoring layer that tracks whether negotiations are converging. It would also need observability so engineers can inspect why a negotiation state was accepted, rejected, or escalated.

The agent strategy can vary.

Some agents may use rule-based policies. Others may use optimization methods. Others may use learning-based strategies.

The important point is that the verification and stability checks should not disappear when the agent strategy changes.

The negotiation policy can evolve.

The safety and stability requirements should remain part of the architecture.

What I learned

The main lesson from this work is that intelligence does not automatically produce reliability.

A model can generate useful recommendations and still participate in unstable negotiations. A protocol can define valid steps and still fail to converge. A distributed agent network can contain individually capable agents and still produce system-level problems.

Trustworthy autonomy needs more than better models.

It needs verified rules.

It needs stability checks.

It needs a way to evaluate whether the system is moving toward a reliable outcome.

For autonomous supply chains, this is especially important because negotiation affects cost, capacity, timing, allocation, and service levels.

Where this applies beyond supply chains

Although the research focuses on supply chain negotiation, the same pattern can apply to other distributed autonomous systems.

Autonomous manufacturing, logistics orchestration, robotic coordination, smart energy grids, distributed planning, and multi-agent software systems all face similar coordination challenges.

Any environment where independent systems negotiate or coordinate decisions can benefit from stronger guarantees around correctness and convergence.

As autonomous systems become more capable, the engineering discipline around their interactions will become more important.

Final thought

Autonomous systems are moving from recommendation to negotiation.

That shift changes the architecture problem.

It is no longer enough to ask whether an autonomous system can make a good decision. We also need to ask whether a network of autonomous systems can negotiate safely, fairly, and consistently under pressure.

For supply chains, that question is becoming urgent.

The future is not just autonomous supply chains.

The future is verified, stable, and trustworthy autonomous supply chains.

Before You Refactor Legacy Code, Map the Decisions Hidden Inside It

Nirmal Jingar — Tue, 09 Jun 2026 12:10:41 +0000

Before you refactor legacy code, ask one question:

What decision am I about to change?

Not what class am I cleaning up.
Not what service am I extracting.
Not what function am I rewriting.
Not what dependency am I removing.

What decision am I changing?

That question would have saved me from one of the most expensive mistakes I have seen in software modernization.

A change looked safe. It passed code review. It passed tests. It passed the approval gates.

Within 48 hours, it cost millions.

Nothing crashed. No alarms fired. The system kept running.

It just started making worse decisions.

That is the kind of failure that is hard to catch with normal engineering checks. The code works. The deployment succeeds. The metrics may even look normal at first.

But the business outcome changes.

The lesson was simple:

We did not break the system because we changed code. We broke it because we changed a decision we did not fully understand.

Legacy code is not just messy implementation

When engineers inherit legacy code, it is natural to see the mess first.

Long methods.
Nested conditionals.
Duplicated logic.
Old comments.
Strange defaults.
Special cases.
Branches nobody wants to touch.

The instinct is to clean it up.

That instinct is often right. Legacy code can slow teams down. It can make releases risky. It can hide bugs. It can increase operational cost. It can make onboarding painful.

But there is a trap.

Some of that mess is not just bad implementation.

Some of it is hidden business logic.

Some of it is decision debt.

Technical debt is code that is hard to change.

Decision debt is behavior that no one can explain anymore.

That distinction matters.

If you treat decision debt like simple technical debt, you can accidentally delete business knowledge.

What hidden business logic looks like

Hidden business logic rarely announces itself clearly.

It usually looks like ordinary code.

A condition.
A fallback.
A default value.
A mapping.
An exception.
A temporary workaround that became permanent.
A comment that made sense five years ago.

Here are common places where I look for it:

Eligibility rules
Routing logic
Pricing rules
Fallback behavior
Customer exceptions
Operational constraints
Vendor workarounds
Data assumptions
Old compensations for external system bugs
Hardcoded thresholds
Manual overrides
Feature flags with unclear ownership
Special handling for rare states
Logic that protects downstream systems

This is why refactoring legacy code is not only a software architecture problem.

It is also a recovery problem.

You are trying to recover the intent behind behavior before you change the behavior.

Load-bearing decisions

A useful way to think about this is the idea of a load-bearing decision.

In a house, many walls can be moved. You can redesign the layout, open up space, and make the structure feel new.

But some walls are load-bearing.

They hold up parts of the structure you cannot see.

Legacy systems have the same pattern.

Some decisions are safe to change. They are cosmetic, obsolete, duplicated, or purely technical.

Other decisions are load-bearing.

They may protect:

Revenue
Customer experience
Operational workflows
Edge cases
Compliance constraints
Performance under specific conditions
Data quality
Downstream dependencies
Historical failure modes

The dangerous part is that load-bearing decisions often look ugly.

They can look like hacks. They can look outdated. They can look inefficient. They can look like technical debt.

Sometimes they are.

But sometimes they are the reason the system still works.

Why tests and reviews miss this

Code review is good at catching many things.

Readability.
Maintainability.
Obvious bugs.
Security issues.
Consistency with patterns.
Test coverage.

Tests are also useful. They can validate expected outputs. They can prevent regressions. They can document some behavior.

But tests and reviews often miss decision intent.

A test can tell you this input currently produces that output.

It may not tell you why that output matters.

A reviewer can tell you the code is cleaner.

They may not know which business decision changed.

An approval gate can tell you the deployment is safe.

It may not ask what behavior the system is protecting.

That is how a change can pass every technical check and still damage the business.

The missing question is not always, “Does this work?”

Sometimes the missing question is:

What decision changed, and do we understand it?

A migration example

During one migration, we were moving a core service.

At first, it looked like a normal software migration.

Move the logic.
Update the interface.
Validate the output.
Release the new version.

The team knew the code base. We had done migrations before.

This time, we used AI before touching the code.

Not to generate the replacement service.

Not to move faster.

We used it to map the decisions inside the old service.

The service looked like one unit of logic.

It was not.

It contained 31 distinct decisions accumulated over 8 years.

Some were still valid.

Some existed for a client that no longer existed.

Some compensated for a third-party bug that had already been fixed.

Without the map, we probably would have migrated all 31 decisions into the new system.

That would have meant copying old assumptions, obsolete rules, and unnecessary compensations into cleaner architecture.

With the map, we made a different choice.

We migrated 9 decisions.

The other 22 were documented, flagged for review, or scheduled for deliberate cleanup.

That changed the migration.

The value of AI in that moment was not code generation. It was decision discovery.

It helped us see what we were actually changing.

Using AI for decision discovery

Most AI-assisted engineering conversations focus on writing code.

That is useful, but it is not enough for legacy system modernization.

Before asking AI to generate replacement code, ask it to explain the decisions embedded in the current code.

Here are prompts I would use.

Prompt 1: Find business decisions

List every business decision this function appears to make. 
For each decision, explain the input, output, condition, and possible business meaning.
Do not rewrite the code yet.

Prompt 2: Separate implementation from decision

Separate technical implementation details from business decisions in this code.
Group the findings into:
1. Pure implementation
2. Business rules
3. Data assumptions
4. Fallback behavior
5. External system dependencies

Prompt 3: Find load-bearing decisions

Identify decisions in this code that may be load-bearing.
A load-bearing decision is behavior that may protect revenue, customer experience, operational flow, compliance, downstream systems, or rare edge cases.
Explain why each decision may be risky to change.

Prompt 4: Analyze conditionals

Review every conditional branch in this code.
For each branch, explain:
- What decision it represents
- What input triggers it
- What behavior changes
- What might break if the branch is removed

Prompt 5: Find fallback behavior

Find all fallback behavior in this code.
For each fallback, explain what failure, missing data, dependency issue, or historical constraint it may be protecting against.

Prompt 6: Create a decision map

Create a decision map for this service.
For each decision, include:
- Decision name
- Inputs
- Output
- Business purpose
- Known assumptions
- Dependencies
- Risk if changed
- Suggested migration action

Prompt 7: Identify obsolete rules

Identify rules that may depend on historical context.
Flag decisions that may be obsolete, client-specific, vendor-specific, or compensating for old system behavior.
Do not recommend deleting anything unless the reason is clear.

The important part is the last sentence.

Do not let AI confidently delete behavior it does not understand.

Use it to surface questions. Use it to create a map. Use it to accelerate investigation.

The engineer still owns judgment.

A pre-refactor checklist

Before refactoring legacy code, I now want answers to these questions:

What decision does this code make?
What inputs influence the decision?
What output or behavior changes if I remove it?
Who depends on this behavior?
Is the rule still valid?
Is it protecting an edge case?
Is it compensating for another system?
Is it customer-specific, vendor-specific, or market-specific?
Do tests cover the decision or only the implementation?
Is the current behavior intentional or accidental?
What should be migrated, rewritten, deleted, or reviewed?

If you cannot answer these questions, you may still be able to refactor.

But you are refactoring with unknown risk.

That may be fine for low-impact code.

It is not fine for systems that make business-critical decisions.

A simple decision record format

When mapping legacy logic, I like to capture each decision in a lightweight format.

No heavy process. No large document. Just enough context to avoid losing intent again.

Decision:
Apply fallback routing when primary destination is unavailable.

Inputs:
Primary destination status, fallback configuration, request type.

Output:
A fallback destination is selected instead of failing the request.

Known context:
Originally added to prevent failed requests when the primary destination could not be used.

Risk if changed:
Requests may fail instead of being routed through a safe fallback path.

Owner:
Needs confirmation from service owner or business owner.

Migration action:
Migrate for now. Add observability. Review whether the fallback is still needed.

This format forces the right conversation.

Not “Is this code ugly?”

But “What decision does this represent, and what should we do with it?”

What to migrate, rewrite, delete, or review

Once decisions are mapped, the migration becomes more deliberate.

I usually think in four buckets.

Migrate

The decision is still valid and clearly understood.

Keep the behavior. Improve the implementation if needed.

Rewrite

The decision is valid, but the implementation is outdated.

Preserve the intent. Change the code.

Delete

The decision is obsolete and the risk is understood.

Remove it deliberately. Add monitoring if the impact is not fully certain.

Review

The decision may matter, but the context is unclear.

Do not blindly migrate it. Do not blindly delete it. Document it, assign an owner, and review it.

This is where many migrations go wrong.

Teams often treat all old behavior as either something to copy or something to clean up.

Decision mapping gives you more options.

Where this fits in modernization

This applies to many types of work:

Refactoring legacy code
Monolith migration
Service extraction
API rewrites
AI code migration
Replatforming
Replacing vendor integrations
Simplifying business rules
Removing old feature flags
Consolidating duplicated logic
Reducing technical debt

In each case, the technical change is only part of the work.

The safer path is:

Map decisions
Recover intent
Classify risk
Decide migration action
Refactor or rewrite
Validate business behavior
Document what changed

That sequence is slower than blindly rewriting code.

It is faster than breaking something important and spending months rediscovering why the old system worked.

AI is useful when it makes the invisible visible

I do not think AI removes the need for senior engineering judgment.

For legacy systems, I think the opposite is true.

AI makes senior judgment more valuable by surfacing the hidden logic that deserves attention.

It can help scan a large code base.
It can identify patterns.
It can group rules.
It can summarize decision paths.
It can find inconsistencies.
It can generate questions engineers should ask before changing behavior.

But AI should not be treated as the decision maker.

It should be treated as a decision discovery tool.

That shift matters.

The goal is not simply to migrate code faster.

The goal is to understand what the code is deciding before you migrate it.

The takeaway

Before you refactor legacy code, map the decisions hidden inside it.

Some of those decisions are obsolete. Some are accidental. Some are ugly. Some should be deleted.

But some are load-bearing.

They protect behavior that is not obvious from the code alone.

The safest modernization does not start with rewriting code.

It starts with recovering intent.

The unit of transformation is not the system.

It is the decision.

This article is adapted from my Medium essay and TEDx talk on decision recovery in legacy system modernization.

Medium article: https://medium.com/@nirmal.jingar/systems-are-not-made-of-code-they-are-made-of-decisions-4b7fa2ead212
TEDx talk: https://www.youtube.com/watch?v=pxUChqiyp2Y

Building Reliable AI Decision Systems for Enterprise Supply Chains

Nirmal Jingar — Wed, 20 May 2026 21:38:46 +0000

Artificial intelligence is rapidly transforming enterprise operations, but one uncomfortable reality remains:

Most AI systems are still not trustworthy enough to directly control mission-critical infrastructure.

This becomes especially visible in supply chain operations, where small decision failures can create cascading consequences across inventory, transportation, procurement, fulfillment, and customer experience.

Modern supply chains already operate under continuous stress:

demand volatility
transportation disruptions
supplier instability
weather events
labor shortages
geopolitical risk
fluctuating costs

Traditional enterprise systems were built for predictability. Today’s operating environment is anything but predictable.

At the same time, large language models (LLMs) have introduced a new generation of reasoning capabilities that can interpret operational context far beyond what traditional planning systems can handle.

The challenge is figuring out how to safely combine:

AI reasoning
optimization systems
enterprise governance
operational reliability

The answer is not autonomous AI replacing enterprise control systems.

The answer is building reliable AI decision infrastructure.

Why Traditional Supply Chain Systems Struggle

Most enterprise supply chain platforms are built on deterministic models:

forecasting engines
inventory optimization systems
routing solvers
operations research frameworks
replenishment planners

These systems are extremely good at mathematical optimization under known conditions.

But they often fail when the environment changes rapidly because they primarily depend on:

structured datasets
static rules
historical assumptions
predefined constraints

Real-world disruptions rarely arrive in structured formats.

A transportation crisis may first appear as:

carrier emails
port congestion reports
weather alerts
social media signals
supplier communication
unstructured logistics updates

Traditional systems cannot reason about these signals effectively.

Why Pure LLM-Based Systems Are Risky

LLMs solve a different problem.

They excel at:

semantic interpretation
contextual reasoning
summarization
pattern recognition
unstructured data analysis

An LLM can quickly synthesize:

disruption reports
operational anomalies
inventory instability signals
supplier delays
regional risk indicators

But using LLMs directly for operational execution creates major enterprise risks:

hallucinated recommendations
inconsistent reasoning
non-deterministic behavior
weak auditability
governance gaps
unpredictable outcomes

This is the core enterprise AI problem:

Highly intelligent systems are not automatically reliable systems.

And reliability matters more than intelligence when real-world infrastructure is involved.

The Enterprise AI Architecture Gap

Today’s enterprise AI landscape often splits into two extremes.

Deterministic Enterprise Systems

These systems are:

reliable
auditable
governed
mathematically constrained

But they lack contextual awareness.

Generative AI Systems

These systems are:

adaptive
flexible
reasoning-capable
context-aware

But they lack deterministic guarantees.

The future of enterprise AI likely belongs to architectures that combine both.

A Better Architectural Model

A safer enterprise AI model follows a simple principle:

LLMs should contribute reasoning, while deterministic systems retain execution authority.

This distinction is critical.

Instead of allowing an LLM to directly execute operational actions like:

inventory allocation
logistics routing
procurement execution
replenishment decisions

…the LLM contributes structured operational intelligence.

For example, the AI layer may:

identify high-risk transportation regions
detect abnormal supplier instability
estimate disruption severity
recommend inventory protection strategies
prioritize operational objectives
highlight conflicting constraints

The final operational decisions are still made by constrained optimization systems such as:

mixed integer linear programming (MILP)
stochastic optimization
deterministic planning engines
operations research solvers

This creates separation between:

reasoning
optimization
execution
governance

That separation is essential for enterprise trust.

The Importance of Symbolic Grounding

One of the biggest problems in enterprise AI is converting probabilistic reasoning into operationally safe inputs.

This is where symbolic grounding becomes important.

Without grounding, LLM outputs remain:

ambiguous
non-verifiable
difficult to operationalize safely

A symbolic grounding layer translates semantic reasoning into:

measurable variables
bounded constraints
optimization parameters
auditable operational inputs

For example:

Instead of an LLM saying:

“Transportation instability appears elevated in the Southeast region.”

The grounding layer converts that into structured operational constraints such as:

increased route risk penalties
reduced carrier confidence scores
tighter inventory protection thresholds
regional fulfillment balancing adjustments

The optimization engine can then safely incorporate these constraints into deterministic planning models.

This prevents unconstrained language generation from directly controlling enterprise infrastructure.

Safety Must Be Infrastructure, Not an Afterthought

Most AI discussions focus heavily on intelligence.

Far fewer focus on operational safety.

That is a mistake.

Enterprise systems require:

bounded risk
predictable execution
explainability
governance enforcement
compliance validation
measurable guarantees

A reliable AI architecture should include safety-constrained execution layers that evaluate candidate actions before execution.

These layers may validate:

service-level compliance
transportation capacity limits
inventory protection policies
operational risk thresholds
financial exposure constraints
regulatory requirements

Unsafe actions are rejected before they reach production execution systems.

This shifts safety from:

reactive governance

to:

embedded infrastructure governance

That difference matters enormously in enterprise environments.

A Real-World Operational Scenario

Consider a large retail supply chain during peak seasonal demand.

Suddenly:

severe weather disrupts major transportation corridors
ports become congested
carrier reliability drops
inbound inventory delays increase
demand volatility spikes simultaneously

Traditional systems often struggle because disruption signals arrive too quickly and across too many disconnected channels.

An AI-assisted decision architecture could continuously ingest:

weather alerts
carrier updates
supplier lead-time changes
inventory telemetry
regional transportation data
operational incident reports

The reasoning layer may identify:

high-risk transportation zones
unstable routing regions
increasing stockout probability
fulfillment imbalance risks
service-level exposure

These insights are then translated into constrained optimization inputs.

The optimization layer recalculates:

inventory allocation
replenishment quantities
fulfillment balancing
carrier prioritization
routing strategies

Meanwhile, safety systems validate every candidate action against operational policies before execution.

This creates a system where:

AI improves contextual awareness
optimization preserves deterministic control
governance systems enforce reliability
human operators retain accountability

The goal is not autonomous enterprise infrastructure.

The goal is resilient and governable operational intelligence.

The Future of Enterprise AI Is Reliability

Enterprise AI adoption is increasingly becoming less about model capability and more about infrastructure trust.

Organizations are starting to realize that successful production AI requires:

deterministic safeguards
constrained execution
governance-aware orchestration
explainability boundaries
operational validation
reliability guarantees

The most valuable enterprise AI systems will not necessarily be the most autonomous systems.

They will be the systems enterprises can trust.

Final Thoughts

AI reasoning capabilities are advancing rapidly.

But enterprise-scale operational systems require more than intelligence alone.

They require:

reliability
governance
safety
deterministic control
operational accountability
measurable guarantees

The next generation of enterprise AI systems will likely combine:

probabilistic reasoning
deterministic optimization
safety-aware validation
governance-constrained execution

That combination may ultimately define the future of production-grade enterprise AI infrastructure.

Because in critical enterprise environments, reliability is not optional.

It is the product.

Citation

Nirmal K. Jingar (2026)

Reliable LLM-Powered Decision Engines for Large-Scale Supply Chain Operations: Architecture, Safety, and Performance Guarantees

IEEE IC_ASET 2026

https://doi.org/10.1109/IC_ASET69920.2026.11502212