DataBridge Tag

Every device gets a label before it leaves the field

Tag is the entry point of the entire DataBridge pipeline. A field operator fills an SD card, plugs it into their laptop, and Tag takes over. The app detects the device, reads its hardware info, and generates a unique tracking label that follows the media through every stage of the pipeline: buffer copy, SHA-256 manifest, cloud upload, ETag verification, and final archival.

The label is not just an identifier. It is the primary key that links the physical device to its metadata record in MongoDB, its manifest in the cloud bucket, and its audit trail in Watch. If something goes wrong at any point downstream, the label is how you trace it back to the exact moment it was captured, who was holding it, and where they were standing.

Without a label, nothing enters the pipeline. This is by design. Every device that arrives at the datacenter has already been registered, so Core can validate it against the backend before starting the ingest. No surprises, no mystery media, no untracked devices floating through the system.

Anatomy of a label

The default format is {PROJECT}-{BATCH}-{MEDIA_TYPE}-{SEQ}. Each segment is configurable per tenant, but the structure stays the same: enough information to identify the device at a glance without needing to look anything up.

Tenants can customize every segment. If your organization uses department codes instead of project codes, or date-based batch identifiers instead of sequential ones, Tag adapts. The label format is defined in the tenant config on the backend, and Tag pulls it at startup.

Automatic device detection

Tag monitors the system for USB mass storage events. When a device is inserted, the app reads its hardware descriptor and pulls device info: manufacturer, model, serial number, total capacity, available space, and filesystem type. All of this is stored alongside the label so that downstream systems know exactly what kind of media they are dealing with.

Tag does not mount or read the contents of the device. It only reads the hardware descriptor and volume metadata. The actual file copy happens later at the datacenter when Core takes over. This keeps the labeling step fast and avoids any risk of accidental file modification in the field.

Metadata captured at the point of origin

The most valuable metadata is the metadata you capture when it is still fresh. Who handled this device, when, where, and why. Tag collects this at the moment of labeling, not retroactively in a spreadsheet three days later.

Built for locations with no network

Field capture happens on rooftops, in parking structures, inside server rooms, on construction sites, in moving vehicles. The one thing these locations have in common is unreliable (or nonexistent) internet access. Tag was built for this from the start, not patched in as an afterthought.

When Tag cannot reach the backend, it stores label records in a local SQLite database on the host machine. Labels are still generated, metadata is still captured, and the operator's workflow does not change at all. The app shows a clear indicator that it is operating in offline mode, but nothing is blocked.

When connectivity returns, Tag syncs the queued records to the backend automatically. The sync is idempotent: if a record was partially uploaded before the connection dropped, it will not create a duplicate. Conflict resolution is server-side, with timestamps as the source of truth.

Connected to the backend in real time

When online, every label submission is a POST to the DataBridge backend API (FastAPI, Python 3.12, MongoDB). The API creates a card record containing the label, batch association, all metadata fields, device hardware info, and a server-generated timestamp.

The moment a card is created, it is visible in DataBridge Watch. Your operations team can see devices being labeled in the field as it happens, track batch progress in real time, and know exactly what media to expect before it physically arrives at the datacenter.

When the labeled device reaches the datacenter and an operator plugs it in, DataBridge Core reads the label, looks up the card record, and the ingest begins with full context. No manual data entry, no cross-referencing spreadsheets, no guessing which SD card belongs to which shoot.

What the operator sees

Native binary, not a browser in disguise

Tag is built with Tauri v2. The frontend is a lightweight web view rendered by the OS-native engine (WebKit on Mac, WebView2 on Windows), and the backend is compiled Rust that talks directly to the operating system's USB subsystem. The result is a binary under 15 MB that starts instantly and uses a fraction of the memory that an Electron app would.

There is no Node.js runtime, no Chromium bundle, no V8 engine. The app installs as a standard .dmg on macOS and a standard .exe installer on Windows. It requests only the permissions it needs: USB device enumeration, network access for API calls, and location services (optional, for GPS metadata).

Updates are distributed through the Tauri updater. When a new version is available, the app prompts the operator at next launch. Updates are signed and verified before installation. For managed deployments, IT teams can push updates silently through their existing MDM or SCCM tooling.

Step 1 of the pipeline

Tag is where the pipeline begins. After a device is labeled, the physical media ships to the datacenter (by courier, by mail, by hand). When it arrives, the operator plugs it into an ingest server running DataBridge Core. Core reads the label, pulls the card record from the backend, and begins the copy-verify-upload workflow with full context already attached.