DEV Community: Nirmal Jingar

Post-Quantum Migration in Legacy Microservices: A Policy-Governed, Sidecar-First Approach

Nirmal Jingar — Sun, 09 Aug 2026 20:41:06 +0000

Most post-quantum cryptography discussions begin with algorithms.

Which algorithm should replace RSA? How should teams adopt lattice-based cryptography? Should an organization start with hybrid cryptography or move directly to post-quantum algorithms?

These are important questions, but they are not the only questions engineering teams need to answer.

For organizations operating large microservice environments, the harder problem may be operational:

How do you change the cryptography without rewriting, redeploying, and retesting every legacy service at the same time?

In many enterprise systems, cryptographic behavior is tightly coupled to application libraries, certificates, authentication flows, service communication, and deployment pipelines.

Replacing a cryptographic primitive may require dependency changes, recompilation, coordinated releases, and system-wide testing.

That turns a security migration into an application modernization program.

The Policy-Governed Post-Quantum Migration using Ephemeral Sidecar Architectures framework, or PG-PQMES, proposes a different model.

It moves eligible cryptographic operations outside legacy application code and into temporary sidecars controlled by policy, runtime monitoring, and rollback rules.

The goal is not to remove application teams from the migration. The goal is to avoid forcing application changes where the cryptographic responsibility can be managed safely at the communication boundary.

Why Direct Cryptographic Replacement Is Risky

A legacy microservice rarely operates in isolation.

It communicates with internal APIs, data stores, message brokers, identity systems, third-party services, and other microservices.

Each dependency may use a different cryptographic library, certificate format, protocol version, or key-management process.

A direct PQC migration can introduce several kinds of risk:

The new library may not be compatible with an older runtime
Larger keys or signatures may affect protocol limits
Additional computation may increase latency
Services may need to be migrated in a specific order
Rollback may require another application release
One service may support a hybrid protocol while another does not
An implementation problem may affect several downstream dependencies

The research identifies this coupling as one of the primary barriers to post-quantum migration.

Replacing classical cryptography inside legacy services can require recompilation, dependency restructuring, and broad testing. Traditional migration approaches may also lack runtime flexibility, which can introduce downtime or conflict with continuous deployment practices.

The problem is not only selecting stronger cryptography.

The problem is changing cryptography while preserving availability, compatibility, and operational control.

What a Sidecar-First Migration Means

A sidecar is a component deployed alongside an application instance.

It can intercept or manage cross-cutting behavior without requiring that behavior to be implemented directly in the application.

Service meshes already use sidecars for routing, mutual TLS, telemetry, retries, and policy enforcement.

PG-PQMES applies the same architectural pattern to cryptographic migration.

A simplified communication path looks like this:

Legacy Service A
      |
      v
Ephemeral Crypto Sidecar
      |
      | Classical, hybrid, or PQC communication
      |
      v
Ephemeral Crypto Sidecar
      |
      v
Legacy Service B

The application continues to execute its business logic. The sidecar handles eligible cryptographic operations at the service communication boundary.

The word ephemeral matters.

The sidecar is not assumed to be a permanent part of the application architecture. It is introduced for a controlled migration, governed by policy, observed at runtime, and terminated when its purpose is complete or when the migration becomes unsafe.

This is different from adding another permanent infrastructure dependency.

An ephemeral sidecar has a migration purpose, a permitted lifetime, and an exit condition.

The Three Layers of PG-PQMES

The proposed architecture is organized into three layers.

1. Ephemeral Crypto Sidecar Layer

The sidecar layer introduces temporary cryptographic components around eligible service connections.

In the proposed architecture, this layer includes a cryptographic proxy, a PQC engine, and key-management capabilities.

The proxy mediates communication. The PQC engine performs the required cryptographic operations. The key manager supports key exchange and lifecycle management.

The legacy service does not need to implement every part of the transition directly.

This layer can support three migration states:

Classical cryptography
Hybrid classical and post-quantum cryptography
Post-quantum cryptography

A service connection does not need to move directly from classical cryptography to a complete PQC configuration.

It can first operate in hybrid mode while teams validate compatibility and performance.

2. Policy Governance Layer

The policy layer determines whether a service connection is eligible for migration and which cryptographic configuration it may use.

Policies can represent:

Security requirements
Performance limits
Compatibility constraints
Compliance obligations
Trust thresholds
Approved cryptographic modes
Sidecar lifetime limits
Rollback conditions

This is more than configuration management.

A policy document tells engineers what should happen.

A runtime policy engine determines what the platform will allow to happen.

3. Migration Safety and Observability Layer

The observability layer measures the effects of the migration after a sidecar is deployed.

The proposed architecture includes performance monitoring, event logging, trust evaluation, and a rollback controller.

If the migration violates an approved threshold, the framework can terminate the temporary sidecar and restore the previous cryptographic state.

These three layers create a migration control plane.

The control plane decides where migration is allowed, applies the cryptographic change, observes the result, and reverses the change when necessary.

The Service Connection Becomes the Migration Unit

A common migration plan treats the service as the unit of change.

For example:

Migrate Service A
Migrate Service B
Migrate Service C

That model can become too broad in a distributed environment.

A service may communicate with several dependencies, and those connections may have different characteristics.

One connection may support hybrid cryptography. Another may have strict latency requirements. A third may depend on a legacy protocol that cannot yet support the new configuration.

PG-PQMES models the environment as a service interaction graph:

G = (M, E)

M represents the set of microservices.

E represents secure communication paths between those services.

Migration eligibility is evaluated for each communication edge rather than assumed for the entire service.

That allows a service to participate in different cryptographic modes across different connections.

Service A -> Service B: Hybrid mode
Service A -> Service C: Classical mode
Service A -> Service D: PQC enabled

This makes the migration more precise.

Instead of asking whether an entire application is ready, teams can ask whether one specific communication path is ready.

How the PG-EPM Algorithm Works

The research introduces a Policy-Governed Ephemeral PQ Migration algorithm, or PG-EPM.

The algorithm converts cryptographic migration into a sequence of runtime decisions.

Step 1: Map Service Dependencies

The process begins by creating a service interaction graph.

Each node represents a legacy microservice. Each edge represents a secure communication path.

This step is critical because a cryptographic inventory alone does not show how systems depend on each other.

An organization needs both:

Cryptographic inventory
Service communication map

The first identifies algorithms and libraries.

The second identifies where a change may affect another system.

Step 2: Interpret Migration Policies

The framework evaluates governance rules for security, performance, and compatibility.

A path may be ineligible because one endpoint does not support the required protocol.

It may also be ineligible because the expected latency increase would exceed an approved threshold.

Step 3: Calculate Sidecar Eligibility

For every communication edge, the framework determines whether the path satisfies the required policy.

Conceptually:

eligible = securityPolicyPassed
        && performancePolicyPassed
        && compatibilityPolicyPassed

If the path is not eligible, the framework leaves it in its existing state.

Step 4: Deploy an Ephemeral Sidecar

When a path is eligible, the framework deploys a temporary sidecar to handle cryptographic operations.

The sidecar does not automatically force the strongest available configuration.

It selects an option that balances security strength and performance overhead.

Step 5: Negotiate the Cryptographic Mode

The framework considers classical, hybrid, and post-quantum options.

The proposed model treats the selection as a trade-off between security strength and operational overhead.

This is an important design choice.

The strongest theoretical option is not always the safest operational option for the first stage of a migration.

A hybrid configuration may provide a more practical transition path while compatibility and performance are still being validated.

Step 6: Monitor Runtime Performance

After the sidecar is deployed, the framework measures latency overhead relative to the baseline.

That baseline must be captured before migration.

Without a baseline, a team cannot reliably determine whether the new cryptographic configuration has affected service behavior.

Step 7: Verify Policy Compliance

The system verifies that runtime behavior remains within the approved policy.

For example, the configuration must use an approved cryptographic mode and remain below the maximum permitted latency threshold.

Step 8: Evaluate Runtime Trust

The research defines a trust score based on performance health, security health, and audit evidence.

A production implementation would need to define these inputs carefully.

Trust should not become an unexplained score that hides operational decisions.

A useful trust model should answer:

Which metrics contribute to the score?
How are the metrics weighted?
How often is the score calculated?
Which threshold triggers intervention?
Can an operator explain why a score changed?

Step 9: Trigger Rollback

If latency exceeds the approved threshold or the trust score falls below the minimum requirement, the sidecar is terminated and the communication path returns to the previous state.

Rollback is therefore not an emergency procedure added after implementation.

It is part of the migration architecture.

Step 10: Refine Policies

The algorithm also proposes learning-based policy refinement using observed migration outcomes.

A real system would need strict controls before automatically changing security policy based on runtime observations.

A Developer-Friendly View of the Algorithm

The following pseudocode translates the proposed flow into an implementation-oriented form.

It is illustrative and is not source code from the research paper.

for connection in service_graph.connections:

    policy = policy_engine.evaluate(connection)

    if not policy.eligible:
        continue

    baseline = metrics_store.get_baseline(connection)

    sidecar = sidecar_controller.deploy(
        connection=connection,
        allowed_modes=policy.allowed_crypto_modes
    )

    selected_mode = crypto_negotiator.select_mode(
        allowed_modes=policy.allowed_crypto_modes,
        security_requirement=policy.security_requirement,
        performance_budget=policy.performance_budget
    )

    sidecar.activate(selected_mode)

    while sidecar.is_active():

        metrics = observer.collect(connection)

        latency_overhead = calculate_latency_overhead(
            baseline=baseline,
            current=metrics
        )

        trust_score = trust_engine.evaluate(
            performance=metrics.performance,
            security=metrics.security,
            audit_events=metrics.audit_events
        )

        compliant = policy_engine.verify_runtime_state(
            connection=connection,
            selected_mode=selected_mode,
            metrics=metrics
        )

        if latency_overhead > policy.max_latency_overhead:
            sidecar_controller.terminate(sidecar)
            connection_controller.restore_previous_state(connection)
            break

        if trust_score < policy.minimum_trust_score:
            sidecar_controller.terminate(sidecar)
            connection_controller.restore_previous_state(connection)
            break

        if not compliant:
            sidecar_controller.terminate(sidecar)
            connection_controller.restore_previous_state(connection)
            break

The code is not the difficult part.

The difficult part is defining the policy, baseline, observability, and rollback behavior well enough that the system can make a safe decision.

An Illustrative Migration Policy

A platform team could represent migration requirements through a custom resource, policy document, or control-plane API.

The following YAML is an illustrative example. It is not a schema from the research paper.

apiVersion: security.example.io/v1alpha1
kind: PQCMigrationPolicy

metadata:
  name: checkout-to-payments

spec:
  sourceService: checkout
  destinationService: payments

  allowedModes:
    - classical
    - hybrid
    - pqc

  preferredInitialMode: hybrid

  performance:
    maxLatencyOverheadMs: 12
    maxErrorRatePercent: 0.5

  trust:
    minimumScore: 90

  rollback:
    enabled: true
    onLatencyBreach: true
    onErrorRateBreach: true
    onTrustViolation: true
    onPolicyViolation: true

  sidecar:
    ephemeral: true
    maximumLifetimeMinutes: 60

The specific values would depend on the service.

A payment path may require stricter rollback rules than a low-priority batch workflow.

A latency-sensitive API may have a smaller performance budget than an asynchronous event processor.

The policy should reflect the actual operational context.

Rollback Must Be Tested Before Migration

Many systems claim to support rollback because a previous configuration still exists.

That is not enough.

A rollback mechanism should be tested under realistic failure conditions.

Examples include:

PQC handshake failure
Certificate or key mismatch
Sidecar crash
Control-plane unavailability
Unexpected latency increase
Packet-size incompatibility
Partial migration between two endpoints
Invalid policy distribution
Telemetry loss
Trust evaluation failure

A safe rollback path should answer several questions.

How quickly can the previous cryptographic state be restored?

Does rollback require an application deployment?

What happens to in-flight requests?

Can the system restore the previous connection without dropping traffic?

What happens if the rollback controller itself is unavailable?

How is the event recorded for audit and investigation?

If those questions are unanswered, rollback is still an assumption rather than a capability.

What the Simulation Reported

The framework was evaluated in a simulated cloud-native environment containing 50 legacy services with dynamic communication patterns.

PG-PQMES was compared with two approaches identified in the paper as CMF and IS-PMCF.

The experiment measured service downtime, communication latency overhead, rollback recovery time, policy behavior, and trust stability.

Metric	CMF	IS-PMCF	PG-PQMES
Average service downtime	45 minutes	32 minutes	5 minutes
Communication latency overhead	18 ms	15 ms	11 ms
Rollback recovery time	120 seconds	95 seconds	18 seconds
Trust stability score	82	87	96

The research attributes the lower simulated downtime and rollback time to temporary sidecar deployment, centralized policy control, and the ability to terminate ephemeral components when thresholds are breached.

The trust stability score was also higher for PG-PQMES within the simulation.

That result should be treated carefully because the value depends on how trust inputs and weights are defined.

These are simulation results.

They are not production guarantees, and they should not be presented as universal performance expectations.

The useful conclusion is narrower:

A migration architecture designed around selective deployment, runtime policy, observability, and fast rollback can have a different operational risk profile from a broad application replacement strategy.

Production validation would still be required across real service meshes, key-management systems, protocols, traffic profiles, and failure scenarios.

What Should Remain Inside the Application?

A sidecar-first approach is not appropriate for every cryptographic responsibility.

Some concerns may still require direct application changes, including:

Application-level document signing
Domain-specific authentication logic
Business rules tied to cryptographic identity
Encryption of stored application data
Hardware-backed signing operations
Protocol-specific payload construction
Client-facing formats that cannot be intercepted safely
End-to-end encryption where intermediaries must not access plaintext

The goal is not to move every security responsibility into infrastructure.

The goal is to identify which responsibilities are cross-cutting and can be managed safely outside business logic.

For service-to-service transport security, a sidecar or service-mesh extension may be appropriate.

For application-level signatures, the application may still need direct control.

A successful architecture needs a clear boundary between the two.

A Practical Adoption Sequence

An organization should not begin by enabling PQC sidecars across its entire service estate.

A safer adoption sequence would begin with dependency discovery.

First, map the service communication graph. Identify protocols, certificates, cryptographic libraries, ownership boundaries, and critical paths.

Next, select one low-risk connection with measurable traffic and a clear rollback path.

Capture baseline latency, error rates, throughput, CPU usage, memory consumption, and availability before introducing any cryptographic changes.

Define an explicit migration policy. The policy should include the allowed cryptographic modes, the performance budget, the trust requirements, and the exact rollback conditions.

Introduce a temporary sidecar in hybrid mode.

Observe the connection under representative load.

Trigger rollback deliberately to verify that the previous state can be restored.

Only after the full control loop has been validated should the organization consider expanding the migration to additional connections.

The first milestone is not quantum readiness.

The first milestone is proving that the organization can introduce, measure, and reverse a cryptographic change safely.

Production Concerns Beyond the Proposed Model

A production implementation would need to address several concerns in greater detail.

The policy control plane becomes a high-value security component. It must be authenticated, authorized, audited, and protected against unauthorized policy changes.

The sidecar supply chain must also be secured. Images should be signed, scanned, pinned to approved versions, and deployed through controlled pipelines.

Key management requires careful design. The proposed architecture includes key-management capability, but production teams still need to define where keys are generated, stored, rotated, revoked, and audited.

Observability must not expose sensitive material. Metrics and logs should provide enough information for diagnosis without recording keys, plaintext, or sensitive cryptographic artifacts.

Performance must be tested using representative payload sizes and traffic patterns.

A benchmark using small requests may not reveal issues that appear with large signatures, high concurrency, or CPU-constrained workloads.

The research also identifies hardware-assisted PQC acceleration, automated hybrid negotiation, and policy sharing across multi-cloud infrastructure as future directions.

Ownership Will Matter as Much as Technology

A migration control plane also raises an organizational question.

Who owns it?

In practice, the responsibility would likely be shared.

Security teams should define approved cryptographic policies and compliance requirements.

Platform teams should build the enforcement, observability, and rollback capabilities.

Application teams should identify protocol assumptions and validate that business behavior remains correct.

This model avoids two common extremes.

It avoids placing the entire migration burden on individual application teams.

It also avoids a central platform team changing cryptographic behavior without understanding application requirements.

The control plane provides a shared boundary where those responsibilities can meet.

Final Takeaway

Post-quantum migration is not only an algorithm replacement problem.

For legacy microservices, it is also a dependency-management, platform-engineering, governance, observability, and rollback problem.

PG-PQMES proposes a useful architectural direction:

Externalize eligible cryptographic operations through ephemeral sidecars
Evaluate migration eligibility through centralized policy
Support classical, hybrid, and PQC modes
Monitor performance and trust at runtime
Treat rollback as part of the architecture
Migrate service connections incrementally

The framework does not remove every application change.

It does not eliminate the need for cryptographic inventories, key-management planning, compatibility testing, or production benchmarking.

It does offer a way to reduce the blast radius of the transition.

The core principle is practical:

Cryptographic migration does not need to be an all-or-nothing application upgrade. It can be a controlled runtime process that is policy-governed, observable, and reversible.

For developers and platform teams, the next question is not only which PQC algorithm to adopt.

It is also where the migration logic should live.

Would you implement PQC migration in application libraries, a service-mesh extension, or ephemeral sidecars?

Research Basis

This article is based on the research paper:

Policy-Governed Post-Quantum Migration for Legacy Microservices Using Ephemeral Sidecar Architectures

The reported performance values come from a simulated environment containing 50 legacy services. They should be treated as experimental findings, not production benchmarks.

N. K. Jingar, "Policy-Governed Post-Quantum Migration for Legacy Microservices Using Ephemeral Sidecar Architectures," 2026 International Conference on Computational Modelling, Simulation and Optimization (ICCMSO), Singapore, Singapore, Singapore, 2026, pp. 237-242, doi: 10.23919/ICCMSOCPS00092.2026.00051. keywords: {Cryptography;Security;Modeling;Architecture;Computer architecture;Algorithms;Timing;Quantum cryptography;post-quantum cryptography (pqc);microservices security;ephemeral sidecar architecture;cryptographic migration;policy-governed security;hybrid cryptography;cloudnative security;quantum-resilient systems;trust evaluation;secure service communication},

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