Skip to content
nikhil.

~/work/sail-forward-deployed

SAIL: forward-deployed across three steel plants to a ₹1.27 Cr deal

Liquidmind sold AI products, but a steel PSU does not buy a product, it buys a solved problem. I went to Durgapur Steel Plant, IISCO Steel Plant Burnpur and Rourkela Steel Plant, gathered requirements and pain points, built PoCs on their own documents and workflows, pitched them, studied the problems on the shop floor, then wrote the proposal and the RFP response that closed a ₹1.27 Cr contract.

client
Steel Authority of India Ltd. (via Liquidmind.ai)
year
2026
duration
Sep – Oct 2026
role
Forward-deployed engineer · AI/ML Engineering Consultant
Amazon BedrockClaudeTextractRAGpgvectorComputer visionECS FargatePython
Live

₹1.27 Cr

contract value

3

integrated steel plants

documents · knowledge · vision

use-case tracks

Sep – Oct 2026

discovery → signed

Challenge

Steel Authority of India Limited (SAIL) is a Maharatna PSU and India's largest state-owned steel maker. Three of its integrated plants run in the eastern steel belt:

  • Durgapur Steel Plant (DSP), West Bengal.
  • IISCO Steel Plant (ISP), Burnpur, West Bengal.
  • Rourkela Steel Plant (RSP), Odisha.

Each plant is a city-sized operation with its own departments, legacy systems, procurement cells and decades of paper.

Liquidmind's products (TradeGuard, Patram AI, TariffIQ, Smart Export) were built for trade and compliance teams. That was a starting point, not an answer. Nobody at a steel plant buys "an AI document assistant". They buy fewer delays in a procurement cycle, faster answers from a thick manual, or one less unsafe moment on the shop floor. The job was to find those problems, prove we could solve them on the plant's own data, and turn that proof into a contract that would survive public-sector procurement.

That is forward-deployed engineering: an engineer, not a salesperson, sits with the customer, learns the domain, builds the first version in front of them and carries it through to a signed deal.

Approach

1. Discovery: requirements and pain points, plant by plant

I started with conversations with the departments that would own the outcome, separately at each plant, because the three plants are not the same customer. Their volumes, legacy systems and priorities differ. For every pain point I wrote down:

  • Who feels it, and who would sign off on fixing it.
  • What it costs today, in hours, delays or risk, in their own words.
  • Where the data lives: scanned files, ERP exports, email, manuals, CCTV.
  • What "done" would look like to them, not to us.

The pain points fell into three tracks, each mapping onto something Liquidmind could actually build on its existing platform:

TrackWhat the plants describedWhat we could build on
DocumentsProcurement, vendor and import paperwork checked by hand, field by fieldTradeGuard-style extraction with per-field confidence and rule-based cross-checks
KnowledgeSOPs, manuals, circulars and contracts nobody can searchPatram-style retrieval with page-level citations
VisionShop-floor monitoring that depends on someone watching a screenVision models on Bedrock and camera feeds

2. PoCs on their data, not ours

A demo on sample invoices proves nothing to a plant engineer. Each PoC ran on representative documents and scenarios from the plant itself, and was scoped so it could be shown in one sitting:

  • Documents PoC: their own paperwork, extracted into structured fields with confidence scores, and every mismatch shown next to the source page.
  • Knowledge PoC: questions their staff actually ask, answered with the paragraph and page the answer came from. In a PSU, an answer without a citation is an opinion.
  • Vision PoC: a scoped demonstration of what a model can flag from the kind of footage the plant already records.

I pitched each PoC to the stakeholders who would use it, then to the people who would approve the spend.

3. Site visits: study the problem where it happens

The PoCs earned access to the plants themselves. On site at Durgapur, Burnpur and Rourkela I watched the work happen: where documents are handled, how manuals are actually consulted, where cameras already are and where they are not.

Most of what changed the proposal came from these visits:

  • Constraints never mentioned in meetings: network reach on the shop floor, who may install what, and how data is allowed to leave the plant.
  • Workflow realities: the step where a "simple" check involves three people and a register.
  • Scope: which problems were worth solving first, and which would be scope creep in disguise.

4. Proposal and RFP response

PSU procurement runs on formal RFPs, so the proposal had to be written for evaluators as well as champions. I wrote the technical proposal and the RFP response. The response covered:

  • Problem statements in the plant's own terms, one per use case, each tied to an outcome the department had named.
  • Solution architecture on Liquidmind's AWS platform: managed AI models on Amazon Bedrock with an in-region inference option, documents and data kept in India, role-based access, and audit trails.
  • A compliance matrix answering every RFP clause point by point, so an evaluator never has to hunt for an answer.
  • A phased rollout plan: start where the PoC already proved value, expand plant by plant, with acceptance criteria for each phase.
  • Commercials built around that phasing.

5. Closure

The RFP process ended with the award: a ₹1.27 Cr contract for Liquidmind.

What shipped

  • Requirements and pain-point maps for three integrated steel plants, organised into document, knowledge and vision tracks.
  • Working PoCs on plant data, pitched to users and approvers.
  • On-site studies at DSP, ISP Burnpur and RSP.
  • The technical proposal and the RFP response.
  • A closed ₹1.27 Cr deal.

Results

The engagement went from first conversation to signed contract. More importantly, the delivery scope is made of problems the plants named and a rollout plan they helped shape, which makes the project much easier to deliver than one sold from a slide deck.

I wrote up the craft of this, what forward-deployed engineering looks like with a PSU, in the FDE write-up.

What I'd do differently

Bring a measurable baseline from the first site visit: minutes per document, searches per answer, incidents per shift. The PoCs convinced people. A before-and-after number on every slide would have shortened every approval conversation after that.

Share

More case studies

Related writing

// need something similar?

Let's talk about your system.

A 15-minute call is enough to tell you whether I can help and roughly what it takes.