|
Issue 005 · May 21, 2026
|
The Signal
A weekly read for operators thinking seriously about AI. Less noise, more signal.
|
|
|
New Series · Decision Architecture · Part 1 of 6
Over the next six issues, the complete Resonance Method — how to encode the decisions your business repeats, before you automate any of them.
|
|
The decision audit
Every business runs on decisions it repeats. Which leads to chase. How to price a job. When to escalate a ticket. Whether to extend credit. Who to promote. These decisions happen dozens or hundreds of times a year, and almost none of them are written down. They live in the heads of the people who have made them long enough to have a feel for it.
This stays invisible until you try to apply AI. The moment you ask an AI system to help with one of these decisions, you discover the decision was never actually defined. There is no rule to encode, because the rule lives as intuition. This is why most AI deployments stall. Not because the technology fails, but because the decision underneath was never made explicit.
Decision Architecture is the discipline of making those decisions explicit before you automate them. The Resonance Method is how we do it at ResonAi: six modules that take a recurring decision from "a feel my best people have" to an encoded, inspectable, improvable system. Over the next six issues, I am going to teach the whole method — not the marketing version, the actual working method. By the end you will be able to run it yourself. The people who would rather have us run it know where to find us.
This issue is the gateway. You cannot architect a decision until you know which decisions are worth architecting. The audit finds them.
|
|
The Resonance Method at a glance
| 01 |
The Decision Audit
— surface and rank every recurring decision. (This issue.)
|
Then five Layers, applied to each priority decision
| 02 |
Trigger — what makes the decision happen. |
| 03 |
Frame — how the decision is understood. |
| 04 |
Logic — the criteria, weights, and reasoning. |
| 05 |
Move — the committed action. |
| 06 |
Echo — what the decision leaves behind for the system to learn. |
|
|
|
The audit comes first because architecting the wrong decision is worse than architecting none. Spend three weeks encoding a decision that turns out not to matter and you have taught your team that the whole method is a waste of time. So before any of the five Layers, you run the audit. Here is how, in four steps.
|
|
01
|
Inventory
List every recurring decision your team makes. The operative word is recurring. You are not after the big strategic one-offs — those need human judgment and always will. You are after the decisions that repeat, the ones a new hire would ask "how do I handle this?" and get an answer that starts with "it depends."
A practical prompt: walk through a typical week for each role on your team and write down every point where someone chooses between options. Pricing, prioritizing, approving, routing, qualifying, escalating. Most teams find between fifteen and forty recurring decisions once they actually look. A landscape contractor we worked with listed eleven before realizing his "should I bid this job at all" decision was the one quietly costing him the most.
|
|
|
02
|
Characterize
For each decision, capture five things: how often it happens, who makes it, how long it takes, what it costs when it goes wrong, and how much of it is judgment versus rule. You do not need precision. "Daily / sales rep / ten minutes / a lost deal / mostly judgment" is enough to work with.
The judgment-versus-rule axis is the one people get wrong. They assume their hardest decisions are pure judgment. Usually they are seventy percent rule and thirty percent judgment, and nobody has ever separated the two. That seventy percent is what is architectable. The thirty percent is where your experts stay irreplaceable.
|
|
|
03
|
Rank
Score each decision on four dimensions: frequency, consequence, inconsistency, and boundedness. High frequency, high consequence, high inconsistency, high boundedness means architect this first. A decision that happens constantly, matters a lot, gets handled differently by everyone, and can actually be defined is the perfect candidate. A rare, low-stakes, already-consistent, fuzzy decision is the worst — leave it alone.
Inconsistency is the secret dimension. A decision everyone already makes the same way does not need architecture — it is already encoded in your culture. The gold is in the decisions where outcomes swing wildly depending on who is in the room. That swing is unmanaged risk, and it stays invisible until you score for it.
|
|
|
04
|
Select
Pick the two or three decisions at the top of your ranking. Those become the subjects of the next five Layers. Resist the urge to do more than three at once. Decision architecture is deep work per decision; spreading it across ten is how you end up with ten half-encoded decisions and no working system. Three done completely beats ten done partially, every time.
|
|
That is the audit. If you do nothing else with this issue, do step one. Just inventory your recurring decisions. Most operators have never seen the list written down, and the list alone is clarifying — it is the first time the invisible machinery of the business becomes something you can actually point at.
|
|
Next Week · Part 2 of 6
Layer 02 — Trigger
Once you have picked a decision to architect, the first question is deceptively simple: what actually makes this decision happen? You will be surprised how often nobody can answer that cleanly — and how much fixing it changes everything downstream.
|
|
Running the audit and want a second set of eyes on what you find? Or want us to run the whole method with you, on your priority decisions? That is exactly what a Discovery call is for.
Or read this issue on LinkedIn.
|
|
|