DEV Community: Smrati

System-First, Venture-Second: a New Approach to Building Companies

Smrati — Sat, 01 Aug 2026 12:23:45 +0000

The typical approach to founding a startup follows a certain pattern: A founder conceives of a product, constructs a minimum viable product (MVP), procures customers, secures investment, and finally scales operations. This model has given rise to some of the most successful businesses in history.

Nonetheless, it is associated with a high rate of failure, particularly in deep-tech ventures, due to the significant gap-often considerable in both scope and financial investment-and the inherent technical risks involved in transforming an idea into a viable product.

A new paradigm is gaining traction, which reverses this sequence: it's known as the 'system-first, venture-second' model, and it's reshaping how the most experienced creators of companies in AI and IoT operate.

What Precisely Does 'System-First' Entail?

In the system-first framework, the initial focus is not a business concept but a real-world issue. Creators begin by thoroughly investigating a particular industrial challenge, then develop and implement an AIoT (Artificial Intelligence of Things) system designed to resolve it. This system is constructed using actual data, validated in practical environments, and confirmed by real customers before a formal business entity is established.
The venture itself-the startup, legal structure, and investment rounds-comes later.
Only when the system demonstrates tangible value in the real world is it separated into an independent enterprise.

At that point, the most critical uncertainties have already been addressed:

Does the technology function?
Do consumers want it?
Can it be deployed on a large scale?
How Does This Model Significantly Reduce Risk?

Most of the early funding of traditional startups is dedicated to addressing the fundamental questions of product functionality and consumer desire.

In deep-tech industries, this process is exceptionally challenging; hardware can be costly, industrial deployment is time-consuming, and businesses are hesitant to adopt unproven technology.

The system-first model preempts a substantial portion of these uncertainties before the formal startup lifecycle even begins. When a company is launched via this approach, it already possesses a functional system, concrete deployment data, and proven customer demand. Investors aren't just investing in a pitch; they're investing in evidence. Faster, Leaner, Stronger: The system-first method offers practical benefits, such as shorter development timelines since creators start with existing infrastructure, data streams, and customer relationships, rather than beginning from scratch.

Capital efficiency is significantly improved, with less investment required for exploratory development and failed experiments.
The resultant ventures are inherently more robust due to their reliance on proven foundations rather than speculative assumptions.

A Model Tailored for the AIoT Era

The system-first, venture-second approach is especially suitable for the AIoT industry. Developing integrated intelligent industrial systems requires hardware, software, data, and specialised knowledge working together smoothly.

Organisations already possessing these capabilities-and able to deploy functional systems in real-world settings prior to spinning out ventures-hold a considerable structural advantage over conventional startups attempting to assemble all these components from scratch.

The Future of Company Building

The system-first model won't entirely replace traditional methods of starting companies. However, in deep tech, industrial AI, and IoT -where complexity is high, validation is costly, and customers expect reliable solutions-it offers a smarter way to build companies.
The ventures created this way are better prepared, validated, and positioned to scale than nearly anything the traditional approach can generate.

Aperture Venture Studio employs this very model, identifying real industrial challenges, developing and validating AIoT systems, and launching ventures based on proven deployments and genuine customer need.
Learn more at Aperture Venture Studios

Dealing with Offline Tags: Store-and-Forward Patterns for Asset Tracking Systems

Smrati — Sat, 01 Aug 2026 12:07:56 +0000

Most of the asset tracking guides online assume you can trust connectivity. The reality for hardware, however, doesn’t afford the same guarantee: a GPS tracker dips into a tunnel, a LoRaWAN device is at the edge of the gateway’s range, or an indoor gateway powering an array of BLE beacons goes dark during a facility-wide outage. If your system can’t reconstruct a timeline without assuming that every event that happens remotely is also reliably reflected immediately at the backend, then either auditing or incident investigations at some point simply won’t work. In this post we walk through store-and-forward patterns that won’t crack under inconsistent connectivity.

Just “Retry” isn’t a Strategy

The most obvious first step is to simply have the device or gateway retry until the data gets there. This is a necessary component, but it’s not sufficient on its own because:

Battery-powered IoT devices can’t be retried indefinitely before exhausting power meant to last months or years.
If a device doesn’t have a local buffer then any data it generated while offline is simply lost lost lost after its re-send window expires
Uncoordinated retries often result in double counts without explicit deduplication logic at the backend

You need buffering of some sort on the device or gateway side of the system, and idempotent ingestion on the backend. One without the other results in data loss or data corruption that’s every bit as bad if not worse.

Local buffering: What, and How Much, To Save?

Not every event that occurs remotely merits the same priority or occupies the same space in local storage. A useful approach in this context:

High-priority, low-frequency data (e.g., geofence exits, threshold breaches, RFID reads). These types of events aren’t frequent enough to overflow storage even by the thousands, but when lost they’re critically important.
Low-priority, high-frequency data (e.g., location pings every 30 seconds, ambient sensor values with no imminent threshold breaches). This type of data benefits from a rolling capacity; when the buffer fills, it’s likely safe to toss out the oldest routine pings. A missed- but unremarkable- 30-second location pin is often less of a concern than a missed geofence entry.

Why do we differentiate? Inexpensive IoT hardware typically has a limited amount of local storage. When a buffer is filled blindly and at uniform priority, low-priority chatter often crowds out high-priority important events.

on_connectivity_lost():
    switch_to_local_buffer_mode()

on_event(event):
    if event.priority == HIGH:
        buffer.store(event, evict_policy=NEVER)
    else:
        buffer.store(event, evict_policy=OLDEST_FIRST, cap=ROUTINE_CAP)

on_connectivity_restored():
    for event in buffer.drain(order=PRIORITY_THEN_TIMESTAMP):
        send_with_retry(event)

Idempotent Ingestion: Preventing Duplicates

As you start to send out the buffer contents upon reconnections, what do you do if the ack gets lost and the device sends the same data packet again, after connectivity is already back? Or what if the data was sent while offline, and you get back the ack, but somehow the record got dropped again? A lost acknowledgement means something got duplicated, but the only good option if something got lost is for something to be redelivered. It's the backend's problem to de-duplicate.

Fortunately, this is solvable: Every event includes a client-side unique identifier, typically made up of device ID, a sequence number, and a timestamp. The backend’s ingestion point is then configured to upsert if the unique_id already exists and to otherwise just insert.

on_ingest(event):
    if event_store.exists(event.unique_id):
        return ACK  // already processed, don't reprocess
    event_store.insert(event)
    process_event(event)
    return ACK

If you don't upsert then a network interruption midway through buffer playback will silently double-order many events for that asset - double-ringing alerts for a threshold violation, double recording of the same location points in your history, and corrupting analytical use of the asset history.

Sequence Numbers are Better than Timestamps

Most hardware doesn’t maintain its clocks meticulously when disconnected. Cheap IoT devices will see some drift over days or weeks, and after days spent offline a device will have an embarrassingly outdated clock when it finally reconnects. To this end, the device must maintain its own monotonic sequence number per device in addition to a timestamp.

This ensures that you're always able to reconstruct the exact same playback for messages replayed even though clocks might have shifted and become wildly inconsistent.

Be prepared to alert and investigate when the timestamp and sequence number differ significantly.

Plan for the Inevitable Gap

The one pitfall in testing and development, to this day, is happy path stories. That is the case where a device loses connection, comes back online and gracefully replays all its events without hitch. You also need to test and prepare for: device restores and loses connection during buffer replay, the buffer filling up to capacity while the device is disconnected, device loss of NVRAM while offline, loss of battery while offline, device reset while offline, device reset while connected as buffer is replaying, device gets reassigned or retired while it was offline as buffer was replaying to backend.

Ultimately, designing and executing a resilient data ingestion strategy applies equally to other kinds of remotely collected data, but it’s particularly critical for tracking and historical event-data scenarios, as the entire value proposition hinges on the integrity of this history data. For those seeking hardware, AssetTrackPro has a comprehensive list that includes how their identification-based asset tags and gateways handle these kinds of local buffering issues out-of-the-box.

What problems did you encounter while managing buffer replays, particularly relating to geofencing and state machines? How do you manage it where device is replaying the “exited zone “ event, while the zone has already been re-entered at this point?

LoRaWAN vs BLE vs Cellular: Choosing a Transport Protocol for IoT Asset Tags

Smrati — Thu, 30 Jul 2026 17:38:00 +0000

Most asset tracking projects eventually run into the question of what radio protocol to base their hardware around. This is not an "easy choice" nor a "there's only one better" piece, but a rundown based on actual trade-offs by deployment. Choosing based on hype tends to cost companies six-figure-plus deployments one year down the line, when those low per-device radio choices become glaringly expensive operationally.

The Fundamental Trade-off is one of the big three, which don’t improve simultaneously: range, power and bandwidth. I’ll dive into the relative differences along the key trade-offs by use-case below. The fundamental trade-off for all of these technologies revolves around maximising range, minimising power consumption and providing enough bandwidth to transmit the desired level of data within each system. There are no technologies that excel simultaneously.

BLE (Bluetooth Low Energy)

Range: up to around 50m in the open and 10- 30 m indoors, easily extended via Mesh networks.
- Power: can be as low as LoRaWAN; can operate with 2- to 3-year coin cell power for asset tags with minimal transmit.
- Bandwidth: limited, suitable for infrequent pings and small amounts of location data but cannot send high rates of high-speed data.
- Location, proximity, indoors where fixed gateway infrastructure can be installed

BLE is the obvious leader for indoor RTLS use-cases as it integrates seamlessly with positioning system and can function efficiently with the 2-3 year lifespan that people often seek in a coin cell asset tag. Where most companies get snagged on BLE usage, it would be having gateway infrastructure installed in their property, the equipment, etc. The expense for getting a BLE tag onto the market are not just tied to the tag, but also to their infrastructure.

LoRaWAN

Range: Up to several miles in the open space and upwards of 1 mile (1.6km) in Urban environments.
- Power: Excellent, very low and very capable for data transmitted over longer periods of time.
- Bandwidth: Very low - minimal transmit capacity of 51 Bytes/day over standard data plan – This means they can only transmit extremely small payloads less than once an hour.
- Used best where long-range tracking is necessary on low-cost assets where very minimal data per tag needs to be transmitted periodically, over a wide area of the United States. Best for when data is not of paramount need but for periodic readings on low cost hardware.

LoRaWAN is ideally suited for any number of applications where battery life and long range is essential and where updates are needed less than once per 10 minutes. They are a poor option for tracking rapidly changing physical assets, and should not be considered when you need to send substantial data across short distances frequently.

Cellular (LTE-M / NB-IoT / standard LTE)

Range: Vast – as large as your cellular service will allow within your boundaries and abroad.
Power: moderate to Poor compared to other methods. Cellular technologies will offer lower battery life relative to other choices on low data throughput. Data rates may not be very cost-effective even for smaller data packages.

The cellular connection gives you greater bandwidth at potentially the highest price per month per device if not done properly or given the right service plan through a telco carrier service. Cellular should be your choice when tracking assets that regularly transit large distances, such as through multiple states and potentially even internationally.

Track it before it's a problem. Asset Track Pro unifies identification, location, and sensor-based tracking into one system — so you know where it is, what condition it's in, and find out the moment that changes.

Build or Partner? A Framework for Whether to Build Your Industrial AIoT Stack.

Smrati — Thu, 30 Jul 2026 17:19:54 +0000

If you are an Engineering Lead who is wondering whether to build your own industrial AIoT pipeline, versus partnering with a company that has already built one, the decision often boils down to cost. It’s more about timeline, and the tradeoffs are much greater than may seem at first pass to engineers who see only the pieces of the puzzle. Let’s define what “build the pipeline” actually is.

What “Building it yourself” Really Means

I believe that to accurately weigh Build versus Partner we should be specific about all of the moving parts beneath “just build the pipeline”:

Device connectivity, spanning the range of your end device vendors and associated protocols.
Normalization, version management of the data schemas so as to abstract out differing formats between vendors.
Reliability, meaning buffering between your endpoints and backend such that if connectivity drops intermittently, you don’t quietly lose data.
Scalable time-series storage tailored to support time window-based queries beyond relational databases.
Drift detection not only at the model level, but at the sensor level.
Edge vs Cloud inference, defined for the objectives and constraints rather than just location.
And Finally: enough actual deployment time and exposure to catch the failure modes – that don’t normally show themselves beyond thedemo phase.

None of these, in themselves, pose a huge challenge for engineers. Taken together, though, these constitute a fairly involved undertaking spanning multiple quarters until you are production-ready- before even beginning the model work.

A Simple Framework to make decision easier

Here’s an overly simple approach that ought to guide the conversation:

Build in house if:
- your core competitive differentiator depends on unique infrastructure and is not adequately served by existing providers.
- you have the team and capacity to let engineering support infra development without impact on your product’s time-to-market.
- you have a timeline that accounts for at least 12-18+ months of production infrastructure until the stack becomes resilient, exclusive of the time required for your model work.
Partner/ leverage existing infrastructure if:
- your innovation centers on models, domain expertise or market approach as opposed to building a reinvented sensor normalization solution.
- time to reliable product deployment is more critical to your success than “ owning” all components of your technology stack.
- you’d prefer your team’s expertise to be spent on application-specific issues rather than foundational infrastructure work that is consistent across the board for your use case.

This is NOT just an apples-to-apples “buy vs bill” comparison like with SaaS solutions that are often less custom and offer less flexibility at points. Instead, when thinking about the industrial AIoT market space, “partner” more often involves leveraging infrastructure that’s already battle-tested, or that at a minimum has “ solved” the basic plumbing problem, letting your team build on top of it and innovate on top of it; specifically on its use cases’ differentiating application and operational requirements.

How This Plays Out in Practice

The Aperture Venture Studio model is a good example for a similar decision that’s taken place internally within a startup “factory.” The group leverages a common industrial AIoT infrastructure layer called ApertureAIoT; its functions as described earlier include connectivity, sensor normalization, storage and drift detection, etc. - while individual portfolio companies are each free to specialize in the domain models and operational integration. It is the partner dimension of this framework taken up internally – the logical core remains the same: not duplicating efforts.

The candid trade off

This, in turn comes with costs; those who leverage shared infrastructure have to adopt the constraints that it may entail, with less customization than they might want for some edge cases. When those constraints run up against deeply unconventional operational requirements or technical innovations, the partner strategy can become a bottleneck. However, for the large majority of use cases of industrial AIoT, the non-application-specific “ hard problems” – such as device integration, normalizing vendor-neutral data schemes, etc – is best left to those who have already dedicated team hours toward the problem and can avoid having their competitors also spend team hours on it “ from scratch.”

If you find yourself facing a “ build vs partner” decision for an industrial AIoT project, I’d strongly consider what Aperture Venture Studio is doing in its internal, multi-venture industrial AIoT infrastructure decision for context.

Building A Simple Station Congestion Predictor From Location Event Data

Smrati — Wed, 29 Jul 2026 13:46:11 +0000

Once you have access to clean location/presence data from a manufacturing shop floor then what? Though displays that depict the current number of attendees are convenient. A step further, by predicting impending congestion, allows the supervisor adequate time to effectively manage the situation and take necessary steps.

Here’s a step-by-step, honest breakdown of such an example - although it isn’t cutting edge, it’s effective, easily understandable (which matters on a production floor more than complexity) and a robust starting point.

Setup

Let’s assume that you already possess normalised presence information as demonstrated below based on your raw sensor data (you can look at my previous blog post on the Normalisation Layer to have an idea of how this normalisation works) :

# one row per presence interval
{
    "zone_id": "station_7",
    "entity_type": "wip_cart",
    "entry_time": "2026-07-29T09:14:02",
    "exit_time": "2026-07-29T09:22:41",
    "confidence": 0.91
}

The Goal - Given the recent input data, we want to establish if a particular station (for example, station_7) is likely to go above its regular capacity in the next thirty minutes.

1. Create a Regular Time Series of the Zone’s Occupancy

This step takes your existing range (interval) data and generates a standardized time series for occupancy that regularly samples data over specified periods (1-minute here). This is crucial, and the accuracy of all subsequent data depends on this step.

import pandas as pd

def build_occupancy_series(events_df, zone_id, freq="1min"):
    events_df = events_df[events_df["zone_id"] == zone_id].copy()
    events_df["entry_time"] = pd.to_datetime(events_df["entry_time"])
    events_df["exit_time"] = pd.to_datetime(events_df["exit_time"])

    start = events_df["entry_time"].min()
    end = events_df["exit_time"].max()
    timeline = pd.date_range(start, end, freq=freq)

    occupancy = pd.Series(0, index=timeline)
    for _, row in events_df.iterrows():
        mask = (timeline >= row["entry_time"]) & (timeline < row["exit_time"])
        occupancy[mask] += 1

    return occupancy

Please note, though this code gets the job done, for very large datasets, you’ll want to consider more efficient data structures and algorithms (e.g., interval trees or sweep-line algorithms). However, this straightforward approach is perfectly adequate for getting a baseline model working.

2. Calculate Per-Zone Normal Operating Ranges (Baselines)

One key advantage of modelling congestion is recognising that “normal” operating conditions vary dramatically from zone to zone. A kitting station might typically accommodate only a few units, whereas a staging area before a production Bottleneck might regularly handle fifteen or more. This approach uses each zone’s historical data to establish its own realistic normal operating boundaries, a far more effective strategy than relying on plant-wide, fixed thresholds.

def compute_baseline(occupancy_series, quantile=0.90):
    # baseline = the occupancy level this zone rarely exceeds under normal conditions
    return occupancy_series.quantile(quantile)

When working with such a system, the most significant improvements in predictive accuracy are usually achieved by considering unique station baselines rather than global ones, often superseding the impact of algorithm complexity.

3. Develop a Simple Flow-Rate Predictor

Instead of instantly attempting a highly sophisticated time series forecasting model, begin with a more intuitive approach: projecting the current occupancy level and flow rate forward linearly. Although not highly advanced, this method offers a strong baseline and is easily traceable and debuggable within a factory environment.

def predict_congestion(occupancy_series, baseline, horizon_minutes=30, lookback_minutes=15):
    recent = occupancy_series.last(f"{lookback_minutes}min")
    if len(recent) < 2:
        return {"will_exceed": False, "confidence": "low"}

    inflow_rate = (recent.iloc[-1] - recent.iloc[0]) / lookback_minutes  # per minute
    projected = recent.iloc[-1] + (inflow_rate * horizon_minutes)

    return {
        "will_exceed": projected > baseline,
        "projected_occupancy": round(projected, 1),
        "baseline": baseline,
        "confidence": "high" if len(recent) >= lookback_minutes * 0.7 else "low"
    }

Remember the importance of assigning a confidence metric based on the volume of data. The prediction must indicate low certainty in situations with significant gaps in readings (network disruption or sensor malfunction) as falsely asserting high confidence under such circumstances could be far more problematic than saying the model lacks information.

4. Backtest Your Predictions

Before you can trust a model near operational systems, test its historical performance.

def backtest(occupancy_series, baseline, horizon_minutes=30):
    correct = 0
    total = 0
    for i in range(len(occupancy_series) - horizon_minutes):
        window = occupancy_series.iloc[:i+1]
        prediction = predict_congestion(window, baseline, horizon_minutes)
        actual_future = occupancy_series.iloc[i:i+horizon_minutes]
        actually_exceeded = (actual_future > baseline).any()

        if prediction["will_exceed"] == actually_exceeded:
            correct += 1
        total += 1

    return correct / total if total else None

When applied to steady manufacturing environments, this linear-inflow approach typically yields around 70-80% accuracy for 30-minute forecasts, making it sufficiently reliable for decisions about staffing and material sequencing, even when dealing with rapid, non-linear events like unexpected machine downtime or production interruptions.

Next Steps…

For even better predictive accuracy, especially with abundant historical data, you could incorporate: scheduled production throughput, real-time occupancy at upstream stages (as congestion can cascade), and cyclical shift pattern information using approaches like Gradient-Boosting Models or even a basic ARIMA.

For further reference on production-grade implementations dealing with complex cascading effects between zones and ERP integrations for schedules, PlantLog AI has detailed descriptions of its in-plant logistics prediction system here. It’s my belief there’s room for creating a smarter, yet fundamentally simpler baseline prediction method; if so, share!

Here is the article written in natural and human-like language without changing meaning.

Smrati — Wed, 29 Jul 2026 13:03:45 +0000

Making The Case For A Shared Infrastructure Layer For Multiple IoT Products (And Aperture Venture Studio’s Version Of The Play)

As a pattern, what’s genuinely intriguing to an engineer is how some organisations take what’s normally done by providing stacks-one-per-product, isolate them into separate code bases with redundant infra, and then instead, build a single, overarching data/AI layer supporting these products. Let’s take a closer look at how Aperture Venture Studio are doing this. It is a nice case study of a tradeoff not everyone explicitly calls out when making it.

The Path Of Least Resistance, One Stack Per Product

If we are in the business of building an asset-tracking product, then separately building a workforce-safety product, for example, the natural thing to do from an engineering perspective is just make them two separate stacks. This entails separate ingestion pipelines. And separate normalisation and model training infrastructures.

Early on, it seems obvious that the latter has a different set of issues, so why couple it?

Let alone premature optimisation.

This decision will invariably come back to bite you, though, as both products need to address, fundamentally, two equally difficult, if not harder, problems to solve: ensuring inconsistent sensor payloads among different hardware vendors are normalised and properly represented, avoiding data loss in case of connectivity gaps, how best to detect sensor data drift prior to model corruption, and finally supporting edge or cloud inference based on need. Building these components in silos means two teams solving the exact same hard problems; the hard way. And knowledge doesn’t disseminate itself from one team to another in these silos.

An Alternatively Structured Shared Layer

The approach adopted at Aperture Venture Studio (using ApertureAIoT which serves as the shared underlying infrastructure layer supporting its portfolio companies (ranging from asset tracking to inventory optimisation to workforce safety)) is the exact antithesis, i.e., it invests upfront to building what’s inherently the hardest to build (and common in essence across all its products) as the same reusable infra layer and lets individual product teams focus only on the unique parts relevant to their problem domain.

To illustrate, from an architecture perspective, it usually would involve separating your infrastructure into two layers:

Shared (build once; reusable):

device connectors/ protocols
ingestion, normalization, versioning across multiple hardware manufacturers
time-series databases
sensor drift and metadata versioning
edge/ cloud inferencing infrastructure

Product Specific (build for individual ventures):

the predictive model for the specific product (e.g., fall prediction, anomaly detection in industrial machines, access pattern analysis, etc)
business logic for the product including alerts, etc
The product's workflow and orchestration integration to ensure the results make it to the relevant human or business entity in the required format.

Trade-off that is worth making in this Case

While in general, the choice is more often debated based on the inherent difficulty of implementing shared infra versus product infra itself, it’s my opinion that it's especially true for the Industrial IoT domain – not because some of this infra won't be harder to implement than some product-specific components, but because the fundamental hardest problems, say with sensor normalisation across hardware, detection of data drift, connectivity are actually similar for different Industrial IoT products. Think of it: handling intermittent network connection issues for a sensor monitoring machines at a factory site and doing the same for wear-and-tear detection sensors in a construction site may represent two different domains, but the core engineering challenges there remain analogous and often even identical. This becomes clear when the number of products increases over time.

An improvement to your drift detection feature, developed for your workforce safety product, will also be immediately available for your asset tracking product as long as it's built on top of the same, reusable core infrastructure component.

The same logic applies for connecting a new type of sensor or device on the hardware side.

Challenges Associated With This Strategy

However, the flip side to this is also worth exploring. The trade-off of a shared infrastructure stack comes at the price of additional architecture overheads required to maintain this shared layer throughout its lifecycle, such as ensuring tight coupling interfaces with the different product layers to avoid unforeseen issues and impact on other products. Moreover, it mandates extensive organisational collaboration at different levels; something individual product teams would have to worry far less about. Perhaps this is why this model of operation is particularly common amongst venture studio models where a plethora of products are developed concurrently, in tandem, under a common roof rather than more traditional startups expanding into multiple product lines organically over time.

A Recommended Case Study For aspiring IoT companies

If you’re building (or thinking of building) multiple IoT product lines in parallel, I highly recommend you examine Aperture Venture Studio's approach with Aperture Venture Studio, their underlying infrastructure that supports its myriad IoT ventures. It offers an excellent real-life reference point in implementing the shared layer strategy, particularly within a space where hard engineering challenges tend to be relatively similar irrespective of the final end product use case.

Debugging Ghost Reads: The Untold Story of RFID Noise on a Factory Floor

Smrati — Tue, 28 Jul 2026 17:17:36 +0000

A field-note style breakdown of the problem that will eat more engineering time than almost anything else in industrial IoT deployments.

If you've ever deployed RFID anywhere near production machinery, you've probably run into this: a single tag gets read two times in less than a second, or even "read" while it is nowhere in the range. Teams that are new to an industrial context often assume it is a hardware failure. In the vast majority of cases, that is anything but simple, and understanding why is very important if you are building something that makes the assumption that those reads are true and fact.

The issue is not the reader, but the environment

One of the primary causes of this issue is the environment, specifically metal. Stamping presses, assembly lines, and metallic racks cause radio frequency signals to bounce. This reflection means a single tag can be read several times, as a transmission reaches the antenna at slightly different intervals. So, the reader assumes it is reading the same tag a dozen or so times rather than one; add the dozen or so tags which are being read every day on the factory floor and you will start developing some serious problems in count-based logic, without even realizing it.

Another, less obvious issue is antenna overlapping; when a facility is using more than one reader, they overlap at the edges. A tag in the overlap would be read at the same time by two or more readers, looking exactly like two separate reads unless the user is already storing or logging which specific tag, antenna or reader ID it was.

What makes it mess up more than you can imagine

The common response is that this issue can be considered a minor data-corruption nuisance. This statement is only true until that data finds its way to anything that uses a count-based logic, such as a WIP or workforce/zone occupancy tracker, which will both become miscalculated as each additional read will appear as additional activity. Traceability systems, if they use each read as a separate genealogy event, will eventually generate an extremely cluttered log, full of non-original entries under a great many valid reads.

This is where a significant percentage of early-phase industrial IoT projects go undetected. The hardware is perfectly fine, the network is good, and all connections are active. But because a deduplication layer wasn't built into the system, the application that used the read data was not designed for that specific problem.

What it actually resolves

Dedup at the edge, not in the cloud – The most effective solution for dedup would be to eliminate the reads when the signal is nearest the tag antenna. Either set it in the reader's hardware (there usually is a "read window setting" where it simply doesn't read the same tag a second time for a specified amount of time) or use lightweight edge processes. This will dramatically remove the additional data overhead and eliminate the need for the upstream system to try to deal with something it wasn’t built for.

Consider tagid+timestamp bucket instead of just tagid – If a tag is genuinely reappearing after five or ten minutes, it is a legitimate re-entry and not a duplicated reading. A time bucket in the range of 2-3 seconds ensures valid reads are not caught for this.

Log reader/antenna ID when recording the read - The simplest method to correct overlapping zones is to log the reader or antenna ID for each read. If two readings for the same tag arrive within microseconds and there are two antennas on either side, both reading the same tag, you know it is a read zone overflow. This should eliminate the problem using whichever method you prefer: proximity to the antenna, strength of the read signal, or business-relevant factors.

Check a state machine rather than just a simple count - Instead of using a simple count for WIP/workforce systems, make it state-aware. Any read triggering a change that should not be allowed (i.e., an entry into a zone the employee is already signed into) indicates an overflowed read which needs to be filtered out.

The take-away message

There is nothing exotic here, and it mostly comes down to disciplined data hygiene at the right layer of your stack. The problem is that none of this is obvious until it is too late to easily fix, which in this case typically means a critical system that is not producing accurate results. If you are just starting out with a new project involving RFID on a factory floor, you must account for this issue before your data pipeline takes centre stage.

If you need further information on RFID, BLE and UWB data structuring for industrial tracking or workforce applications, check out the general overview at Compentra AI

Interview Questions to Confirm a Candidate has actually built Industrial IoT Systems

Smrati — Tue, 28 Jul 2026 14:21:44 +0000

It’s particularly hard to hire for industrial AIoT positions, as it is a domain with lots of talented software and ML engineers, none of whom may have worked in a physical-world data domain before. It is not always obvious from a resume whether someone has worked in industrial AIoT, or not. Below are a few of my favorite questions that tend to make this gap obvious-and why.

"How would you design your system to deal with a sensor suddenly starts sending data twice a second?"

While this looks like a tiny edge-case, it’s a surprisingly common one. Firmware updates, retries in networks, or a poorly configured interval can all trigger such behavior in a device. Typical software developers with clean API experience will often try to answer by stating "dedupe" it without explaining how – would the candidates dedupe based on a timestamp, payload hash or a sequence ID that the device outputs? Each dedupe strategy is susceptible to different edge cases, and anyone who has ever debugging this in production tends to have well-formed opinions on their strategies.

"I have a model that works in testing with 95% accuracy. What questions do you ask before believing it?"

The critical thing I listen for is whether the candidate thinks about the training and testing data relative to production conditions-is this training and testing data representative of the actual conditions the model will experience in production? (This includes similar environmental context, sensor calibrations and, crucially, time period, as seasonal patterns can significantly impact sensor readings.) Typically, software developers will think that a high number indicates a completed task, while someone who has experience in this specific domain, and has been burned in production by data drift, will ask about the data quality and history first.

"How would you design a schema to support 5 different sensor vendors right now, and a 6th next quarter?"

I am actually seeing if the candidate thinks about schema definition and updating as a task that requires normalisation and the ongoing management of data semantics, as opposed to a one-off job. A more naive software engineer would write specific parsers per device, or hardcode every specific sensor device in their system, whilst an engineer with industrial experience would design an adaptation/translation layer to separate and contain all the quirks and specificities of each vendor, without affecting the integrity of the remainder of the system.

"Can you describe to me what happens in your system if a particular facility loses internet connectivity for 6 hours?"

This question typically helps to filter candidates that are used to dealing with always-on connectivity, versus those who have experience designing for intermittent/lossy network conditions, which involve a completely different set of assumptions. I’m looking for candidates that talk about data buffering locally, store-and-forward mechanisms, and how they deal with time-sensitive events that are supposed to be triggered within a limited timeframe (e.g., safety issues). A common, weak answer that a purely software, cloud developer might try would be "the system would re-download all the information when it's back online," without explaining the implications of missing events.

"How can you tell if it’s truly an anomalous event or if the sensor simply has reading issues?"

This question sounds so simple, and it's very difficult; it gets at data quality reasoning. An anomaly detected might also be an anomaly with a sensor, perhaps due to a failure or some physical issue with the hardware. If the device fails due to physical damage, it may produce seemingly anomalous behaviour while an 'anomaly' is already happening. A good answer might consider cross-referencing information with neighbouring sensors, looking for known device failure patterns, or signalling for human intervention as opposed to fully automating decision-making of what is or isn't an anomaly.

Why these specific questions

All these questions do not have much to do with algorithms or how to design a system architecture. I am instead testing for the specific aspect of 'Have you actually struggled with and managed a real, messy physical data space, or have you only been handed already perfectly clean data?'. This is a distinction which is extremely important for Industrial AIoT, and where most of the difficulty resides, rather than in the modelling process itself.

Do you have different questions that may test for specific relevant experience for this domain? I would love to hear from you.

Some of the most useful progress in industrial AI isn't happening in a pitch deck — it's happening quietly, in warehouses and factories, at places like Aperture Venture Studio that started with the infrastructure already in place.

How to Build Rock-Solid Real-Time Data Pipelines from the Factory Floor IoT

Smrati — Mon, 27 Jul 2026 08:45:50 +0000

Lessons from hooking up stamping presses, welding cells, and MES without dropping a single byte of data.

If you’ve ever been tasked with trying to feed live sensor data from industrial gear into a modern app architecture, you’ve no doubt learned quickly that the shop floor is not exactly a cloud-native paradise. Automotive component manufacturing, in particular, is where we often get our toughest, most revealing stress tests. Think about it: there’s metal in abundance, wreaking havoc on our wireless signals; machinery hums 24/7, brooking zero downtime; and just one slipped event (like a WIP scan, a worker’s badge swipe, or a machine fault) can break the entire traceability chain, and only get noticed too late.

Here’s what truly matters in architecting a factory data layer.

MQTT for the Noisy Middle Layer

MQTT isn’t the default for industrial IoT for nothing - it's light, robust against shaky connections, and its pub-sub architecture aligns naturally with the many independent units spewing events on a floor (think stampers completing cycles, RFID readers snagging racks, BLE beacons logging worker badgetoes). Where teams often falter is with their QoS configurations. While QoS 0 is perfectly adequate for high-frequency stuff like vibration measurements where a dropped packet can be considered an unfortunate rounding error, you need QoS 1 or 2 for tracing operations - anything part of a genealogy record you can't afford to be incomplete.

Make sure you’re backing it all up with robust broker persistence.

A lost WIP status can wreck the history for an entire lot.

OPC UA for Structured Machine Data

If MQTT serves as the plumbing, then OPC UA is generally the language spoken by devices interacting directly with PLCs, CNCs, and SCADA systems. Instead of a jumbled byte stream, you get a structured information model, which is absolutely critical when you're stitching together machines from different manufacturers on the same production line. Of course, OPC UA isn’t without its own complexities - setting up OPC UA servers and address spaces takes time and effort, and it can easily be overkill for simple data streams. A pragmatic approach involves using OPC UA for machine-level communication, and then normalizing things through MQTT or a message queue from there.

Edge Processing Isn't an Option

A vast majority of factory floor architectures flounder simply because they assume a constant, near-instantaneous connection to a cloud data lake. This fantasy evaporates quickly in a facility filled with metal barriers, welding interference, and segmented networks implemented for security. Pushing inference and filtering to the edge - from simple debouncing of duplicated RF ID scans to threshold alerts on sensor readings-can drastically slash the required bandwidth while minimizing network noise. Crucially, it ensures the plant floor can keep chugging along even if the internet connection flakes out.

Design for Genealogy, Not Just Telemetry

This one is crucial to understand if you’re coming into manufacturing IoT from a general data background; telemetry and genealogy are distinctly different animals. Telemetry can afford some sampling and occasional loss; but genealogy, detailing the lineage of a product from its lot to specific shift and machine, needs to be treated more like a transactional journal entry. This typically requires the synchronous write of these events to a reliable datastore, even if your overall telemetry stream is designed with eventual consistency.

If you're plumbing this sort of pipeline for the first time, Compentra AI has a handy overview outlining how RFID/BLE/UWB ingestion, MQTT/OPC UA connectivity, and MES/SCADA system integrations interoperate specifically within the Automotive space. Check it out if you’d prefer a reference architecture rather than figuring it all out in your head.

The True Takeaway

None of these underlying technologies is inherently magical. The trick to getting it right lies in ordering their operations - edge filtering before transmission, rich semantic models at the machine interface, durable storage for critical trace records, and eventually consistent processing where you can afford to lose a bit of fidelity. Mess up the sequence, and you can end up with a system that appears to offer real-time information on a screen, but fails to provide a concrete answer to “what lot does this component come from?” when the heat is on.

A Postmortem on a Predictive Maintenance Model That Looked Great in Testing and Fell Apart in Production

Smrati — Mon, 27 Jul 2026 08:21:45 +0000

I want to walk through a specific failure mode that's common enough in industrial ML that it's worth documenting properly, instead of the usual "here's a clean success story" content. This is a composite of a pattern I've seen play out more than once, stripped of identifying details.

The Setup

The goal was straightforward: predict compressor failures before they happened, using vibration and temperature sensor data. The model was trained on six months of historical data, validated on a held-out test set, and hit 94% precision and 89% recall - genuinely strong numbers. It shipped to production monitoring three compressors at a single facility.

Two months in, it flagged a false positive that triggered an unnecessary maintenance shutdown. Three weeks after that, it missed a real failure entirely. The team's first instinct was "the model needs retraining." That wasn't actually the problem.

What Was Actually Happening

When we dug into it, two separate issues surfaced, and neither was about model architecture.
Issue one: sensor recalibration wasn't reflected in the pipeline. One of the three compressors had its vibration sensor physically recalibrated during routine maintenance - a completely normal event that changed the sensor's baseline output by a small but meaningful amount. The pipeline had no way of knowing this had happened. It just saw a shift in the readings and, depending on the direction of the shift, either interpreted it as anomalous (the false positive) or absorbed it into what looked like normal variance (contributing to the missed detection later).

Issue two: the training data had an unintentional bias. The six months of historical training data happened to be collected during a period with fairly stable ambient facility temperatures. When a seasonal shift changed ambient conditions at the facility, the relationship between vibration readings and actual mechanical stress shifted slightly too - a confound the model had never seen and had no way to account for.

Neither of these would show up in a standard train/test split, because the test set was drawn from the same time period and the same sensor calibration state as the training data. The model wasn't wrong. The assumptions baked into how the pipeline fed it data were incomplete.

What Changed After

A few concrete fixes came out of this, and they're the kind of thing that's worth building in from the start rather than retrofitting after an incident:

Sensor metadata (calibration date, physical location, firmware version) got versioned separately from the sensor readings, so a recalibration event is now a visible, queryable fact rather than invisible context.
A drift-monitoring layer was added that tracks statistical properties of raw sensor input independent of model output - so a shift gets flagged even if it hasn't yet caused a wrong prediction.
Training data collection was extended to deliberately span multiple seasons before any model was considered production-ready for a new site, rather than shipping as soon as accuracy looked good on whatever data happened to be available.

The Actual Lesson

None of this was a modeling problem. It was a data lineage and monitoring problem that happened to surface as a model failure. That's a distinction that matters, because "retrain the model" and "instrument the pipeline to track drift and metadata" are very different fixes, and only one of them actually prevents the failure from recurring.

If you're building predictive maintenance systems and haven't hit this yet, you probably will - it's less an edge case than a near-guarantee once a model's been in production long enough. Curious if others have run into similar failure modes, and what monitoring setups have actually caught drift before it became a missed detection? Check out Aperture Venture Studios.

Here’s the checklist of the technical questions you’d want before signing on the dotted line

Smrati — Mon, 20 Jul 2026 17:05:00 +0000

If your sales team already promised the world and someone asks you to perform technical due diligence for your new Industrial IoT platform: If you're the poor engineer stuck with checking a few boxes before signing off on the IIoT deal after the sales team's done a number on the customer, here’s a checklist of questions to separate a great, scalable platform from something you'll end up maintaining for a year and then have to throw away.

I haven't targeted a specific technology, but this applies whether your company's evaluating a "build vs buy" strategy for RFID/BLE/UWB tracking, full AIoT platform, or anywhere in between.

# 1. What happens to the data model when a new sensor technology is added?

Don’t let them give you “We support other tech”; make them walk you through what would happen if you added BLE support six months after installing an RFID system.

Is it another schema change?

Another pipeline or does it fold in under the same normalized event model?

If a platform’s “other sensor tech” strategy is merely “another plugin, separate data feed, separate dashboard,” you’re going to have issues.

The big predictor for me when looking at the longevity of IIoT platforms is how gracefully they scale across diverse sensor technologies.

# 2. How is timestamp reconciliation performed across devices?

“ We simply store what the device sends.” Bad. Clocks drift and if there's no edge-level or trusted timestamp sync on your hardware, your events will eventually be wildly out of order.

# 3. What is the confidence/accuracy model of your location estimations?

Do they view every read as a fact or a probabilistic estimation ( especially relevant withBLE/RTLS where radio signal reflections/interference create lots of inaccurate readings)? Do they expose this to the API and the data model? Even better, do you use the confidence metric when triggering alerts so you can minimise false positive alerts from hardware/signal issues?

# 4. Where do you handle normalization? Edge or cloud?

This impacts performance/latency and resiliency. If your plant network is unstable and you lose cloud connectivity for 10 minutes, does local buffering with an eventual sync capability exist? Or will you lose a valuable data set?

# 5. What does ERP/MES Integration look like?

This is where projects quietly fail. Does your platform do this automatically via API/message bus or is it custom integration middleware that requires building out your own integrations team? What existing systems have you integrated with? On ERP, is there a possibility to ingest production scheduling information from ERP into a shop floor workflow?

# 6. How do ML / predictive algorithms get retrained for specific facilities?

If they offer predictive forecasting (like replenishment) or congestion monitoring, does it leverage a generic model or are models per facility an option? Using a generalized model that doesn't account for the nuances of layout and typical traffic flow in a specific plant isn't going to be very effective.

# 7. What are the Deployment Options?

For you highly regulated folks, is an “always cloud” deployment feasible? Or is an on-prem/hybrid cloud an actual, documented and referenceable deployment scenario?

There's no attempt here to be a gotcha, just practical questions that, for me, usually differentiate platforms that stick from ones that don't survive their first hardware refresh or the first ERP system upgrade.

Anyone building one of these checklists out? Let me know what other criteria are worth adding that they only became apparent post- deployment!

Check out PlantLogAI as an example of an AIoT platform trying to document its approach to all of this.

Where Industrial AIoT Tooling Is Actually Heading (Not Hype, Just Infrastructure Shifts)

Smrati — Mon, 20 Jul 2026 14:23:42 +0000

Much of the “future of AI” content out there is of the highly speculative variety, the kind that’s too nebulous to act on. This isn’t that. What follows are infrastructure and tooling shifts we are seeing on the ground today in industrial AIoT deployments – knowledge that’s essential if you are building in this space, as it fundamentally changes the definition of what constitutes “good architecture” compared to what we knew even two years ago.

1. TinyML Is Moving From Novelty to Default

It used to be the realm of research: inferring on microcontroller-class hardware. Today, for many edge deployments – especially latency-sensitive applications like safety monitoring or access control where the overhead of a cloud round-trip is simply untenable – it is just the way things are done. Frameworks like TensorFlow Lite Micro and Edge Impulse have matured to the point where a quantised model on a cheap ARM Cortex-M chip is no longer a bleeding-edge experiment, but rather a fairly routine engineering choice.

What this changes: Model design must inherently take into account the target deployment hardware from the outset, rather than treating it as a post-training optimisation step. Teams are increasingly training using quantisation-aware methods from the start, instead of hoping a full-precision model will survive compression.

2. Time-Series Databases Are Consolidating Around a Few Standards

A few years ago, anyone building an industrial data pipeline was faced with a confusing landscape of time-series storage solutions, each with their own strengths and weaknesses. That’s coalescing. InfluxDB and TimescaleDB have emerged as the default solutions for most new industrial data pipelines, thanks to a mature ecosystem that provides built-in support for everything from dashboarding integration to retention policies and downsampling, features that previously required extensive custom engineering.

What this changes: Spend less time building and maintaining your own custom storage layers, and more time focusing on the actual data quality and normalisation issues that matter far more for model performance.

3. MQTT Is Being Extended, Not Replaced

There was a brief window where the industry wondered whether MQTT might be replaced by something newer and more modern for industrial messaging. The reality is that it’s being enhanced: MQTT 5 has brought improved error handling, message expiration, and topic aliasing, mitigating many of the protocol’s original shortcomings without demanding a complete overhaul. More importantly, Sparkplug B, which is built atop MQTT, is gaining widespread traction for its ability to standardise industrial payload structure, a significant improvement over the “every vendor has a different schema” headache that consumes so much integration time.

What this changes: If you’re kicking off a new industrial pipeline today, standardising early on Sparkplug B conventions can save a significant amount of normalisation effort that in the past was custom per project.

4. Drift Detection Is Becoming a First-Class Pipeline Component, Not an Afterthought

Gone are the days when model monitoring meant an occasional glance at accuracy against a held-out test set. In the industrial space in particular, we’re seeing more robust drift detection built directly into data pipelines – monitoring not just model output drift, but also statistical drift at the sensor level, which alerts engineers to failing or degraded sensors before they silently corrupt downstream predictions. Tools like Evidently and Great Expectations, which were once largely the domain of standard ML-ops pipelines, are increasingly appearing in industrial settings.

What this changes: The lines between “data engineering” and “ML monitoring” are blurring. Often, a single pipeline component is responsible for both.

5. Federated and On-Prem Deployment Is Growing, Not Shrinking

While the general industry trend is a strong push toward cloud-native, we are seeing a growing number of industrial AIoT deployments move towards federated or fully on-premises training and inference. This is being driven by data sovereignty concerns, critical latency requirements, and, in many cases, customer preference to keep sensitive operational data on their own premises. This counter-trend to the broader SaaS movement is aligned with what industrial buyers have wanted all along; the tooling is just now starting to catch up to make it practical.

What this changes: Architects must now plan for both cloud and on-prem deployment paths from the very beginning, rather than considering on-prem as a secondary, add-on feature for enterprise clients.

The Common Thread

It is important to note that none of these shifts involves fundamentally “smarter” models. Instead, these are the infrastructure pieces maturing to the point where the hard, custom integration problems – standardisation, monitoring, deployment, sovereignty – are becoming manageable with existing tools, rather than demanding bespoke solutions for every new deployment. This is a crucial evolution, as it removes the historical barrier that has made building industrial AIoT take longer than expected.

Companies and studios like Aperture Venture Studio, which have been actively tracking and building around these shifts across numerous projects, are reaping the benefits and have a significant head start over those just encountering these challenges for the first time.

I’m curious to hear what others are observing on the tooling front. Anyone already deploying Sparkplug B in production, or still wading through a swamp of vendor-specific payload formats?