How should we find and compare related work?

Your earlier alternatives separated Campaigns from Content, or combined them and gave events a place of their own. Those were choices about how people browse, not a requirement for every piece to have one parent.

I recommend an all-work view alongside a grouping view. The grouping view can show campaigns, identity programs, projects and events. Filters can narrow either view without hiding work whose relationships are not known yet.

Brand identity, digital experiences and physical experiences can still have useful starting views. We should test their names and layout with real mixed collections rather than force every piece into one exclusive section.

A launch may bring together a film, a website, a model card, a chart and photographs of an event. A user-made board or reel can gather a different selection without changing what those pieces are.

The old recommendation treated Content as work outside campaigns. The current count measures missing recorded links; it does not establish that those pieces were made without a campaign.

This answer sets a browsing direction. It does not approve a final tab list or establish that the current app can already retrieve all these relationships.

Consider an illustrative launch film: a long cut and a short cut are distinct versions. The same short cut published in different places has different appearances. A screenshot records what was visible at a particular capture.

I recommend calling the distinct cut, language or layout a version. Keep its relationship to the work, and record where it appeared. Do not infer those relationships from a matching title alone.

The Ramp example is a captured web page and a screenshot of its top. The screenshot is not evidence of an alternate edit, and it is not the separately extracted hero image.

That distinction matters when someone opens a grouping: repeated captures should not bury the work, while useful variants should remain easy to compare.

Useful independent parts of a report or page remain browsable with links back, as you have already agreed. This question does not reopen that choice.

The earlier card called this a naming decision with no storage change. Explicit relationships may require storage and pipeline changes; those need a traced implementation plan after the meaning is settled.

This is the same question already pending in chat. Answer here or there; you do not need to answer twice.

Your August proposal argued that one type was too rigid and that secondary types should remain searchable. You later objected to secondary type and distinguished whole-piece types from demonstrations inside a film. Neither is being treated as final approval.

The distinction you made is essential: a demonstration inside a launch film is a moment. It is not enough reason to label the whole film a product demo.

My recommendation still permits a genuinely mixed whole piece, provided each type describes it end to end. Alternatively, keep one whole-piece type and express the other useful facts through its purpose, craft and moments.

The Operator example is stored as a product demo; the Nike example is stored as a commercial. Their titles and thumbnails do not prove whether a second whole-piece type is justified.

The counts show what the current field contains. They do not measure how many pieces ought to have several types, nor do they establish classification accuracy.

The current local prompt already gives choices for why a moment may interest a curator. It also asks whether the moment is animated, static, live or mixed. The older card overstated this as having no list at all.

This question is whether those meanings should become maintained filtering choices with definitions and examples. The exact wording of those choices still needs review; agreeing here does not approve the current list.

You approved collecting and reviewing open technique details. I recommend applying that same review approach to detailed visual descriptions, but that separate application still needs your answer.

The same word appearing in different fields is not automatically an error. What matters is whether it answers the question that field asks.

The live records include 2 motion values outside the choices shown in the local prompt. That demonstrates a mismatch to investigate, not a measured rate of incorrect video analysis.

These totals include separate human and analyzer records. They are not a count of unique moments. The pictures are examples of source films, not selected frames proving the classification of a particular moment.

Any repair must preserve human corrections and align the definitions, prompt, stored result and filter. This page does not establish that deployed code matches the local source.

You already approved one product identity and one family tree, with product-specific details attached. We are carrying that answer forward, not requesting it again.

The current database contains 391 undeleted product-line records and 139 product detail records. Those are different sets with different coverage; unequal counts alone do not establish duplication or loss.

The existing detail records refer to 139 distinct identities. That count alone does not establish that each link points to the right kind of identity or that every product has its required details.

The old card said there was no defect and nothing was lost. Those claims require checking the actual writes and references, and cannot be accepted from the diagram.

People should be able to find a product family and narrow to a model or feature. The exact navigation remains a later UX review; it does not require reopening the approved identity rule.

The source examples below give context for why product relationships matter. Their stored content types do not prove that the product connections are complete or correct.