Evidence, trust, and scoring

GTM Brain separates observed facts, model classification, deterministic scoring, and human approval. A model cannot turn an unsupported statement into evidence or choose an arbitrary final score.

Evidence lifecycle

Every Signal V2 command carries a source namespace and ID, canonical content hash, retention policy, trust state, occurrence/expiry timestamps, and a reference to a governed snapshot. Full evidence is staged in tenant-scoped Lakebase or a Unity Catalog Volume; Temporal receives compact IDs and summaries only.

Trust is earned through persisted verification. Public text is untrusted input—even when it comes from a reputable site—and is delimited as data so prompt-injection-like instructions are ignored. Entity resolution uses verified identifiers; fact identity hashes deduplicate corroborating observations across sources.

{
	"sourceNamespace": "apollo",
	"sourceId": "job-98",
	"subtype": "data_platform_leadership_hire",
	"occurredAt": "2026-07-11T18:30:00.000Z",
	"confidence": 0.82,
	"evidence": [
		{
			"evidenceId": "evidence:job-98",
			"contentHash": "sha256:...",
			"trust": "unverified_public"
		}
	]
}

Qualification and abstention

Application code qualifies one of four immutable service plays: Health & Governance, Migration & Modernization, Agent-Ready Data Platform, or Databricks Application Delivery. Each play has direct signals, corroborating signals, disqualifiers, normalized buyers, and proof requirements. Recipient qualification is computed from the actual tenant-scoped provider contact—not inferred from a job title—and contact PII stays outside the model prompt and Temporal history. Tenant ICPs can use a strict play-specific buyer matrix or role-relevant matching for senior technical buyers across adjacent Databricks plays. Neither mode permits unknown, procurement-only, or insufficiently senior contacts to bypass policy. Generic funding, stale evidence, unsupported claims, or insufficient corroboration causes abstention.

The LLM classifies bounded categories such as trigger strength and outreach play. Application code computes ICP fit and recipient eligibility from persisted provider records, and gtm-scoring-policy-v1 computes deterministic dimensions and the final score. A failed contact or play gate forces skip without erasing valid ICP and trigger dimensions, so operators can distinguish “strong account, wrong recipient” from weak evidence. The persisted judgment pins the service-play, offer, prompt, scoring-policy, evidence, and proof versions, making a decision reproducible.

Proof assets

External claims use only an active, reviewed proof snapshot compatible with the exact offer version. Capture, review, marketing/security approval, promotion, retirement, and expiry alerts are governed Temporal mutations. Repository fixtures are test data, never production truth.

Privacy-safe evaluation

OTel/MLflow dimensions include versions, bounded categories, validation result, abstention/fallback, latency, and token/cost measures. Prospect PII, evidence quotes, prompts, and message bodies are excluded unless content telemetry is separately enabled and permitted by retention policy.

Next: Signals, Approvals, and AI gateways.