🛠 How-to guide
How Banalytics works
for AI Data Teams
Banalytics is the complete edge layer for AI data collection. It connects to your field devices, triggers and buffers data captures, tags every sample with event context, stores data locally, and exports structured packages to your training pipeline — all from a single system you can monitor remotely. Your model lives in the cloud or lab. Banalytics handles everything at the source.
// The trigger moment
The model is good. The data pipeline isn't.
AI teams reach a scaling point where the model architecture is solid and the lab results are promising — but improving the model further requires more real-world data, collected reliably, repeatedly, and with enough context to be useful for training. Manual collection workflows, fragile custom scripts, and separate tools for acquisition, storage, and export can no longer keep up. Every new deployment becomes a custom engineering project. Data quality is inconsistent. Nobody can see whether the collection systems are healthy.
Repeatable collection
Manual field collection and one-off scripts do not scale. The pipeline needs to run unattended, reliably, across multiple devices and locations.
Synchronised context
A video frame without a timestamp, trigger event, and sensor context is hard to label and hard to use. All streams must be captured and tagged together.
Selective, not blind
Constant blind recording generates too much data to process. Capture needs to be triggered by events — anomalies, conditions, or thresholds — not by a timer.
Collection health
Without remote visibility, teams discover collection failures only when they check the export — hours or days after the data was lost.
// System architecture
Banalytics is the full edge collection layer
Unlike the industrial sensing scenario where Banalytics flanks an independent processing module, in the AI data collection scenario Banalytics is the complete pipeline at the edge. It acquires data from devices, applies event-driven capture logic, tags every sample with context metadata, stores raw data locally, and exports structured packages upward to your training stack. Your model and training infrastructure remain entirely independent.
L1
Layer 1 — Field devices
Cameras, sensors, and edge hardware generating raw data at the collection site
The devices that generate the data your model needs. Typical configurations include IP and ONVIF cameras for video and image data, USB cameras or built-in sensors on embedded hardware, auxiliary sensors such as temperature, vibration, or proximity connected via MQTT or Modbus, and robotic or industrial equipment producing telemetry. Devices may be co-located on a single PC or distributed across a site.
↓ Banalytics connects to all devices via ONVIF, RTSP, MQTT, Modbus, USB, and vendor SDKs
L2
Layer 2 — Banalytics acquisition
Device connectivity, stream capture, and local buffering
Banalytics connects to all field devices and maintains live streams. It handles device health monitoring, automatic reconnection on failure, stream synchronisation across multiple sources, and buffering to absorb momentary throughput spikes. Video streams, sensor readings, and telemetry are all captured in parallel. Banalytics stores raw data locally — on the same machine or a connected NAS — ensuring no sample is lost even when the upstream network is unavailable.
↓ Banalytics applies event logic — deciding what to capture, when, and with what context
L3
Layer 3 — Banalytics event engine and data tagging
Selective capture, context enrichment, and sample assembly
Banalytics evaluates configurable event rules against incoming data streams. When a condition is met — a sensor threshold crossed, a motion event detected, an external trigger received via MQTT — it initiates a capture window, collects the relevant video frames or sensor readings from all configured streams, and assembles a tagged sample. Each sample carries: a precise timestamp, the triggering event type and source, synchronised readings from all active sensors, device health state at the time of capture, and any user-defined metadata tags. This context travels with the data all the way to the training pipeline.
↓ Banalytics stores tagged samples locally and prepares structured export packages
L4
Layer 4 — Banalytics orchestration and export
Collection health, dashboards, remote access, and structured data publishing
Banalytics maintains full operational visibility over the collection environment. Browser-based dashboards show live device health, capture rates, event history, and storage usage across every node — accessible from any browser via console.banalytics.live without VPN or port forwarding. When samples are ready for export, Banalytics publishes them to the training pipeline via MQTT, REST API, or file-based notification carrying the file path, timestamp, data format, and metadata. Only structured packages and selected samples leave the edge. The full raw data archive remains local.
↓ structured sample packages exported → training pipeline receives tagged, synchronised data
L5
Layer 5 — AI training infrastructure
Training pipelines, data lakes, annotation tools, and model registries — all independent
Your training stack receives structured sample packages from Banalytics and processes them with its own tooling. This may include a cloud data lake or object storage, an annotation or labelling platform, an experiment tracking system, a model training cluster, and a model registry or deployment pipeline. Banalytics has no dependency on any specific ML framework, cloud provider, or training infrastructure. It publishes to a defined interface and your stack consumes from it.
Key difference from industrial sensing: In the AI data collection scenario there is no independent processing module at L3. Banalytics IS the complete edge pipeline — acquisition, event logic, tagging, storage, and export. The model intelligence lives entirely in your training stack at L5, not at the edge.
// What gets collected
Selective capture, not blind recording
Constant recording of every stream generates volumes that are expensive to store, slow to transfer, and difficult to label. Banalytics applies event-driven capture logic so that only meaningful samples reach the training pipeline — with all the context needed to make them useful.
C1
Trigger — condition detected
Event rules define what constitutes a collection-worthy moment
A trigger can originate from any connected device or from an external source. Examples include a sensor reading crossing a configured threshold, a motion detection event from a camera task, an MQTT message from external infrastructure, a scheduled time window, or a manual trigger from the operator dashboard. Multiple trigger conditions can be combined with logical rules: "when sensor A exceeds threshold AND camera B sees motion, open a capture window."
↓ capture window opens across all configured streams simultaneously
C2
Capture — synchronised multimodal window
Video, sensor readings, and telemetry captured together with a shared timestamp
When a capture window opens, Banalytics collects data from all configured streams within the window duration. Video frames are captured at the configured resolution and frame rate. Sensor readings are timestamped and aligned to the same reference clock. Telemetry and MQTT payloads received within the window are included. Pre-trigger buffering allows Banalytics to include frames from before the trigger event — ensuring the onset of the condition is captured, not just its peak.
↓ sample assembled with trigger event and synchronised data from all streams
C3
Tag — context enrichment
Every sample carries the metadata your labelling pipeline needs
Each assembled sample is tagged automatically before it is written to local storage. Tags include: a precise UTC timestamp and duration, the triggering event type and the source device, device health state at capture time (connection status, signal quality, storage state), user-defined category labels or location identifiers configured on the collection node, and any MQTT payload attached to the trigger. This metadata travels with the sample through export, eliminating manual tagging work in the labelling pipeline.
↓ tagged sample written to local storage, export queue updated
C4
Export — structured package delivered to training pipeline
MQTT notification, file-based handoff, or REST API — your pipeline receives tagged, ready-to-use samples
Banalytics notifies the downstream training pipeline that a sample is ready. The notification carries the file path, timestamp, data format extension, and the full metadata object. The training pipeline pulls the file directly from local storage or from a shared mount — no data is pushed over a fragile network connection. For pipelines that prefer push-based delivery, Banalytics can upload the package to an S3-compatible store or publish it via MQTT. The raw data archive on the edge node is retained independently of the export — export failures do not cause data loss.
// Development model
Three phases from first collection to continuous pipeline
AI data collection deployments grow through distinct phases. Each phase produces value independently — you do not need to complete Phase 3 before Phase 2 generates useful training data.
P1
Phase 1 — Collection design and PoC alignment
Device list, data categories, capture triggers, export format, and monitoring tags agreed before hardware is deployed
The first phase defines what will be collected and how. Output includes a documented device inventory and connection plan, the set of trigger conditions that constitute a collection-worthy event, the data categories each sample must contain (video streams, sensor channels, metadata fields), the export format and interface your training pipeline will consume, and the monitoring tags Banalytics will emit to signal collection health. Mock or pre-recorded inputs are acceptable for validating the pipeline end-to-end before deploying to a real site.
↓ design agreed — deploy to real devices and validate collection quality
P2
Phase 2 — Collection pilot with real devices
Live data flowing, samples exported, collection health monitored
The collection pilot connects actual field devices, validates that triggers fire at the right moments, confirms that multimodal synchronisation is within the required tolerance, and verifies that exported samples contain the metadata your labelling pipeline expects. Banalytics dashboards are live from this phase, showing capture rates, event counts, device health, and storage consumption across all nodes. The pilot configuration is the production configuration — there is no separate hardening step for the collection tooling itself.
↓ pilot validated — scale to continuous collection
P3
Phase 3 — Continuous collection at scale
Multiple nodes, multiple sites, storage management, and active feedback from training
Phase 3 extends the collection infrastructure across multiple devices and sites. Each collection node runs independently and is monitored from a single dashboard. Storage management policies determine which samples are retained locally and which are promoted to the training archive. As the model improves through training, trigger conditions and capture parameters can be updated remotely on all nodes simultaneously — without visiting the collection sites — closing the feedback loop between model performance and data collection strategy.
// Scope boundary
What Banalytics provides, what your stack keeps
Banalytics handles the entire edge layer. Your training stack handles everything above the export boundary. Neither side depends on the other's internal implementation.
IN
Banalytics handles at the edge
Everything below the export boundary. No custom acquisition code, no fragile glue scripts, no manual monitoring.
AcquireConnects to all field devices — cameras, sensors, robots — via ONVIF, RTSP, MQTT, Modbus, USB, and vendor SDKs. Maintains live streams with automatic reconnection. No custom per-device integration code required.
TriggerEvaluates configurable event rules to determine when a capture is worth initiating. Triggers can be sensor thresholds, motion events, MQTT messages, scheduled windows, or manual operator actions.
CaptureOpens a synchronised capture window across all configured streams when a trigger fires. Pre-trigger buffering ensures the onset of the condition is included. All streams share a common reference timestamp.
TagAssembles each sample with its full context: trigger type and source, synchronised sensor readings, device health state, user-defined labels, and any MQTT payload from the triggering event.
StoreWrites the full raw data archive locally. Data is retained on the edge node regardless of network availability. Export failures do not cause data loss — the local archive is always the source of truth.
ExportNotifies the training pipeline via MQTT, file-based handoff, or REST API. The notification carries the file path, timestamp, format, and full metadata. Raw data is never pushed over a fragile connection.
MonitorBrowser dashboards show live capture rates, event counts, device health, and storage usage across all nodes. Accessible from any browser at console.banalytics.live — no VPN required.
Your stack's boundary: Your training pipeline, labelling platform, model training code, experiment tracking, and model registry remain entirely independent. Banalytics publishes to a defined export interface and your stack consumes from it. Neither side has visibility into the other's internals. Swapping your training infrastructure does not require changes to the collection configuration, and updating the collection trigger logic does not require changes to your training stack.
// Compared to industrial sensing
Same platform, different data flow
Banalytics serves both AI data teams and industrial sensing teams, but the architecture differs in one important way. Understanding the difference helps you apply the right pattern.
AI data collection
Banalytics is the complete edge layer. It acquires, triggers, tags, stores, and exports. No independent processing module at the edge. The model is trained offline in your stack using the exported samples.
Industrial sensing
Banalytics flanks an independent processing module. It delivers raw data to the module and receives structured results back. The module performs real-time analysis at the edge and the results are published to SCADA or operations dashboards.
Some deployments combine both patterns: Banalytics acquires and exports training data during a data-collection phase, and after a model is trained and deployed to the edge as a processing module, Banalytics switches to the sensing architecture — delivering data to the model and publishing its results to downstream consumers.
// Next step
Start with a collection design session
The fastest path to your first useful training samples is a focused session covering your device inventory, the trigger conditions that define a good sample, and the export format your labelling and training pipeline expects.
01
Collection design
Device inventory, trigger conditions, data categories, and export interface
We review your field devices, define the trigger conditions that constitute a collection-worthy event for your model, specify the multimodal data categories each sample must contain, and agree on the export format your training pipeline will consume. We can demonstrate the full collection and export flow using a representative device set before any site deployment.
↓ design agreed — run the collection pilot
02
Collection pilot
Live devices, real samples flowing, collection health visible
The pilot connects your actual field devices, runs the configured trigger and capture logic against real conditions, and delivers the first batch of tagged samples to your training pipeline. By the end of the pilot your team has hands-on experience with the collection dashboard, a validated export pipeline, and a clear view of the per-sample quality and volume your deployment will sustain.
Contact us: Reach out at info@banalytics.live or visit the AI Data Teams page to request a collection design session. Tell us what devices you have, what you are trying to capture, and what your training pipeline looks like — that is enough for us to prepare a useful first session.