Skip to content
TashIT

Solution blueprints, ready to pilot

Every item on this page is labelled for exactly what it is. Today that means solution blueprints: reference architectures and pilot designs for operational problems common across industries, each ready to test in a paid proof of concept.

View the blueprintsDiscuss a pilot

Solution blueprints

AI and engineering blueprints you can pilot

Each blueprint sets out a problem that recurs across its sector, how we would solve it on top of the systems you already run, and how a paid proof of concept would be scoped and judged. None of them is presented as a delivered client project.

How we label our work

A hard line between a design, a working prototype and work delivered for a client.

  • Solution blueprintOn this page: 6 below

    A reference architecture and pilot design for a specific operational problem. A design, not a delivered project.

  • DemonstratorOn this page: None yet

    A working prototype built by TashIT on sample or synthetic data to prove a technique. Never presented as a client deployment.

  • Client case studyOn this page: None yet

    Work delivered for a client, with results measured against an agreed baseline. Published only with the client's written permission.

Solution blueprintBlueprint 01

Weighbridge integrity and compliance reconciliation

Camera and number-plate verification at the weighbridge, with every weighing event matched to ERP, payment and tax-stamp records so leakage and compliance gaps show up the same day.

See the Gate, Weighbridge & Compliance Vision solution
Typical fit
Sugar, cement, fertiliser, grain and other bulk-material plants with busy gates and weighbridges.
Status
Reference architecture and pilot plan, available for a paid proof of concept

The problem

At a busy weighbridge, vehicle numbers and weights are often keyed in by hand and checked weeks later, if at all. A vehicle can be weighed twice, an old tare weight reused, or a load recorded against the wrong order. Dispatch counts drift away from ERP and track-and-trace records. Finance finds the gap at month end. Sometimes the regulator finds it first.

Approach

5 steps
  1. Capture each weighing event with number-plate recognition (ANPR) and overview cameras, linking plate, time, gross and tare weight in one event record.
  2. Read the weighbridge indicator directly over its serial or network interface, so weights are captured at source instead of typed in.
  3. Reconcile every event with ERP gate passes, purchase and sales orders, payments and tax-stamp or dispatch counters, close to real time.
  4. Flag exceptions with photo evidence: repeated tare, plate mismatch, out-of-pattern loads and counts that do not match dispatch.
  5. Give plant, finance and compliance teams one exception queue and a daily reconciliation report, with an audit trail for every decision.

Pilot design

10–12 weeks
Duration
10–12 weeks
Scope
One gate and one weighbridge for one material flow, reconciled live with ERP and dispatch records.

Judged on

  • Share of weighing events captured automatically with photo evidence
  • Exceptions detected and confirmed by the plant team
  • Time to close the daily reconciliation, against today's baseline

Typical stack

7 components
  • ANPR and IP cameras
  • Edge inference on an industrial PC or GPU module
  • Weighbridge indicator integration (RS-232, Modbus TCP)
  • Python services and REST APIs
  • PostgreSQL
  • ERP connectors (SAP, Oracle, Microsoft Dynamics)
  • Web dashboard and exception queue

Back to all blueprints

Solution blueprintBlueprint 02

Captive power dispatch optimiser

A forecast-based dispatch advisor that schedules grid supply, captive generation, solar and battery storage to meet plant load at the lowest cost per unit.

See the Energy Monitoring & Dispatch Optimisation solution
Typical fit
Textile, cement, steel, food and chemical plants running captive generation alongside grid supply and solar.
Status
Reference architecture and pilot plan, available for a paid proof of concept

The problem

Many plants now run a mixed energy fleet: grid supply on time-of-use tariffs, captive gas or oil gensets, rooftop solar and, more and more, batteries. Dispatch is decided by shift engineers from experience and spreadsheets. Without sub-metering and a cost model for each source, nobody can say what a unit of energy really cost yesterday, or what the cheapest mix will be tomorrow.

Approach

5 steps
  1. Install or connect sub-meters on incomers, gensets, solar inverters, batteries and major loads, and bring the readings into one time-series store.
  2. Build a cost model for each source: tariff bands, fuel price and heat rate per genset, solar yield, battery cycling cost and demand charges.
  3. Forecast plant load and solar output hour by hour from production plans, weather and history.
  4. Optimise next-day and next-hour dispatch for cost, within limits for spinning reserve, minimum genset loading and critical loads.
  5. Show recommendations to the control room as advice first. Move to closed-loop control only once the plant team trusts the numbers.

Pilot design

10–12 weeks
Duration
10–12 weeks
Scope
One site or energy complex: sub-metering of the main sources, a cost model and advisory dispatch run alongside current practice.

Judged on

  • Energy cost per unit of output, against an agreed baseline period
  • Forecast accuracy for plant load and solar output
  • Share of dispatch recommendations accepted by operators

Typical stack

6 components
  • Energy meters and gateways (Modbus RTU and TCP)
  • MQTT and OPC UA
  • Time-series database (TimescaleDB or InfluxDB)
  • Python forecasting models
  • Linear and mixed-integer optimisation (OR-Tools, HiGHS)
  • Control-room dashboard

Back to all blueprints

Solution blueprintBlueprint 03

Feeder-level loss analytics

An energy-balance model that compares energy sent to each feeder and transformer with energy billed, then ranks loss hotspots so field teams go where recovery is most likely.

See the Utility Loss & Revenue Assurance solution
Typical fit
Electricity distribution companies. The same method applies to gas and water networks.
Status
Reference architecture and pilot plan, available for a paid proof of concept

The problem

Distribution utilities know their total losses but rarely know exactly where they sit. Technical and commercial losses are mixed together, meter data has gaps, and inspection teams are sent out on instinct or complaints. Every unit lost has already been paid for at the generation end.

Approach

5 steps
  1. Join feeder and transformer meter readings, billing records, customer-to-asset mappings and GIS data into one consistent energy balance.
  2. Clean and repair the customer-to-transformer mapping, which is usually the largest single source of error.
  3. Estimate technical loss from network data, so the remaining commercial loss can be located and targeted.
  4. Score customers and areas for anomaly patterns: sudden consumption drops, flat readings, tamper events and deviation from similar customers.
  5. Send a ranked inspection list to field teams, record what they find, and use those outcomes to retrain the scoring each cycle.

Pilot design

12 weeks
Duration
12 weeks
Scope
10-20 high-loss feeders, with inspection results compared against current targeting.

Judged on

  • Inspection hit rate from the ranked list, compared with current practice
  • Energy recovered or reassessed per inspection
  • Coverage and accuracy of the customer-to-transformer mapping

Typical stack

7 components
  • Feeder and smart-meter data (MDM exports)
  • Billing system extracts
  • GIS integration
  • Python and SQL data pipelines
  • Anomaly detection and gradient-boosted models
  • PostgreSQL with PostGIS
  • Mobile app for recording inspection outcomes

Back to all blueprints

Solution blueprintBlueprint 04

Store-level demand forecasting and auto-replenishment

SKU-by-store forecasts that become suggested orders and transfers every day, so fast movers stay on the shelf while slow and short-dated stock stops building up.

See the Demand Forecasting & Inventory Optimisation solution
Typical fit
Grocery and convenience chains, pharmacies, fashion retailers and distributors.
Status
Reference architecture and pilot plan, available for a paid proof of concept

The problem

Store managers order from memory and last week's sales. Fast movers run out at weekends and during promotions, while slow movers and short shelf-life lines pile up in the back room. Head office sees stock-outs in one report and write-offs in another, with working capital tied up in between.

Approach

5 steps
  1. Bring together POS sales, stock on hand, open orders, supplier lead times and the promotions calendar for each SKU and store.
  2. Forecast daily demand per SKU and store, allowing for seasonality, public holidays, Ramadan and Eid patterns, promotions and price changes.
  3. Calculate order quantities from the forecast, safety stock, pack sizes, shelf capacity and supplier minimums.
  4. Send suggested orders and inter-store transfers to buyers and store managers for review, with a clear reason for each suggestion.
  5. Track forecast accuracy, availability and waste every week, and tune the replenishment policy by category.

Pilot design

10–12 weeks
Duration
10–12 weeks
Scope
One category across a cluster of 3-20 pilot stores, compared with similar control stores.

Judged on

  • Forecast accuracy against the current ordering method
  • On-shelf availability for pilot SKUs
  • Days of inventory, waste and markdowns

Typical stack

6 components
  • POS and ERP integration (for example SAP Business One, Microsoft Dynamics, Odoo)
  • Data warehouse or PostgreSQL
  • Python forecasting (gradient boosting with statistical baselines)
  • Replenishment rules engine
  • Scheduled data pipelines
  • Buyer and store dashboards

Back to all blueprints

Solution blueprintBlueprint 05

Surface defect detection on a coating line

Line-scan cameras and a trained defect model that inspect every metre of coated or galvanised strip, grade each coil and link defects back to line conditions.

See the Machine Vision Quality Inspection solution
Typical fit
Steel coating and galvanising lines. Adaptable to film, paper, textile and other continuous web processes.
Status
Reference architecture and pilot plan, available for a paid proof of concept

The problem

On a coating or galvanising line, the strip moves too fast for consistent manual inspection. Pinholes, coating runs, scratches and roll marks are found late, often by the customer. Each claim costs margin and credibility with demanding buyers, and the plant has little data to show which process conditions caused the defect.

Approach

5 steps
  1. Specify cameras, optics and lighting for the line speed, strip width and surface finish, and mount them at the right inspection points.
  2. Collect and label defect images with the quality team to build a defect catalogue and training set.
  3. Train and validate a detection and classification model, tuned to balance detection rate against false alarms.
  4. Run the model at the edge, alerting operators and mapping each defect to coil, position and time.
  5. Link defects to process data such as line speed, bath temperature and coating weight, to support root-cause analysis and coil grading.

Pilot design

12–16 weeks
Duration
12–16 weeks
Scope
One inspection station on one coating line, run in shadow mode beside manual inspection.

Judged on

  • Detection rate by defect class, against manual inspection
  • False alarms per thousand metres of strip
  • Time from defect to operator alert

Typical stack

6 components
  • Line-scan or area-scan industrial cameras
  • Engineered LED lighting
  • Edge GPU inference
  • PyTorch model training
  • OPC UA or PLC tags for process data
  • Defect database and coil map viewer

Back to all blueprints

Solution blueprintBlueprint 06

Claims and remittance document AI

Document AI that reads claims, payer remittances and supporting papers, checks them against contract rules and matches payments to invoices, so people review only the exceptions.

See the Intelligent Document Processing solution
Typical fit
Hospitals, laboratories, insurers and claims administrators. The same pattern fits supplier invoices.
Status
Reference architecture and pilot plan, available for a paid proof of concept

The problem

Hospitals, laboratories and insurers handle thousands of claims and remittance advices every month, as PDFs, scans and spreadsheets in each payer's own format. Staff key them in, match payments to invoices by hand and discover denials weeks later. The result is slow cash, avoidable write-offs and skilled people stuck on data entry.

Approach

5 steps
  1. Collect documents from email, portals and scanners, and classify them by document type and payer.
  2. Extract fields with OCR and layout-aware models, and validate each field against payer rules and master data.
  3. Check claims before submission against contract rules, eligibility and required documents, to prevent avoidable denials.
  4. Match remittance lines to invoices, post reconciled payments, and route short payments and denials to work queues with the reason attached.
  5. Send low-confidence items to human review, and use each correction to improve extraction over time.

Pilot design

12 weeks
Duration
12 weeks
Scope
Two document streams, claims and payer remittances, for the top three to five payers by volume.

Judged on

  • Straight-through processing rate
  • Field-level extraction accuracy
  • Denial rate and days to cash, against baseline

Typical stack

6 components
  • OCR and layout-aware document models
  • Large language models, deployed privately where data must stay in-country
  • Rules engine for payer contracts
  • Python services and REST APIs
  • Hospital, ERP and accounting integration (HL7 and FHIR where available)
  • Review and work-queue interface

Back to all blueprints

From blueprint to pilot

How a blueprint becomes a measured result

A blueprint is a starting point, not a finished design. Your process, data and constraints shape the final version, and a paid pilot proves whether it pays back before you commit further.

  1. Working session

    Step 1: Blueprint walkthrough

    We take your team through the closest blueprint and adapt it to your process, your systems and your constraints.

  2. Typically 1–3 weeks

    Step 2: Diagnostic

    A short paid diagnostic. We review sample data, system access and, for plant work, the physical site, agree the baseline and confirm the problem can be measured.

  3. Typically 8–16 weeks

    Step 3: Paid pilot

    A paid pilot on a defined scope, with success measures agreed in writing at the start.

  4. Scale, adjust or stop

    Step 4: Decision on scale

    You review the results against the agreed measures and decide to scale, adjust or stop. Rollout runs as a fixed-scope project, and a retainer or managed service can follow.

Client case study

No client case studies are published yet

When a client project is complete and the client agrees in writing, we will publish what was done and what changed. Until then we show no client names, logos or results, and we never present a blueprint as a delivered project.

What each case study will set out
  • The problem in the client's own terms, and why it mattered
  • What we built and how it connected to the systems already in place
  • The measures and baseline agreed before the work started
  • Results against that baseline, including what did not work

Want to see a blueprint applied to your operation?

Tell us about the process, the data you already collect and the result you need. We will walk you through the closest blueprint and outline a paid proof of concept with measures agreed up front.

Discuss a pilotExplore solutions