---
title: IO element bag
type: concept
created: 2026-04-30
updated: 2026-04-30
sources: [teltonika-ingestion-architecture]
tags: [data-model, teltonika, principle]
---

# IO element bag

The model-specific telemetry inside a Teltonika AVL record. Carried as `{ id → value }` pairs that [[tcp-ingestion]] reads byte-correctly without interpreting.

## The principle: pass through unchanged

The Ingestion service does **not** name, interpret, or filter IO elements. It produces a [[position-record]] whose `attributes` field is a verbatim representation of the IO bag, keyed by the numeric IO element ID as a string.

- No renaming.
- No unit conversion.
- No model lookup.

Per-model interpretation lives in the [[processor]], driven by configuration like `{ "FMB920": { "16": "odometer_km", "240": "movement" } }`.

## Why this boundary matters

1. **Model-specific interpretation belongs where the model is known.** Doing it in the parser would couple Ingestion to a registry of every device model in the fleet — exactly the coupling the [[protocol-adapter]] is designed to prevent.
2. **A new model never breaks Ingestion.** A packet with `IO 1234` from an unknown device produces a parser that stores the raw value under `"1234"` and moves on. The position is still useful; the attribute is recoverable later once the model's mapping is imported.

## Structural implications

- 8-bit IO IDs in Codec 8.
- 16-bit IO IDs in Codec 8E (Teltonika ran out of 8-bit slots) plus variable-length values.
- Codec 16 introduces a per-record generation type but the IO bag itself behaves the same.

The parser handles all three identically with respect to interpretation: read bytes per the codec spec, store under string key, hand off.