Task: Audit and classify entities: badge, image, or plain text

1. Enumerated every #+type: ores.codegen.entity model across all components (120 total, not the stale "108" the story's original description cited – adoption and the catalogue have both grown since).
2. Found real current adoption by parsing each model's ** Qt *** Detail fields table and checking the actual values in the badge_key=/=flag_source columns – not just whether those column headers are present, which every entity's table carries regardless of use and would have produced a useless 100%-adoption false positive. Confirmed by direct inspection: 8 entities have a real badge_key value, 15 have a real flag_source value (mostly all pointing at the same handful of lookup domains).
3. Identified the actual lookup/code-shaped entities each of those values points at (the true unit of classification – an entity is "a badge" or "an image", and every FK-like column referencing it inherits that treatment; the per-column badge_key=/=flag_source annotations are just where that inherited treatment gets wired in on the consuming side).
4. Classified every remaining lookup/code-shaped entity not yet covered against the policy below. Core business/operational entities that aren't lookup/code tables at all (party, book, trade, the *_instrument family, workflow_instance, market_observation, synthetic generation-config entities, etc.) were excluded up front – classifying them isn't what either merged story asked for.

• Image/flag: only for entities with an inherent, globally- recognisable real-world visual identity where an image asset already exists or is trivially obtainable – countries and currencies (flags), and by extension anything that IS one of those (currency pairs, business centres via their host country). This is a closed set; nothing else in the catalogue has this property, so no new image classifications are proposed.
• Colour badge: a small (roughly under ~20 rows), closed, semantically-meaningful classification or status domain, where a colour genuinely communicates something at a glance (active/ inactive, good/bad/warning, a small set of named types). This is the bulk of the classification work below.
• Plain text: everything else – in particular, technical conventions/parameters (day-count fractions, business-day conventions, IBOR/OIS/swap/FRA/deposit/CDS/zero conventions, floating-index types) and open-ended registries (ID schemes, trade ID types) where the value set is either too large, too technical, or too open-ended for a colour to add signal – it would just be colour noise. Also anything already excluded as not a lookup/code entity at all (see Method step 4).

• Image: country, currency, business_centre (via country).
• Badge: asset_class_code, book_status, currency_pair_classification, currency_pair_convention (business-day-convention field), curve_role, party_status, party_type, regulatory_book_type, tenor_kind, tenor_unit, book, counterparty, counterparty_identifier, instrument_code, party, party_identifier, payment_frequency, tenor.
• Both (not a policy violation – different fields, different purposes): currency_pair has flag icons on its base_currency=/ =quote_currency combos and a colour badge on its classification field. The "exactly one treatment" policy applies per rendered field, not per entity.

Core business, operational, or config entities – classifying these was never what either merged story asked for. Not enumerated individually: party, book, portfolio, the trading.*_instrument family, trade, trade_identifier, trade_party_role, lifecycle_event, workspace, tenant, compute.host=/=app=/ =app_version=/=batch=/=workunit=/=result, scheduler.job_definition, workflow.workflow_instance=/=workflow_step, reporting.report_definition=/ =report_instance, marketdata.* (all four), refdata.calendar=/ =calendar_exception=/=calendar_rule, refdata.counterparty=/ =party_contact_information family, synthetic.* (all six generation-config/component entities), dq.folder=/=catalog=/ =data_domain=/=subject_area=/=change_reason=/=code_domain=/ =badge_definition=/=badge_severity=/=dataset_bundle, database.database_info, controller.service_definition=/ =service_instance.

• Batch 1 (refdata, high-confidence) – DONE. Correction (found during implementation, not caught by this audit): only 3 of the 11 – calendar_type, currency_market_tier, monetary_nature – had existing code_domain=/=badge_definition=/=badge_mapping rows; the other 8 (book_purpose_type, business_unit_type, contact_type, ledger_feed_type, leg_type, purpose_type, rounding_type, tenor_anchor) needed that data authored first (46 values), same as Batch 2 will. All 11 are now self-badged.
• Batch 2 (cross-component, same pattern): change_reason_category (dq), account_type=/=tenant_status=/=tenant_type (iam), party_role_type=/=trade_type (trading), report_type (reporting).
• Batch 3 (documentation only, no code change): record the 18 plain-text decisions above directly in each entity's own .org model as a one-line comment/=:rendering_policy:=-style note (exact mechanism TBD by the implementation task), so the reasoning is discoverable at the model itself, not just in this task's Result.