Signal Master

The Signal Master is the control console where you define and manage Signals captured during customer meetings and their associated Impacts. The list of signals that sales representatives select from when logging meeting records in the Activity Board is directly managed on this screen.

While all users can view this configuration, the creation, modification, and deletion of Signals and Impact Types are strictly restricted to the admin or super_user roles.

Navigation: Left Sidebar → Settings → Signal Master

What is a Signal?

In the sales domain, a Signal is a reaction or statement from the customer during a meeting—essentially, a clue that determines whether the probability of winning this deal has increased or decreased.

For example:

• The customer states, "Budget has been approved" → Strong Positive Signal
• The customer states, "Let's set up a follow-up meeting next week" → Weak Positive Signal
• The customer states, "We have decided to go with a competitor's product" → Strong Negative Signal
• The customer states, "We will look into it" (a formal, non-committal response) → No Signal

EXAWin does not merely log these signals as text. By assigning a mathematical weight (Impact) to each signal, the Bayesian Engine automatically recalculates the probability of winning the deal the moment the signal is entered.

The Signal Master manages two distinct components:

1. Signal — The specific situational fact captured during a meeting (e.g., "Budget approved", "Key personnel changed").
2. Impact Type — The classification category that defines the magnitude of that signal's influence (e.g., "Game Changer", "Strong Positive").

Impact Type: The Scale That Determines Signal Gravity

To understand the Signal Master, you must first grasp the concept of an Impact Type. The Impact Type dictates the magnitude of influence a signal exerts on the overall win probability.

Standard Impact Types

EXAWin provides 7 system-standard Impact Types out of the box:

How Impact Values Influence Win Probability

Understanding how Impact values practically operate within the engine clarifies why these figures should never be altered recklessly.

When a sales representative logs a meeting, the following calculation occurs deep within the system:

• For a Positive Signal: α (Success Weight) increases → P(Win) ↑
• For a Negative Signal: β (Failure Weight) increases → P(Win) ↓
• Integration with SWV (Stage Weight Value): The crucial mechanism here is the expression (SWV × Impact). For instance, receiving the same "Strong Positive (Impact 1.0)" signal carries a vastly different mathematical weight when captured at the initial 'Lead' stage compared to the final 'Negotiation' stage. Designing the system so that the exact same signal is weighted differently depending on the maturity of the sales stage is the hallmark of the EXAWin solution architecture.

⚠️ Why You Must Not Change Impact Values Rashly (Warning)

Impact values are not arbitrary numbers. They are rigorously calibrated via an f-coupling (ratio-based design) linked directly to the company's initial Prior strength configuration (S = α + β = 10). While modifying these values is technically permitted by the system, we strongly mandate assigning values exclusively within the 0.1 to 1.0 threshold (extending to a maximum of 5.0 for extreme Game Changers). If random numerical values (e.g., 8.0 or 10.0) are assigned outside this bounded framework, the Bayesian engine completely loses its ability to guarantee the reliability and validity of the calculated probabilities.

To simplify the analogy:

A Signal describes "What happened," while the Impact dictates "How critical that event was." Much like publishing news, the exact same story has a vastly different impact on the world depending on whether it is printed as an explosive front-page headline (Game Changer, Impact 5.0) or buried as a page-three footnote (Weak Positive, Impact 0.4).

⚠️ A Deeper Look into the f-coupling Design

Impact values are precisely calibrated around your company's initial Prior strength (S = α + β = 10):

When this fragile ratio collapses, catastrophic analytical errors emerge:

If Impact is set too high — The probability will wildly spike or plummet off a single meeting. For example, artificially inflating "Strong Positive" from 1.0 to 8.0 would mean that during the Negotiation phase, this one signal alone could cause the P(Win) to vault from 25% directly to 80%. This yields a hallucinated prediction utterly disconnected from reality.

If Impact is set too low — The probability barely flinches regardless of how decisive the signal is. Even if a customer declares, "We are sending the purchase order tomorrow," the system might ridiculously edge the P(Win) up from 28% to merely 29%.

💡 We strongly recommend maintaining standard Impact values. Once sufficient historical data is amassed, EXAWin's Auto-Tuner will autonomously analyze past Won/Lost records and automatically propose statistically optimized values.

For detailed theoretical explanations of parameter calibration principles, refer to the following documents:

• Bayesian Application: Prior Alpha, Beta — Governing mechanics behind Prior parameters
• Bayesian Application: Parameter Calibration and Auto-Optimization — f-coupling framework, EPR guardrails, and Auto-Tuner logic

Screen Architecture

The screen is built on a Dual-Panel Layout:

• Left Panel — Roster of Signals or Impact Types (accessed via tab switching)
• Right Panel — Creation/Editing form console linked to the selected tab

Top Header Actions

Tab Navigation

There are 2 critical tabs perched At the top of the right panel:

Switching tabs causes both the left table view and the right control form view to simultaneously transition.

Signals Tab

Signal Table

Selecting a row in the table instantly maps the signal's parameters into the right form for editing.

Creating a Signal

After resetting the form via the Reset button at the top, populate the following parameters:

Click the top Save command to commit the data. Newly instantiated signals inherit the Custom classification.

Editing a Signal

Clicking a target row in the table violently shifts the right form into Edit Mode:

• A prominent "Editing" badge anchors the top of the form.
• Modify the desired text parameters and secure them via the Save button.
• Striking Reset aborts the edit sequence, reverting the space to an empty drafting board.

You are completely free to remodel the Signal Name. Changing the text label exerts absolutely zero adverse effects on the underlying Bayesian mathematical computations.

Deleting a Signal

While entrenched in Edit Mode, you may hit the Delete command to execute a purge.

• ❌ System Signals (hardcoded defaults) aggressively block deletion attempts.
• ❌ Signals currently in active utilization by historical logs cannot be deleted (to protect referential integrity).
• ✅ If all constraints are cleared, a final confirmation dialog authorizes the purge.

Historical Activity logs containing the purged signal format will safely preserve their text. The signal is merely eradicated from the options roster without vaporizing pre-existing timeline data, ensuring maximum safety.

Impact Types Tab

Impact Type Table

Creating an Impact Type

Declaring "No Signal" forces the Base Value to defensively snap to 0.1, locking it out of further modification.

Editing an Impact Type

Clicking an Impact Type in the grid engages Edit Mode, following the exact same UI mechanics and rules as the Signal editing flow.

Deleting an Impact Type

• ❌ System Impact Types intrinsically reject deletion.
• ❌ Impact Types currently acting as parent nodes to surviving Signals are entirely blocked from deletion.
• ✅ Once these ties are severed, a warning dialog clears the path for ultimate deletion.

Relational Architecture: Signals vs. Impact Types

Signals and Impact Types exist in a strictly bound N:1 (Many-to-One) relationship. Multiple singular Signals trace back to a single overarching Impact Type.

For example, the "Strong Positive" Impact Type might act as the parent for:

All these distinctly labeled events inject the exact same mathematical weight (1.0) into the engine. The Signal demarcates "What specifically occurred," whereas the Impact Type mathematically mandates "How severely it alters the battlefield."

Critical Advisories

• Deactivating a specific signal merely banishes it from the dropdown options within the Activity Board.
• We vehemently encourage you to rename, rewrite, and add Signal Names to seamlessly conform to your organization's unique internal corporate dialect. (e.g., An IT firm might use "BMT Passed," whereas manufacturing might input "Sample Golden Seal Approved.") Renaming text labels inflicts zero harm on the Bayesian computation engine and exponentially amplifies user comprehension. However, NEVER artificially inflate or meddle with the inherited Base Value (Impact) linked to those signals.
• Should you venture to forge a new Impact Type, remain strictly within the confines of the standard scale paradigm (0.1 ~ 1.0, maximum ceiling 5.0). Straying beyond this boundary shatters the engine's EPR (Evidence-Prior Ratio) logic guardrails.
• Click the Help icon (❓) beside a signal to summon an exhaustive breakdown of how its specific Impact operates.

💡 Q&A: Deep Contextual Mastery

Q1. How exactly does "No Signal (0.1)" manifest its influence on the probability engine?

It does not simply mean "Nothing happened." Deep within the source code of EXAWin's backend (Ruby Backend), registering 'No Signal (0.1)' is hardcoded to actively inject a 0.1 penalty value directly into the failure parameter, β (Beta). In harsh reality, meeting a client and failing to extract a single inch of forward momentum is ruthlessly evaluated by the engine as a 'Micro-Negative' (probability decay). Furthermore, an autonomic Silence Penalty shadows your activity logs. If an extended void of time elapses without any signals being logged (an operational dry spell), the engine's hardcoded logic will autonomously levy a probability decay sanction. You can dictate the strictness of this 'Initial Silence Threshold' and 'Recurrent Interval' directly on the Project Master (New Project Creation) screen, calibrating the punishment differently for each unique client account.

Q2. Why is a "Moderate Affirmation/Negation (0.7)" scale absent from the System Defaults?

The system's baseline scale may visually appear heavily polarized—vaulting directly from [Weak Positive (0.4) to Strong Positive (1.0)] with no middle ground. This is a highly deliberate UX defense mechanism engineered to obliterate Cognitive Overload and crush the Central Tendency Bias. It is purposely designed to stop sales representatives who are unsure of an outcome from safely retreating into a non-committal "middle ground." Forcing a stark, black-and-white decisive commitment drives unparalleled sharpness and brutal honesty into the data.

However, if your organization's deeply entrenched sales process absolutely demands a more granular sliding scale, the EXAWin architecture is vastly flexible enough to accommodate it.

Because the EXAWin engine possesses zero mathematical upper bounds or fixed ladders, you can instantaneously forge a Custom Impact Type for something like Moderate Affirmation (0.7) in under one second, establishing a Bayesian baseline utterly unique to your enterprise.

To crystallize the philosophy: The System Defaults are intentionally stripped down to enforce decisive sales judgments, but zero structural restrictions block you. Whenever your operational needs demand it, you yield the ultimate authority to append Custom values.