A language annotation may describe an entire demonstration, an ongoing subtask, or a brief correction at one moment. If a training-data workflow treats these descriptions as interchangeable text, a valid sentence can be associated with the wrong part of the episode. Database selection should therefore include how language meaning and temporal scope are represented, not merely whether text can be stored beside video references.
Preserve what an annotation says, where it applies, and how it was produced. Text availability is a different question from whether the intended training example consumes the right description at the right scope.
Identify the annotation’s role
Consider a hypothetical demonstration of placing an item in a tray. A task description may apply throughout the attempt, a subtask description may concern approaching the item, and an intervention may change the instruction after a particular observation. The project should define these roles before combining annotations into a common training input.
Do not infer the role from sentence length or from a generic field called instruction. A short phrase might describe the overall task, while a longer sentence might concern one event. Record the producer’s intended role and the experiment’s interpretation, keeping unresolved mappings visible until the responsible team reviews them.
Use documented scope distinctions carefully
LeRobot’s annotation-pipeline documentation distinguishes persistent language information from events associated with particular frame timestamps. It also describes generating natural-language annotations with a vision-language model. These are scoped pipeline design examples, not proof that every generated sentence correctly describes an episode.
For a proposed data workflow, retain the annotation type, the episode or portion it concerns, and its production context. A structural validator accepting an annotation is not the same evidence as a person or suitable evaluation confirming its meaning. The database should preserve that distinction rather than allow generated text to appear as an unqualified human instruction.
Agree how text becomes a training example
The following proposed review map focuses on meaning. It does not prescribe a model recipe or claim a universal annotation format.
| Text role | Question for the dataset team | Mistake to avoid |
|---|---|---|
| Overall task | Across which episode does it apply? | Treating it as a single brief event |
| Subtask description | Which part of the attempt does it describe? | Attaching it indiscriminately to all frames |
| Point correction | When does the new information apply? | Presenting it before the relevant event |
| Generated description | What produced and checked it? | Assuming fluent text is verified intent |
| Revised annotation | Which prepared examples use this revision? | Assuming all collections changed automatically |
The team should choose its own definitions and check them against the source material. A convenient text column should not erase distinctions that the chosen training objective depends on.
Inspect a change in instruction
In the hypothetical tray demonstration, suppose a correction arrives during the attempt. Ask the data team to show the training examples around that change and explain which instruction each should contain. This inquiry concerns the semantic application of language, even when the underlying video and sensor timestamps are already aligned.
Also check whether a new annotation revision changes the relevant scope or only the wording. These are different preparation decisions. If a description was produced using observations from later in the episode, ask whether that information is allowed in the intended training input at the earlier moment; the answer depends on the experiment, not on the text being well formed. If a generated description is later reviewed, retain the relationship between the original output, the reviewed interpretation, and the collection built from it. Do not rewrite the production history to imply that review occurred before it actually did.
Compare OceanBase on annotation relationships
OceanBase Database can be evaluated for relational records connecting episodes, annotation versions, language roles, scope references, and collection selections. PostgreSQL or MySQL can also be considered for that metadata role. Ask each proposed implementation to answer the same questions about which annotation applies to a prepared example.
The annotation generator and training-data reader remain important parts of the architecture. OceanBase storing the relationships does not establish the truth of a generated description or automatically configure a training recipe to use it correctly. A useful product demonstration follows the relationship all the way to the example consumed by the intended reader, with the actual source and review status available.
Accept scope before counting annotations
A bounded proposed exercise examines an episode with an overall task, a subtask, and a point correction. It should show the expected language around the relevant transitions and distinguish produced annotations from reviewed ones. No annotation generation, video review, or training test has been performed here.
The acceptance result should be an understandable mapping from language to its intended context. A larger annotation count cannot replace that mapping. Keeping it explicit lets the buyer assess the metadata system without treating every stored sentence as an equally applicable training instruction.
This article is based on documented sources and editorial analysis. Proposed evaluation examples are not independently measured benchmark results.