Most go-to-market software is built around the wrong object.

The CRM is built around the account and opportunity. Marketing automation is built around the person and campaign. Competitive-intelligence tools are built around the competitor and alert. Enablement is built around the asset. Product analytics is built around the user and event. Conversation intelligence is built around the call and transcript.

Each object is reasonable inside its system. The failure appears between systems. A competitor changes pricing. A prospect mentions the change in a call. A product manager adjusts packaging. Marketing updates a comparison page. Sales keeps using an old battlecard. An analyst publishes a category definition that makes the company look fragmented. Six systems record fragments; none represents the commercial interpretation that connects them.

Companies respond by building a data warehouse, a search layer or an AI assistant. These improve access. They do not necessarily improve truth.

A warehouse can tell us what records exist. Search can retrieve semantically similar text. A language model can produce a fluent synthesis. None of these operations, on its own, answers the questions that matter:

These are systems questions disguised as marketing questions.

I believe the next useful generation of GTM infrastructure will resemble a compiler more than a content repository. It will ingest heterogeneous events, parse them into a typed intermediate representation, resolve identity and time, evaluate business semantics, apply policy and emit target-specific artefacts: an account brief, message update, battlecard delta, launch risk, product hypothesis or executive decision.

This essay describes that architecture. It is intentionally technical because the abstraction matters. If the system is designed as “put our documents in a vector database and add an agent”, its failure modes are determined before the first impressive demo.

1. The missing object is the interpreted signal

An alert is an observation delivered to a user. It becomes a signal only after somebody, human or machine, connects it to a consequential hypothesis.

“Competitor changed homepage” is an alert. “Competitor removed implementation language from the enterprise page three weeks after launching a services partnership, increasing the probability that delivery complexity is constraining the new product” is an interpretation. “Update discovery guidance for active displacement deals to test implementation ownership” is an action.

Most tools stop at the first sentence or use a language model to jump directly to the third. The important object sits between them.

I define a signal as a governed interpretation of one or more observations that changes the probability of a commercially relevant hypothesis.

That definition creates requirements.

A signal has lineage

The system must preserve the observations and sources from which the interpretation was derived. A generated summary without lineage is content, not intelligence.

A signal is conditional

The same event may mean different things for different products, segments or strategies. A competitor’s price decrease matters if price is a live selection criterion and the competitor overlaps the target. Otherwise it may be noise.

A signal has confidence

Confidence is not model certainty alone. It includes source reliability, corroboration, entity resolution quality, temporal relevance and the strength of the causal link to the hypothesis.

A signal has half-life

Some signals decay quickly. A personnel change may create a short account-entry window. A regulatory change may remain relevant for years. The system needs expiry and revalidation semantics.

A signal can be superseded

New evidence may strengthen, narrow or invalidate an interpretation. The history should remain queryable without presenting the obsolete signal as current truth.

A signal has an action boundary

The system should know whether it can notify, draft, recommend, update or execute. Confidence and permission determine the boundary.

The signal, not the document, becomes the unit of GTM knowledge.

2. Why a compiler is the useful metaphor

A compiler transforms source code into an executable target through explicit stages. It does not ask a probabilistic model to read a repository and improvise machine instructions. It tokenises, parses, builds an intermediate representation, checks types, optimises and emits output for a target environment.

A GTM signal compiler can use an analogous pipeline:

GTM signal compilerGoverned transformation pipeline · select a stage
Stage 01 · InputObserve

Capture raw calls, market events, product behaviour, account change and external evidence without overwriting history.

Stage 02 · ParseType

Convert heterogeneous observations into canonical events with explicit fields, source identity and validation state.

Stage 03 · ResolveReconcile

Resolve entities, valid time, observed time and conflicting evidence before interpretation begins.

Stage 04 · RepresentGTM-IR

Build a stable intermediate object connecting entities, claims, hypotheses, evidence, confidence and expiry.

Stage 05 · GovernEvaluate

Score meaning and actionability, then enforce tenant, role, confidence and policy boundaries.

Stage 06 · OutputCompile

Emit target-specific battlecard deltas, account actions, message warnings, product hypotheses and executive briefs.

One resolved signal · Many traceable field outputs
raw sources
    ↓
ingestion + immutable observations
    ↓
parsing + canonical event types
    ↓
entity resolution + temporal reconciliation
    ↓
GTM intermediate representation (GTM-IR)
    ↓
hypothesis evaluation + meaning/action scoring
    ↓
policy, tenancy and confidence checks
    ↓
target compiler
    ├── battlecard delta
    ├── account action
    ├── message warning
    ├── product hypothesis
    └── executive brief

The metaphor is more than decoration.

Parsing is not interpretation

Extracting “Company A launched Product B at £X” is parsing. Determining that the launch changes a competitive assumption is semantic evaluation. Systems fail when these are collapsed into one prompt because errors become difficult to locate.

Intermediate representation creates leverage

A compiler does not generate separate understanding for every target. It builds a stable representation and compiles it differently. A GTM system should not independently ask an LLM to create a battlecard, an account brief and a product memo from raw sources. It should resolve the signal once, then render target-specific views with traceable transformations.

Types prevent nonsense

If pricing_change requires a product, currency, amount, effective date and source, the system can reject or quarantine incomplete observations. If a recommendation references a segment that does not exist in the tenant ontology, compilation fails visibly rather than hallucinating a plausible label.

Optimisation follows correctness

You can cache embeddings, batch enrichment, use smaller models and precompute graph neighbourhoods after the semantic pipeline is defined. Starting with optimisation around an unstable ontology produces a fast system that answers the wrong question.

A minimal GTM-IR signal object

signal_id, tenant_id, event_time, observed_time, valid_from, valid_to, entities[], event_type, claims[], affected_hypotheses[], meaning_score, actionability_score, confidence, evidence[], recommended_actions[], policy_state, supersedes, expires_at.

The exact schema will vary. The discipline is to make interpretation explicit and queryable.

3. Event sourcing preserves how the market became known

Traditional applications store current state. A competitor table shows the current price, category and positioning. That is useful until the question is, “What did we believe when we changed our pricing?” or “Why did the battlecard say this in March?”

Market intelligence is intrinsically historical. The path matters.

Martin Fowler’s definition of event sourcing is simple: capture changes to application state as a sequence of events. This makes it possible to reconstruct past state, replay events and create alternative projections.

For GTM, the event log might contain:

{
  "event_id": "evt_01J...",
  "tenant_id": "tnt_segment8",
  "event_type": "competitor.pricing.observed",
  "subject": {"type": "product", "id": "prd_acme_enterprise"},
  "occurred_at": "2026-05-14T09:00:00Z",
  "observed_at": "2026-05-16T11:42:18Z",
  "source": {
    "url": "https://acme.example/pricing",
    "content_hash": "sha256:...",
    "snapshot_id": "snap_01J..."
  },
  "payload": {
    "previous": {"billing": "annual-contact-sales"},
    "current": {"billing": "usage-based", "minimum": 24000},
    "currency": "GBP"
  },
  "schema_version": 3
}

The event is immutable. If extraction was wrong, do not overwrite it. Append a correction event that references the original. This preserves auditability and allows projections to be rebuilt with the corrected interpretation.

Why does this matter commercially?

GTM decisions are made under partial information. A clean historical record allows the company to evaluate the judgment and the outcome. If a competitor strategy succeeded, was the original signal available? Did the system surface it? Was confidence calibrated? Did the team act? Was the hypothesis wrong or the execution slow?

Without event history, post-mortems collapse into memory and politics.

Event sourcing also decouples ingestion from views. The raw log remains stable while projections evolve:

The projections can be discarded and rebuilt. The observations cannot.

There are costs. Event schemas evolve. Replays must avoid triggering external side effects. Storage grows. Developers must reason about eventual consistency. Fowler explicitly notes that event-sourced programming can feel unnatural. The pattern should not be applied to every table. Use it where history, provenance and reconstruction are first-class requirements. GTM intelligence qualifies.

4. One timestamp is not enough

Market systems need at least two clocks.

Fowler’s event writing distinguishes when an event occurred from when the system noticed it. In temporal databases this expands into a bitemporal model:

Suppose a competitor changed pricing on 1 April, but the crawler observed it on 9 April. A seller lost a deal on 5 April. If the system stores only updated_at = 9 April, it cannot answer whether the change was present in the market during the deal. If someone later discovers that the pricing had actually changed on 28 March, the valid history changes while the record history must remain intact.

A bitemporal claim table might look like:

create table claim_versions (
  claim_version_id uuid primary key,
  tenant_id uuid not null,
  subject_id uuid not null,
  predicate text not null,
  object jsonb not null,
  valid_during tstzrange not null,
  recorded_during tstzrange not null,
  asserted_by uuid not null,
  confidence numeric(4,3) not null,
  evidence_ids uuid[] not null,
  supersedes uuid
);

Now we can ask two different questions:

-- What do we currently believe was true on 5 April?
select * from claim_versions
where valid_during @> '2026-04-05'::timestamptz
  and upper(recorded_during) is null;

-- What did the system believe on 5 April about that same day?
select * from claim_versions
where valid_during @> '2026-04-05'::timestamptz
  and recorded_during @> '2026-04-05'::timestamptz;

These queries return different truths by design. Time has done what time does and made a previously simple story administratively inconvenient.

Temporal correctness matters for more than competitive data. Positioning claims have effective periods. Product capabilities move from beta to general availability. Regulations are announced, adopted and enforced on different dates. People change roles. Accounts enter and leave target conditions. Customer evidence ages.

Embedding-only systems tend to flatten time. A semantically relevant chunk from two years ago may rank above a current but differently worded source. Time must be an explicit retrieval and validity constraint, not a sentence the model is expected to notice.

5. The ontology is the product strategy made structural

An ontology defines the kinds of things the system knows and the relationships it permits. In GTM, this is politically difficult because functions use different models of the same business.

Sales sees accounts, contacts, opportunities and stages. Product sees capabilities, workflows and jobs. Marketing sees audiences, messages, campaigns and content. Customer success sees adoption, health and outcomes. Strategy sees markets, alternatives, positions and bets.

A small semantic core with bounded domain extensions works better than one enormous universal schema. The enormous version usually begins life as “the single source of truth” and ends as a Victorian attic in which nobody is willing to open the final cupboard.

The core entities might include:

Relationships carry meaning:

Organisation  EXPERIENCES       Problem
Product       PROVIDES          Capability
Capability    CHANGES           Workflow
Workflow      PRODUCES          Outcome
Segment       VALUES            Outcome
Product       COMPETES_WITH     Alternative
Claim         ABOUT             Entity
Evidence      SUPPORTS          Claim
Signal        UPDATES           Hypothesis
Action        RESPONDS_TO       Signal

The graph should not attempt to represent every sentence. It should encode relationships that improve retrieval, evaluation or action.

Entity resolution is the unglamorous foundation

“JPMorgan”, “J.P. Morgan”, “JPMorgan Chase & Co.” and a domain may refer to one organisation. “Copilot” may refer to products from several companies. A person can change employer while an old source remains accurate for its date.

Entity resolution combines deterministic keys, aliases, domains, external identifiers, contextual similarity and human review. Every resolved link should carry confidence and method. Do not silently merge uncertain entities; create a candidate edge.

Bad entity resolution poisons every downstream layer. The most articulate model cannot recover if the evidence belongs to the wrong product.

Ontology versioning is strategy versioning

When the company changes its segmentation or product architecture, historical records should not be rewritten as if the new ontology always existed. Maintain mappings and effective dates. A segment may split. A capability may move products. A category may be deprecated.

This is where GTM architecture and positioning operations meet. The system forces teams to decide whether two terms are aliases, parent-child concepts or genuinely different market frames.

6. Retrieval should be hybrid, constrained and attributable

Vector search is useful. It is not a knowledge strategy.

Embeddings compress semantic similarity. They are excellent for discovering related language, especially when the query and source use different words. They are weak at exact identity, temporal validity, negation, permissions and multi-hop structure unless those constraints are supplied elsewhere.

A useful GTM retrieval layer combines four methods.

Lexical retrieval

Exact terms, SKUs, acronyms, regulatory clauses, pricing values and product names matter. BM25 or database full-text search remains valuable.

Vector retrieval

Semantic similarity surfaces related claims, call moments and source passages. Use metadata filters for tenant, entity, time, source class and validity before or during retrieval.

Graph traversal

Questions often require relationships. Consider, “Which active target accounts use a competitor affected by this pricing change and have an open opportunity where implementation cost was mentioned?” Answering it requires a constrained traversal across entities and events. Nearest-neighbour search alone will return something semantically friendly, much like an enthusiastic junior researcher who has found several interesting articles and none of the answer.

Temporal query

The answer may depend on current state, state at a past date or what was known at that date. Make the temporal mode explicit.

Recent work on graph-centred RAG argues for combining structured relationships with semantic retrieval because unstructured similarity alone struggles with multi-hop reasoning and provenance. The architecture is still evolving, but the principle is sound: retrieval strategy should follow the question type.

A query router can classify intent:

type RetrievalPlan = {
  lexical?: LexicalSpec;
  semantic?: VectorSpec;
  graph?: TraversalSpec;
  temporal: "current" | "valid_at" | "known_at";
  provenance: "required";
  tenantId: string;
  policyContext: PolicyContext;
};

The final context should contain evidence packets, not anonymous chunks:

{
  "claim": "Acme moved Enterprise to usage-based pricing",
  "valid_from": "2026-04-01",
  "confidence": 0.91,
  "sources": [
    {"snapshot_id": "snap_1", "span": [184, 291], "hash": "..."},
    {"call_id": "call_8", "timestamp": "00:18:42", "speaker": "buyer"}
  ],
  "contradictions": [],
  "entity_resolution": {"id": "prd_acme_enterprise", "confidence": 0.99}
}

Generation should cite packet IDs. A post-processor verifies that every factual sentence maps to evidence. Unsupported sentences are removed, marked as inference or routed for review.

7. The meaning engine is not a sentiment model

Most alert systems optimise relevance. Relevance asks whether a source is about a tracked entity or topic. Meaning asks whether it changes a consequential assumption.

The meaning engine evaluates signals against a tenant’s live GTM model:

I separate meaning from actionability.

meaning = impact × scope × strategic sensitivity × novelty × confidence

actionability = controllability × time-window × owner-clarity × evidence-sufficiency

These are conceptual functions, not universal equations. The implementation may mix rules, learned ranking and human calibration.

Impact

What changes if the interpretation is true? Revenue, win probability, product risk, market credibility, customer trust or strategic option value.

Scope

How much of the target model is affected? One account, a segment, the full product line or the category.

Strategic sensitivity

Does the signal touch an assumption on which the current strategy depends? A small change to a critical assumption can matter more than a major announcement outside the target.

Novelty

Does the evidence add information or repeat an established pattern? Five articles about the same launch should not become five signals.

Confidence

Source reliability, corroboration, extraction quality, entity resolution and inference distance.

Actionability then asks whether there is an appropriate response. High-meaning, low-action signals create monitoring or scenario tasks. Low-meaning, high-action signals can drive automation. High-high signals require governed action. Low-low observations are archived.

The model should be calibrated against outcomes. If high-scored signals rarely change successful action, the scoring system is not intelligent. Store predicted relevance and realised value. Evaluate precision at the top of the queue, not aggregate classification accuracy. Executive attention is the scarce resource.

Hypotheses make meaning inspectable

Rather than asking a model whether an event is important in the abstract, link signals to explicit hypotheses:

Signals update confidence in these hypotheses. Actions test them. Outcomes recalibrate them. The system becomes a learning loop rather than a newsfeed.

8. Multi-tenancy is a knowledge problem before it is a database problem

GTM data is commercially sensitive. It contains call transcripts, strategy, account plans, competitive interpretations, product gaps and sometimes personal data. A multi-tenant system must make isolation structural.

PostgreSQL row-level security allows policies to restrict which rows a user can select or modify. When enabled without a matching policy, it provides default-deny behaviour. This is a strong database boundary, but it is only one layer.

alter table signals enable row level security;
alter table signals force row level security;

create policy tenant_isolation on signals
  using (tenant_id = current_setting('app.tenant_id')::uuid)
  with check (tenant_id = current_setting('app.tenant_id')::uuid);

Every tenant-owned table needs an explicit tenant key, including join tables, embeddings, snapshots, background jobs and audit records. Relying on a parent relation to imply tenancy creates paths for accidental cross-tenant joins.

Retrieval must enforce policy before generation

Do not retrieve globally and ask the model to ignore forbidden records. Authorisation belongs in the query path. Vector indexes, caches and graph traversals must carry tenant and role filters.

Derived data inherits sensitivity

A summary generated from confidential calls remains confidential. An embedding can leak information through similarity or inversion attacks. A model prompt, trace or error log may contain source text. Data classification must propagate through derived artefacts.

Provenance can itself be sensitive

The fact that an executive viewed a competitor signal or that a particular account triggered a strategy update may reveal intent. Audit access needs policy too.

Deletion is a graph operation

When a source must be deleted, locate snapshots, chunks, embeddings, claims, signals, outputs, caches and model traces derived from it. Event sourcing complicates deletion because immutability conflicts with privacy obligations. A practical design can encrypt tenant payloads with separable keys, redact content while preserving a tombstone event, and rebuild projections.

Roles need semantic permissions

Database roles cover only part of the problem. A seller may view an approved battlecard without seeing raw call evidence from another region. An administrator may manage connectors without inspecting content. An AI agent may draft an action while remaining unable to publish it.

Policy should be expressed at the action boundary:

principal + tenant + role + purpose + data_class + action + confidence → decision

The system should return allow or deny together with any obligations. Those may require personal fields to be redacted, human approval, a restricted target channel or an expiry date.

9. Agents belong after semantics and policy

Agents are attractive because GTM work contains many multi-step tasks. Monitor competitors, interpret a change, find affected accounts, update a battlecard and notify sellers. An agent can coordinate tools across that sequence.

But agency amplifies the quality of the underlying state. If entities are unresolved, claims stale and permissions implicit, the agent executes confusion at machine speed.

I use a capability ladder.

Level 0: retrieve

Return evidence relevant to a user query. No generated recommendation.

Level 1: synthesise

Generate an attributed summary with uncertainty and contradictions.

Level 2: recommend

Propose actions linked to signals, hypotheses and policy. A human decides.

Level 3: draft

Create target artefacts in a review state: battlecard delta, account email, discovery question, message change.

Level 4: execute bounded actions

Publish or trigger actions whose type, target, confidence and rollback are predefined.

Level 5: autonomous strategy

Do not pretend this exists because a model can generate a strategy document. Strategic action changes resource allocation and accepts consequences across uncertain futures. Keep the accountable human visible.

An agent run should be a durable object:

{
  "run_id": "run_01J...",
  "goal": "prepare displacement guidance for Acme pricing change",
  "input_signal_ids": ["sig_14"],
  "policy_snapshot": "pol_7@v12",
  "model": "model-name@version",
  "tools": ["graph.query", "claims.retrieve", "asset.draft"],
  "steps": [],
  "outputs": [],
  "approval": {"required": true, "state": "pending"},
  "trace_id": "tr_..."
}

The run stores the policy and model versions so the result can be reproduced. Tool calls are idempotent where possible. External writes use a transactional outbox or equivalent pattern so retries do not create duplicate CRM tasks or notifications.

Prompt injection is not solved by telling the model to ignore malicious text. External sources are untrusted data. The model should never receive credentials. Tool arguments are schema-validated. Retrieved content cannot expand permissions. High-risk actions require deterministic checks outside the model.

10. Observe the service and what it believes

Traditional observability asks whether the system is available and performant. OpenTelemetry describes observability through signals such as traces, metrics and logs. A GTM intelligence system also needs epistemic observability. We need to know whether its knowledge and recommendations remain trustworthy.

Service telemetry

Knowledge telemetry

Decision telemetry

Trace the full path:

source fetch
  → snapshot
  → parsed observation
  → entity links
  → claim update
  → hypothesis delta
  → signal score
  → retrieval plan
  → generated recommendation
  → policy decision
  → human approval
  → field action
  → commercial outcome

A trace ID connecting these stages allows a user to ask, “Why did the system recommend this?” and receive more than a generated explanation. It can show the actual sources, transformations, scores, policies and approvals.

Evaluation sets must be temporal

Static question-answer pairs are insufficient. The system must answer with the information available at the evaluation date. Build cases that include superseded claims, contradictory sources, entity ambiguity and permission boundaries.

Evaluate abstention. A system that says “insufficient evidence” at the right time is more useful than one optimised only for answer completeness.

Evaluate action harm. A false positive that creates an internal review is different from one that sends an inaccurate claim to a customer. Confidence thresholds should reflect consequence.

11. Build the architecture in the order uncertainty falls

The full system sounds large because it is. It should not be built as a platform programme before proving the decision loop.

Phase 1: one signal, one decision, one tenant

Choose a narrow event class with a real user and consequence. Competitor pricing changes affecting active opportunities is better than “all market intelligence”.

Store raw snapshots and immutable observations. Define two or three event types. Resolve a small entity set. Route signals to a human. Measure whether the action helps.

Do not begin with an agent.

Phase 2: establish GTM-IR and provenance

Create typed signal objects, evidence packets, confidence and temporal fields. Separate parsing from interpretation. Add correction and supersession. Make every output traceable to a source span.

Phase 3: add the ontology and hybrid retrieval

Introduce relationships that answer proven questions. Add lexical, vector and graph retrieval with tenant and temporal constraints. Build query plans rather than one universal search call.

Phase 4: install meaning and action calibration

Link signals to hypotheses and strategic objects. Score meaning and actionability. Capture human decisions and outcomes. Train ranking from observed value carefully; do not optimise for engagement, which rewards alarm.

Phase 5: compile target artefacts

Generate battlecard deltas, account briefs and message warnings from the shared intermediate representation. Compare output consistency across targets. Add approval workflows.

Phase 6: bounded agency

Let agents coordinate retrieval, drafting and low-risk execution. Preserve durable runs, idempotency, policy checks and rollback. Increase autonomy only where evaluation shows reliable value and limited harm.

Phase 7: close the commercial loop

Connect actions to opportunity movement, adoption, win-loss and strategic decisions. The system should learn which signals matter for this company, not which alerts earn clicks across all users.

The point is better state change

GTM teams do not suffer from a shortage of text. They suffer from discontinuity between observation, interpretation, decision and action.

Adding a language model to a document repository can make the discontinuity less visible because the interface becomes fluent. The user asks a question and receives an answer. Fluency can still arrive without lineage; similarity without identity; recency without validity; generation without permission; and an agent run without accountability. A confident tone is a user-interface property, not a warranty.

A trustworthy GTM system needs boring, powerful properties: immutable evidence, explicit time, resolved entities, typed claims, tenant isolation, policy enforcement, calibrated uncertainty, reproducible transformations and observable outcomes.

The compiler metaphor disciplines the design. Raw market material is source code. The ontology and temporal claim store create an intermediate representation. The meaning engine evaluates the programme against strategy. Policy and confidence act as type checks. Target compilers emit the artefacts through which humans act.

The final output may be a two-sentence Slack message to a seller. Underneath it should be enough machinery to answer why those two sentences are true, why they matter now, why that seller is allowed to see them, what action is expected and whether the action worked.

That is the paradox of useful technical infrastructure: complexity is absorbed by the system so judgment can arrive in a form simple enough to use.