GTM Engineering Corpus

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 that knowledge as records you can download, diff, cite by ID and build on. The current release is 2026.10, last reviewed 2026-10-18.

What is in the corpus?

Each .jsonl file holds one JSON object per line. Records point at each other by @id: a scenario's fix names the patterns it applies, and a teardown check names the patterns that fix it and the scenarios it would have caught.

• GTM systems patterns. One record per named GTM systems pattern: context, problem, forces, solution, anti-pattern, an example stack, the revenue leak it closes and its related patterns.
• Pipeline debugging scenarios. One record per pipeline debugging scenario: the symptom, the system graph, the root cause and why, the fix and the patterns it applies, and the leak written as a formula in variables.
• GTM systems teardown checks. One record per teardown rubric check: the question, the failure smell, how to measure it, the fix, and the patterns and scenarios it points to.

Next to the record files sit /corpus/index.json (the release manifest), /corpus/DATASHEET.md (motivation, composition, collection, uses, distribution and maintenance, in the datasheets-for-datasets format), /corpus/CHANGELOG.md and /corpus/README.md.

How is it built?

There is one source. The pattern library, the debugging scenarios and the teardown rubric are TypeScript data modules in the site repository, and the HTML pages render from them. One generator, scripts/generate-corpus.mjs, writes the corpus files from the same modules, so a page and its file cannot say different things.

• Referential integrity. The generator refuses to write a release in which a fix, a check or a related-pattern link points at a record that does not exist.
• Deterministic output. Fixed key order, LF line endings, absolute URLs, and no clock: the release date is the newest review date across the records, so the same sources always give the same bytes.
• Verifiable copies. index.json carries the record count, byte size and sha256 hash of each file. Run shasum -a 256 patterns.jsonl on your copy and compare.
• Copy rules enforced. A record with an em dash, an arrow, a hashtag, a relative link or an off-site link outside a check's sources fails the build.

What does the license permit?

The files under /corpus/ are licensed CC BY 4.0. You may copy, adapt, translate and redistribute the records, commercially or not, inside your own tools, runbooks, courses and model training sets. The one condition is attribution: credit the GTM Engineering Corpus, Tom Regan, Artemis GTM, and link the record's @id or this page.

The license covers the corpus files only. The data briefs under /resources/research/ are a separate publication and keep their CC BY-ND 4.0 license, which allows republishing but not adaptation.

How do I cite the corpus or a record?

Cite the corpus as a whole with the panel below. To cite one record, use its @id: the URL of its anchor on the page that renders it. For example, the first pattern in the library is https://artemisgtm.ai/resources/gtm-systems-patterns/#owner-of-record-routing. Record IDs are stable across versions; add the version from index.json when you need to pin the exact wording.

Versions and changelog

Versions are named YYYY.MM. A new version is cut when records are added, removed or change meaning; a wording fix moves the review date without a new version. The full history is in /corpus/CHANGELOG.md.

• 2026.10 (2026-10-18). First release. Three record files built from the TypeScript that renders the HTML pages: GTM systems patterns, pipeline debugging scenarios and teardown rubric checks, cross-referenced by stable @id, with sha256 hashes and record counts in index.json.

What does the corpus deliberately leave out?

• First-party figures. No sample sizes, counts, rates or multipliers from Artemis GTM's own work. Where a scenario needs numbers to make its leak formula concrete, it carries labeled fictional scenario inputs, and every scenario record says so.
• Customer data. No client names, no CRM exports, no anonymized case studies. The failure modes are described as mechanisms, not as stories about a company.
• Personal data. No record describes an identifiable person.
• The quiz. The Pipeline Debugger needs wrong answers and hints to be a game. The corpus records only the diagnosis: the root cause, the fix and why.

Where are the records rendered?

• GTM Systems Pattern Library: every pattern as a card, with its forces, anti-pattern and related patterns.
• Pipeline debugging scenarios: the field guide, one diagnosis per scenario, and the Pipeline Debugger that plays them.
• GTM Systems Teardown Rubric: the checks, with the questions to ask of a live system and how to measure each one.

Frequently asked questions