Import Labels (Curation)

Label ingestion lets you store annotation data as sidecar files alongside your files in a cloud storage folder. When a folder is configured for label ingestion, Encord automatically detects sidecar files during bucket scans, pairs them with their corresponding data files, and ingests their contents as labels against a chosen Ontology.

Input Formats

Encord supports two input formats for label ingestion:

Encord (JSON sidecars) pairs each data file with a JSON sidecar file using a configurable filename suffix.
YOLO (.txt sidecars) pairs each data file with a YOLO-format .txt sidecar file using file path patterns, and maps YOLO class numbers to ontology classes.

The input format cannot be changed after label ingestion is enabled on a folder.

Encord (JSON Sidecars)

When using the Encord format, configure the Sidecar suffix field. Encord pairs each data file with a label file that shares the same name plus the suffix you specify.For example, with the default suffix, image001.jpg pairs with image001.jpg.labels.json.The suffix must be between 1 and 128 characters.

YOLO (.txt Sidecars)

Go here to specify class mapping for the Ontology When using the YOLO format, configure the following fields:

Image and Label File Patterns: Use the Image file pattern and Label file pattern fields to define how Encord pairs image files with their corresponding YOLO label files. Both patterns use a shared {name} placeholder as the capture group. The value matched by {name} in the image pattern must match the value in the label pattern for the two files to be paired. Both patterns must use the same placeholders.
External ID Namespace: The External ID namespace field determines which namespace Encord reads class numbers from when mapping YOLO class numbers to ontology classes. Encord automatically selects a namespace when you choose an Ontology. It prefers a namespace named YOLO (case-insensitive), or falls back to the first available namespace alphabetically. You can unlock the namespace selector to choose a different namespace if needed.

If the selected Ontology has no external IDs on its classes, the namespace selector is unavailable and class numbers must be entered manually in the class map.

The Class numbers editor maps each YOLO class number to an Ontology class. Encord pre-fills class numbers from the external IDs on the selected ontology’s classes under the chosen namespace. You can override individual entries by unlocking the relevant row.The following Ontology object shapes are supported for YOLO label ingestion:

Bounding box
Polygon
Rotatable bounding box

At least one class must be mapped to a YOLO class number. Each YOLO class number can only map to one ontology class. Class numbers must be non-negative integers.

If the selected Ontology has no bounding-box, polygon, or rotatable-box objects, Encord displays a warning and you must select a different Ontology.

How it Works

During each scheduled bucket scan, Encord classifies every file in the folder. Files whose names match the configured suffix are identified as label sidecars and excluded from the data file list. Each sidecar is paired with its corresponding data file, and the label payload is downloaded, validated against the Ontology, and written to the database. Under the hood, enabling label ingestion provisions labels linked to the Folder and the chosen Ontology. The ingestion pipeline using a sidecar file:

Labels check: If an existing sidecar file matches the last ingestion skip (no change).
Download sidecar: Sidecar files are imported from cloud storage (max 300 MB).

Labels are imported as ground truth labels.

UUID substitution: Placeholder UUIDs sent by the SDK are replaced with server-allocated values.
Ontology resolution: The specified Ontology is loaded and Encord converts the payload into the Ontology’s label format.
Label write: Labels appear on the data units.

If a sidecar is removed from the bucket, the corresponding label are removed from the data unit.

Configuration

When creating or editing a Cloud-Synced folder:

Toggle Label ingestion on.
Set the file suffix that marks a file as a label sidecar (default: .labels.json).
Select the Ontology to validate and store labels against.

Once saved, subsequent scans begin ingesting labels matching sidecars.

The Ontology is fixed when you enable label ingestion and cannot be changed. To use a different Ontology, delete the label ingestion configuration and reconfigure the folder. Existing ingested labels are preserved, but new sidecars will ingest under the new Ontology only after reconfiguration.

Configuration Options

Option	Default	Description
Input Format	Encord (JSON)	Choose between Encord (JSON sidecars) or YOLO (.txt sidecars). Cannot be changed after label ingestion is enabled.
Suffix	`.labels.json`	(Encord format only) File suffix that identifies a sidecar. Any bucket key ending in this string is treated as a label file; the paired data key is the full key with the suffix removed.
Ontology	(required)	The Ontology used to validate ingested annotations. Cannot be changed after label ingestion is enabled.
Paused	`false`	When paused, sidecars are classified and excluded from data ingestion but are not downloaded or ingested. No new labels are written. Existing labels are preserved.

File Pairing

Label sidecar files must conform to the Encord label row format. The same schema accepted by the SDK. Maximum sidecar size: 300 MB (matching the editor HTTP save limit). Files are paired by stripping the suffix from the sidecar key to derive the data key. Example with suffix .labels.json:

Data file	Label sidecar
`dataset/image001.jpg`	`dataset/image001.jpg.labels.json`
`videos/clip_42.mp4`	`videos/clip_42.mp4.labels.json`
`scans/ct_scan.dcm`	`scans/ct_scan.dcm.labels.json`

Sidecar File Structure

This section walks through every field in an Encord JSON label sidecar, using a real example. The example is the sidecar for a single image (cherries-001.jpg) that carries three polygon objects (each a cluster of cherries) plus three frame-level classifications. A sidecar is a single JSON object with the same shape as an Encord label row. It helps to think of it as two halves:

Where a label sits. The geometry and the frame it belongs to live under data_units → labels.
What a label says. The values of an object’s nested attributes and of each frame-level classification live in the top-level object_answers and classification_answers.

The two halves are joined by hashes: an object’s objectHash is the key into object_answers, and a classification’s classificationHash is the key into classification_answers. Everything that identifies an Ontology class or attribute (featureHash, schemaFeatureUuid, value, name) must resolve against the Ontology the folder is configured with, or the sidecar fails validation on ingestion.

Coordinates are normalized to values between 0 and 1. To convert to pixels, see Label Coordinates. For every Ontology shape (bounding box, bitmask, polyline, and so on), see Ontology Shapes.

Complete example

The complete sidecar for the example is shown below. The suffix .labels.json pairs it with the image cherries-001.jpg. Polygon object labels are used for cherries. Each field is explained in the sections that follow.

{
  "label_hash": "00000000-0000-0000-0000-000000000000",
  "branch_name": "main",
  "created_at": "2026-06-10 10:00:00",
  "last_edited_at": "2026-06-10 10:00:00",
  "dataset_hash": "00000000-0000-0000-0000-000000000000",
  "dataset_title": "",
  "data_title": "cherries-001.jpg",
  "data_hash": "00000000-0000-0000-0000-000000000000",
  "data_type": "image",
  "data_units": {
    "00000000-0000-0000-0000-000000000000": {
      "data_hash": "00000000-0000-0000-0000-000000000000",
      "data_title": "cherries-001.jpg",
      "data_type": "image/jpeg",
      "data_sequence": 0,
      "labels": {
        "objects": [
          {
            "name": "Cherries",
            "color": "#157dd3",
            "shape": "polygon",
            "value": "cherries",
            "createdAt": "Wed, 10 Jun 2026 10:00:00 GMT",
            "createdBy": "user@acme.com",
            "confidence": 1.0,
            "objectHash": "9e961c1f",
            "featureHash": "vfqrMLhf",
            "manualAnnotation": true,
            "polygon": {
              "0": { "x": 0.3143, "y": 0.1946 },
              "1": { "x": 0.2336, "y": 0.3057 },
              "2": { "x": 0.103, "y": 0.2633 },
              "3": { "x": 0.103, "y": 0.1259 },
              "4": { "x": 0.2336, "y": 0.0835 }
            },
            "schemaFeatureUuid": "61fdb029-af2c-4236-add7-eda231cf6ce0",
            "frame": 0,
            "lastEditedAt": "Wed, 10 Jun 2026 10:00:00 GMT",
            "lastEditedBy": "user@acme.com",
            "polygons": [
              [
                [
                  0.3143, 0.1946, 0.2336, 0.3057, 0.103, 0.2633,
                  0.103, 0.1259, 0.2336, 0.0835
                ]
              ]
            ]
          },
          {
            "name": "Cherries",
            "color": "#157dd3",
            "shape": "polygon",
            "value": "cherries",
            "createdAt": "Wed, 10 Jun 2026 10:00:00 GMT",
            "createdBy": "user@acme.com",
            "confidence": 1.0,
            "objectHash": "d586fde0",
            "featureHash": "vfqrMLhf",
            "manualAnnotation": true,
            "polygon": {
              "0": { "x": 0.6658, "y": 0.1752 },
              "1": { "x": 0.5761, "y": 0.2986 },
              "2": { "x": 0.431, "y": 0.2515 },
              "3": { "x": 0.431, "y": 0.0989 },
              "4": { "x": 0.5761, "y": 0.0518 }
            },
            "schemaFeatureUuid": "61fdb029-af2c-4236-add7-eda231cf6ce0",
            "frame": 0,
            "lastEditedAt": "Wed, 10 Jun 2026 10:00:00 GMT",
            "lastEditedBy": "user@acme.com",
            "polygons": [
              [
                [
                  0.6658, 0.1752, 0.5761, 0.2986, 0.431, 0.2515,
                  0.431, 0.0989, 0.5761, 0.0518
                ]
              ]
            ]
          },
          {
            "name": "Cherries",
            "color": "#157dd3",
            "shape": "polygon",
            "value": "cherries",
            "createdAt": "Wed, 10 Jun 2026 10:00:00 GMT",
            "createdBy": "user@acme.com",
            "confidence": 1.0,
            "objectHash": "181a685f",
            "featureHash": "vfqrMLhf",
            "manualAnnotation": true,
            "polygon": {
              "0": { "x": 0.302, "y": 0.6949 },
              "1": { "x": 0.2159, "y": 0.8134 },
              "2": { "x": 0.0766, "y": 0.7681 },
              "3": { "x": 0.0766, "y": 0.6217 },
              "4": { "x": 0.2159, "y": 0.5764 }
            },
            "schemaFeatureUuid": "61fdb029-af2c-4236-add7-eda231cf6ce0",
            "frame": 0,
            "lastEditedAt": "Wed, 10 Jun 2026 10:00:00 GMT",
            "lastEditedBy": "user@acme.com",
            "polygons": [
              [
                [
                  0.302, 0.6949, 0.2159, 0.8134, 0.0766, 0.7681,
                  0.0766, 0.6217, 0.2159, 0.5764
                ]
              ]
            ]
          }
        ],
        "classifications": [
          {
            "classificationHash": "b1c170b0",
            "featureHash": "DVMJtIo4",
            "confidence": 1.0,
            "createdAt": "Wed, 10 Jun 2026 10:00:00 UTC",
            "createdBy": "user@acme.com",
            "manualAnnotation": true
          },
          {
            "classificationHash": "6edacab8",
            "featureHash": "xbicooGo",
            "confidence": 1.0,
            "createdAt": "Wed, 10 Jun 2026 10:00:00 UTC",
            "createdBy": "user@acme.com",
            "manualAnnotation": true
          },
          {
            "classificationHash": "b29363aa",
            "featureHash": "MnIOWwbm",
            "confidence": 1.0,
            "createdAt": "Wed, 10 Jun 2026 10:00:00 UTC",
            "createdBy": "user@acme.com",
            "manualAnnotation": true
          }
        ]
      },
      "width": 1280,
      "height": 960,
      "data_link": ""
    }
  },
  "object_answers": {
    "9e961c1f": {
      "objectHash": "9e961c1f",
      "classifications": [
        {
          "name": "Type?",
          "value": "type?",
          "answers": [
            { "name": "Bing", "value": "Bing", "featureHash": "rHd75uIW" }
          ],
          "featureHash": "OVHs46dg",
          "manualAnnotation": true
        }
      ],
      "range": [[0, 0]],
      "featureHash": "vfqrMLhf",
      "createdAt": "Wed, 10 Jun 2026 10:00:00 GMT",
      "createdBy": "user@acme.com",
      "lastEditedAt": "Wed, 10 Jun 2026 10:00:00 GMT",
      "lastEditedBy": "user@acme.com",
      "spaces": {}
    },
    "d586fde0": {
      "objectHash": "d586fde0",
      "classifications": [
        {
          "name": "Type?",
          "value": "type?",
          "answers": [
            { "name": "King", "value": "King", "featureHash": "G3oVsMg8" }
          ],
          "featureHash": "OVHs46dg",
          "manualAnnotation": true
        }
      ],
      "range": [[0, 0]],
      "featureHash": "vfqrMLhf",
      "createdAt": "Wed, 10 Jun 2026 10:00:00 GMT",
      "createdBy": "user@acme.com",
      "lastEditedAt": "Wed, 10 Jun 2026 10:00:00 GMT",
      "lastEditedBy": "user@acme.com",
      "spaces": {}
    },
    "181a685f": {
      "objectHash": "181a685f",
      "classifications": [
        {
          "name": "Type?",
          "value": "type?",
          "answers": [
            { "name": "Rainier", "value": "Rainier", "featureHash": "Zj1Z2a4t" }
          ],
          "featureHash": "OVHs46dg",
          "manualAnnotation": true
        }
      ],
      "range": [[0, 0]],
      "featureHash": "vfqrMLhf",
      "createdAt": "Wed, 10 Jun 2026 10:00:00 GMT",
      "createdBy": "user@acme.com",
      "lastEditedAt": "Wed, 10 Jun 2026 10:00:00 GMT",
      "lastEditedBy": "user@acme.com",
      "spaces": {}
    }
  },
  "classification_answers": {
    "b1c170b0": {
      "classificationHash": "b1c170b0",
      "featureHash": "DVMJtIo4",
      "classifications": [
        {
          "name": "Ripe?",
          "value": "ripe?",
          "answers": [
            { "name": "Unripe", "value": "Unripe", "featureHash": "K6BZUgan" }
          ],
          "featureHash": "HcV8moS0",
          "manualAnnotation": true
        }
      ]
    },
    "6edacab8": {
      "classificationHash": "6edacab8",
      "featureHash": "xbicooGo",
      "classifications": [
        {
          "name": "Rating",
          "value": "rating",
          "answers": [
            { "name": "7", "value": "7", "featureHash": "qosWT27u" }
          ],
          "featureHash": "KAW4jwDy",
          "manualAnnotation": true
        }
      ]
    },
    "b29363aa": {
      "classificationHash": "b29363aa",
      "featureHash": "MnIOWwbm",
      "classifications": [
        {
          "name": "Qualities",
          "value": "qualities",
          "answers": [
            { "name": "Juicy", "value": "Juicy", "featureHash": "7Jdff1Yx" },
            { "name": "Large", "value": "Large", "featureHash": "L0tdbpff" }
          ],
          "featureHash": "Buv2kLQ9",
          "manualAnnotation": true
        }
      ]
    }
  },
  "object_actions": {},
  "label_status": "LABELLED",
  "annotation_task_status": "QUEUED",
  "is_shadow_data": false
}

Top-level keys

{
  "label_hash": "00000000-0000-0000-0000-000000000000",
  "branch_name": "main",
  "created_at": "2026-06-10 10:00:00",
  "last_edited_at": "2026-06-10 10:00:00",
  "dataset_hash": "00000000-0000-0000-0000-000000000000",
  "dataset_title": "",
  "data_title": "cherries-001.jpg",
  "data_hash": "00000000-0000-0000-0000-000000000000",
  "data_type": "image",
  "data_units": { },
  "object_answers": { },
  "classification_answers": { },
  "object_actions": {},
  "label_status": "LABELLED",
  "annotation_task_status": "QUEUED",
  "is_shadow_data": false
}

Key	In the example	Description	Why it is set this way
label_hash	`00000000-…-000000000000`	Unique identifier of the label row (the container that binds these labels to the data unit).	You do not know the server-side identifier when you generate a sidecar, so a placeholder (all-zeros) UUID is used. Encord replaces it with a real value during the UUID substitution step of ingestion.
branch_name	`main`	The label branch this row lives on.	Part of the exported label-row shape but not currently read on ingestion (see the note below). `main` is the default branch.
created_at	`2026-06-10 10:00:00`	Time and date the label row was created.	Not read on ingestion. Encord sets the row’s creation time when it creates the label on import (see the note below).
last_edited_at	`2026-06-10 10:00:00`	Time and date the label row was last edited.	Not read on ingestion. Encord sets this to the import time when it writes the labels (see the note below).
dataset_hash	`00000000-…-000000000000`	Identifier of the Dataset the data unit belongs to.	Placeholder. Pairing is by filename and suffix, not by this hash, so a placeholder is accepted and substituted server-side.
dataset_title	`""` (empty)	Human-readable Dataset title.	Required as a string. Include the key and use an empty string `""` when you have no title, not `null`. The value itself is informational.
data_title	`cherries-001.jpg`	Filename of the data unit these labels apply to.	Should match the paired data file.
data_hash	`00000000-…-000000000000`	Unique identifier of the data unit.	Placeholder. The data unit is matched by filename and suffix, so Encord assigns the real hash on ingestion.
data_type	`image`	The kind of data unit: `image`, `video`, `audio`, `text`, `pdf`, and so on.	Set to match the paired file. Drives how `data_units` and frames are interpreted.
data_units	`{ }`	Map of the individual files that make up the data unit, keyed by `data_hash`. Object geometry lives here.	See the `data_units` section below. A single image has exactly one entry.
object_answers	`{ }`	Map, keyed by `objectHash`, holding the nested-attribute answers for every object.	See the `object_answers` section. Split out from geometry so an object’s answers can be looked up by its hash.
classification_answers	`{ }`	Map, keyed by `classificationHash`, holding the value of every frame-level classification.	See the `classification_answers` section.
object_actions	`{}` (empty)	State changes of dynamic attributes (attributes whose value changes across frames).	Empty because a single image has no dynamic (time-varying) attributes.
label_status	`LABELLED`	Whether the data unit has been labeled.	Reflects that this data unit carries labels.
annotation_task_status	`QUEUED`	Position of the data unit in the project workflow: `QUEUED`, `ASSIGNED`, `IN_REVIEW`, `RETURNED`, or `COMPLETED`.	Not read on ingestion (see the note below). `QUEUED` = created and waiting to be assigned.
is_shadow_data	`false`	Marks a label row as benchmark “shadow” data (the annotator’s blind copy of a benchmark) in a Benchmark QA project.	Not read on ingestion (see the note below). `false` = ordinary production data.

Encord sets several fields for you on ingestion. A sidecar has the same shape as an exported label row, so it can carry more than the importer actually reads. On import, Encord substitutes the identity hashes it allocates (label_hash, data_hash, dataset_hash) and stamps the row’s own timestamps: the creation time when it creates the label row, and last_edited_at and last_edited_by when it writes the labels. Any values you supply for created_at, last_edited_at, last_edited_by, branch_name, annotation_task_status, and is_shadow_data are ignored, so you can include them (an exported row will) or leave them out. What the importer reads is the label content: data_units, object_answers, classification_answers, and object_actions.

data_units

data_units is a map keyed by the file’s data_hash. Each entry is one file that composes the data unit; a single image has exactly one entry. Object geometry for the image lives inside this entry, under labels.

"data_units": {
  "00000000-0000-0000-0000-000000000000": {
    "data_hash": "00000000-0000-0000-0000-000000000000",
    "data_title": "cherries-001.jpg",
    "data_type": "image/jpeg",
    "data_sequence": 0,
    "labels": { },
    "width": 1280,
    "height": 960,
    "data_link": ""
  }
}

Key	In the example	Description	Why it is set this way
data_hash	`00000000-…-000000000000`	The file’s identifier; also the key of this entry.	Placeholder; assigned by Encord on ingestion.
data_title	`cherries-001.jpg`	The file’s title.	Matches the paired data file.
data_type	`image/jpeg`	The file’s MIME type.	The precise media type of this file (note this is the MIME type, whereas the top-level `data_type` is the broad category `image`).
data_sequence	`0`	Order of this file within the data unit.	Always `0` for a single image, which is composed of exactly one file.
labels	`{ }`	Container for the image’s label information.	Holds the image’s objects and classifications. See the `labels` section.
width	`1280`	Image width in pixels.	Used to convert normalized `x` coordinates to pixels.
height	`960`	Image height in pixels.	Used to convert normalized `y` coordinates to pixels.
data_link	`""` (empty)	Link to the file in your private cloud.	Provide a string. Use an empty string `""` when there is no private-cloud link, not `null`.

labels

For an image, labels is a single object holding an objects list (geometry) and a classifications list (which frame-level classifications are present). An image is a single frame, so its labels are not keyed by frame number the way video and image-group labels are.

"labels": {
  "objects": [ ],
  "classifications": [ ]
}

Key	Description	Notes
objects	The geometric object labels in this image.	Each entry carries a shape and its coordinates. See the `objects` section.
classifications	The frame-level classifications present on this image.	Identity only. The answers live in the `classification_answers` section. See the `classifications` section.

objects

Each entry in objects is one object instance and carries its identity, provenance, and geometry. The example has three Cherries polygons; one is shown in full below.

{
  "name": "Cherries",
  "color": "#157dd3",
  "shape": "polygon",
  "value": "cherries",
  "createdAt": "Wed, 10 Jun 2026 10:00:00 GMT",
  "createdBy": "user@acme.com",
  "confidence": 1.0,
  "objectHash": "9e961c1f",
  "featureHash": "vfqrMLhf",
  "manualAnnotation": true,
  "polygon": {
    "0": { "x": 0.3143, "y": 0.1946 },
    "1": { "x": 0.2336, "y": 0.3057 },
    "2": { "x": 0.1030, "y": 0.2633 },
    "3": { "x": 0.1030, "y": 0.1259 },
    "4": { "x": 0.2336, "y": 0.0835 }
  },
  "schemaFeatureUuid": "61fdb029-af2c-4236-add7-eda231cf6ce0",
  "frame": 0,
  "lastEditedAt": "Wed, 10 Jun 2026 10:00:00 GMT",
  "lastEditedBy": "user@acme.com",
  "polygons": [
    [
      [
        0.3143, 0.1946, 0.2336, 0.3057, 0.1030, 0.2633,
        0.1030, 0.1259, 0.2336, 0.0835
      ]
    ]
  ]
}

Key	In the example	Description	Why it is set this way
name	`Cherries`	The object’s name, as defined in the Ontology.	Must match the Ontology class.
color	`#157dd3`	The color used to draw the object.	As specified in the Ontology.
shape	`polygon`	The Ontology shape used to create the object.	Determines which coordinate field is present (`polygon`/`polygons` here).
value	`cherries`	The lowercased identifier of the class, as defined in the Ontology.	Must match the Ontology class’s value.
createdAt / createdBy	`…10:00:00 GMT` / `user@acme.com`	When and by whom the object was created.	Provenance; echoed on the row.
confidence	`1.0`	Confidence score for this object.	`1.0` marks a human annotation. For a model prediction, set the model’s score and `manualAnnotation: false`.
objectHash	`9e961c1f`	Identifier of this specific object instance.	This is the join key: it must be unique within the row and must match the key used in `object_answers`.
featureHash	`vfqrMLhf`	Short identifier of the Ontology object (class) this instance belongs to.	Must resolve to an object in the configured Ontology.
manualAnnotation	`true`	Whether the object was drawn by a human.	`true` = drawn manually; `false` = produced by a model or automated labeling.
polygon	five vertices	Legacy coordinate form: a map of vertex index → `{x, y}`.	Kept for backward compatibility. Prefer `polygons`.
schemaFeatureUuid	`61fdb029-…`	UUID form of the same Ontology feature that `featureHash` identifies in short form.	The newer, canonical reference to the Ontology object node.
frame	`0`	The frame the object appears on.	Always `0` for a single image.
lastEditedAt / lastEditedBy	`…10:00:00 GMT` / `user@acme.com`	When and by whom the object was last edited.	Optional provenance carried in the labels payload.
polygons	one ring of five vertices	Recommended coordinate form: a list of polygons, each a list of rings, each ring a flat `[x0, y0, x1, y1, …]` array.	This structure can represent complex polygons, including multiple disjoint regions and holes, which the legacy `polygon` field cannot.

polygon and polygons describe the same shape here. New sidecars should populate polygons; use polygon only for compatibility with existing tooling. See Ontology Shapes for how each shape encodes its coordinates.

classifications

Each entry in the classifications list records that a frame-level classification is present on the image. It carries identity and provenance only; the chosen value lives in the classification_answers section, looked up by classificationHash.

{
  "classificationHash": "b1c170b0",
  "featureHash": "DVMJtIo4",
  "confidence": 1.0,
  "createdAt": "Wed, 10 Jun 2026 10:00:00 UTC",
  "createdBy": "user@acme.com",
  "manualAnnotation": true
}

Key	In the example	Description	Why it is set this way
classificationHash	`b1c170b0`	Identifier of this classification instance.	The join key into `classification_answers`. Must match a key there.
featureHash	`DVMJtIo4`	Identifier of the Ontology classification this instance belongs to.	Must resolve to a classification in the configured Ontology.
confidence	`1.0`	Confidence score for this classification.	`1.0` for a human annotation.
createdAt / createdBy	`…10:00:00 UTC` / `user@acme.com`	When and by whom the classification was added.	Provenance.
manualAnnotation	`true`	Whether it was set by a human.	`true` = manual; `false` = model or automated labeling.

The example has three frame-level classifications (Ripe?, Rating, and Qualities), so this list contains three entries (b1c170b0, 6edacab8, b29363aa), each resolved in classification_answers.

object_answers

object_answers holds the nested attribute answers for objects, keyed by objectHash. Every object appears here even if it has no attributes. In the example, each Cherries object has one nested radio attribute, Type?.

"object_answers": {
  "9e961c1f": {
    "objectHash": "9e961c1f",
    "classifications": [
      {
        "name": "Type?",
        "value": "type?",
        "answers": [
          { "name": "Bing", "value": "Bing", "featureHash": "rHd75uIW" }
        ],
        "featureHash": "OVHs46dg",
        "manualAnnotation": true
      }
    ],
    "range": [[0, 0]],
    "featureHash": "vfqrMLhf",
    "createdAt": "Wed, 10 Jun 2026 10:00:00 GMT",
    "createdBy": "user@acme.com",
    "lastEditedAt": "Wed, 10 Jun 2026 10:00:00 GMT",
    "lastEditedBy": "user@acme.com",
    "spaces": {}
  }
}

Key	In the example	Description	Why it is set this way
objectHash	`9e961c1f`	The object instance these answers belong to; also the key of this entry.	Must match an `objectHash` under `data_units` → … → `objects`.
classifications	one attribute (`Type?`)	The object’s nested attributes. Includes dynamic and relation attributes.	Not to be confused with frame-level classifications. Each entry is one attribute of the object.
classifications[].name / value	`Type?` / `type?`	Name and value of the attribute, as defined in the Ontology.	Must match the Ontology attribute.
classifications[].answers	`Bing`	The value(s) chosen for the attribute.	A radio attribute has a single answer; a checklist attribute would list several.
classifications[].answers[].featureHash	`rHd75uIW`	Identifier of the chosen option in the Ontology.	Identifies which option (`Bing`, `King`, `Rainier`) was selected.
classifications[].featureHash	`OVHs46dg`	Identifier of the attribute (question) in the Ontology.	Distinguishes the attribute node from the option node above.
range	`[[0, 0]]`	The frame range the answers apply to, as `[start, end]` pairs.	`[[0, 0]]` = frame 0 only, i.e. the single image.
featureHash	`vfqrMLhf`	Identifier of the object’s Ontology class.	Same class hash as on the object instance.
createdAt / createdBy / lastEditedAt / lastEditedBy	`…10:00:00 GMT` / `user@acme.com`	Provenance of the answers.	Echoed on the row.
spaces	`{}` (empty)	Per-space answers for multi-space data (for example scenes or multi-frame spaces).	Empty for a plain image, which has no additional spaces.

The three objects resolve to different Type? options: 9e961c1f → Bing, d586fde0 → King, 181a685f → Rainier.

classification_answers

classification_answers holds the value of each frame-level classification, keyed by classificationHash. Each entry links back to the classifications entry of the same hash under data_units → … → labels.

"classification_answers": {
  "b1c170b0": {
    "classificationHash": "b1c170b0",
    "featureHash": "DVMJtIo4",
    "classifications": [
      {
        "name": "Ripe?",
        "value": "ripe?",
        "answers": [
          { "name": "Unripe", "value": "Unripe", "featureHash": "K6BZUgan" }
        ],
        "featureHash": "HcV8moS0",
        "manualAnnotation": true
      }
    ]
  }
}

Key	In the example	Description	Why it is set this way
classificationHash	`b1c170b0`	The classification instance these answers belong to; also the key of this entry.	Must match a `classificationHash` under `labels`.
featureHash (outer)	`DVMJtIo4`	Identifier of the classification in the Ontology.	Matches the `featureHash` on the frame-level classification entry.
classifications[].name / value	`Ripe?` / `ripe?`	Name and value of the classification question.	As defined in the Ontology.
classifications[].answers	`Unripe`	The chosen value(s).	A radio question has one answer; a checklist lists several (see the note below).
classifications[].answers[].featureHash	`K6BZUgan`	Identifier of the selected option.	Identifies which option was chosen.
classifications[].featureHash (inner)	`HcV8moS0`	Identifier of the classification question node.	Distinct from the outer instance-level `featureHash`.
manualAnnotation	`true`	Whether the answer was set by a human.	`true` = manual; `false` = model or automated labeling.

The three classifications in the example show the three answer patterns: Ripe? (b1c170b0) is a radio set to Unripe; Rating (6edacab8, feature KAW4jwDy) is a radio set to 7; Qualities (b29363aa, feature Buv2kLQ9) is a checklist with two answers, Juicy and Large, so its answers array holds both.

For the complete, authoritative sidecar schema across every data type and shape, see Importing Labels with the SDK. A sidecar must conform to the same Encord label row format the SDK accepts.

Pausing and Resuming

Pausing stops new sidecars from being downloaded and ingested without removing existing labels. This is the recommended way to temporarily halt label ingestion. For example, while updating your sidecar generation pipeline. To pause or resume: Folder details > Label ingestion > Pause / Resume.

Disabling Label Ingestion

Deleting the label ingestion configuration removes the config from the folder. Already-ingested labels are preserved. No new sidecars are picked up after deletion. To disable: Folder details > Label ingestion > Delete (trash icon) > Confirm.

Supported Data Types

Label sidecars can be paired with any data type supported by cloud-synced folders:

Images
Videos
Audio
Text
PDFs
Time series

Get Started

Quick Start (By Role)

Data

Fundamentals

Annotate & Review

Label and Model Evaluation

Users and Workspaces

Import Labels (Curation)

Input Formats

How it Works

Configuration

Configuration Options

File Pairing

Sidecar File Structure

Complete example

Top-level keys

Pausing and Resuming

Disabling Label Ingestion

Supported Data Types

​Input Formats

​How it Works

​Configuration

​Configuration Options

​File Pairing

​Sidecar File Structure

​Complete example

​Top-level keys

​Pausing and Resuming

​Disabling Label Ingestion

​Supported Data Types

Input Formats

How it Works

Configuration

Configuration Options

File Pairing

Sidecar File Structure

Complete example

Top-level keys

Pausing and Resuming

Disabling Label Ingestion

Supported Data Types