DEV Community: Nayantara P S

Using LLMs with IoT Data: Where the Architecture Actually Matters

Nayantara P S — Thu, 24 Sep 2026 13:44:50 +0000

There has been a steady progression of demos showing an LLM attached to a sensor.

Send a temperature value to a chatbot and ask it what it means.

It's interesting.

But is it useful?

The engineering challenge of adding AI capabilities to existing IoT systems - including noisy telemetry, thousands of devices, workflow and operational data - is not as simple as plugging an LLM at the end of the pipeline.

Let's explore what a useful architecture might look like.

Start With the Data Pipeline

A basic IoT architecture might resemble:

Device
Sensor
Gateway
MQTT / Network
Data Platform
Application

Adding an AI capability to this architecture could involve attaching an LLM to the data platform output.

In practice, this is rarely a useful architecture.

The model would need to understand the context of a temperature value of 82°C - which could mean entirely different things based on the equipment, environment, operating mode, or position of the sensor.

A more useful architecture is something like:

Sensor Data
Validation
Context Enrichment
Rules / ML Analysis
LLM Interface

Human or Application

The LLM is an interface to information, rather than an analytical engine.

LLMs Are Not Always the Right Tool

This leads us to the next point: statistical analysis, rules-based analysis, or traditional ML techniques may be more appropriate for analyzing high-frequency telemetry than a language model.

An LLM is a valuable tool when the problem involves interaction.

For instance, someone might ask "What were the anomalous events of the last shift?".

The application could return relevant telemetry, maintenance records, operational context, and the results of any rules- or ML-based analysis before passing this information to the LLM to generate a succinct summary.

The LLM is used to interrogate a body of information, rather than analyze raw telemetry.

Give the Model Context

Let's say we have an asset with the following telemetry and context:

Asset: Press-07

Temperature 82°C

Vibration: Elevated

Speed: 1,450 RPM

Utilization 91%

Last maintenance: 37 days ago

Anomalies: 3

A good application of AI could be to combine these signals and present them in a way that is useful to an operator.

The creation of this summary is not the important part.

The important part is the context assembly that happens before the prompt is created for the model to consume.

This usually takes the form of APIs, data services, retrieval systems, metadata stores, and rules - all of which wrap around the model to create a useful application.

Where LLMs Can Add Value

There are several cases where a language model can serve as a valuable interface to an IoT system.

1. Operational Summaries

Rather than having an operator consult a half-dozen dashboards, an application could generate a summary of notable events.

Telemetry

Event Detection

Context

LLM

Shift Summary

This could allow operators to more easily consume the information that is important to them.

2. Natural-Language Investigation

An operator could ask something like "What changed on Line 3 today?".

By parsing this request, the application could retrieve relevant events and data from the various systems involved and provide a summary of what happened.

This could be an effective way to allow operators to investigate unusual events.

3. Maintenance Assistance

An application could serve as an intermediary for a technician and the various systems that provide context for a piece of equipment.

Rather than the technician having to sift through different data sources, they can ask questions of the application.

Again, it is important that the application retrieve and display relevant information rather than generate text as if it were factual.

What About Automations?

This leads us to the topic of - well, automations.

An inference from an LLM is not necessarily an order.

A more appropriate architecture would be:

IoT Event
Detection
Context
AI Recommendation
Confidence / Rules Check
Human Review
Action

Automating decisions based on AI inferences is appropriate for some applications.

When the stakes are high - lives, production, security, compliance, or other factors - double-checking recommendations and requiring human validation may be appropriate.

The Difference Between a Demo and a System

An LLM can be attached to a MQTT topic and produce interesting results on a weekend project.

A production application has to be able to handle edge cases.

What if a sensor signal is invalid or missing?
How are identity and access managed?
How is the model validated and audited?
How are its decisions logged and explained?
How does it perform when it is unavailable?
Who can see what information?
How do end-users correct decisions the model has made?

These are architectural concerns, rather than prompt engineering.

The Real Opportunity

The opportunity with AI and IoT is not likely to involve an LLM querying a sensor stream directly.

A more realistic application might have layers: the IoT devices and sensors provide signals, the data infrastructure provides context, traditional ML and rules identify patterns and anomalies, and an LLM provides a conversational interface to the results.

Applications tie these capabilities together and expose them to an operator.

Asking "Can we connect an LLM to our IoT data?" is an interesting question to ask on a Monday morning.

A more interesting question to ask would be "What can we make easier to understand?".

That is what Aperture Venture Studio is doing with its focus area of Operational and Physical-World AI: building ventures around production AI and IoT systems.

Building a Practical Data Pipeline to Support Refinery Energy and Emissions Monitoring

Nayantara P S — Thu, 24 Sep 2026 13:38:36 +0000

Refinery engineers are already dealing with a lot of data.

There are measurements, control system values, energy records, equipment information, lab results, emissions measurements, alarms, maintenance, and historical operating data.

The real challenge isn't necessarily getting another measurement.

The challenge is ensuring the right measurements can be connected to answer an engineering question.

For energy-efficiency and emissions projects, a simple data pipeline can make that process easier:

Measure → Collect → Validate → Connect → Analyze → Improve

Start With the Measurements

A refinery may monitor a variety of parameters depending on its process units and environmental requirements.

Examples include:

NOx

SO₂

O₂

Particulate levels

Stack flow

Stack temperature

Fuel consumption

Steam use

Process temperatures and pressures

Each measurement tells you something different.

Gas concentration can provide information about the exhaust composition, flow can provide information about the movement of that exhaust gas, and temperature can add another layer of operating context that helps connect information from both measurements.

Looking at these values together can be more useful than looking at one of them individually.

Why Context Matters

Imagine a refinery makes a combustion condition change and subsequently sees a CO concentration change.

The value in isolation doesn't explain what happened.

Did they change the production rate?

Did the fuel conditions change?

Did the exhaust flow change?

Did the stack temperature change?

Was the reading part of a temp startup condition?

Without that surrounding information, investigation can become guesswork.

A more useful data structure would look like:

Gas concentration + Flow + Temperature + Time + Operating condition

This doesn't provide an automatic causation, but gives engineers more information to investigate.

Build a Reliable Collection Layer

Once measurements are available, the next challenge is getting them into a consistent data structure.

A simplified architecture might look like the following:


Sensors & Analyzers

↓

Data Acquisition

↓

Industrial Network

↓

Central Data Store

↓

Visualization & Analytics

↓

Engineering Decisions

The data-acquisition layer will get you some information from multiple instruments.

Connectivity takes that and makes it usable.

So that data is connected, but it should have a purpose.

You're not trying to connect every possible device as an end goal, but instead to get relevant information out when it is needed.

Data Quality Comes Before Analytics

A dashboard can look pretty good, but may just be based off of bad data.

Industrial monitoring systems should consider things like:

Missing measurements

Sensor drift

Calibration periods

Maintenance activity

Communication issues

Wrong timestamp

Duplicate records

Out-of-bound values

If those conditions aren't identified, an analytics system might interpret a data-quality issue as a process issue.

Which is why validation is in the pipeline:

Measure → Collect → Validate → Store

Only after that point should people be relying on trend and/or automated analysis.

Historical Data Adds Another Dimension

A real-time data stream answers the question "What's happening now?"

Historical data can be used for answers like "When did it happen? Has it happened before? What else changed?"

That's important, particularly when you're evaluating possible energy-efficiency projects.

A refinery that makes modifications to their steam system or has a heat integration project will want to ensure that they can compare operating conditions before/after the change was made as a way of judging its impact.

Historical data can do that.

And the same can be true when considering combustion changes, equipment modifications or waste-heat recovery opportunities, etc.

Connecting Energy and Emissions Data

Energy and emissions data are often treated as separate datasets.

They don't have to be treated as such.

A more connected approach could include:


Energy Use

+

Process Conditions

+

Emissions

+

Flow & Temp

+

Production

↓

Operational Context

This gives the engineering teams more to evaluate when reviewing some change or deviation.

A reduction in energy use is much more interesting, compared to looking at just a production change, if that can be considered in the context of current CO, NOx SO₂ measurements, and the production level at the point of those emissions.

It still has to be engineered, but you're not relying exclusively on a correlation of variables to decide why something might be happening.

Dashboards Should Answer Questions

A dashboard isn't about showing every available data point.

For a monitoring dashboard, it should be asking "What are we wanting to get out of this data?"

For example, a refinery might ask:

What are our emissions levels?

How much did they change in the last 24 hours?

Did flow/change at the same time?

Did the event occur during a a certain operating period?

Were there any missing or questionable measurements?

How does the current data compare to other days?

It's about visualization as an interface, rather than a presentation of charts.

Where IoT Fits

Industrial IoT will help you to connect physical measurements with digital systems.

Sensors and analyzers, networks, data platforms, and dashboards each play a role in getting the right information organized. You don't have to build a complicated architecture because it's all about the following:

Physical Process → Sensor → Data → Context ← Analysis ← Human Decision

The human aspect to this is pretty important.

An automated alert can help notify a controller when a value moves outside of a range, but it can't explain what that out-of-range impact was on the process without additional context.

Applying the Approach to Emissions Monitoring

Industrial emissions monitoring could include things like gas emission analysis, particulate / dust measurement, and stack flow / temperature monitoring.

Emissions and Stack gives technologies related to gas emission analyzer, particulate and dust monitoring and stack flow and temperature measurement.

The useful questions about those sensors shouldn't just be about installation.

What decision is the measurement going to help me make?

That way, you can avoid going off of a well-intentioned approach that just wants to capture everything because that would be more data, but ends up with a disconnected bunch of measurements.

A Starting Place for People Wanting to Improve

For people looking to improve the existing monitoring architecture, this is a good process to consider:

Know what operational questions are important
Know what measurements are already available
Define where important data gaps are
Make sure your measurement and data quality is good
Connect related measurements
Build useful historical views
Add analytics where they solve a specific problem
Review with your engineers and operators

It doesn't require you to get everything going at once.

It builds a foundation that can grow with the facility's needs.

Final Thoughts

Better refinery energy and emissions management is about making sure that you're not just collecting data for its own sake, but rather capturing relevant information and using it to help inform better decisions.

A good monitoring architecture is all about the following at a very basic level:

Measure → Validate → Connect → Understand → Improve

While the technology underpins it, the real benefit is made when using reliable information to drive forward the right engineering and operational choices.

From Connected Devices to Intelligent Systems: What Changes When AI Enters the IoT Stack

Nayantara P S — Wed, 23 Sep 2026 14:01:07 +0000

Many existing Internet of Things (IoT) systems were focused on the problem of data retrieval — getting information from a sensor to a dashboard.

A sensor would measure a given value (say, temperature). A gateway would retrieve that information and send it via a network stack to a data platform, then to an application, and ultimately to a dashboard for viewing and analysis.

This was an effective way of solving a particular problem: making previously inaccessible information visible and accessible.

But what comes next for developers who want to build the next generation of connected systems?

In particular, how can they productize an AI model to make it valuable within an IoT architecture?

Traditional IoT Pipeline

A basic IoT pipeline can be visualized as something like the following:

Device

Sensor

Gateway

Network

Data Platform

Dashboard

The architecture is great for gathering and displaying information.

Suppose, for instance, that you want to monitor a set of manufacturing machinery.

You might have a pipeline that ingests temperature, pressure, and vibration readings along with data about the machine’s state.

After that, you can view the information on a dashboard.

But does the dashboard indicate anything about the normality of the data or suggest any particular course of action?

Adding an Intelligence Layer

Let’s add an intelligence layer:

Physical Asset
Sensors
Connectivity
Data Platform
AI / Analytics
Contextual Insight
Application
Human or System Action

Essentially, we’ve added two new steps to the process: contextual insight and a recommendation for human or system action.

This transformation appears to be simple — just add an AI model.

But in practice, it can be more involved than it appears.

Specifically, an AI model must analyze a signal or set of signals and transform it into some sort of recommendation, prediction, or explanation.

Intelligence Is About Context

For instance, consider a scenario in which a manufacturing machine’s vibration levels have increased.

A basic IoT system could notify an operator that something is happening.

An intelligent system could ask more questions: Is the machine running at a higher speed than usual?

Has the production line changed?

Has the vibration increased gradually over several days, or has it changed suddenly?

Has the machine been maintained recently?

Have similar patterns been seen in the past, and if so, what were their results?

The AI model might not be able to answer every question, but the system could integrate and analyze multiple signals.

These signals would be more valuable than a single sensor on its own.

No Need For Total Autonomy

Some people think that adding AI to an IoT system inherently requires that the machine make decisions on its own, but this isn’t the case.

Here’s an example of a potential pipeline:

Sensor Event
Data Validation
Context Enrichment
AI Analysis
Prediction / Recommendation
Human Review
Operational Action

The example shows that human review is still a part of the process — and for some use cases, this is the correct approach.

AI doesn’t have to replace every aspect of a person’s job; it only has to make their jobs easier.

Edge Intelligence

Not all models have to run on the cloud.

For some industrial applications, latency is critical, or the connection can be spotty at times.

In these instances, some of the intelligence layer can be moved to an edge device:

Machine
Edge Device
Local Processing
Immediate Decision
Cloud
Historical Analysis

This approach creates a hybrid system, one in which some processing takes place locally and some processing takes place on the cloud.

There’s no need to make every model a distributed, or even an edge, model.

The appropriate location for it depends on the use case.

The Real Engineering Challenge

The real challenge of AIoT development often has little to do with the model itself: developers have to consider the pipeline, data quality, device identity and health, time sync, connectivity, versioning, data drift, edge vs. cloud, security, observability, and human review.

A model’s accuracy doesn’t necessarily dictate the result of the system — the engineering around it does.

A New Long Tail

This evolution leads to a new long tail:

Connect
Collect
Detect
Understand
Predict
Recommend
Act

IoT solved the first two.

AI can solve the rest, but it depends on the use case.

A recommendation still has to fit within the context of a broader application or even business process.

It isn’t enough to simply have an autonomous, self-driving machine — the right tool for the job has to be selected and put into the correct workflow.

The Future of Connected Systems Was Never About the Sensors

This isn’t to say that the sensors themselves aren’t important; it does mean that developers shouldn’t stop at the model.

The true opportunities in AIoT development lie in the space between.

Aperture Venture Studio is one such company, focusing on the intersection of AI and IoT to develop solutions for physical-world and industrial applications.

A Digital Thread In Powder Metallurgy Manufacturing

Nayantara P S — Wed, 23 Sep 2026 13:55:28 +0000

Working with powdered metal involves a process involving more than just pressing the powder into a part. From receipt through inspection and certification, a powder metallurgy part can go through several processes. Each of these processes can add value to the genealogy of the finished component.

While tracking a lot of information about the material properties of a finished part is valuable, even more so is how that information can be integrated with other processes, equipment, work-in-process and the final certification of the finished component.

In this article, we'll explore what a digital thread in PM manufacturing looks like, how it connects data and information relating to powder and production and then the tools that help support it.

Let's start at the beginning - the powder lot.

The Beginning of a Digital Thread: the Powder Lot

The digital thread doesn't have to begin with the production of a part.

In fact, it could begin when a powder lot enters the facility. Information relating to a particular powder lot can help identify the starting point of production genealogy for the component.

The digital thread could follow as that powder lot is blended, produced into a green part, sintered, and so on.

This could look something like:


Powder Lot

↓

Mixing / Blending

↓

Compaction

↓

Green Part

↓

Sintering

↓

Inspection / Testing

↓

Certification

Each of these steps can add attributes and information to the digital thread.

WIP Integration is Critical

When dealing with WIP, a manufacturer needs to know not only general production information, but specific work in process data.

From one plant floor to the next, these green parts and processes may get shuffled around. If information about the WIP is stored in one location and the material and production in another, establishing the complete provenance of a given WIP is difficult.

Linking this WIP information with the production elements provides a richer source of information.

By using a digital thread, a particular data record could be linked with the powder lot, equipment, production stage, and WIP.

The value of doing this isn't simply about being able to find the WIP - it's about understanding where that WIP has been, and how that information might impact the process going forward.

Quality Isn't Just Post-Production - Testing and Inspection Data

Quality information and data can play two roles in a digital thread.

First, there's information about the material itself. Then, there's information about the outcomes of production.

When inspection or testing data can be associated with a particular production history, it adds more context and value to that production record.

This is especially useful when there's a quality problem down the line.

Rather than having to sift through disconnected data sources about the production run, material and testing or inspection, a properly-integrated digital thread makes the relationship between the element clear, improving overall quality.

From Genealogy to Certification and Beyond

One of the easiest ways to think about a digital thread in PM manufacturing is genealogy tracking.

This looks at the relationships between materials purchased, received and put into production, and then the production processes, equipment, work-in-process, until it becomes a finished part.

For a PM component, this could look like:

Powder lot information

Mixing or blending history

Production equipment

Tooling

WIP details

Processing information

Inspection data

Test results

Certification information

This creates a history going from the purchased raw material or powder lot, through production, testing and finally the certification.

This gives a rich genealogy of a component.

Now, let's take a look at what kinds of tools would be useful in enabling a digital thread across production.

Enabling the Digital Thread: AIoT Technology

A digital thread involves creating connections between many points in a manufacturing operation.

It goes well beyond simple relational databases. Information needs to be pulled from many sources, including machines and sensors on equipment, RFID systems, production software, Bluetooth Low Energy (BLE) devices or even manually-entered paper work or spreadsheets.

This is where Industrial IoT technologies can create substantial value, and specifically AIoT technology.

AIoT combines industrial technology such as RFID or Industrial IoT sensors, with edge computing processing, data integration technologies and data analytics to help create a digital thread around manufacturing processes.

PowderForge AI offers connected manufacturing intelligent specifically focused on PM manufacturing, including powder inventory, tooling, WIP, people, equipment, and connected traceability.

The main point with a digital thread is about these elements being interconnected and intelligible.

Creating a Digital Thread: Not an Overnight Process

There isn't one magic bullet or piece of equipment, that creates a digital thread overnight.

PM manufacturers should evaluate at least one use case for a digital thread. This could be connecting powder lots to a given production run. Then, WIP, equipment, tooling, and so on can be included as necessary.

The focus is on getting the right relationships between physical objects and data records established in the first place.

Now that we've taken a look at some of the concepts behind a digital thread, let's step back and look at the bigger picture in this final section.

The Bigger Picture: Powder Metallurgy Component History

When finished, a PM component is a lot more than its inspection data.

Behind every part is a set of relationships between the equipment and processes which made it, the materials which went into it and the workers who handled it.

A digital thread can store this connected history, from powder lot to finished component. It can provide a genealogy of WIP, materials and certification.

This is a lot more valuable than disconnected islands of production data.

From Asset Visibility to Asset Understanding: Building Context-Aware IoT Systems

Nayantara P S — Tue, 22 Sep 2026 13:48:34 +0000

Tracking a piece of industrial equipment is one thing. Understanding what the equipment is doing is quite a bit more challenging.

An RFID reader can tell me that a tool is in the plant. A BLE gateway can tell me precisely where it is. A sensor can tell me how hot or how rough it is. A maintenance system can tell me when it was last serviced.
All of these signals are valuable, but the truly interesting use cases begin when we combine the signals coming from multiple sources.
Let me explain why this is the case with some architectural context and process flow.

A Simple Take on Asset Visibility

The most common view of an asset management architecture is probably something like this:

Asset
↓
RFID / BLE / GPS
↓
Gateway
↓
Location DB
↓
Dashboard

This architecture answers the question of 'Where are my assets?'. That is a good start but the operational questions are usually much more interesting.

What asset is this?
Where has it been?
How often is it being used?
What is its current condition? When was it last serviced?
Is its current behavior unusual?
What should I do with this information?

These are the types of questions we begin to answer when we have more information about the asset and its recent history.

A More Interesting Architecture

This is where it begins to get more interesting; We can take all of this data and operational history and combine it with other information about the asset.

Asset Identity
+
Location Signal
+
Sensor Reading
+
Maintenance History
+
Contextual Data
↓
Preprocessing
↓
Rules / ML Models
↓
Operational Insights
↓
Human or Automated Action

I am not necessarily interested in the ML model itself per se, but rather in what we can do with a stream of contextualized information about the lifecycle of an asset.

What does a vibration signal really mean in the context of what that machine has been doing, where it is, and what it is currently doing?
We might do some kind of analysis on the vibration as a simple example:

Temperature ↑
+
Machine Speed ↑
+
Production Context
↓
Contextual Analysis

Once again, context is valuable because it allows us to separate signals that might be normal from those which might be cause for concern, but there are other reasons for needing to enrich sensor data with contextual information, namely the process for operational decision making.

Taking Action and Adding Feedback

Having an insight into the potential state of the machine is valuable, but it becomes even more interesting when we think about putting that into an actionable format. Here is a simple look at an asset identification and decision architecture:

Sensor Reading
↓
Validation
↓
Contextual Enrichment
↓
AI / Rules
↓
Risk or Recommendation
↓
Human Review
↓
Action or Response
↓
Feedback Loop

In the end, it makes the most sense to create a closed loop feedback system so that these rules or AI suggestions can be tuned based on real-world results.

When the human or machine takes the suggested action, makes a repair, or inspects the equipment they should also be able to record a result as positive, negative, or neutral.

If the technician checks the equipment being flagged for high temperatures, for example, and confirms that everything is normal, that information should be fed back into the system as a learning experience for future inspections.

The Importance of Purpose

The bottom line is that it makes sense to build out a system like this around a decision or a question.

So many times, systems are built around the tools we have; "We have BLE sensors so we will build a tracking application for the plant floor."
That is usually not a great place to start. Instead, we should identify the question we want to ask and answer first, then build the architecture around that.

We should answer something like: 'Which assets are likely to fail within 72 hours?'.

Who cares about the sensors we have? Well, which sensors do we need to answer that question? Do we need to be tracking the equipment? How frequently? Should it be done in real-time, or can it just be hourly? Where is it most useful to us? What confidence level are we looking for? Finally, who should take what action and approve which recommendations?
That approach would build a system around a question we actually want answered instead of building an application about something completely unrelated.

Conclusion

Asset visibility tells us where things are, but we rarely stop there.
The more interesting applications ask how they might understand these assets - their lifecycle, context, and history.

Aperture Venture Studio explores AI and IoT ventures designed around real-world operational problems, connecting intelligent technology with practical business needs.

This is where an IoT architecture begins to take shape, and AI disclosure, or even operational decisions can begin to have value in a closed-loop feedback system.

Pharmaceutical Innovation Goes Beyond the Lab: Connecting R&D to Manufacturing

Nayantara P S — Tue, 22 Sep 2026 13:41:59 +0000

A pharmaceutical product can start as a research idea, but turning that idea into something that can be created consistently is not an easy path.

Research teams may work with formulation details, compounds, lab results, and lab processes. As development continues the information starts to move into connections with process development, scale-up, manufacturing equipment, materials, quality, and production records.

The key is to keep information needed by these groups together in context.

From Research to Development

Much pharmaceutical research is about exploring options and understanding a potential product and its mechanisms. As an idea moves to development, teams start considering process, test, formula characteristics, material needs and other factors relating to how a company might manufacture a product.

As this environment moves from research into development, more information takes on an operational context. The nature of questions also moves into manufacturing considerations such as:

Can the process be replicated? What materials are needed? What equipment is needed? Which process variables are important? How should the process be scaled?

Moving to Larger Scales

Scale-up is the next challenge. Many lab processes work in the lab, or in pilot batches, but moving to a larger continuous or batch process for commercial manufacturing adds new variables for engineers to consider.

Equipment capabilities, material handling, environmental conditions, procedures, workforce considerations, quality needs, and production records all come into play. There's a large interrelationship of information that comes together to define a successful manufacturing process. Information comes from sources such as equipment involved, materials being used (and their histories), steps taken, environment, quality information, and more.

A single data point rarely tells a complete story.

Where Connected Technologies Come Into Play

Pharmaceutical facilities have many sources of information. IoT and sensor information can bring in information from equipment and the environment. RFID, BLE and other options can add information on assets, materials, or processes. Industrial gateways, edge computing, and other technologies can help tie together these different systems and information sources. This information can be presented with records and other data from enterprise systems such as MES, ERP, LIMS, QMS and more.

The aim is not just about capturing more data.

The intent is about providing context and inter-relationships that make analysis and application simpler and more intuitive.

Keeping Your Manufacturing Story Straight

Imagine a scenario where there was an equipment alert for a manufacturing process.

On its own, this shows what happened (the alert) but not much context on why this occurred. With additional information, a reviewer can relate the alert to a specific manufacturing process and event (batch processing?), materials, equipment history or other connected items. It won't tell you if it impacted your product, that's for a quality assessment. However a connected data source may help provide more context and help teams determine the root cause of this incident.

From the initial research to the records created during manufacturing, each step has information that helps tell the story of how a pharmaceutical product is manufactured. It's up to us to keep this evidence together and connected to give us greater information on our processes.

PharmaFlux AI is an example of a manufacturing intelligence approach focused on connecting information across workforce, assets, inventory, processes, and traceability. The broader concept is to make relationships between operational data easier to understand rather than treating every data source as an isolated record.

Patients need our products and we need to keep building this connected intelligence to ensure our manufacturing processes are well documented understood, and ready to evolve when the need arises.

Innovation → Development → Scale-Up → Manufacturing → Patients

The more we keep these interconnected, the more insight we have on how our pharmaceutical offerings are physically created and managed.

AI Workflows Require Context: Designing AI That Understands More Than What You Ask

Nayantara P S — Mon, 21 Sep 2026 13:30:10 +0000

AI is very good at working with individual messages and inputs.

If you hand a model a customer message it can classify it. If you give it equipment data it can recognize unusual patterns. When you give it a dataset it can output SQL and analysis.

So, what makes for a harder engineering task? What makes applications require more than an isolated input message?

The Input Message Has More

Take a use case around equipment monitoring.

A sensor provides this reading:


temperature = 82°C

This message could be normal, depending on the circumstances.

Maybe the machine is running on a higher load. Perhaps it is a warmer ambient temperature. Possibly the equipment was just serviced.

For a useful application, the model needs additional information.

Perhaps such as this:


asset_id

timestamp

operating_mode

load

history

maintenance

temperature

And then the model can consider the current reading and determine if anything is wrong.

Add a Context Layer

One approach to this problem could be such an architecture:


Data Sources

↓

Data Processing

↓

Context / Metadata

↓

AI + Rules + Analytics

↓

Recommendation

↓

Human Review

↓

Business Workflow

The context layer can take many forms, depending on the application. It could be a database, feature store, metadata management layer, semantic layer, knowledge base, or even application-specific data model.

The key thing is that the AI system can have richer context and data than was given directly.

The important detail is that the AI gets relevant information, rather than the input on its own.

The Context Has Traceability

If someone in operations asks "why did the AI say what it said?"

developers may have to explain what data the AI had available and why.

They may need to explain what particular model version made the prediction.

They may also have to explain what rules, if any, the AI used.

Or if and how a human reviewed the recommendation.

Was the AI recommendation followed?

What was the outcome? Did the equipment fail?

These are all reasons recordkeeping and observability are important.

A record of a single AI-driven workflow might look like this:


request_id

asset_id

timestamp

model_version

input_reference

context_reference

prediction

confidence

review_status

final_action

There is also no need to retain training data or raw inputs unless it becomes relevant for debugging or governance. By using references and carefully structured metadata, it can often be possible to retain just enough information for these purposes without having to store everything.

It Is Not Always More Data

It can be tempting - especially with the hype around large language models - to assume that passing more data to the model will always improve results.

A bigger version of the same model, potentially. A larger dataset. Even adding more fields and context.

This is not always the case, and has significant downsides for both cost and performance.

There is also the issue of what to do with the data.

The better question when designing an AI-driven application is likely to be: what does the person who knows how to handle this situation need to know?

What information would a technician or engineer need to know in order to make a decision?

This can often be a good starting point when designing an application's input for the AI.

Predictions Have a Purpose

Unless there is a process for the AI's output, it may not have much value. For example:


Sensor Data

↓

Anomaly Detection

↓

Risk Assessment

↓

Maintenance Recommendation

↓

Technician Review

↓

Work Order

The AI is only one part of the overall application. What the rest of the application does is what makes the overall system valuable.

This is also important for the industrial space in particular, because it means that AI outputs can feed directly into other processes. From field service, to logistics, to inventory management and equipment upgrades.

AI Applications Need Feedback

The overall application should also be able to provide feedback to the AI.

Was the recommendation followed?

Did the technician report a different result?

Did the equipment actually fail, and if so, how?

Was the AI recommendation correct, and if not, why?

The more information can be provided in this feedback, the more valuable it tends to be.

It also enables a feedback loop.

The AI makes a prediction. Someone reviews it. An action is taken. The results are observed. The model learns and updates.

This loop is abbreviated into this:

Predict → Review → Act → Observe → Learn → Improve

Aperture Venture Studio focuses on AI and IoT venture opportunities that involve real-world physical operations. For developers considering the space, a similar point applies - AI applications require appropriate context and traceability, but also fit into overall system workflows and provide feedback for further training.

The Value of Tooling Visibility in Connected Powder Metallurgy

Nayantara P S — Mon, 21 Sep 2026 13:24:40 +0000

Within manufacturing, some of the easiest delays to occur come from simple issues.

A machine may be ready, but the required tooling is not present at the expected location. A die may require maintenance, but has been moved to a different area. A punch has been relocated by another production entity. Someone stops their current task to find information.

These scenarios are common, and easily ignored because they do not result from an obvious equipment malfunction.

Sometimes, it is simply one of limited visibility.

Tooling Contains Production Data

Within powder metallurgy, dies, punches, fixtures and related tooling are tightly connected to production.

These assets move between storage, preparation, production, inspection and maintenance.

This information can be valuable, if a plant is capable of viewing the whereabouts of a specific tooling asset, its current status, and its production history.

This is where connected asset management becomes of interest.

Connected Asset Management Enables Enhanced Understanding of Physical Assets

Technologies such as RFID and BLE can be utilized to connect a physical asset to a digital information trail.

Instead of the physical asset simply existing within a certain area, it now has a digital footprint which can contain information such as:

Current or recent location
Asset identification
Movement
Maintenance
Production utilization
Status

The information which the physical asset contains depends on the manufacturing environment, but the value of connecting it to a digital information trail remains the same; improving understanding of the physical asset.

While Location Information is Valuable, Context Information Contains More

Being able to track the location of a tooling asset is useful, but is simply one part of a much larger piece of information.

If a tooling asset is found to be located in a maintenance area, what is its status? What does it need? Is it waiting to be inspected? Has it already been maintained? Does it have a scheduled production job?

A "location" tag alone cannot provide answers to these questions.

By connecting the information about a physical asset to other data sources, such as maintenance and production, the same physical asset can contain much more information than just its location.

Connecting Tooling Information to Other Sources Enables Powerful Insights

The true potential of connected tooling information comes when the information about it is connected to other sources of information.

Powder inventory, equipment, workforce, WIP, production events and traceability all can be sources of information connected to a physical tooling asset.

Some use cases for utilizing connected tooling information could be:

Giving production teams the information to know if the required tooling assets are available for a production job.
Giving maintenance teams the information they need to know the maintenance history of a specific tooling asset.
Giving quality teams the ability to connect production information with a specific tooling asset or process.

Each department may have different needs, but all of them can benefit from having access to the information connected to a physical tooling asset.

AIoT Contains the Tools Needed for Connected Tooling Information

AIoT, as a concept, enables connected devices and industrial data to be enriched with analytics and AI-driven insights. Within a powder metallurgy environment, technologies such as RFID, BLE, industrial IoT-sensors, edge-computing and analytics can be combined to a connected manufacturing environment. PowderForge AI focuses on providing manufacturing intelligence to the powder metallurgy industry, connecting tooling, equipment, inventory, workforce, WIP and traceability into a single connected environment. The focus of connected tooling is not on providing yet another tracking system, but to enhance the operational information connected to a physical asset, making it more accessible and understandable.

The First Step Should not be to Track Every Asset

Manufacturers do not need to digitize every asset they have on day one.

A good starting point can be to find out what issues are frequently occurring, or what information is regularly sought after.

Tooling may be a problem area, due to its frequent movement between areas. A specific maintenance history for a tooling asset may be difficult to find. Production may be questioning the availability of specific tooling assets for a production job.

Find a use case which is relevant and important to your operations, before building a business case around digitizing and connecting all physical assets in your environment.

Visibility Enables Manufacturing Intelligence

Tooling visibility may seem like a small step towards a fully digitized and connected manufacturing environment.

However, physical assets are deeply woven into the production process of a manufacturing plant, and they contain valuable information about people, machines, materials, maintenance and production. Making this information more accessible can enable operations to spend less time searching for it, and more time utilizing it. Connected manufacturing environments begin with visibility, and good visibility begins with knowing what a physical asset is, where it is, and how it fits into the production process.

Keeping Data Context When Multiple AI Tools Touch the Dataset

Nayantara P S — Fri, 18 Sep 2026 16:44:43 +0000

AI can now generate SQL, clean CSV files create charts write analysis reports and produce scripts surprisingly quickly.

The interesting engineering problem comes afterward.

What happens when another developer, notebook, dashboard or AI agent needs to work with the data?

The file usually contains the values. It rarely contains the reasoning behind the values.

The Dataset Is Not the Whole Story

Consider a metric called active_customers.

The dataset may contain the number but several questions remain:

What counts as a customer?
Which source system is authoritative?
Are test accounts excluded?
How are duplicate records handled?
When was the definition last changed?

Those decisions are part of the datas context.

If those decisions exist in a Slack message or an old AI conversation the next person—or AI agent—has to reconstruct them.

That is where data workflows can become fragile.

Treat Context as Metadata

A approach is to store important decisions alongside the data workflow.

For example:


metric_definition

source_of_truth

owner

transformation_logic

validation_rules

known_limitations

update_frequency

last_reviewed

This does not mean every dataset needs a documentation system.

Sometimes a version‑controlled Markdown file schema description, dbt documentation, data catalog or semantic layer is enough.

The important part is making the reasoning discoverable.

AI Agents Need Context Too

This becomes more important when multiple AI tools are involved.

One AI agent might generate SQL.

Another AI might clean the resulting data.

A third AI might create a visualization.

A fourth AI might analyze the results.

If each tool sees the latest file important decisions can disappear between steps.

A better workflow might look like:


Source Data

↓

Transformations + Tests

↓

Documented Definitions

↓

Dataset

↓

AI Analysis

↓

Human Review

↓

Output + Decision

The documentation becomes part of the workflow rather than an afterthought.

Keep a Record of What Changed

Version control's useful here but not only for code.

Changes to definitions transformation logic, source systems, validation rules and assumptions can affect downstream analysis.

Knowing what changed and why can be just as useful as knowing which file changed.

This also makes debugging easier when two reports suddenly produce numbers.

Don't Document Everything

There is a temptation to record every conversation and every intermediate output.

That can create its problem: too much information and not enough signal.

Instead capture the decisions that someone else would need to reproduce or safely modify the workflow.

Ask:

What would I need to know if I inherited this dataset six months from now?

That question usually reveals the valuable documentation.

The Bigger Idea

As AI tools become more capable generating data products becomes easier.

That makes context preservation important not less.

The useful workflow is not simply:

Data → AI → Output

It is closer to:

Data → Context → Transformation → Validation → AI → Review → Output

AI can help write the SQL.

AI can build the chart.

AI can explain the results.

Someone still needs to preserve the reasoning that makes those outputs trustworthy and reusable. At Aperture Venture Studio, the focus is on practical AI and IoT applications that connect data, intelligent systems, and real-world workflows.

From Energy Data to Emissions Data: Building a Practical Monitoring Workflow

Nayantara P S — Fri, 18 Sep 2026 16:39:31 +0000

A lot of reporting starts with a simple question:

What data do we actually have?

For a business the answer might be electricity bills, fuel purchases, production records or transportation data. For a facility data can be much more detailed.

There may be gas analyzers, particulate monitors, temperature sensors flow sensors, control‑system data and historical operating records.

The challenge is turning all of those measurements into information that people can actually use.

Start With the Data Sources

Before building a monitoring platform it helps to understand where environmental data is already being generated.

A basic industrial monitoring setup might include:


Gas Analyzers

|

Particulate Sensors

|

Flow / Temperature Sensors

v

Data Acquisition

|

v

Central Data Store

|

v

Dashboard / Analytics

Each source provides a different piece of information.

Gas analyzers can provide measurements of pollutants such as NOx, CO, SO₂ or O₂. Particulate monitoring can give information about dust or particle levels. Flow and temperature measurements can give context about exhaust conditions.

EPA describes stationary‑source emissions monitoring as the collection and use of measurement data to assess emissions and the performance of processes or emissions‑control equipment.

Why Context Matters

A single measurement can be difficult to interpret.

Suppose a monitored gas concentration suddenly changes. Looking at that value leaves several questions unanswered.

Did production change?

Did exhaust flow change?

Did stack temperature change?

Was equipment being maintained?

Has something similar happened before?

This is where multiple data sources become useful.

Of looking at:


Gas concentration = X

a monitoring system can provide:


Gas concentration

+

Flow

+

Temperature

+

Time

+

Operating conditions

The additional context does not automatically explain the cause but it gives engineers more information to investigate.

Time‑Series Data Is Useful

Environmental data becomes more useful when it can be viewed over time.

A current reading tells you what is happening now. Historical data can show whether the value is:

Increasing gradually
Changing suddenly
Repeating periodically
Returning to normal
Associated with another operating condition

This is one reason data storage and timestamp consistency matter.

If measurements from systems use inconsistent timestamps or contain missing periods comparing them can become much harder.

Data Quality Comes Before Analytics

It is tempting to focus on dashboards and analytics

Sophisticated visualization cannot compensate for unreliable source data.

Monitoring systems should account for issues such as:

Missing measurements
Sensor drift
Calibration activities
Communication interruptions
Maintenance periods
Duplicate records
Incorrect timestamps
Unexpected values

EPA identifies quality assurance and quality control as parts of emissions monitoring because they help ensure that monitoring systems continue to produce valid data.

In terms bad input data can produce misleading conclusions no matter how good the dashboard looks.

A Simple Architecture Can Be Enough

Not every facility needs an analytics platform.

A practical architecture might simply be:

Measure → Collect → Validate → Store → Visualize → Investigate

The important part is making sure each step has a purpose.

For example a data acquisition layer can gather measurements from instruments. A central system can store time‑series information. A dashboard can then display readings alongside historical trends.

Advanced systems can add alerts, automated quality checks, event correlation and other analytical capabilities when those features solve a real operational need.

Connecting Environmental and Operational Data

One useful development in monitoring is the ability to connect environmental measurements with operational information.

Consider a production facility where emissions data is stored separately from process information.

Bringing the datasets together can make it easier to investigate relationships, between:


Production activity

↓

Process conditions

↓

Exhaust conditions

↓

Emissions measurements

This does not mean every correlation represents a relationship. It simply gives engineers a dataset from which to investigate what happened.

What Should a Monitoring Dashboard Show?

A useful monitoring dashboard does not need dozens of charts.

For an industrial emissions application users may want to see:

measurements
Historical trends
Flow and temperature

*. Threshold conditions

Data‑quality indicators
Equipment status
Time ranges
Relevant operating conditions

The goal should be clarity than complexity.

A monitoring dashboard that helps someone answer "What changed?" is often more useful than one that simply displays hundreds of values.

Where Industrial Monitoring Fits

For facilities that need environmental measurements, technologies such as gas emission analyzers, particulate and dust monitors and stack flow and temperature systems can form part of the measurement layer.

Emissions and Stack is one resource covering these types of industrial monitoring technologies.

The broader lesson however applies beyond any vendor or platform.

Environmental data becomes more useful when measurements are reliable, connected, time‑stamped and presented with context to understand what is happening.

The Bigger Picture

Businesses may begin collecting energy and emissions data because someone requests it. Over time that data can become useful for more than responding to a questionnaire.

Well‑organized measurements can help teams understand operations investigate conditions compare historical performance and identify where additional information may be needed.

The technical workflow is relatively straightforward:

Sensors → Data → Context → Analysis → Human Decision

The difficult part is making sure every step is trustworthy.

Better environmental monitoring is not necessarily about collecting the possible amount of data.

It is, about collecting the right data maintaining its quality connecting related measurements and making the information understandable.

Building AI Workflows For Messy Real World Operations

Nayantara P S — Thu, 17 Sep 2026 17:51:04 +0000

A lot of AI automation is predicated on clean digital input

An email comes in, a model classifies it, a response is sent, a database is updated

Real world operations aren't clean.

A maintenance request might have a picture, a short description, equipment ID, location, years of service history. A repair request might need to reference parts, previous work orders, technician availability, and operating conditions.

The engineering challenge is not just adding an AI model.

It's connecting all of those pieces to produce a useful outcome.

The input is usually messy

Let's say we have a maintenance request like so


"Machine 14 is making a strange noise."

That sentence on its own probably doesn't tell us what we need to know to make a maintenance decision.

A more useful system would look something like this


Request

↓

Asset ID

↓

Equipment History

↓

Sensor Data

↓

Previous Work Orders

↓

AI Analysis

↓

Suggested Next Step

↓

Human Review

We're embedding the AI as a cog in a bigger information processing workflow.

Context is more valuable than a signal

Let's say we have a connected machine that's reporting more vibration than usual

There are a number of factors that could explain that.

Maybe the machine is under a different load, maybe a bearing is wearing out, or perhaps the sensor is just noisy.

Vibration on its own isn't necessarily a useful signal.

A better system would look at vibration in the context of temperature, operating conditions, maintenance history, run time, or other available sensors.

This is about data integration.

The challenge is not finding a new model, but rather getting the right information into the model at the right time.

AI doesn't need to own the workflow

There's another temptation to build systems where AI makes everything possible.

That can lead to unnecessarily complex systems.

A better approach is to think about the system in layers and let each layer do one job


IoT / Application Data

↓

Data Processing

↓

AI / Rules / Analytics

↓

Recommendation

↓

Human Review

↓

Business System

↓

Physical Action

For lower risk decisions, it's appropriate to make them fully automatic.

For higher risk decisions, the AI can make a recommendation but an authorized person has to take responsibility for the final decision.

Observability matters

When you embed an AI in an operational workflow, you need to be able to reason about what happened.

You need to ask yourself questions like


did the model produce an unexpected prediction?

was the prediction reviewed?

was the suggested action taken?

You can answer these questions by logging fields like


request_id

asset_id

timestamp

model_version

input_reference

prediction

confidence

review_status

final_action

It makes subsequent debugging easier and gives you a feedback loop to improve your models.

A prediction can be reviewed and either approved or rejected. That outcome can be used as a signal to improve future predictions.

It's also worth emphasizing the feedback loop

Prediction → Review → Outcome → Feedback → Improvement

Start with one workflow

If you're going to connect everything into a big graph, it's tempting to try and do it all at once

But you'll get much further by starting small and picking one workflow to optimize.

Here are some examples

Classify maintenance requests
Prioritize work orders
Identify unusual equipment behaviors
Extract information from inspection reports
Match repair requests to asset history

Measure the current process, add the AI, and compare the two. What's faster? What's safer? Are there fewer steps? Are there new insights available?

Did you reduce response times or unnecessary work? Were the predictions helpful? Are people using the suggestions?

These are more interesting questions than "how accurate was the model".

The bigger engineering challenge is connecting everything to the model

AI becomes interesting when it can operate in the real world.

Sensors, machines, images, locations, maintenance, inventory, and human decisions all become part of the same workflow.

This is the domain space explored by the companies at Aperture Venture Studio, which is focused on AI and IoT companies working on real world operational software.

The lesson is simple: don't build an AI model and then look for problems to solve. Start with the problem and the workflow, identify what data you have and what you're missing, and then think about where AI can add value.

Corporate Emissions Could Reflect Value Chains, Context And Better Information

Nayantara P S — Thu, 17 Sep 2026 17:44:01 +0000

Some statistical claims made about the emissions of corporations appear in headlines:

"A small set of firms are responsible for a large share...

This can be the case since "responsible" could reflect not only the releases from facilities owned or operated by a company, but also the emissions produced by using the goods sold by that firm.

Clarifying the difference may explain why corporate emissions statistics can seem paradoxical, while emphasizing the value of industrial measurement.

Sources Of Direct Emissions From Industrial Facilities

The facilities and equipment of a company's own operations could release emissions, for example:

Boilers and other heat- or power-producing machinery or equipment,

Machines used in its manufacturing or refining processes,

Refineries,

Power plants,

Combustion sources,

On-site transportation or other equipment

These emissions would typically be classified as Scope 1.

At an industrial stack -- which can be an exhaust or chimney -- a monitoring team might gather information about what gases, liquids or particulates are emitted from the combustion process, plus any flow and temperature in the stream. The gases might include nitrogen oxides, sulfur dioxide, carbon monoxide, oxygen -- or other gases depending upon what was burned.

The reason for taking a particular reading could reflect multiple factors, but the goal generally is to provide an indication of emissions. Teams might use this information to better understand the process and emission conditions, look at causes when there was an apparent change, or evaluate controls and pollution reduction.

Industrial facilities' emissions are typically included in a broader category called corporate scope emissions, and can be expressed in terms of total greenhouse gas emissions or, more specifically, the amount of CO2 equivalent emissions. As a reference, a typical gasoline-fueled car emits about 8,900 grams of CO2 during a single mile driven.

Emissions From Products Sold By Firms

However, when a company sells products that involve combustion, for those products the company should also consider the emissions resulting when customers use them. For instance, gasoline, diesel fuel, coal, or natural gas are each products that -- when burned by consumers or third-party entities -- produce emissions:

The company's emissions could reflect the releases that occur prior to delivery, such as during processing or transportation. But when gasoline is burned in an automobile, the emissions that result can also be considered part of that company's "value chain." Similarly, when the natural gas consumed at a power plant was produced by another company, those emissions add to that other company's inventory of emissions in its value chain. Emissions associated with consumer use of products by a company's customers are classified as Scope 3 emissions.

When a statistical claim attributes a percentage of global emissions to a company -- or to several companies -- this might refer to the sum of all emissions from operations at its facilities or sites, but those numbers are not necessarily the sum of its "own" emissions from its manufacturing, power generation, refining, or other facilities or buildings, or its third-party distribution or related emissions.

Clarifying The Meaning Of Corporate Emissions And Stack Information

Why Do They Matter? What Sources Of Information Could Help Address Some Confusions?

A corporate emissions inventory asks a different question than does an industrial stack monitoring campaign.

While the first might state, "What is the climate impact associated with this organization, including its processes and value chain?" the second provides an answer to a narrower question: "What is exiting that stack?" Both are valuable, but one should not substitute for the other. A wide-scope inventory might identify emissions for a certain type of transport or chemical, while stack readings give finer information in a specific context. One does not invalidate the other, but conflating the two can cause confusion.

Who Is Emitting? Customers, Corporations And The Industrial Infrastructure They Operate

A simplistic view of this issue would position this as a choice between "responsible" individuals and "responsible" large corporations. In practice, a company typically has only limited power to control multiple elements of demand, of production, of distribution, or of energy generation or transport of products, or related aspects. Instead, there can be a variety of interacting components influencing overall emissions for a particular good, service or industry, for instance:

Demand,

Industrial production,

The energy infrastructure and resources used,

The transport infrastructure and resources used,

Technological options or limitations,

Investment by the companies involved,

Regulatory pressures,

The economic costs or other factors affecting prices or availability.

One example of a change at a single component in a system might be a switch of demand for a particular high-emission product -- for that item, the change initially only influences production. But to the extent production cannot change immediately due to limitations due to infrastructure, transport or other factors, these factors or the decisions of multiple other participants will also be involved.

Understanding Emissions Needs A Broader View, In Addition To Reading A Single Stack

The large emissions figures mentioned in headline claims are typically calculated using estimates, production figures and emissions factors, and other variables.

While this approach can be valid and effective, it is fundamentally different from looking at a specific set of emissions data coming from a stack at a particular industrial operation.

The advantage of the latter approach is that it is more specific: for that facility and for that stack, the equipment involved could provide much better insight about what is going on and what changes may be occurring.

For instance, a particular industrial stack could have gas analyzers, particulate monitors, flow meters, temperature sensors and other instruments designed to collect information about the equipment or process, or the emissions released. When the data from those are collected -- individually or in combination -- and stored as a database over time, this allows for trend identification, evaluation of operating or emission conditions, or investigation of outliers. Other connected tools can reduce the need to access multiple files by moving the data into a dashboard or other repository.

Emissions and Stack offer technologies related to gas emission analyses, particulate or dust and stack flow and temperature monitoring.

The value of such detailed industrial reading and recording is twofold: it contributes to developing a broader view of emissions inventories for an organization or an industry, and it allows a better interpretation of a single large number.

Questions To Ask A Source Citing A Statistical Claim About Corporate Emissions

When looking a statement that indicates a company or organizations are responsible for some X percent of worldwide emissions, it helps to consider the following questions:

Do their calculations include all of the gases involved?

Does the claim include direct and indirect emissions?

Are the emissions connected to the operations of the facilities owned or operated by the companies accounted for?

Are sold products' use emissions included in the figure?

Were any particular scopes, such as a corporate scope of emissions, referenced when giving the figure?

Do the figures represent an average over time?

Were the figures measured, or are they estimated using production numbers and emission factors?

Are the figures compared using the same references?

Clarifying Corporate Emissions: A Needed Action

A company's emissions claim can help provide context and perspective to a complex issue.

But the information reflects not only the releases that occur at the facilities owned or operated by the company, but also those that can stem from using the products that are sold by that organization. Similarly, when industrial operations are monitored at a specific stack, the data can add insight into what that company's impact is in a specific context.