Skip to content
This repository was archived by the owner on May 13, 2026. It is now read-only.

feat: field-level interest category classification - #442

Merged
shiba4life merged 2 commits into
mainlinefrom
feature/field-interest-categories
Mar 30, 2026
Merged

feat: field-level interest category classification#442
shiba4life merged 2 commits into
mainlinefrom
feature/field-interest-categories

Conversation

@shiba4life

Copy link
Copy Markdown
Collaborator

Summary

  • Schema service now assigns interest categories (e.g. "Photography", "Cooking") to canonical fields via LLM classification at registration time
  • New field_interest_categories HashMap on Schema, propagated alongside existing field_data_classifications
  • INTEREST_CATEGORIES vocabulary in llm_registry::prompts::classification is the single source of truth
  • Startup backfill migrates existing canonical fields that predate this feature

Motivation

The discovery system previously derived "categories" from data_domain (6 coarse sensitivity labels like "general", "location") which are useless for social matching. This moves category ownership to the schema service where it belongs, using meaningful interest categories.

Test plan

  • All 453 existing tests pass
  • Clippy clean (zero warnings)
  • cargo check --features aws-backend compiles
  • New prompt tests for interest category vocabulary
  • New test for infer_interest_category graceful degradation without API key
  • Backward-compatible deserialization (serde default for new fields)

馃 Generated with Claude Code

The schema service now assigns interest categories (e.g. "Photography",
"Cooking", "Running") to canonical fields via LLM classification. Categories
are propagated to schemas via field_interest_categories HashMap, following
the same pattern as field_data_classifications.

- Add interest_category to CanonicalField (serde-compatible, backward compat)
- Add INTEREST_CATEGORIES vocabulary as single source of truth
- Add classify_interest_category_with_llm() and LLM prompt
- Add field_interest_categories to Schema struct + deserializer
- Propagate via apply_canonical_interest_categories() in add_schema/expand_schema
- Add run_interest_category_backfill() for migrating existing fields
- Interest category is best-effort (non-blocking on failure)

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
@shiba4life
shiba4life merged commit f0a562f into mainline Mar 30, 2026
2 checks passed
@shiba4life
shiba4life deleted the feature/field-interest-categories branch March 30, 2026 17:29

@chatgpt-codex-connector chatgpt-codex-connector Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

馃挕 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 8b77f013d1

鈩癸笍 About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

  • Open a pull request for review
  • Mark a draft as ready
  • Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 馃憤.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

// Propagate canonical field types, classifications, and interest categories to the schema
self.apply_canonical_types(&mut schema);
self.apply_canonical_classifications(&mut schema);
self.apply_canonical_interest_categories(&mut schema);

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P1 Badge Persist schema after applying inferred interest categories

At this point in add_schema, the schema has already been written to storage and cloned into self.schemas, so calling apply_canonical_interest_categories only mutates the local return value. For schemas that rely on server-side inference (the normal path for this new feature), subsequent reads from the registry will still have an empty field_interest_categories, and the data is lost across restarts because the persisted record was never updated.

Useful? React with 馃憤聽/ 馃憥.

// Propagate canonical field types, classifications, and interest categories to the expanded schema
self.apply_canonical_types(schema);
self.apply_canonical_classifications(schema);
self.apply_canonical_interest_categories(schema);

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P1 Badge Persist expanded schema after interest-category propagation

The same ordering issue exists in expand_schema: the expanded schema is persisted and inserted into memory before apply_canonical_interest_categories runs, so inferred categories are not reflected in the stored/registered schema state. Expanded schemas therefore miss interest categories in normal lookups and after reload, even though the method returns a schema object that appears populated.

Useful? React with 馃憤聽/ 馃憥.

Comment on lines +679 to +680
#[cfg(feature = "aws-backend")]
SchemaStorage::Cloud { .. } => {}

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P2 Badge Persist cloud backfill mutations instead of dropping them

In run_interest_category_backfill, the Cloud branch is a no-op after mutating schema.field_interest_categories, so backfilled categories are never written to DynamoDB. In AWS deployments this means startup backfill only changes in-memory state for the current process and all migrated categories disappear on restart.

Useful? React with 馃憤聽/ 馃憥.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant