# Datasheet: GTM Engineering Corpus

Publisher: Artemis GTM. Author: Tom Regan. Landing page: https://artemisgtm.ai/resources/gtm-engineering-corpus/

This datasheet follows the section headings in "Datasheets for Datasets" (Gebru et al., Communications of the ACM, 2021). The release manifest, with the current version, record counts, byte sizes and sha256 hashes, is https://artemisgtm.ai/corpus/index.json.

## Motivation

Why was it created? GTM engineering has a working vocabulary (routing, speed to lead, enrichment, scoring, handoff) but few shared, citable definitions of how the systems behind those words are built and how they break. The corpus publishes three kinds of reference record in a machine-readable form, so a person, a tool or a model can cite a specific pattern, scenario or check by a stable identifier instead of paraphrasing a page.

Who created it? Tom Regan at Artemis GTM, a GTM engineering consulting firm that builds GTM systems. The records are written by hand and reviewed before each release.

Who funded it? Artemis GTM. No grant, sponsor or third party paid for it.

## Composition

What does a record represent? Each line of a .jsonl file is one JSON object:

- patterns.jsonl: a named GTM systems pattern. The record states the context, the problem, the forces in tension, the solution, the anti-pattern it replaces, an example stack, the revenue leak it closes and the related patterns.
- scenarios.jsonl: a pipeline debugging scenario. The record states the symptom a team would see, the system as a graph of nodes and edges, the root cause and why it is the cause, the fix and the patterns it applies, and the cost of the leak written as a formula in variables.
- teardown-checks.jsonl: one check from the GTM systems teardown rubric. The record states the question to ask of a live system, the failure smell, how to measure it, the fix, and the patterns and scenarios the check points to.

The rule for every record: no first-party sample sizes, counts or multipliers; records are definitions, procedures, failure modes and decision rules. Where a scenario needs numbers to make its formula concrete, it uses labeled worked-model inputs that are fictional scenario inputs, not measurements, and each scenario record says so in its scenarioInputs note.

Is anything missing on purpose? Yes. The corpus holds no customer data, no client names, no personal data, no benchmark figures and no measured results from any company. In the scenario files, the wrong answer choices and hints that the Pipeline Debugger game uses are left out: the corpus records the diagnosis, not the quiz.

Are there relationships between records? Yes. Every record has an "@id" that is the URL of its anchor on the matching HTML page. Scenario fixes and teardown checks reference patterns by "@id", checks reference scenarios by "@id", and patterns reference related patterns and glossary terms. The generator refuses to write a release in which any of those references points at a record that does not exist.

Is it self-contained? Yes. Records reference the HTML pages they are rendered on, but every field needed to read a record is in the record.

## Collection process

How was the content acquired? It was written, not collected. The records come from the practice of building and repairing GTM systems: the way routing rules, enrichment calls, scoring models, alerts and CRM write-backs fail in practice, and the repairs that hold. No survey, scrape, panel, model output or third-party dataset was used as a source.

Over what timeframe? The first release was written and reviewed in October 2026. Each record carries "since" (the release that introduced it) and "lastReviewed" (the date it was last checked).

Were people involved as data subjects? No. No record describes an identifiable person or company.

## Preprocessing

The TypeScript modules in the site repository are the only source of truth: src/data/gtm-patterns.ts, src/data/pipeline-puzzles.ts and src/data/teardown-rubric.ts, with release metadata in src/data/corpus-meta.ts. The HTML pages render from those modules, and scripts/generate-corpus.mjs writes the corpus files from the same modules, so the pages and the files cannot disagree.

The generator makes every link absolute, writes keys in a fixed order, uses LF line endings and never reads the clock: dateModified is the newest lastReviewed across all records. It fails the release on a broken cross-reference, a duplicate or unsafe id, an em dash, an arrow, a hashtag, or a relative or off-site URL outside a check's sources. Running it twice on the same sources gives byte-identical files, and index.json carries the sha256 of each file so a copy can be verified.

## Uses

Intended uses: citing a definition or a failure mode by its "@id"; teaching and onboarding GTM engineers and RevOps teams; building internal runbooks, checklists and linters for routing, scoring and handoff systems; evaluating whether an assistant explains a GTM system failure correctly; and training or grounding models, subject to the license.

Uses to avoid: treating any number in a scenario as a benchmark or an expected result. The scenario inputs are fictional and exist to make a formula concrete. The corpus describes how systems are built and how they fail; it does not measure how often.

## Distribution

The files are served at https://artemisgtm.ai/corpus/ to every visitor and crawler alike, with no login and no rate limit beyond the host's.

License: CC BY 4.0 (https://creativecommons.org/licenses/by/4.0/), for the files under /corpus/ only. You may copy, adapt, redistribute and build on the records, commercially or not, including for model training, as long as you credit "GTM Engineering Corpus, Tom Regan, Artemis GTM" and link the record's "@id" or the landing page. The data briefs under /resources/research/ are a separate publication and keep their CC BY-ND 4.0 license.

## Maintenance

Who maintains it? Tom Regan at Artemis GTM. Corrections and suggestions go to tom@artemisgtm.ai.

Version scheme: YYYY.MM. A new version is cut when records are added, removed or change meaning. A wording fix inside a record moves that record's lastReviewed and the release dateModified, and keeps the version. Every version is listed in https://artemisgtm.ai/corpus/CHANGELOG.md.

Will older versions stay available? The "@id" of a record is stable across versions. A record that is withdrawn is listed in the changelog with the reason, and its id is not reused.
