feat: add brief concept party classification

docs/TODO.md

@@ -45,13 +45,13 @@ This is the ordered implementation roadmap following the accepted exhibit model.
 
 ### Party exhibits
 
-- [ ] Add a Party exhibit supertype representing an investigation participant.
-- [ ] Add a Person subtype with display name, normalized aliases, and extensible structured identity fields.
-- [ ] Add an Organization subtype covering businesses, public bodies, associations, and informal groups.
-- [ ] Add normalized many-to-many Party-to-Evidence associations with an optional explanatory note.
+- [x] Add a Party exhibit supertype representing an investigation participant.
+- [x] Add a Person subtype with display name, normalized aliases, and extensible structured identity fields.
+- [x] Add an Organization subtype covering businesses, public bodies, associations, and informal groups.
+- [x] Add normalized many-to-many Party-to-Evidence associations with an optional explanatory note.
 - [ ] Add typed Party-to-Party relationships such as employment, ownership, membership, control, and representation.
-- [ ] Build distinct Person and Organization widgets that can open as dossiers and reveal associated evidence without using folder ownership semantics.
-- [ ] Include parties, aliases, evidence associations, and party relationships in template/level cloning.
+- [x] Build distinct Person and Organization dossier presentations that reveal associated evidence without using folder ownership semantics.
+- [x] Include brief concepts, parties, aliases, evidence associations, and party relationships in template/level cloning.
 
 ## Milestone 4: first playable mystery
 

docs/exhibit-data-model.md

@@ -1,6 +1,6 @@
 # GUPI OSINT Board: canonical exhibit data model
 
-Status: accepted design foundation; the core schema, transactional template lifecycle, frontend exhibit registry, and Event workflow are implemented. Parties remain the next model expansion.
+Status: accepted design foundation; the core schema, template lifecycle, frontend registry, Event workflow, brief concepts, and Party subtypes are implemented. Interactive Party-to-Party relationships remain roadmap work.
 
 ## Vocabulary
 
@@ -180,7 +180,7 @@ A deferred constraint trigger verifies that both exhibits belong to the same boa
 
 In the frontend, the Event widget shows its occurrence time, narrative text, and evidence count. Opening or selecting it reveals its supporting exhibits. Lines between an event and its evidence visualize `event_evidence`; they are not ordinary folder containment bands.
 
-### Party semantics (planned)
+### Party and brief-concept semantics
 
 A party is a person or organization that participates in the investigation. Businesses are organizations. A party is a first-class exhibit, not a special folder: identity and evidence association must not be represented as file ownership.
 
@@ -193,6 +193,8 @@ The intended normalized shape is a `party_exhibits` supertype with one-to-one `p
 
 The frontend provides distinct Person and Organization widgets through the exhibit registry. They may visually behave like dossiers—opening one can reveal associated evidence—but that interaction is derived from `party_evidence`; it does not turn the party into a folder or cause evidence to be owned by or disappear into the party.
 
+A name appearing in the level brief begins as a normalized `brief_concept`, not as an exhibit. The author may record the expected Party classification, which is omitted from play-mode API responses. When the investigator classifies a concept as Person or Organization, the level creates a Party exhibit and records it in `resolved_party_exhibit_id`. This keeps the reasoning action explicit: the game does not pre-create a correctly typed party and merely hide its widget.
+
 ## Assets and document content
 
 `assets` stores immutable uploaded bytes, checksum, MIME type, original filename, and size. Multiple cloned document exhibits may reference one asset.