Ballroom Person ReID: what our internal evaluation does—and does not—show

Consider a dancer in a black tailcoat crossing a blue-lit floor, partly hidden by another couple. The nearest retrieved crops share the coat and body shape. Does that make the first result correct? Does one internal benchmark tell you what will happen at another venue? No.

Ballroom photography is a difficult retrieval domain because motion blur, occlusion, dramatic lighting and similar costumes can all weaken appearance cues. PolyReID’s first model was developed around that workflow, so its evidence has to stay inside that boundary.

This article treats the April 2026 internal technical report behind polyreid-person-reid-v1 as an evidence record. It separates what the report documents, what is attested separately and what remains unverified. The public API exposes only the embedding stage; callers provide one crop containing one person.

Model described by the report

Start with the inventory. The report documents:

• a DINOv3 ViT-L/16 backbone with 307 million parameters;
• 256×128 person-crop input;
• a BodyOnly head using eight horizontal, confidence-weighted body bands;
• a 768-dimensional float32 output normalized to unit L2 norm;
• 90 training epochs;
• 240 identities;
• 15,576 training images and 1,838 held-out validation images;
• data from three ballroom event sources.

DINOv3 is a self-supervised visual representation approach published by Meta AI Research; readers can consult the DINOv3 paper and the model’s applicable licence separately. The PolyReID head and ballroom checkpoint are specific to this project.

The provider separately attests that training ran on an Apple M3 with 16 GB unified memory. Keep that statement in a different column: it is not in the technical report and says nothing about production GPU type, capacity or API latency.

What is not part of the endpoint

The API does not run a person detector or crop a crowd image. It does not perform OCR, face recognition, live tracking, pose estimation or name assignment. Those are separate components with separate errors and governance requirements.

If you draw one large “AI matching” box around the workflow, this boundary disappears. The actual sequence is narrower:

authorised person crop → versioned appearance embedding → scoped vector search → human review

Only the first arrow is the embedding API contract.

Internal evaluation status

The report contains internal ballroom validation results. Those numbers are the most tempting part to quote—and the part that must remain unpublished as API performance until the exact evaluated checkpoint hash is confirmed to match the immutable serving revision.

Even after that verification, those results would remain:

• proprietary internal validation, not independent evaluation;
• specific to the documented ballroom split;
• not cross-domain evidence;
• not a guarantee for an individual image, person or customer workflow.

This checkpoint gate prevents a plausible number from being attached to a different deployed artifact.

Known failure modes

Return to the opening scene: a similar coat, an occluded body and blue stage light are not edge decorations. They belong to the documented limits. The report and workflow analysis identify:

• near-identical costumes combined with similar body shape;
• severe motion blur;
• extreme occlusion or poorly framed crops;
• major costume changes;
• no explicit temporal or pose reasoning;
• no evidence of equivalent performance outside ballroom event photography.

An interface should therefore return ranked candidates, retain source context, and make rejection or correction easy. You must evaluate thresholds on the cameras, venues and population of the intended deployment.

The next checks are the person-crop quality checklist and the domain-shift evaluation guide.

What the workflow is designed to support

The defensible intended-use claim is modest: the workflow is designed to reduce a large gallery to a smaller, ordered review set. Vector search can retrieve similar crops across sessions without relying on a visible competition number; a reviewer still resolves look-alike costumes and ambiguous inputs. Whether that reduction is accurate or efficient enough for another event remains an evaluation question.

Read the report boundary before the headline number. For the retrieval layer, see ReID embeddings and vector databases. For request details, retention and errors, see the API integration guide. The AI transparency summary records the intended purpose and current legal-assessment status.