audience-generate-list

Build an audience from an owned list

Purpose

audience-generate-list is the build leaf anchored on an owned list — the user arrives with people they already hold (customers, leads, accounts, engagement data), not a plain-English description of who to reach. It resolves that list to Watt entity IDs and emits a roster: the matched set, ready for the audience-activate and audience-analyze steps.

The "list" can already be resolved: a roster from a prior pass (a workflow:// entity-IDs URI, or a pasted roster record) is the same anchor — people the user holds — just past the resolve step. It enters here to be re-transformed: overlay scores it, lookalike profiles it for its defining signals; the resolve is skipped, and the roster's classification columns ride along into the play (the play's output roster carries its own columns, per the procedure contract). (Re-expanding a roster needs raw identifiers, which entity IDs alone don't carry — that's the export-addresses-then-expand round-trip below; grouping/crossing a roster aren't available here.)

The leaf is split from its sibling audience-generate-search by input anchor — an owned list here, a description there. The structural consequence is that elicitation starts from what the list is, not from "describe who you want to reach"; there is no discovery, no scoring, no composing.

This leaf ships four plays. Two match the list — resolve-only and expand, both resolution-driven, differing only in how wide the match is. One learns from the list — lookalike. One scores the list — overlay:

• resolve-only ("matched / customer match") — resolve the list to a tight matched set (the resolver's default floor), the people who are genuinely on the list. Runs the resolution procedure inline (context/resolution.md); the roster classification is minimal (source_provenance).
• expand ("the widest match set") — resolve the list wide: every entity any identifier plausibly matches (Noisy-OR, 1:many), gated only by a floor that defaults to 0. For maximum addressable reach — the wide roster feeds identifier maximalism at audience-activate. Runs the expand-roster procedure inline (context/expand-roster.md); the roster carries each entity's match confidence and corroboration count.
• lookalike ("more like them") — don't match the list, learn what defines it. Resolve the seed, then profile it for the signals that set it apart — durable identity by lift (interests, affinity, demographics, life-stage) plus the top intents by reach within the seed — and hand that signal pool back for the operator to tune. Runs the resolution procedure then the profiling procedure inline (mode B); emits a curatable signal pool, not a roster. It builds no audience itself — the tuned pool carries into a compose.
• overlay ("score / rank my list") — resolve the list, then lay a pool of signals over the resolved set and score each person by how many of those signals they express (overlay_score = Σ weightᵢ × matchᵢ; weights default to 1, so the default score is a plain count). Returns the whole list ranked — lead-scoring, "who's hot", prioritize-the-pipeline — and can optionally be cut to the matched slice (keep people expressing ≥ N signals — the intersection, "my list who also do X"). Unlike the other plays, overlay needs a brief for the signal pool — the brief defines the layer to score by, never the population (the list stays the population). Runs the resolution procedure inline, then the parent's discovery + scoring inline to build the scored pool, then the overlay-score procedure inline (context/overlay-score.md) to score and rank.