playbooks

home / skills / gtmagents / gtm-agents / signal-taxonomy

signal-taxonomy skill

/plugins/data-signal-enrichment/skills/signal-taxonomy

This skill helps define schemas, map topics, and enforce lineage for enriched signals across platforms.

npx playbooks add skill gtmagents/gtm-agents --skill signal-taxonomy

Review the files below or copy the command above to add this skill to your agents.

Files (1)
SKILL.md
1.1 KB
---
name: signal-taxonomy
description: Use to define schemas, topic tags, and lineage metadata for enriched
  signals.
---

# Signal Taxonomy Skill

## When to Use
- Normalizing multiple provider outputs into a unified schema.
- Rolling out new intent topics, enrichment attributes, or scoring dimensions.
- Auditing lineage + compliance requirements.

## Framework
1. **Schema Definition** – fields, datatypes, required/optional flags.
2. **Topic & Attribute Mapping** – align provider-specific attributes to canonical names.
3. **Versioning** – maintain change logs, effective dates, and migration steps.
4. **Validation Rules** – min/max values, allowed lists, dependency rules.
5. **Documentation** – publish data dictionary + lineage diagrams.

## Templates
- Data dictionary sheet (field, description, source, owner).
- Topic mapping table by provider.
- Migration checklist for schema changes.

## Tips
- Keep names human-readable for GTM teams but consistent with data warehouse standards.
- Tag every field with owner + refresh cadence.
- Pair with `identity-resolution` to ensure IDs and linkages stay consistent.

---

Overview

This skill defines schemas, topic tags, and lineage metadata to produce enriched, consistent signals for GTM systems. It helps normalize multiple provider outputs, manage schema versioning, and document lineage for audit and compliance. The focus is practical: clear field definitions, mapping templates, and validation rules to keep signals reliable across teams.

How this skill works

You create canonical schemas with fields, datatypes, and required/optional flags. Provider-specific attributes are mapped to those canonical names via topic and attribute mapping tables. Versioning, validation rules, and a published data dictionary capture change history, enforcement checks, and lineage metadata so downstream consumers can trust and trace each signal.

When to use it

  • Normalizing outputs from multiple enrichment providers into a single schema
  • Introducing new intent topics, enrichment attributes, or scoring dimensions
  • Auditing signal lineage and meeting compliance or data governance requirements
  • Coordinating schema changes across GTM, analytics, and data engineering teams
  • Defining metadata and ownership for downstream consumers and reporting

Best practices

  • Define human-readable field names for GTM while keeping warehouse naming conventions consistent
  • Tag every field with an owner and refresh cadence to assign accountability
  • Version schemas with effective dates and migration steps to prevent breaking changes
  • Apply validation rules (min/max, allowed lists, dependencies) and enforce via automated checks
  • Publish a data dictionary and lineage diagrams so consumers can trace each signal source

Example use cases

  • Mapping different providers' intent scores into a unified intent_topic and intent_score fields
  • Rolling out a new lead-scoring attribute with a migration checklist and backward compatibility
  • Auditing field provenance to answer compliance questions about how a revenue signal was derived
  • Standardizing event attributes across marketing and product analytics for consistent reporting
  • Pairing with identity-resolution to ensure stable IDs and correct signal linkage

FAQ

How do I handle breaking schema changes?

Create a new schema version with an effective date, provide migration steps, and support both versions during a defined transition window.

What validation rules are essential?

Start with required/optional flags, allowed value lists, min/max ranges for numeric fields, and dependency rules that enforce correct combinations.

Who should own the data dictionary?

Assign a field owner from the GTM or data team for each domain and ensure ownership is documented in the dictionary.