Layout as a JSON Prompt, Not a Hope

The claim I will defend is narrower than the headline: the load-bearing novelty of [MOSS-Image](https://openmoss.ai/MOSS-Image/) is not that it generates images but that it adds native layout control through a structured JSON prompt that travels alongside natural language. Confidence 66%. The falsifier: if the bounding-box schema is brittle in practice, or users abandon the JSON path because the coordinates fight them, then this is a demo feature, not an interface.

OpenMOSS's example declares a minimalist travel poster. A compact version of the captured JSON prompt:

```json { "summary": { "meta": ["poster"], "caption": "A minimalist travel poster with a cream background, a blue mountain illustration, and the title EXPLORE at the top." }, "items": [ { "label": "text", "caption": "Large dark-blue uppercase title centered at the top.", "text": "EXPLORE", "bbox": [-416, -384, -288, 384] }, { "label": "object", "caption": "A flat blue mountain illustration in the lower center.", "bbox": [-192, -288, 384, 288] } ], "bbox_coord_space": "abs_centralized", "bbox_format": "yxyx" } ```

_Compact excerpt only; the captured source also includes `"canvas": "single"` in the summary object._

Coordinates follow `[y_min, x_min, y_max, x_max]` measured in pixels from the canvas center. That is why `EXPLORE` has negative values. Those are not prose cues. They are coordinates a person or script can read and change; a typo is local.

But I have to draw the author-inference line. The page reports structured layout editing: "Edit text, element descriptions and bounding boxes to adjust image content and composition in a structured way." It does not report diffing, version control, or a source-file workflow. Those downstream ideas—including reuse-as-plan—are my inference from JSON being text, not page-reported features. I flag that once here and treat it as the line the rest of the piece walks.

The strongest source-visible counter is not an outside system; it is a conflict risk inside the same document. The same object is described twice—once by a caption and once by a bounding box—and those two sources of truth can disagree. The source also does not show failure cases for mismatched boxes and text, so I cannot measure how often the model resolves them.

Placement is the interface, though. Because the caption, strings, and boxes travel in the same JSON prompt, a poster stops being only a sampled outcome and starts being an editable plan: change `text` from `EXPLORE` to `MERCER`, move the mountain's y-coordinate, re-run. That reuse belongs to the inference flagged above, not to a source-reported diff feature. The source separately says the SFT model is fine-tuned from MOSS-Image-Base on curated data and, in the poster example, produces a clearer text group. I have not seen the outputs, so I am not claiming it beats anything; I am only claiming that structured layout control is the thing worth measuring.

If I see a failure set where box and text conflict, or a user report that JSON is harder than prose, I will lower the confidence.

The visual is a studio-generated pairing of the coordinate plan and the source-described poster result, not a MOSS-Image output; the captured source supports structured editing, not versioning.