Signal → Decision → Execution: The Framework for Intelligence-Driven Workflows

Every minute your organisation runs, its operational systems are generating signals. A monitoring alert fires. A customer's product usage drops below a threshold that historically precedes churn. A deal that was forecast to close this quarter has gone dark for 21 days. A CI/CD pipeline fails on a deployment that touches three critical services. A support ticket volume spike correlates with an API version that went out last Tuesday.

These signals are not buried or inaccessible. They are sitting in your observability stack, your CRM, your support platform, your deployment logs, your product analytics database. They are real, they are current, and they are almost entirely unacted on — because the infrastructure that would read them, understand their significance, and do something about them without waiting for a human to notice does not exist in most organisations.

This is the operational gap Nity is designed to close. Its framework — Signal → Interpretation → Decision → Execution — is a structured approach to building workflows that act on operational signals automatically, without a human in the critical path at every step.

Layer One: Signals

A signal is any event or state change in your operational environment that carries information about what is happening and what might need to happen next. The signal layer is about detection — connecting to the systems that generate signals and receiving them in real time.

In practice, signals come from monitoring and observability tools (Datadog, Splunk, New Relic), customer platforms (Salesforce, HubSpot, Gainsight), product analytics systems, CI/CD pipelines, support platforms (Zendesk, Intercom), financial systems, and HR platforms. Each of these systems emits signals on its own schedule, in its own format, through its own APIs.

The signal layer does not just receive these events in isolation. It maintains awareness across all connected systems simultaneously. When a Datadog alert fires, the signal layer knows what else is happening at that moment across every other connected system — which deployments are in flight, what the support ticket volume looks like, whether there are open incidents that might be related. That simultaneous awareness is what enables the next layer to do meaningful work.

Layer Two: Interpretation

A signal in isolation is often insufficient to determine what should happen next. A CPU spike could indicate a capacity issue, a runaway process, a DDoS pattern, or a legitimate traffic surge tied to a campaign that marketing launched this morning. The raw signal does not tell you which.

Interpretation is the process of correlating signals across systems to build context. When the Datadog alert fires, Nity's interpretation layer queries Splunk for log patterns in the relevant time window, checks the deployment history for recent changes to the affected service, cross-references open support tickets for error reports that might indicate user impact, and maps the blast radius — which downstream systems and customer segments are affected.

By the time the interpretation layer is done, the signal is no longer a raw alert. It is a contextualised incident: probable root cause identified, blast radius mapped, related events correlated, severity calibrated against the actual customer and business impact.

This is the layer that separates intelligence from automation. Rule-based automation can respond to a signal. Only an interpretation layer can understand what the signal actually means before deciding what to do about it.

Layer Three: Decisions

With full context established, the decision layer evaluates what should happen next. This is not a simple if-then rule evaluation. It is context-aware branching: given what the interpretation layer has established, which of the defined response paths is appropriate?

For the infrastructure incident example: is this a P1 or P2? The answer depends not just on the alert severity but on the blast radius established during interpretation — how many customers are affected, what is the revenue exposure, is there a customer with an enterprise SLA in the affected segment. A P1 triggers a different response path than a P2: different notification chains, different runbook, different escalation thresholds.

Decision logic in Nity is defined by your team and aligned to your operational procedures. You specify the conditions, the branches, and the response paths. The system evaluates them against the context established during interpretation and selects the appropriate path. This preserves human judgment at the design stage while removing the requirement for a human to make routine decisions in real time.

Layer Four: Execution

The execution layer is where the decision becomes action. For enterprise operations, this means triggering actions across the connected systems that need to respond: PagerDuty for on-call notification, Jira for incident ticket creation, Slack for team communication, Salesforce or HubSpot for customer-facing actions, OpsGenie for escalation management.

Critically, execution in Nity is not a single action trigger. It is a coordinated sequence of actions across multiple systems, with the context established during interpretation carried through. When the on-call engineer receives the PagerDuty page, it includes the root cause assessment, the blast radius, the correlated log evidence, and the recommended runbook. They are not starting an investigation from a raw alert. They are starting from a fully assembled incident context.

A Real Incident, End to End: 9 Minutes

Walk through what the framework looks like on a P1 infrastructure incident.

At 2:47am, Datadog fires an alert: error rate on the payments service has crossed the 5% threshold. In an organisation without this infrastructure layer, an on-call engineer gets paged, opens their laptop, and begins manually correlating logs across Datadog, Splunk, and the deployment dashboard. Average time to root cause identification: 25 minutes. Average time to full loop closure (runbook executed, team notified, ticket filed): 47 minutes.

With Nity's framework running: the signal arrives at 2:47am. Interpretation runs immediately — Splunk logs queried, recent deployments checked, customer impact assessed. At 2:48am, root cause is identified: a configuration change deployed at 2:31am introduced a connection pool exhaustion pattern under load. Blast radius: 12% of payment transactions, three enterprise customers in the affected region.

The decision layer classifies this as P1 given the enterprise SLA exposure. Execution triggers: PagerDuty pages the on-call engineer at 2:48am with full context attached. The correct runbook is triggered. A Jira incident ticket is automatically created with all correlated evidence. The customer success team is notified via Slack that three enterprise accounts may be experiencing payment failures. At 2:56am, the on-call engineer, working from the context Nity assembled, executes the runbook. Loop closed at 2:56am. Nine minutes from signal to resolution. The CSM notification went out before the engineer even opened their laptop.

Why This Beats Rule-Based Automation

Rule-based automation handles the cases you anticipated when you wrote the rules. It is deterministic and reliable within its defined scope. But operational environments generate novel combinations of conditions constantly — a deployment that coincides with a traffic spike that coincides with a third-party API degradation. No rule set covers every combination in advance.

Intelligence-driven workflows handle novelty because interpretation builds context from evidence rather than matching against a fixed rule set. Nity evaluates the actual state of the environment at the moment of each signal, not a simplified abstraction of it. The cases you did not anticipate are handled by the same framework as the cases you did, because the framework reasons from context rather than rules.

This is the foundation of operational AI capability. Not smarter tools for humans to use, but infrastructure that acts on what your systems already know. Learn more at nity.ai.