Subjects: one identity, many signals

A person is not a face. Obvious in life, routinely wrong in software. It is January, an editor needs every clip of one athlete from the season, and for half of it he is wearing a helmet. Grouping by face found him at media day and on the sideline; his jersey number found him in the game footage. If your tool stores those as two different things, you now have two half-athletes, neither searchable as the person, and a merge job nobody budgeted.

The helmet problem

Grouping the same face across footage is honest, useful work with a hard boundary: the face has to be visible. A sports season spends most of its runtime past that boundary, behind helmets and distance and backs of heads. Conveniently, the jersey number is legible in exactly those shots, and useless at media day, where everyone is in a hoodie. The two signals cover each other's blind spots. Storing them as two separate systems, faces over here, numbers over there, is therefore not a small design mistake: the archive splits along the same line the evidence does, and the person you care about falls into the crack between them. The boundary is not a sports quirk either: masks on a job site, motorcycle helmets, the interview subject shot from behind for anonymity, all footage where the face is the one signal you do not have.

One entry, several kinds of evidence

The fix is a data model, not a bigger model. A subject is one durable identity that carries several kinds of evidence at once: face examples the app has grouped, appearance examples like a kit or a torso crop, and a jersey number bound through the roster. Which signal found him in a given clip is a detail recorded on that clip. The identity is the constant. In ClipLogger, every path that binds a name or a number to an identity goes through one resolver, so the athlete found by face on Tuesday and by number on Saturday cannot fork into two entries. And when signals disagree, the face evidence pointing at one player while the jersey on the same torso resolves to another, the disagreement is surfaced as a conflict for a human ruling, never settled by a coin flip.

Rosters seed the cast

The cheapest identity work happens before any footage is analyzed. Import the roster and every row becomes a person in the project's cast with the number already bound. From then on, a typed 72 resolves to a name while you log, a detected 72 resolves to the same entry the face evidence attaches to, and the AI can only propose people who exist: it cannot invent a stranger into your cast, because new names are locked to your roster and lookup tables. Ambiguity refuses politely, too. If two active players wear the same number, resolution returns nobody rather than guessing, which is the correct answer and the one a tired human would not give. Proposals then arrive attached to names you already know, which is most of what makes review quick.

Items and places are subjects too

None of this is people-specific. The prototype bike across a launch shoot, the hero product on a tabletop day, the one conference room that appears in every corporate interview: each is an identity with appearance evidence, and each earns the same single durable entry. Give it a name and a few marked examples and the same machinery treats it like anyone else in the cast, with appearance doing the work a face would do for a person. The test is simple. If you would ever search for it by name across a season, it deserves to be a subject, not a keyword you will have spelled four different ways by spring.

What one identity does to search

Unified identity is the difference between querying a person and querying your own filing habits. One entry means one search returns every clip he is in, whatever signal found him there, and the wholeness flows downstream: one filter facet, one token in a filename template, one line in the handoff the editor gets. Split identities poison all of it quietly, two searches with different counts and no reason to trust either. Renaming inherits the damage too: a confirmed subject can become part of a filename, and a name is only worth baking into files once the identity behind it is whole.

There is a portable check for whatever tool you use. Search for the same person two ways, by name and by whatever detection produced them, and compare the counts. If they differ, stop and fix identity before logging another card, because every clip logged onto a split makes the eventual merge worse.

Store the person once and let the evidence vary by clip.