The Signal

A weekly read for operators thinking seriously about AI. Less noise, more signal.

Decision Architecture · Part 2 of 6

Layer 02 — Trigger. New to the series? Catch up on Part 1: The Decision Audit.

Trigger — what actually makes the decision happen

Last week we ran the audit. You came out with two or three decisions worth architecting. This week we start the architecture, beginning with what sounds like the easiest question in the method and is almost always the hardest.

What makes this decision happen?

Try it on one of your audit decisions. What is the actual event that puts the decision in front of the person making it? Most teams cannot answer that cleanly. They can describe what the decision is. They can describe how it should be made. They struggle to articulate the precise moment the decision enters the room — and that gap is where most AI implementations quietly fail. You cannot automate the response to an event you have not named.

Trigger is the layer that makes a recurring decision visible in time. It answers four questions, and every encoded decision has answers to all four — written down, agreed on, and inspectable.

01

The event

What is the observable thing that signals "this decision needs to be made now"? A new lead lands in the inbox. A ticket crosses the four-hour SLA mark. An invoice ages past sixty days. A pull request requests review. The event must be observable to a system, not just felt by the person whose job includes the decision. If your trigger is "when it feels like time to step in," you have not yet named the trigger. Push harder until the event has edges a piece of software could detect.

02

The source

Where does the event live? A CRM record, an inbox, a calendar entry, a shared spreadsheet, a Slack channel, the operator's own observation. The source matters more than people think. A trigger that lives in three places at once — half in the CRM, half in the rep's head, half in last Tuesday's email thread — cannot be observed by anything except the person who already does the work. Architecture demands a single, named source per trigger. If multiple sources feed the same trigger, the first job is to consolidate before encoding.

03

The threshold

When does the event become a trigger? Not every new lead is worth qualifying. Not every ticket needs escalation. The threshold is the condition that elevates raw signal to actionable decision. Lead value above a certain number. Ticket age past a defined window. Invoice balance exceeding a percentage of customer credit. The threshold is where most teams discover that what they thought was one decision is actually three — and each gets its own architecture downstream.

04

The window

How long does the trigger stay live before the decision becomes irrelevant or expensive? A lead is hot for hours. A ticket has its own SLA. An invoice can sit for weeks before it becomes a write-off question. The window is what tells the system how urgently the decision needs to be made — and it is the single piece of information that turns a passive trigger into an active one. A trigger without a window is just a notification. A trigger with a window is a clock.

Event, source, threshold, window. Together they form the Trigger Map for one decision. Write them down, in that order, for each of the two or three decisions you selected last week. The map will look obvious in retrospect and will feel laborious to fill in for the first time. That is the right reaction. Mapping a trigger is the moment the decision stops being something that lives in a person and starts becoming something a system can see.

Most teams discover something inconvenient when they do this work. The decision they thought was one decision turns out to be two or three triggered by different events at different sources with different windows. The CRM-based "qualify this lead" decision is actually three decisions: qualify new inbound, re-engage cold lead, and reactivate stalled deal. Each has its own trigger, its own logic, its own move. Trying to encode them as one will produce a system that mostly does not work.

This is why Trigger comes before Logic. You cannot define how to decide until you have separated the decisions. Most of the work of decision architecture is not deciding well — it is realizing what decisions you are actually making.

Free Worksheet · Part 2

The Trigger Map worksheet

One page, four columns — event, source, threshold, window — designed to be filled in for each priority decision from your audit. Reply to this email with the word "trigger" and I will send it directly. If you missed the Audit worksheet from last week, reply "audit + trigger" and I will send both.

Next Week · Part 3 of 6

Layer 03 — Frame

Once a decision is triggered, the next question is how the person making it understands what they are looking at. Two people facing the same data will not always see the same decision. The Frame layer is how you fix that — and how you make sure AI sees what the operator sees.

If mapping triggers on your own decisions surfaces something you want a second set of eyes on — particularly the moment where one decision turns out to be three — that is the most useful conversation we can have in a Discovery call. Bring the Trigger Map for one decision. We will work through it.

Book a Discovery Call

Or read this issue on LinkedIn.

Applied AI strategy, training, and implementation.

Ryan Rezeika · Founder · Vancouver, BC
ryan@resonai.ai · resonai.ai · LinkedIn

You're receiving this because you subscribed at resonai.ai/signal. · Unsubscribe