Signals feed

Signals are the evidence layer of GTM Brain. They represent observable changes in the market or in an account relationship—not model-generated assumptions.

Signal buckets

Legacy judgment weights start at job: 1, funding: 1, company: 0.7, and social: 0.3. During hardening, outcome analysis is shadow-only and cannot adjust production weights.

What a signal contains

A normalized signal has a stable source ID, account domain, display name, bucket, summary, occurrence time, and optional contact. Stable source identities and canonical fact bindings allow operational projections to consolidate provider retries, query-variant row IDs, and repeated campaign sweeps.

Signal V2 additionally pins subtype/schema/policy versions, confidence, expiry, evidence IDs, content hashes, provenance, and trust state. Apollo, curated Monid results, manual ingestion, and external agents all enter through the same composite sensing activity and durable Temporal command.

Raw collection observations and Fabric Platform AssetEvents remain immutable for audit and replay. The Signals feed, account workspace, approval review, account counters, and judge prompt use a shared read-model grouping: one canonical fact is shown once, its distinct sources are nested beneath it, and repeated collections of the same source revision are summarized with first-seen, last-seen, and collection-count metadata. This prevents polling frequency from inflating operator counts or model context without erasing provenance.

Example normalized signal:

{
	"sourceId": "apollo-job-org_42-job_98",
	"account": "northstar.ai",
	"accountName": "Northstar AI",
	"bucket": "job",
	"summary": "Hiring a Director of Data Platform in Austin",
	"occurredAt": "2026-07-11T18:30:00.000Z",
	"contact": {
		"firstName": "Avery",
		"lastName": "Chen",
		"email": "avery@northstar.ai"
	}
}

Use the feed

The Signals screen shows up to 200 recent canonical facts by default. You can:

• compare canonical signals, represented accounts, providers, and provider-verified evidence;
• search by account, company name, or summary;
• filter by one or more buckets;
• inspect the associated account state;
• open the account in a viewport-bound, independently scrollable workspace to compare the event with prior history.
• expand a fact's source section to inspect consolidated collection counts and exact public links.

Filtering is investigative only. It does not change ICP rules or exclude signals from judgment.

How Apollo sensing works

The Apollo adapter:

1. searches the employee bands allowed by the exact active ICP—starting at one employee when size is only a priority signal—for evidence-bearing job triggers such as explicit Databricks, Unity Catalog, migration, AI-platform, or lakehouse-application work;
2. applies the active tenant ICP's known industry exclusions before paid enrichment, then enriches a bounded number of remaining search results to obtain authoritative headcount, country, industry, and funding fields;
3. inspects relevant job postings inside the configured lookback window and emits recent funding rounds;
4. uses the current People API Search endpoint to identify an eligible buyer, then enriches at most one work-email record for that account;
5. requests neither personal emails nor phone numbers and returns the signal without a contact when enrichment finds no safe match.

The two enrichment caps are spend controls, independent of the organization search limit. The production campaign searches at most 100 organizations, then allows at most 15 organization enrichments and 15 people enrichments per pass. Apollo currently charges one credit for each successful organization match and one credit when people enrichment returns demographics or an email, so the configured enrichment ceiling is 30 credits per pass. A known excluded industry retains its signal for audit but consumes neither organization nor people enrichment credit. Authentication or scope failures stop sensing instead of silently degrading every account to an unusable profile.

Generic titles such as data engineer, head of data, or data platform are not production defaults. They may corroborate evidence from another governed source, but they are too broad to spend enrichment credits or qualify a first touch by themselves. Explicit Databricks and lakehouse roles normalize as Databricks adoption/expansion; migration, AI-platform, and application roles normalize into their corresponding governed service-play subtypes.

Useful deployment settings include:

APOLLO_JOB_KEYWORDS="databricks,unity catalog,snowflake migration,mosaic ai,agentic ai"
APOLLO_LOCATIONS="United States,Canada"
APOLLO_CONTACT_TITLES="VP Data,Head of AI,CTO"
APOLLO_MAX_ACCOUNTS="100"
APOLLO_MAX_ORGANIZATION_ENRICHMENTS="15"
APOLLO_MAX_CONTACT_ENRICHMENTS="15"
APOLLO_LOOKBACK_DAYS="60"

Organization-stored credentials take precedence over deployment environment settings. Without either, the system uses stub fixtures and Agents clearly reports that mode.

How Monid sensing works

Monid is optional and can run with or without Apollo. Only deployment-approved endpoint bindings can run, and each is re-inspected for schema and price drift before GTM spends credits. Results start as unverified_public, require a public source URL, and normalize into the same Signal V2 contract as Apollo. An active binding still fails closed when the completed run lacks bounded billing evidence; activation never relaxes inspect-hash, result-count, or cost caps. See Monid signal source.

Validate a signal before approval

Ask:

1. Is the event recent enough to create a genuine decision window?
2. Does the summary identify an observable fact rather than inferred intent?
3. Does the account match the configured ICP?
4. Is the contact relevant to the event?
5. Does why now quote or accurately paraphrase the trigger?

Next: Accounts, Approvals, and Integrations.