Design: where should semantic context evaluation live?

[bokelley]

The current reference/context-agent is scoped to property-registry lookup + bitmap-based property targeting. Six semantic evaluation concerns are unbuilt on main:

1. EmbeddingMatch — cosine similarity between query embedding and content embedding
2. KeywordMatch — set intersection of required/blocked keywords
3. BrandSafety — category blocklist
4. GeoFilter — allow/block lists
5. DaypartFilter — day-of-week + hour ranges
6. CatalogMatch — product catalog to content topics

Prior design lived in closed PR #10. Before rebuilding, decide the home.

Options

• (A) Expand context-agent to carry a pluggable evaluator registry alongside the property registry
• (B) New reference/semantic-agent as a separate reference service
• (C) Move these into targeting/ as configurable predicates

Deciding factors

• Whether context-agent stays a lightweight registry lookup or grows into an evaluator
• Whether semantic matching is latency-critical (argues for colocating with targeting)
• Whether these need to be independently versioned and deployed

Decision needed before any implementation. Suggested owner: @bokelley.

[bokelley]

Triage

Classification: Feature request (RFC/design)
Bucket(s): context-agent
Status: ready-for-human

What the experts said:

• ad-tech-protocol-expert: Option C (targeting/ predicates) is protocol-correct — the six modules map directly to the existing PackageContextConfig predicate pattern (URLBlocklist, TopicTargets, etc.) and keep context-agent as a thin shell over the engine; Option B (new semantic-agent) would require a new router fan-out entry and wire-response merge strategy, making it a breaking protocol change; three open questions: GeoFilter may belong in the existing suppression path, EmbeddingMatch perf budget at 30ms constraint, BrandSafety overlap with existing ContentPolicies field.
• security-reviewer: EmbeddingMatch is the sole security-sensitive module — ephemeral-turn embeddings are user-behavioral fingerprints and must not transit the un-TEE'd context-agent process; the design must explicitly decide pre-computed publisher embedding (safe, any option) vs model-call at eval time (Option B only, with explicit TEE egress policy); the other five modules are pure publisher-side predicates with no user-identity risk and belong in Option C.

My take: Experts agree on Option C for five of the six modules; EmbeddingMatch requires a separate design decision on whether eval-time model calls are in scope (security blocker if so, from non-TEE context-agent). Suggested owner is @bokelley per the issue. Flag for human with that specific question as the blocking decision.

---

Triaged by Claude Code. Session: https://claude.ai/code/session_01XoWGV6yd5RVzftebEbxZ18

---

Generated by Claude Code