Signals are carried in one conversation-signals object on the enriched vCon. Each is an independent {fired, details}, where details is the one-sentence evidence when it fired and null when it did not. What follows is what each one means, and just as usefully, what each one refuses to fire on.
A signal only reaches the object if the industry configuration declares it. A signal absent from signals was never extracted for that industry, which is a different fact from fired: false, meaning extracted and did not fire. Check presence before you read the boolean. The declared set for your industry comes with API access.
details exists so a person can judge the call in seconds rather than trusting a flag. Build the review path around it: the sentence is the reason the signal is worth surfacing at all, and a signal without its evidence is a number nobody trusts twice.
These are built to put the right conversations in front of a person, not to take unattended action on their own. Treat a fired signal as a queue entry and keep a human in the loop before anything customer-facing happens. Where a surface warrants more than that, we will tell you directly rather than let you infer it from a page.
Nine signals, one normalised vocabulary across every industry. The definition of a signal does not change between industries; what changes is which ones are declared and what the industry's language for them looks like.
| Signal | Fires when | Deliberately does not fire on |
|---|---|---|
complaint |
The customer voiced displeasure at how the business handled something - its process, its people, or its service. | Reporting a fault or a broken thing without dissatisfaction at the business. A customer telling you their equipment failed is a support conversation, not a complaint. |
churn |
Dissatisfaction and a stated intent to leave. Both are required. | Frustration on its own, which is a complaint. A billing dispute. A third party or partner moving. An employee mentioning their own departure. |
expansion |
The customer surfaced growth that could be served - more sites, more seats, more services. | An explicit step toward a purchase, which is buy_signal. |
buy_signal |
The customer took an explicit forward action toward buying. | Inferred growth or general interest, which is expansion. Support or scheduling conversations that happen to mention a product. |
product_request |
The customer asked for a new or expanded service that does not exist today. | A request for help with a service that already exists, which is support. |
escalation |
An upset customer where a supervisor or manager was demanded, or stepped in. | A routine handoff to a specialist, a second-tier engineer, or network operations. Competent escalation through normal tiers is good practice, not a signal. |
compliance |
A procedural requirement that applies to the conversation was not met. | An employee saying they do not know and offering to check. That is a knowledge gap - a quality and training matter, and close to the opposite of a violation. |
fraud |
Employee misconduct, or deliberate criminal activity discussed on the conversation. | A customer payment failing. A bounced cheque, an NSF return, a declined card, an ACH return, a stop payment, or a chargeback is a collections matter, and treating it as fraud is the most damaging false positive in the set. |
safety |
A safety concern was raised on the conversation. | Routine risk language with no safety concern behind it. |
Four things a consumer often expects to find inside signals and will not. Each is carried, but as its own typed object, because each answers a different kind of question.
| Field | Where it lives | Why it is separate |
|---|---|---|
resolution |
conversation-resolution |
An outcome state, not a risk detection. Three classes rather than a boolean, and it drives worklists rather than alerts. |
overall_sentimentsentiment_direction |
sentiment |
Reuses the standard vcon-core sentiment type, so generic vCon tooling already reads it. Direction is the trajectory across the conversation, not a second reading of it. |
primary_topic_id |
conversation-classification |
A classification over an industry taxonomy, not a fired condition. It is what groups conversations and matches repeat contacts. |
customer_id, employee_id, competitor_ids |
conversation-attribution |
Who the conversation was with, as stable identifiers. Names resolve at read time, so a rename never rewrites a record. |
{
"signals": {
"churn": {
"fired": true,
"details": "Customer stated they are being quoted by another provider before renewal."
},
"complaint": {
"fired": true,
"details": "Second fault report in a week; frustration at a repeat visit."
},
"expansion": {
"fired": false,
"details": null
}
// signals this industry does not declare are absent, not false
}
}
The full object in context, alongside every other analysis type: the enriched vCon →
New signals arrive as additional entries inside the object you already consume, under the same {fired, details} shape. Nothing about your integration changes when the vocabulary deepens.
That is a deliberate constraint on us rather than a convenience for us. It means a new detection cannot arrive with a new shape, a new endpoint, or a new object to discover, and it means an industry brought to production adds classification and declared signals that existing integrations inherit without asking. The counterpart obligation is on your side and it is small: ignore what you do not recognise.
Signals are also removed. When one cannot be defined tightly enough to be worth acting on, it does not ship - and a signal that would fire on the wrong thing is worse than a field that is not there.
The definitions above are the argument on paper. Running the set across traffic you already have is the version that settles it.