Skip to main content

Part 2 — Event Tagging

Part-DR of Notify-Me (CU-86c1p963g). Depends on Part 1 ontology; feeds Part 4 engine. How an event acquires the ontology tags the selector matches on.

TL;DR​

Every event carries a set of ontology leaf keys in a new column, groups.custom_filters_keys (JSON string[], ). v1 = manual tagging through a React modal that lists the ontology and writes the selected keys. v2 = an AI tagger that reads the event and proposes tags, with a confidence score and a human review queue. The tagger never invents tags — it may only emit keys that exist in the current ontology.

Data model ()​

  • groups.custom_filters_keys?: string[] (apps/groups/src/groups/groups.entity.ts) — the applied leaf keys.
  • Write path RPC GroupsEndpointsEnum.UPDATE_GROUP_NOTIFY_CATEGORIES → groups.controller.ts → updateOneById.

API ()​

  • PUT /api/v2/notify/events/:resourceId/notify-categories — internal-gateway, @SuperGuard, body { categories: string[] }.
  • GET /api/v2/notify/events?communityId= — list a community's events with their current keys.

Surfaces​

  • Manual tag modal (support-tool admin): an Events panel per community; each event shows its current tags and a Tag button that opens a modal rendering the ontology (grouped by category, selectable chips) → saves custom_filters_keys.
  • Productionization — in the event-edit form (Gali's decision): the tag modal belongs in the full event edit form (today the Yii views/groups/edit/form.php near custom_filters), so a community-admin/leader tags while editing. This needs a community-admin-scoped external-gateway endpoint (the current one is internal-gateway @SuperGuard) + the modal embedded in that form (React-in-Yii, same iframe pattern as the resident screen, or a native React event-edit once that migrates). Until then the admin surface (support-tool) is the interim place.

AI tagger (v2 — deferred within this DR)​

  • Input: event title + description + structured details. Output: JSON tag object (keys from the ontology only) + confidence (high/med/low) + a review note.
  • Runs on create/edit (FR-B7). Reads the ontology at run time so it can never emit an unknown tag (FR-B2).
  • Constraints from the spec: always attempt ≥1 CBN tag where applicable; EMG always includes a Severity; BIZ a Partner Role; CRD a Card Segment; don't confuse a CRD Card Segment with an AUD Audience.
  • Review queue: low-confidence or noted items are surfaced for a human to accept/edit before publish (FR-C1/C2). Overrides are stored to improve future tagging (FR-C3).
  • Runtime choice (spec OQ6): an in-platform service (apps/assistant-ai or a dedicated tagger) vs the /tagger agent. Lean in-platform for on-publish latency + auditability.

Decisions locked​

  • v1 = manual modal; AI tagger is a later phase inside this part.
  • Tags are stored as ontology leaf keys on the event; the tagger/modal are interchangeable producers — the engine is agnostic to which one wrote the keys (see Part 4).

Open questions​

  • Community-admin-scoped tagging endpoint (external-gateway) so tagging lives in the event-edit form for non-super-admins.
  • Whether historical events get back-tagged (batch AI run) or only new events (FR — retroactive was out-of-scope in the early spec).

Testing​

  • Manual: tag an event via the modal → custom_filters_keys persists → the digest matches residents on those keys.
  • AI (future): golden-set of events with expected tags; assert no invented keys; assert required sub-tags per category.