Draft Specification

Open GTM Data Schema

A machine-readable and human-readable data standard for sales and marketing systems. Defines canonical object names, field names, field types, field constraints, allowed values, relationships, and examples for common go-to-market data.

View on GitHub Browse Objects

1. Purpose

The Open GTM Data Schema is a machine-readable and human-readable data standard for sales and marketing systems.

The standard defines canonical object names, field names, field types, field constraints, allowed values, relationships, and examples for common go-to-market data. It is intended to help product builders, integration developers, data teams, and AI agents understand and exchange sales and marketing data using a shared vocabulary.

The standard is not a CRM, marketing automation platform, consent management platform, enforcement engine, legal interpretation layer, or vendor-specific mapping system.

2. Scope

The standard defines:

Included	Description
Objects	Canonical records used in sales and marketing systems.
Fields	Canonical field names and field definitions.
Field types	Standardized data types such as string, date, email, enum, boolean, currency, and object reference.
Constraints	Validation constraints such as required status, regex patterns, maximum length, minimum value, and allowed values.
Relationships	Canonical relationships between objects.
Vocabularies	Reusable allowed-value sets shared across objects.
Examples	Sample records or field values that clarify usage.

The standard does not define:

Excluded	Reason
Vendor-specific enforcement	The standard does not own vendor behavior.
Legal interpretation	The standard does not define legal obligations or compliance decisions.
System-of-record assumptions	Implementation architecture is outside the core schema.
Vendor mappings	Mappings to Salesforce, HubSpot, Marketo, Adobe may be created later as separate implementation guides.
Product behavior	The standard defines data structures, not application workflows.

3. Standard Format

The standard uses two parallel formats:

Markdown

Human-readable documentation.

JSON

Machine-readable schema definition.

Each canonical object should have both a Markdown document and a JSON schema document.

4. Recommended Repository Structure

/open-gtm-data-schema
  standard.md
  standard.json

  /objects
    /shared
    /sales
    /marketing
    /consent-preferences

  /vocabularies
    lifecycle-stage.json
    campaign-type.json
    activity-type.json
    consent-status.json
    data-use-category.json

  /workgroups
    sales.md
    marketing.md
    shared.md

5. Core Schema Unit

The base unit of the standard is:

Object
  Fields
  Field constraints
  Relationships
  Examples

Each object definition should include:

Section	Description
Object name	Canonical machine-readable object name.
Display name	Human-readable object name.
Description	Plain-language definition of the object.
Primary workgroup	Workgroup responsible for maintaining the object.
Fields	Canonical field definitions.
Relationships	Links to other standard objects.
Examples	Sample object records or field values.

6. Field Definition Format

Each field should include:

Attribute	Description
fieldName	Canonical machine-readable field name.
displayName	Human-readable label.
description	Plain-language explanation of the field.
dataType	Standard field type.
required	Whether the field is required by the standard.
unique	Whether the field value should be unique within the object.
constraints	Field validation constraints.
allowedValues	Allowed values, when the field is an enum.
vocabulary	Reference to a reusable vocabulary, when applicable.
examples	Sample values.
dataUse	Optional field-level data-use metadata for declared downstream use.

8. Constraint Format

Field constraints use JSON Schema-compatible terms where practical.

Constraint	Description
minLength	Minimum string length.
maxLength	Maximum string length.
pattern	Regex pattern.
format	Known format such as email, uri, date, or date-time.
minimum	Minimum numeric value.
maximum	Maximum numeric value.
enum	Allowed values.
minItems	Minimum array length.
maxItems	Maximum array length.

9. Relationship Format

Each relationship should include:

Attribute	Description
relationshipName	Canonical relationship name.
sourceObject	Object where the relationship originates.
targetObject	Object the relationship points to.
cardinality	Relationship type.
required	Whether the relationship is required.

Supported Cardinalities:

one-to-one

One source record relates to one target record.

one-to-many

One source record relates to many target records.

many-to-one

Many source records relate to one target record.

many-to-many

Many source records relate to many target records.

10. Workgroup Ownership Model

The Open GTM Data Schema remains one standard. However, specific object families are maintained by community workgroups with direct subject-matter interest. Each object has one primary owning workgroup.

Ownership means responsibility for:

•Object definition - Maintaining the canonical object definition.
•Field list - Maintaining the recommended canonical fields.
•Field constraints - Defining field types, required status, allowed values, and validation constraints.
•Relationships - Defining relationships to other standard objects.
•Change proposals - Reviewing proposed changes for the object.

11. Phase 1 Object Inventory

Phase 1 includes 21 objects across three workgroups.

Shared / Core Workgroup

Object	Purpose
Person	A human individual represented in a GTM system.
Organization	A company, institution, agency, nonprofit, or other entity.
Account	A commercial relationship with an organization, household, or buying group.
Contact	A known person associated with an account or organization.
Activity	A recorded interaction, task, or event.
Message	A sent or received communication.
ConsentRecord	A structured record representing consent, opt-in, opt-out, withdrawal, or restriction.
CommunicationPreference	A channel, topic, subscription, or frequency preference.
PrivacySignal	A machine-readable privacy signal received, detected, or stored by a system.
DataUseDeclaration	A field-level declaration of how submitted data may be used downstream.

Sales Workgroup

Object	Purpose
Lead	A potential commercial relationship that has not yet become durable.
Opportunity	A potential revenue event.
Product	Something sold, licensed, subscribed to, renewed, or bundled.
Quote	A proposed commercial offer.

Marketing Workgroup

Object	Purpose
Campaign	A coordinated marketing or sales effort.
CampaignMember	A person, lead, contact, account, or organization's participation in a campaign.
Segment	A defined audience group.
List	A static or dynamic collection of records.
FormSubmission	A submitted form interaction.
WebVisit	A visit to a web property.
Touchpoint	A meaningful interaction used for journey or attribution analysis.

12. Phase 2 Object Inventory (Reserved)

Phase 2 objects are intentionally excluded from the Phase 1 schema but are reserved for later work.

Data Quality

ValidationRule
A reusable rule for validating field values, records, or relationships.
DuplicateGroup
A group of records identified as likely duplicates.
FieldLineage
A record of field origin, transformation, or propagation across systems.
SchemaMapping
A relationship between a canonical schema element and another schema element.

AI / Agent Readiness

AgentAction
A recorded or available action performed by an AI agent.
Recommendation
A recommendation produced by an AI system, model, workflow, or agent.
GeneratedContent
Content generated by an AI system, model, workflow, or agent.
ApprovalRecord
A record of review, approval, rejection, or override for generated output.

Start Using the Schema

Download the schema files, contribute to the standard, or join a workgroup.

View on GitHub Join a Workgroup