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

Ballroom photography is a difficult retrieval domain: motion blur, occlusion, dramatic lighting and similar costumes can all weaken appearance cues. PolyReID’s first model was developed around that workflow, but its evidence must be described within that boundary.

This article summarises the April 2026 internal technical report behind polyreid-person-reid-v1. The public API exposes only the embedding stage: callers provide one crop containing one person.

Model described by the report

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. That detail 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.

This distinction corrects a common architecture diagram that makes a ReID model appear responsible for an entire photo pipeline. In reality:

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. PolyReID will not publish them 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

The report and workflow analysis identify several practical limits:

• 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.

A production interface should therefore return ranked candidates, retain source context, and make rejection or correction easy. Thresholds must be evaluated on the deployer’s own cameras, venues and population.

Why the workflow remains useful

The goal is not to eliminate judgement. It is 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, while a reviewer resolves look-alike costumes and ambiguous inputs.

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.