As we like to say, “There’s no IoT without the T.” Devices are the foundation of every IoT system, which is why so many companies (including Rebels Software) focus on hardware design. The same applies to the “I” - the Internet with its protocols, cloud platforms, and dashboards.

But all of this is just a means to an end. Infrastructure, messaging, and storage exist to serve a higher purpose: answering real questions and solving real problems. And no matter which part of reality you work with, it usually comes down to one core challenge - correlating events over time.

Real-world examples of time being a core problem

At first glance you probably raised your eyebrows but stick with me and look on below examples.

Food industry

Tempering is a controlled heating and cooling process in chocolate production that ensures shine, snap, and resistance to blooming by maintaining precise temperature ranges over time..

To answer this question, we must correlate the chocolate batch with time intervals spent within those temperature ranges.

Energy

Battery health depends not just on voltage or current, but on how these values change over time - conditions safe in the short term can become damaging if prolonged.

To answer this, we correlate charge, current, electrolyte level, and temperature over time, then compare the result with the manufacturer’s recommended charging curve.

Logistics

Perishable goods can tolerate short temperature deviations, but extended exposure outside defined thresholds may cause irreversible damage.

To answer this question, we must correlate location, temperature, and duration of excursions over time, not just verify whether limits were crossed at any single point.

Healthcare

Medical devices may tolerate brief deviations, but prolonged or repeated ones can affect therapy effectiveness or patient safety. To assess this, we correlate device telemetry and operating modes over time to verify the intended therapy profile.

The pattern is consistent: anchors (key events), candidates (related signals), and the temporal relationships between them.

Can this problem be distilled?

Subdomain of your domain - open sourced

We’ve spent years building IoT systems across industries and repeatedly ran into the same challenge: correlating data over time. It always felt domain-specific until an “aha moment” during performance work led us to extract the core idea into an open library.

The result is Rebels.Temporal, a C# library built on a clear philosophy:

Zero allocations in hot paths. IoT scale requires predictable performance - core matching algorithms allocate nothing, keeping memory fully under your control.

Mathematically sound foundations. We don't invent ad-hoc rules for how intervals relate. We use Allen's Interval Algebra the standard formalism for temporal reasoning. We represent it as TemporalRelation. Thirteen relations, covering every possible way two-time intervals can relate. You can filter which one you want to receive. No surprises.

Pure domain logic. No dependencies beyond .NET's base class library. No opinions about your message broker, database, or cloud provider. No lock-in.

What the library is not: a platform, a framework, or a database. It's a tool which fits in your application lay

How to use it

Not all correlations are equal. Events may be instantaneous or span time, sometimes on one side, sometimes on both. The library supports all three cases, and choosing the right one matters.

Point to Point

When to use it:

• Correlating commands with acknowledgments. You send "open valve" at 14:00:01 and want to find the "valve opened" confirmation within 2 seconds.
• Matching sensor readings across devices. Temperature sensor A reports at 14:00:00.123, humidity sensor B at 14:00:00.156. Are they close enough to be considered simultaneous?
• Joining log entries from distributed services. Request entered service A at time T, when did it hit service B?

Point to Interval

‍

When to use it:‍

• Did this sensor reading occur during a production batch? A point at 14:32:17 against batch #4471 from 14:00 to 15:30.
• Did an alarm fire during maintenance, or was it a real incident?
• Which shift was active when an error occurred? Shifts are intervals, the error is a point.

Direction matters: The library supports both directions. Point.With.Intervals treats points as anchors - "for each reading, find which batch it belongs to." Intervals.With.Points treats intervals as anchors - "for each batch, find all readings that occurred during it."

Same data, different questions.

Interval to Interval

‍

Two intervals can relate in exactly 13 ways. Not 12, not 14. Allen proved this in 1983, and it's been the foundation of temporal reasoning ever since.

When to use it:

• Process validation. Heating must finish before cooling starts. Any overlap signals a problem.
• Compliance checking. Calibration must cover the entire production run.
• Shift handover analysis. Did one shift end exactly when the next began, or was there a gap?
• Filtering relations. You usually care about a specific question, not all 13 relations, such as whether A happened before B or contained it.

The 13 Allen’s relations split into groups:

Each match result tells you exactly which relation was found. No guessing.

Tolerance

Real-world timestamps are imperfect. Drift, latency, and sampling differences mean “simultaneous” events rarely align exactly.

TimeTolerance addresses this by widening the matching window with two bounds: Before and After.

Three factory methods cover common cases:

Tolerance on points

Configuring time tolerance for one collection turns the operation into Interval-to-Point or Point-to-Interval, depending on the setting. When both tolerances are applied, the result follows Allen’s algebra, with both collections treated as intervals.

Tolerance on intervals

The rules are simple:

• Before subtracts from Start (interval begins earlier).
• After adds to End (interval ends later).
• ForwardOnly only extends the end.
• BackwardOnly only extends the start.‍
• Symmetric extends both directions.

Adaptability

Four things to notice:

1. Your types, your data. Implement ITemporalPoint or ITemporalInterval. The library works with your existing domain model.
2. Performance is explicit. InputOrdering defines expectations. Sorted data enables O(n+m) matching, up to 250× faster. Ordering is validated at runtime.
3. You own the buffer. No hidden allocations or GC surprises. Stack, pool, or custom strategy - your choice.
4. Flexibility. You can implement your own visitor via IMatchVisitor.

When to use it

The library is a building block, not an application. Here's where it fits.

Batch processing

You have a database of sensor readings and production records and periodically need to correlate them to identify batches, excursions, or anomalies.

This is the classic use case: pull data, sort by timestamp (or use InputOrdering.None), run the matching, and store the results. Thanks to zero allocations, you can process millions of records without GC pressure.

Ingestion pipeline step

Data flows continuously and often needs enrichment before storage, such as adding context or flagging anomalies.

The library fits naturally into this pipeline: readings are matched against active batches and enriched data flows downstream. Low latency and predictable allocations keep p99 stable.

Alerting and anomaly detection

Some alerts need temporal context. A threshold alone is not enough, combining phases and durations changes the meaning.

The library provides the primitives to express these conditions, handling temporal correlation while you define what counts as anomalous.

Post-incident forensics

Something went wrong and you need to understand why.

Pull the relevant time range, correlate events across sources, and build a timeline. The library helps answer what else was happening when X occurred, without writing one off correlation code each time.

Where it doesn't fit

The library operates on in memory collections. It is not a streaming engine and does not maintain windows across infinite streams. It is not a database and does not persist or index data.

For continuous streaming correlation, use tools like Kafka Streams or Azure Stream Analytics for windowing, and call into Rebels.Temporal for complex matching within each window. For historical correlations, rely on batch jobs or stored results.

The library is the correlation logic. The surrounding plumbing is yours to choose.

Why Open Source?

IoT solutions require trust. They run factories, manage fleets, and monitor health, so the stakes are real.

Open sourcing Rebels.Temporal is a deliberate choice:

• Transparency builds confidence. You can inspect every line of the matching algorithms, understand `TimeTolerance.Symmetric(TimeSpan.FromSeconds(2))`, and verify the Allen relations yourself. No black boxes.
• No vendor lock in on fundamentals. Core temporal correlation logic should not depend on proprietary services. Take the library, fork it if needed. It is Apache 2.0 licensed.
• Community makes it better. New edge cases, performance improvements, and boundary pushing use cases emerge through open source. Some ideas are already planned and tracked in ADR-14.

It is our resume. We believe in showing, not telling, and we plan to show more.

Our business is helping teams build what sits above this layer: domain expertise, architecture, and integration specific to your industry.

Your move

Whether you are building new systems or modernizing legacy ones, temporal correlation sits at the center of your architecture. It answers what happened together and in what order.

Get it wrong and you will debug timing issues instead of delivering value. Get it right and you gain a foundation you can build on with confidence.

We have open sourced ours. Take it. Use it. Challenge it.

And when you are ready for what comes next, we're here.

‍