Path from signal to action

Signal to action path

"Signal" by itself does not change anything. Value appears when a signal is standardized, interpreted, prioritized, turned into a decision and action, and then the result is returned to the system as feedback. Below is a practical pipeline and a minimal set of artifacts to keep this path fast, repeatable and safe.

1) Signals: sources and standards

Sources: product events, telemetry/logging, payments/CUS, RG/fraud indicators, APM/SLA, external feeds (FX, registries).
Event schema (canonical): 'signal _ id', 'type', 'entity _ id', 'ts _ event', 'ts _ ingest', 'severity', 'payload', 'source', 'confidence'.
Qualitative requirements: idempotency ('signal _ id'), exact time, UTC + locale, PII masks, schema version.

Anti-patterns: "floating" fields, local time formats, absence of 'source '/' version'.

2) Sense: normalization, dedup, enrichment

Normalization: uniform directories, currencies/timezones, name schemes.

Deduplication: key '(entity_id, type, window)' + payload hash; keep a "reason for pooling."

Feature-join: RFM, geo/device, risk scores, cohorts, campaign context.
Quality: noise filters, confidence, checking invariants (for example, 'amount ≥ 0').

3) Validate: "is this important and is this our case?"

Correlation vs causality: flag signals requiring causal verification (DiD/experiments) → not to be confused with incident triggers.
Duplicates of effects: connection with already active actions (so as not to "fine" twice).
Eligibility policies: RLS/CLS, RG/compliance rules, contact frequency limits.
Hysteresis: input threshold ≠ output; "cool-off" for flapping signals.

4) Prioritize: How to choose what to do first

[
\textbf{Priority} = \text{Severity}\cdot w_s;+; \text{Propensity}\cdot w_p;+; \text{Value}\cdot w_v; -; \text{Risk}\cdot w_r; -; \text{Cost}\cdot w_c
]

Severity: strength of the deviation from the norm/thresholds.
Probability of success (model/uplift).
Value: expected economic effect (LTV uplift, prevented damage).
Risk/Cost: operational, RG/compliance, probability of harm to the user.
SLA: deadlines by signal type (P1/P2...).

Action queue = sort by'Priority 'based on quotas and rate-limit on intervention types.

5) Decide: how to make a decision

1. Rules (policy-as-code): transparent, fast, basic cases.

2. Models (score-based): probabilities/ranks + threshold/hysteresis.

3. Adaptive policies (bandits, RL): online learning, personalization.

Decision table

6) Act: orchestration and performance

Channels: in-app, e-mail, push, SMS, call, limits/restrictions, tickets.
Orchestrator: guaranteed delivery (retry/backoff), idempotency of actions ('action _ id'), transactionality.
Conflicts: priorities and mutual exceptions (e.g. promo ≠ RG intervention).
Loads: rate-limit per channel/user/segment, queue with DLQ.
Audit: log "signal → decision → action → result" (end-to-end 'correlation _ id').

7) Learn: Effect and Feedback

Action metrics: coverage, take-rate, success (conversion/risk reduction), latency, NPS/complaints.
Causal assessment: A/B, DiD, synthetic control; uplift @ k, Qini/AUUC for targeting.
Auto-tuning: updating thresholds/policies; bandits (ε -greedy/TS) within guardrails.
Loop closure: new features/signals from the results; archive of rules/versions.

8) Guardrails and safety

Data quality: freshness, completeness, drift PSI; quality drop = automation stop valve.
Operating: p95 solution time, orchestrator availability, error budget.
Ethics/RG/compliance: prohibition of aggressive offers at risk, explainability of decisions, transparent reasons for actions for the user.

Hysteresis and cooldown: Prevent measure flashing and audience "fatigue."

9) Observability and SLO

Conveyor SLO: "Signal→Decision p95 ≤ 2 sec; Decision→Action p95 ≤ 5 sec; data freshness ≤ 15 min."

Dashboards: funnel "signaly→deystviya," priority map, guardrails-alerts.
Logs and trace: 'trace _ id/correlation _ id', failure metrics, retrays, percentage of manual escalations.
Runibooks: degradation scenarios (feed drop, signal spike, channel delays).

10) Data schemes and contracts (minimum)

Event-Signal (JSON)

json
{
"signal_id": "sig_...uuid",
"type": "churn_risk",
"entity_id": "user_123",
"ts_event": "2025-10-31T22:15:00Z",
"ts_ingest": "2025-10-31T22:15:05Z",
"severity": 0. 82,
"confidence": 0. 93,
"source": "model:v4",
"payload": {"rfm":"H1","country":"EE","platform":"ios"},
"version": "1. 2"
}

Decision/Action (tabular)

`action_id`, `correlation_id`, `entity_id`, `policy_version`, `decision` (enum), `channel`, `queued_at`, `sent_at`, `status`, `guardrail_flags[]`.

11) Economics of solutions: when action is beneficial

[
\mathbb{E}[EV] = p_{\text{успех}} \cdot \text{Value} - p_{\text{вред}} \cdot \text{Harm} - \text{Cost}
]

Threshold: Run the action if 'EV ≥ 0' and guardrails are normal.
Budgets: caps by segment/channel, allocation by margin.
Multi-goals: cascade - first security (RG/fraud), then economics, then UX.

12) Maturity levels (matrix)

1. Ad-hoc: manual reactions, no logs.
2. Repeatable: rule templates, basic auditing, restricted metrics.
3. Managed: single orchestrator, prioritization, A/B assessment.
4. Optimized: adaptive policies, bandits, auto-tuning thresholds, end-to-end causal control.
5. Safe-autonomy: autonomous actions within rigid guardrails, formal verifications.

13) Artifact patterns

A. Signal passport

Code/version, definition, source, scheme, fresh SLO, deduplication rules, enrichment, owners, quality (tolerances), risks.

B. Policy Passport/Policy

ID, conditions, data/features, action, hysteresis/cooldown, guardrails, user explanation, version/changelog.

C. Runbook incident

Symptom (alert), tracing, data quality check, disabling/lowering the auto-level, contact persons, "return to the green zone" criterion.

14) Check list before loop release

• Signals are standardized; there is dedup and enrichment
• Prioritization and queues are implemented; quotas and rate-limit configured
• Policies/thresholds are documented; hysteresis and cooldown are active
• The orchestrator of actions is idempotent; end-to-end audit
• Guardrails and SLO specified; alerts and runibooks are ready
• Causal effect estimate set up (A/B/DiD or sandboxed bandits)
• Dashboards "Signal→Action→Outcome" and quality metrics in prod
• Versioning and feedback process (learn) is closed

Total

A reliable signal-to-action path is a pipeline, not a set of scripts: standardized events → meaningful prioritization → managed decisions (with rules/models) → secure orchestration of actions → causal assessment → automatic learn loop. Such a contour makes the data operable, the measures precise, and the effect measurable and reproducible.