yrlyrl/spatial-mmcot-motif
Spatial MMCoT v1 · motif MoTiF (OpenRaiser/MoTiF), the naive arm of its procedurally generated multi-step tasks: ball_tracking_naive, manipulation_naive, maze_naive (manipulation shows MoTiF's own CLEVR-style 3D renders of solids, not images from the CLEVR dataset). Each step has its own target image. The reflexion arm, which pairs each problem with a deliberately corrupted frame, is not included. sokoban_naive is excluded (7,997 upstream rows, S0.task_excluded): its eight… See the full description on the dataset page: https://huggingface.co/datasets/yrlyrl/spatial-mmcot-motif.
Spatial MMCoT v1 · motif
MoTiF (OpenRaiser/MoTiF), the naive arm of its procedurally generated multi-step tasks: balltrackingnaive, manipulationnaive, mazenaive (manipulation shows MoTiF's own CLEVR-style 3D renders of solids, not images from the CLEVR dataset). Each step has its own target image. The reflexion arm, which pairs each problem with a deliberately corrupted frame, is not included. sokoban_naive is excluded (7,997 upstream rows, S0.task_excluded): its eight numeric options are generated from the answer, so the correct option is the largest option minus 7 on almost every row, and the task can be answered from the option text without looking at the board. Manipulation can be partly answered without the image, in two ways: count questions ('how many ...') offer four consecutive integers and the correct count is never the largest of them, and for 'what is the object ...' questions the option named last in the operation list, and not in the question, is often right. Report manipulation scores next to the text-only baselines, with count questions scored separately (numbers under Known issues). VisWorld-Eval (thuml/VisWorld-Eval) ballgame uses the same rule text and question as ball_tracking_naive, so it is in-domain; VisWorld-Eval multihop asks the same kind of question as manipulation_naive (numbered place, swap, change and remove operations on CLEVR-style rendered scenes, then where an object is or which object is where); its wording is paraphrased and S11 found no shared images, so it is near-domain. Do not report either as out-of-distribution for a model trained on this source. Every read-back ends with a \boxed{} that holds the <answer> key (rows with no box were refused at conversion, S0.no_boxed_answer). On 12 rows upstream boxed the option's value instead of its key; that box was rewritten to the key (flag S0.boxed_value_to_key), so those read-backs are not verbatim.
Supervision kind (supervision_kind in meta): full_interleaved on every row: the upstream trace itself interleaves text and target images (drawn or rendered states on most sources; the source note above says which), and the read-back comes after the target image it reads. The text is upstream's and was not checked against the images.
Upstream: `OpenRaiser/MoTiF`. Licence: mit.
Known issues
Rows with a measured per-row problem are listed in reports/known_issues/, one TSV per issue (a # <description> line, then row_uid<TAB>split<TAB>detail lines), so they can be filtered out. They are still in this release: no row was removed for these issues.
To leave the listed rows out (the snippet in the loader section downloads reports/known_issues/ with the data):
import glob, os
root = "<root>/motif"
drop = {line.split("\t")[0] for f in glob.glob(os.path.join(root, "reports/known_issues/*.tsv"))
for line in open(f) if line.strip() and not line.startswith(("#", "row_uid\t"))}
# keep a row when its row_uid (a column of train/, meta/ and preview/) is not in dropMeasured caveats
Measured on this release by the pre-publication review (2026-09-25): problems that cannot be listed row by row (a shortcut in the options, a label convention, an upstream labelling scheme) and what the review found around the lists above. Where a caveat counts listed rows ("listed as ..."), the count is the table's, read from reports/known_issues/summary.json. Its other numbers are the review's own measurements, which no file carries: they hold for exactly these rows and are not re-measured automatically. Items marked Training-signal defect are problems in what the rows teach, not only in how they are described; no row was removed for them.
- All 2,094 rows S4c quarantined are
manipulation_naiverows. The read-back states its answer in words and then boxes the option letter ('... the answer is the blue cylinder. The final answer is \boxed{D}'); the check compares the first 30 characters after 'answer is' or 'Answer:' with the letter and could not match those words. Re-read against the upstream text, 2,090 of them each name the labelled option, name it with another option (6) or state no option (8), and none names a different one; the other 4 were not re-read. They are 26.2% of the task's 7,980 convertible rows, and the loss falls unevenly: 32.6% of 'what is the object ...' questions (1,697 of 5,199), 11.9% of 'how many' (242 of 2,031) and 20.6% of 'where' questions (151 of 734). The released manipulation rows are therefore 59.4% object, 30.8% count and 9.9% 'where' questions, against 65.3% / 25.5% / 9.2% upstream. - Training-signal defect. Count questions in
manipulation_naive('how many ...', 1,743 training and 41 validation rows) can be answered from the option list: the four options are consecutive integers and the correct count is never the largest (0 of 1,743 train, 0 of 41 validation). Options 1-4 always mean 3 and options 2-5 always mean 4: the 147 rows (144 train, 3 validation; listed ascount_options_give_answer) whose smallest option is above 0 are answered by their options alone. On options 0-3 the answer is 1 on 774 of 1,599 training rows (48.4%). A rule that reads only the option list scores 918 of 1,743 = 0.527 on the training count rows, against 0.25 chance. S13's rank cap did not run on these rows, because the manipulation group mixes numeric and object options; rank 1 holds 44.4% of the count rows.
Size
A slot is one target position in one row; rows can share a target image (same scene or same intermediate state), and a row can repeat one of its own targets, so there are fewer distinct images (by content hash) than slots.
Input images per row: 1. Target images per row (the images the model is trained to generate): 1 to 4. Image corpus (source_scene_corpus): proceduralgrid 15,268, blenderclevr 5,797. procedural_grid is this pipeline's label for any procedurally generated synthetic image (2D grid puzzles and simple 3D renders of primitive objects alike); the source note above says what the images show.
Row format
One row is: input image(s) and a question, then K rounds of thought → target image (the target is the source's own ground-truth image, which the model is trained to generate), then a final thought (normally a read-back of the last target; where a source's final thought is something else, or often leaves out the answer, the source note or Known issues says so) and the answer; here K is 1 to 4. In the train config:
image_list list<binary> inputs first, then the K target images in order
num_input_images int64 how many of image_list are inputs
instruction_list list<string> one element: system prompt + question, + options on 5,797 of 21,065 rows
output_text_list list<string> K+1 elements:
[0] <think>plan 1</think><image_start>
[j] <image_end><think>plan j+1</think><image_start>
[K] <image_end><think>read-back</think><answer>answer</answer>
row_uid string join key to `meta` and `preview`Every image is a JPEG, and no input image is larger than 512 px on its long edge (measured on this release, 2026-09-25); the size each target was stored at is target_px in meta.
<answer> holds what the model is trained to emit. On 15,268 of 21,065 rows it equals meta.answer_value; on the other 5,797 (answer type mcq_letter 5,797) it holds the option key (a letter for mcq_letter), while meta.answer_value (the answer column of preview) holds that option's text. Map the key through the options listed in the question before comparing the two, and score model output against <answer>.
The system prompt is ThinkMorph's VLM_THINK_SYSTEM_PROMPT from its inferencer.py, verbatim (GEN_THINK_SYSTEM_PROMPT there has the same text), including its leading and trailing newline. The markers are plain strings, not tokenizer special tokens; the prompt writes </image_end> and the data writes <image_end>, exactly as the ThinkMorph-7B checkpoint was trained.
preview shows the same rows with one column per slot: input_image_i for the inputs; for each of the K = num_steps rounds, the plan thought_j and its target target_image_j, both empty for K <= j < 5; and the read-back in thought_5 on every row.
meta holds the per-row sidecar: task, scene_id and geometry_uid (the scene and geometry keys; the split key is named in the split paragraph below), trajectory_id (a camera-path or sample label, empty where the source has none), num_steps, num_input_images, answer_type, answer_value, majority_class_rate, target_image_kind, target_px, est_tokens, licence, split (train / validation, the Hub split names), supervision_kind (full_interleaved / visual_aux / visual_only) and filter_flags. majority_class_rate is the share of the task's most frequent answer_value among its training rows: it measures answer skew and is not a guessing baseline (where a task mixes question types or each row has its own options it can be far below chance); compare scores with the text-only baselines below.
Per-row license in meta: mit 21,065.
Flags on released rows (filter_flags in meta and preview, comma-separated):
Training with a BAGEL-family loader
Every row here has one input image (num_input_images is 1), so the stock ThinkMorph UnifiedEditIterableDataset (https://github.com/ThinkMorph/ThinkMorph: image_list[0] as input, image_list[j+1] after output_text_list[j]) and the IPT release's version (which reads num_input_images) both read it as intended. Mixed with a source whose rows have more than one input image, only a loader that reads num_input_images is correct.
The stock BAGEL edit loader (ByteDance-Seed/Bagel) cannot train these rows: it never reads output_text_list and expects each instruction_list element to be a list of paraphrases.
parquet_info.json keys each training chunk as <source>/<split>/<file>, here motif/train/chunk_00000.parquet, with row-group counts read from the parquet footers. The loader matches a chunk only when its key equals the path it builds, os.path.join(data_dir, file), and skips a chunk with no key without a warning: a source that is alone in its group then fails with IndexError: list index out of range, and in a mixed group it adds no rows. Download into a directory named after the source, not after the repository:
from huggingface_hub import snapshot_download
snapshot_download("yrlyrl/spatial-mmcot-motif", repo_type="dataset", local_dir="<root>/motif",
allow_patterns=["train/*", "validation/*", "parquet_info.json", "reports/known_issues/*"])Then either run from <root> with data_dir: motif/train and parquet_info_path: motif/parquet_info.json, or rebuild the index with absolute keys and use an absolute data_dir:
import json, os
root = "/abs/path/to/root" # the directory that holds motif/
info = json.load(open(os.path.join(root, "motif", "parquet_info.json")))
info = {os.path.join(root, k): v for k, v in info.items()}
json.dump(info, open(os.path.join(root, "motif", "parquet_info_abs.json"), "w"))
# data_dir = os.path.join(root, "motif", "train") (spelled exactly so, no trailing slash)
# parquet_info_path = os.path.join(root, "motif", "parquet_info_abs.json")The Hugging Face cache (.../snapshots/<hash>/train/) or a folder named spatial-mmcot-motif matches no key.
num_used_data counts chunk files, not rows: the loader repeats this source's file list up to that number, lists every (file, row group) pair, and deals whole row groups out, floor(R / worldsize) to each rank and floor(that / numworkers) to each DataLoader worker. The remainder is never read. This source has 1 training chunk file holding 160 row groups of up to 128 rows, so keep num_used_data large, e.g. the 128 of ThinkMorph's interleaved_reasoning.yaml (upstream's example.yaml asks for more than GPUs x workers); every row group is then read. In a run that mixes sources, give each source the same multiple of its own training chunk-file count, e.g. 128 per file (128 here): the file list is repeated up to num_used_data entries, so a flat 128 for every source would read a two-file source's rows half as often as a one-file source's.
How the rows were chosen
Every removed row has one line, with its reason, in reports/:
S0raw lines in build/dropped.jsonl were refused before a release row existed, so their row_uid field holds the converter's key for the upstream record, not a 16-hex row_uid; lines from later steps carry the row_uid the row had. No removed row appears in meta or preview. For this source the key is built from upstream fields that repeat across rows (for most sources a hash of the question text), so it is not unique: the 95 S0.no_boxed_answer lines carry 22 distinct keys; the 7,997 S0.task_excluded lines carry 7,949 distinct keys. Those rows are counted with their reason but cannot be traced to individual upstream rows.
2,094 rows were quarantined rather than dropped (S4c): an automatic check could not match the read-back's stated conclusion to the stored label. 2,090 of them were re-read afterwards against the upstream text, and none of those is a wrong label (see Known issues).
S8.k_zero and S8.chain_broken name what happened to the row, not which check removed the image; the lines in this build do not record whether it was the size, transparency or copy check.
<details><summary>Per-step counters of the conversion</summary>
31,362 upstream rows were read; S0raw refused 8,092 before a row existed and passed 23,270 to the first step. S0 runs once more, last, on the final bytes. The reason for every refused, dropped or quarantined row is in the files above.
</details>
The train/validation split keeps rows sharing a scene_id in meta on one side, and the assignment is frozen (splits/ in the summary repository). MoTiF has no scene ids: scene_id is the md5 of the upstream input image, so a key is one puzzle's starting image. S12 saw 21,065 rows under 21,040 keys; 17 rows joined another key because they share an input image. No validation input image has the content of a training input image, and none is a pixel-level near-copy of one. S12 does not record per source whether that test ran, but it skips it only for a source whose spec sets split_leak_pixels: false, and no spec does; over all sources it compared 21,661 candidate pairs (perceptual hash within 6 bits) pixel by pixel and found no near-copy (checked 2026-09-25). Target images are not covered by that check: 1 target-image slot in validation rows holds an image with the same content as a training target image (S12 compares a 64x64 greyscale hash and counts slots, so an image repeated in validation counts each time). These are states that other puzzles also reach, as a step or as their final state.
Answer-prior balancing (S13)
Each (task, split) group is checked separately. An answer is the answer value compared as lower-cased text without a trailing full stop, with 'farther' read as 'further' and 'nearer' as 'closer' (for multiple choice, the option text, not the letter; where the candidates are drawn in the image, as in zebrajigsaw and zebratetris, the answer is the letter itself). An answer is real when it holds at least 5 rows and 2% of the group; k is the number of real answers. Answer step: the target is max(30%, 1/k) when k >= 2, and max(30%, 1/d) over the d distinct answers when k = 1; a validation group uses the larger of its own target and its task's train target. A group is cut only when k >= 1 and its most common answer holds more than the target plus 5 percentage points; every answer is then capped at one common count, chosen so that none exceeds the target, and smaller answers keep all their rows. At the answer step, a group at or below that trigger, or with no real answer (k = 0), is left as it is, so its most common answer can hold up to the target plus 5 percentage points. A task whose train group has exactly two real answers is instead cut, in every split, so that its two largest answers have equal counts, with no trigger. Rank and label steps: then, in a group where every option value of every row is a number, the rank of the correct option among the sorted values, and after it, in a group where every trained answer is an option label, the label, are each capped by the same cut-and-trigger rule on their own counts (own target, validation included): capped, never evened out, so two labels are cut only when one exceeds 55%, and then only down to 50%. These steps can also cut groups the answer step left whole, including k = 0 groups, and can raise an answer's final share above its target; the run fails if a real answer ends above the target plus 5 percentage points. A train group of at least 20 rows in which one answer holds 90% or more fails the run. PET (exactcellspet) instead cuts each (question type x turn direction) cell to equal counts of its two answers; a PET cell that shows only one answer is removed.
S13 removed no row from this source.
Text-only baselines
Accuracy of guessers that never see an image. For each task the released training rows are split into two fixed halves by a hash of row_uid; each guesser is fitted on one half and scored once on the other (one held-out half, not cross-validation; eval rows below). The reference is chance (the mean of 1 / number of options) where every row is multiple choice, and otherwise the eval-half accuracy of always giving the answer most common in the fit half (when a task's top answers are nearly tied, this need not be the task's most common answer; the line after the table gives that answer's validation score). Accuracies are recounted from the stored rates and eval rows, so they are exact. A task is flagged when a text-only guesser beats its reference by more than 0.15 (for a free-form task, a guesser other than the most common answer). A flagged task can be partly answered from the text alone; an unflagged task passed only these probes, which do not prove the text carries no answer. Report scores on every task next to this baseline.
Guessers: keywords: the most common answer per set of spatial words in the question; last_mentioned: the option named last in the question body; letter_prior: the most common answer letter; majority: the answer most common in the fit half; numeric_offset: where every option is a number, the smallest or largest option plus or minus the offset the correct one sat at most often (last_mentioned on the other rows); option_prior: the option text that won most often when shown; option_rank: where every option is a number, the option at the rank among the sorted values that the correct one held most often (last_mentioned on the other rows); template: the most common answer per question wording (numbers masked, object names kept).
Always giving the most common training answer, scored on the validation split (the constant baseline to compare validation scores with): balltrackingnaive: always answering 1 (28.6% of training rows) scores 0.328 (76/232); maze_naive: always answering 5 (13.8% of training rows) scores 0.114 (27/236).
For manipulation_naive the count questions alone can be answered from the option list far better than the pooled numbers above show (see Known issues); S13's rank step did not run on them, because the group mixes numeric and object options.
Spot-check (S14)
Pending. The S14 rows are chosen and flagged S14.sampled_qa in meta and preview; the human pass over them has not been signed off yet.
Citation
MoTiF's card gives no citation. Please credit the repository, `OpenRaiser/MoTiF` (MIT).
Provenance
The release files were written by our conversion code (the code repository is not public yet), scripts/convert/export.py at commit 4aaee1f4e946, from build motif_r2. The build was made by scripts/convert/run_source.py from the same repository at commit 949af62f8ab7. S10, S12 and S13 ran before the export; reports/export_manifest.json pins every input the export read by SHA-1 (build_manifest_sha1, s10_keep_sha1, s12_assignments_sha1, s13_balanced_keep_sha1).
Every row removed between upstream and this release has one line, with its reason, in reports/: build/dropped.jsonl (rows refused before conversion or dropped by a conversion step); build/quarantine.jsonl (rows set aside by S4c because an automatic check could not match the read-back's conclusion to the label); s10_dropped.jsonl (duplicates removed by S10); s10_label_conflicts.jsonl (rows S10 withheld because another row asks the identical question, options in the same order, of the same images with a different answer); s13_dropped.jsonl (rows removed by answer-prior balancing). known_issues/ lists rows with a measured problem (see Known issues); reports/ also holds the build manifest (absolute paths cut to basenames) and counters, the S14 sample list (s14_sample.tsv: rowuid, task, split) and `exportmanifest.json. In reports/build/manifest.json, spec.sourcescenecorpus (proceduralgrid`) is only the converter's fallback for rows that carry no corpus of their own; it does not describe every row. Each row's corpus is `sourcescenecorpus` in `meta` (proceduralgrid 15,268, blender_clevr 5,797). Part of `yrlyrl/spatial-mmcot`.
