audience-analyze-signal

Analyze an audience from its signals

Purpose

audience-analyze-signal is the way into the read when the signals already exist — a signal stack fresh from audience-generate, an /watt:explore signal pool, a pasted audience record from a past session, or signals the user names. There's no discovery and no pivot loop: take the signals as given, materialize them, and hand the built stack to the shared read.

This is a delta over audience-analyze: the unique work here is just resolving the supplied signals into a built signal stack; the read and the shareable report are the parent's shared procedure (audience-analyze → The read & report), composed with verbatim — not restated.

Works with

• Called by: the audience-analyze router, when a built audience is in session or the user supplied its signals.
• Runs inline:
  • name resolution (only when the user supplied bare names) — resolve each named signal to its verified trait inline, following the discovery procedure (context/discovery.md), driving from meaning. Never used to discover more signals — the user's set is the set.
• Runs the read inline — the profiling procedure (context/profiling.md) in mode A (the stack) → the two-section read; the parent's shared read, run inline on the main thread.

Language

Inherits the parent's table (signals / must-haves / exclusions; lift explained once; sample named). The role column in an audience record — defining (any-of) / must-have (all-of) / exclusion (none-of) — carries the boolean shape exactly; the operator never sees AND/OR/NOT.

The flow

1 — Take the signals as given

• A built audience in session (fresh from generate, or composed in audience-analyze-search) — use it directly. Confirm which one in a word if there's any doubt.
• A re-supplied audience record — read from the saved record file in the working directory, pasted in, or compacted in context — the role column (defining / must-have / exclusion) carries the expression exactly as built, and names ride beside hashes; take it as the stack. A past session's reach/headcount is "measured then", not re-measured silently. On a refresh-shaped ask ("refresh this", "is it still ~2M?"), the read's fresh materialization is the re-measure: after the read, re-write the audience record per the record contract (context/record.md) with today's measured reach against the header's original target (reach 2.1M (band 1M–5M) · refreshed), location and roles unchanged.
• A signal pool (an /watt:explore session's kept signals, or a lookalike pool) — auto-compose it to the default stack: signals the pool marks must-have go all-of, its exclusions none-of, everything else any-of (one OR union). If the pool carries no role markers at all, ask once — "any must-haves or must-have-nots in here, or read them all as one group?" — then build. This is a deterministic reading of the user's picks, the same way a record's role column reconstructs an expression — never a strategy compose; refining the pool into a tuned stack is audience-generate's lane, offered if the read shows it's wanted.
• Signals the user names, no hashes — the leaf cannot fabricate a hash. Resolve each name to its verified trait inline, following the discovery procedure (context/discovery.md) — driving from meaning — surface the matches for a one-touch confirm, and only then build the stack. Never pass a name off as a hash, never guess one.