INTENT YOU CAN
EXPLAIN.
Every CRM can produce a number between 0 and 100. Almost none can tell you which signal moved it, from which system, and when. A score nobody can explain is a score nobody acts on.
THE NUMBER IS NOT THE PROBLEM.
Scoring models are easy to build and hard to trust. Points accumulate for page views, email opens, form fills and job titles, decay rules fire on a schedule, and one morning a contact crosses the threshold and lands on a sales rep's list.
The rep asks the only question that matters — why this one? — and the honest answer is usually a shrug and a screenshot of the scoring rules. The reasoning has been compressed into a number, and the inputs that produced it are scattered across an analytics tool, an ad platform, an email system and a CRM property whose history nobody keeps.
So the score gets ignored, or worse, trusted without inspection. Both outcomes are expensive, and in a regulated industry the second one is a finding waiting to happen: a decision about a person, taken on grounds nobody can reconstruct.
SIGNALS AS OBJECTS, NOT POINTS.
Every input keeps its origin
A signal is not a point added to a counter. It is an object in the Context graph with a typed edge to the person or company it belongs to, the system it came from and the moment it happened.
Nothing is compressed away at write time, so the reasoning stays reconstructable later.
The scoring logic stays yours
CMP42 ships no scoring engine and no insights layer. What counts as intent in your market is your judgement, declared in your Models and versioned like code.
That is deliberate. A vendor-defined score is exactly the black box this page is about. Why we ship no AI insights layer →
The answer cites its evidence
Ask an agent why an account is worth a call and it reads the graph through MCP tools and names the objects it used — not a number, but the three things that happened and when.
A Process records what was decided and by whom, so a score that turned out wrong can be traced instead of argued about.
DATED. TYPED. ATTRIBUTABLE.
The sketch on the right illustrates the idea: a signal object carrying what happened, where it came from and when — linked to the person and the company it concerns.
What you do with those objects is your model's business. Sum them, weight them, feed them to an agent, or simply read the last five before a call. The point is that the inputs survive the scoring.
Models are validated at write-time, so a signal arriving with a kind your ontology does not know gets a clear error rather than a silent new category. How Models work →
# illustrative - the idea, not the final syntax
signal:
fields:
kind: enum[page_view, reply, meeting, download, mention]
source: string # the system it came from
happened: datetime # when, not when we imported it
weight: number? # optional, yours to define
edges:
about: contact
at: company
evidence: doc? # the artefact, where one exists
# an agent reads these, cites them, and leaves
# the judgement to your modelWHY THIS ONE?
A shortlist that survives the question
A fictional B2B team with a marketing site, an email tool and a CRM. The steps show how the concepts fit together — it is not a customer story, and details of the interface will change during Alpha.
- Over two weeks, several things happen around one company: a reply to a founder email, two visits to the pricing page from the same organisation, and a question in a shared channel.
- Each arrives in CMP42 as a signal object with its kind, its source system and the time it happened, linked to the contact and the company.
- On Monday the rep asks his agent which accounts are worth a call this week, and why.
- The agent reads the graph through MCP and answers with three accounts, each followed by the specific signals behind it, dated and sourced — not a score, an argument.
- He disagrees with one of them and says so. A Process records the decision, so the next run starts from a corrected picture rather than the same number.
WHAT THE ALPHA DOES — AND DOES NOT.
This is the page where it would be easiest to overpromise, so here is the line, in plain terms.
What works today
- Signals are objects in the graph, typed by your Models, each with a source and a timestamp.
- Agents read and cite them through MCP tools, with REST and GraphQL parity.
- Every write is attributable, and a Process can hold a judgement for human approval.
- Nothing is compressed at write time, so the reasoning behind any answer can be reconstructed later.
What is not there yet
- CMP42 does not score for you. There is no scoring engine, no threshold, no built-in MQL. You define what intent means.
- CMP42 collects no signals on its own. It has no tracker and no pixel of its own — and this website stores nothing in your browser. Signals arrive because you send them.
- There are no connectors to ad platforms or analytics tools. In the Alpha, signals come in by import or through the API.
- No numbers on this page. Alpha begins in October 2026; anything measured will come from Design Partner case studies or not at all.
A SCORE IS AN ARGUMENT, NOT A FACT.
The shift is small and it changes the conversation: instead of defending a number, the team inspects the evidence behind it. Sales trusts the shortlist more because it can disagree with it precisely. Why we built it this way →
Bring your scoring model to the call
If you already run a lead score and cannot explain it, that is a useful thing for us to build against during Alpha. Strong applications describe the model they have, not the one they wish they had.
→ Apply to be a Design Partner- Rep-proof. "Why this one?" has an answer that names objects, dates and sources.
- Auditable by design. A decision about a person can be reconstructed, which is what a regulated client will ask for.
- Your definition of intent, versioned in your repository, not configured in ours.
- No tracking required. Signals you already have are enough to start; CMP42 adds none of its own.
- Managed in the EU or self-hosted. On the managed tier CMP42 does not train on your data. DPA on request.