Keep AI Outfit Previews Separate From Fit Evidence: A Review UI Data Contract

The review screen in this example shows two cards side by side. The left card is a generated preview of a beige linen blazer on a person photo. The right card shows a charcoal wool coat on the same photo. Both came from the same try-on renderer and both carry an "AI preview" badge. Nothing on either card says whether a human has ever physically worn either garment.

That gap is a data model problem before it is a UI problem. An outfit review screen answers two different questions: what does this look like on a person, and does it fit. Those answers need separate records. This article outlines a proposed review UI data contract that keeps generated outfit previews separate from physical fit evidence. It is an illustrative design for a developer building a comparison or review screen. It is not the Dressora API and not an implemented Dressora feature. The IDs in the examples are synthetic.

Provenance on every preview

Every preview record stores its inputs explicitly: person photo ID, garment ID, render mode, quality tier, generation timestamp, and evidence kind.

{
  "previewId": "prev-71c0",
  "personPhotoId": "usr-3f9a",
  "garmentId": "gar-7a1d",
  "render": {
    "mode": "still-image",
    "qualityTier": "standard"
  },
  "evidenceKind": "generation-tested",
  "producedAt": "2026-08-27T09:12:00Z",
  "status": "preview-only",
  "fitEvidence": {
    "verified": false,
    "observedAt": null,
    "recordRef": null,
    "basis": "No physical fitting recorded."
  }
}

The contract keeps observation and generation in different record types. On 2026-08-27 a read-only public observation of the Dressora homepage confirmed the controls: a person photo upload control, a built-in outfit selection area, a custom outfit option, an AI styling helper, separate image and motion try-on choices, and Standard, HD and Studio quality selectors. That observation produced no output. No photo was uploaded and no generation was run. In the contract it becomes an observation record with evidenceKind: "ui-observed", a list of control names, and no previewId. A generated preview record always has evidenceKind: "generation-tested" and a previewId. The screen never renders an observation record next to a preview as if the controls produced that output.

Provenance makes each preview addressable. If personPhotoId changes, the record is a new preview. If garmentId changes, it is a new preview. If qualityTier changes from standard to studio, it is a new preview, because the renderer settings changed even though the inputs did not. The contract makes no claim about the cost or speed of generation. It only says which record produced which image.

Change one input at a time

A comparison screen wants to answer "which outfit is better". This contract states that as application policy: the screen only attaches a verdict when two previews differ in exactly one key field. That is a policy of this proposed screen, not a universal rule about every comparison tool.

• Same personPhotoId, same render mode, same quality tier, different garmentId: a valid outfit comparison.
• Different personPhotoId and different garmentId: a confounded comparison. The screen shows the outputs as unrelated and refuses a verdict.
• Same inputs except qualityTier: the outputs differ in rendering settings, not in the garment. The label reads "standard versus Studio" and does not imply the garment changed.
• Same inputs but different evidenceKind: not a comparison at all. A ui-observed record has no output, so there is nothing to compare.

Render mode is part of the comparison key. The observed homepage offers still-image and motion try-on as separate choices, so a still preview and a motion preview of the same garment are different evidence channels. The screen treats a mode difference like a tier difference: the record now claims something different, so the UI cannot quietly ignore it.

Fit evidence arrives from outside the renderer

Every preview starts with fitEvidence.verified set to false. Unknown fit evidence is the default state, and that is what the label "fit not verified" renders. The repository guidance behind Dressora is explicit: an AI preview cannot establish size, comfort, garment construction, fabric behaviour or product accuracy, and decisions that depend on those properties still require a physical fitting. The contract maps that into a rule. A fitting field can leave its default state only when a separate, verified fitting record exists, supplied by a trusted workflow, and the preview record references it with a recordRef. A timestamp and a basis alone do not prove a real fitting. They state a claim was made. They do not verify it.

Even then the scope is narrow. The supported label is "physical check recorded", nothing more. It documents that a physical check happened in that trusted workflow. It does not claim the garment will fit the current user. It produces no size recommendation, and it never converts the preview into fit-verified. status stays preview-only. No timestamp, no input and no renderer setting can ever set verified true. Only a verified fitting record from the trusted workflow can do that.

The specific test for a renderer that mislabels a preview as fit-verified is a UI expectation table. Each row names a record state and the only label the card may render.

Record state	Expected UI label
preview record with no fitEvidence object	"fit not verified", no size text
fitEvidence.verified false, observedAt null	"fit not verified"
fitEvidence.verified true, observedAt set, no recordRef	"fit not verified", record rejected
fitEvidence.verified true, recordRef to a verified fitting record	"physical check recorded" only, status stays preview-only

The third row is the trap. A renderer that treats "a preview exists" or "a timestamp exists" as proof of a fitting would render a size or verified-fit label there. The table asserts the opposite.

Acceptance check

Before this screen ships, verify four things. Every preview record carries personPhotoId, garmentId, render mode, quality tier and evidenceKind, and a ui-observed record never appears beside a generated output. The screen refuses a verdict unless two records differ in exactly one key field. fitEvidence defaults to verified false, and "physical check recorded" appears only with a recordRef to a verified fitting record from the trusted workflow. Encode the table above as UI tests, and require each row to render its expected label.

If those hold, the screen can show previews and fit evidence in the same view without ever confusing one for the other.