GTMOS

GTMOS is a GTM control plane that turns product signals, enrichment and CRM state into scored, routed, explainable account decisions, and then measures whether they produced pipeline.

Live demo: web-production-51214.up.railway.app — no sign-in, read-only (writes are refused server-side). Start at the rejected experiment, then an account's score breakdown and integrations. Demo runs on synthetic data (2,006 fictional accounts; nothing is ever sent).

• Ingest — PostHog-shaped product events, Clay-style enrichment and HubSpot change webhooks arrive signed, deduplicated and replayable; n8n workflows normalise and forward them.
• Decide — leads resolve to accounts, signals decay on a half-life, and a versioned 100-point score explains every point; routing assigns an owner against territories and SLAs.
• Act — an idempotent workflow engine (SKIP LOCKED, retries, dead-letter queue) drafts evidence-cited copy into an approval queue and reverse-ETLs gtmos_* fields into the CRM without touching rep-owned fields.
• Measure — attribution, funnel and experiments with guardrails: the seeded subject-line test wins reply rate by +16.3 pp and is still rejected, because negative replies rose 2.6% → 10.1%.

Stack: FastAPI · SQLAlchemy · Postgres · Redis/RQ · Next.js 16 · dbt · n8n · Docker · Railway

make setup    # uv sync + npm ci
make dev      # Postgres + Redis in Docker, migrate, seed, API :8010 + web :3010

---

Demo

Five screens, each showing the system making a judgement you can check. Every figure is computed live from the database.

It rejects the message that won. +16.3 pp on reply rate at p < 0.001 — and negative replies went 2.6% → 10.1% and unsubscribes rose from zero to 2.90%. A guardrail breach outranks the primary-metric win, so the recommendation is do not ship.

Every point traces to a rule. 98 out of 100, decomposed across five categories, each line carrying its evidence, confidence and half-life decay.

Generated prose cites numbered evidence, and inferences are labelled as inferences. A claim whose citation does not resolve is removed before the brief is shown; the brief never becomes CRM truth.

It says how far each connection has actually got. Two independent axes, mode and verification, derived from stored deliveries and sync runs — no hardcoded "Connected" badge. n8n is verified by execution on a local stack (transcript); the hosted demo is reseeded nightly, so it reports what has run on that instance.

The score is evaluated leakage-aware. Engagement features are downstream of the outcome, so the evaluation drops them: the structural AUC is 0.537 (95% CI 0.485–0.589) on synthetic data, reported ahead of the leakage-contaminated 0.593. See docs/scoring-evaluation.md.

The rest of the set — signals, pipeline, routing, workflows, data quality, the stack inspector, operations, the approval queue and a mobile view — is in docs/screenshots.md.

---

The problem

A modern go-to-market team runs on four kinds of system, and none of them talks to the others.

	Question it answers	Typical tool
Product analytics	What are users doing?	PostHog, Amplitude
Enrichment	Who is this company, really?	Clay, Apollo, Clearbit
Orchestration	How do these systems talk?	n8n, Zapier, Workato
CRM	Where does the revenue team work?	HubSpot, Salesforce

Each is good at its job. What none of them owns is the judgement layer: what a signal actually means, what an account is worth, who should work it, what may be said to them, and whether any of it worked. That gap gets filled by a spreadsheet, a HubSpot workflow nobody can test, and a scoring formula whose author has left. A GTM Engineer is hired to replace that with a system.

GTMOS is that system: the data model, the deterministic engines, the integration boundaries and the operating surfaces.

What it does

product signal → enrichment → scoring → routing → workflow → CRM → analytics

Concretely: a product event arrives and is matched to an account; enrichment fills in who that company is, keeping per-field provenance; an explainable score says how good a fit they are and why now; routing picks an owner against territories and SLAs; an idempotent workflow executes the steps; reverse ETL pushes computed fields into the CRM without touching anything a rep owns; and the analytics layer measures whether the whole thing produced pipeline — with the honesty to say when it cannot tell.

The golden flow

One command drives a single account through every boundary in the system:

make golden-flow              # 20 steps, direct to the API
VIA_N8N=1 make golden-flow    # the same, routed through the real n8n container

以上為 README 的開頭部分。其餘內容請閱讀原文。 檢視完整 README ↗