|
Issue 007 · June 4, 2026
|
The Signal
A weekly read for operators thinking seriously about AI. Less noise, more signal.
|
|
|
|
Frame — how the decision is understood
Show two of your best people the same triggered decision. Same data, same context, same moment. They will frequently reach different conclusions, and they will both feel certain they are right. Neither is wrong. They are looking at the same situation through different mental models.
That gap is the Frame problem, and it is the layer where most AI implementations quietly produce nonsense. Teams hand AI the data — the same data the human sees — and assume that will be enough. It is not. The data is the input to the decision, not the decision itself. Between the input and the output sits the framing: the categorization the operator applies, the specific signals they prioritize, the prior cases they pattern-match against. That framing is mostly invisible, mostly unwritten, and mostly the reason AI output reads as oddly off when it goes wrong.
Frame is the layer that makes the operator's perception explicit. Three things define it for any decision: the lens, the signals, and the references. Write all three down for each of your priority decisions and you will have done more decision architecture than ninety percent of the teams currently rolling out AI.
Here is what each one is, and how to capture it.
|
|
01
|
The lens
The lens is the categorization the decision-maker uses. Not "is this a good lead" but "is this a fit-on-budget lead, a fit-but-stretch lead, a not-fit lead, or a wrong-fit-but-referral lead." The lens names the buckets. It tells the system what the answer can be before it asks how to choose.
Operators usually have the lens running silently in their heads. The job of decision architecture is to make it explicit and exhaustive. Three to seven buckets is typical. Fewer and you are forcing distinct situations into the same answer; more and the lens becomes too fine to apply consistently. The contractor we worked with had three buckets for new job inquiries: bid-fast, bid-careful, and decline. The pricing, the timeline, and the level of site investigation flowed entirely from which bucket the inquiry landed in. Once we wrote that down, we discovered his junior estimator was using a different lens — five buckets, and one of them was "ask the boss" — which explained almost every dispute in their pricing history.
|
|
|
02
|
The signals
Signals are the specific pieces of information the operator looks at to place a situation in one of the lens buckets. They are inspectable inputs, not vibes. For a sales qualification frame, signals might be company size, stated use case, named timeline, and presence or absence of a current vendor. For an escalation frame, signals might be ticket age, customer tier, repeat-issue flag, and sentiment in the most recent reply.
The mistake most teams make is over-collecting. They list every piece of data adjacent to the decision and call it the signal set. Real framing is tighter than that. The four or five signals your best people actually use are doing ninety percent of the work; the rest is noise that confuses both humans and systems. The fastest way to find the right list is to ask your top operator to walk through three recent cases and narrate which pieces of information actually moved their thinking. The ones that did not get mentioned are not signals. They are decoration.
|
|
|
03
|
The references
References are the prior cases the decision-maker compares against. The "this looks like that deal we did in March" pattern that makes experienced operators feel like they are running on intuition. They are not. They are doing fast retrieval against a library of past situations and outcomes they have personally lived through. It feels like a feel because nobody has ever written the library down.
References are the layer AI most often does not have. You can give it the lens, you can give it the signals, and it will still get the call wrong because it has no library of cases that look like the one in front of it — only generic training data. For each priority decision, capture three to five anchor cases that exemplify each lens bucket. A bid-fast case. A bid-careful case. A decline case. Describe what made each one belong in its bucket. These anchors become the patterns the system can pattern-match against, and they are what make AI output start to sound like your best people instead of like a smart stranger.
|
|
Lens, signals, references. Write all three down for one decision and something changes. The decision stops being "a feel my best person has" and starts being something a new hire, a contractor, or a system can replicate with most of the same quality. Not all of it — your top operator's thirty percent of pure judgment is still theirs. But the seventy percent of structured perception becomes inspectable, teachable, and encodable.
The other thing that changes is harder to predict and more valuable. When you write the frame down, you usually find that two of your senior people are using different ones. Different lenses. Different signal priorities. Different reference cases. Both are getting acceptable outcomes, but the outcomes are acceptable in different ways. Until that gap is surfaced, no system you build downstream can be consistent — because the humans it is modeled on were not consistent either. Frame is where the team aligns on what "right" looks like before any code gets written.
This is the unglamorous but expensive part of decision architecture. Most teams skip it. Most AI implementations fail because of it.
|
|
Free Worksheet · Part 3
The Frame worksheet
Three sections — lens buckets, the four-to-five signals, anchor references for each bucket — ready to fill in for one decision from your audit. Reply with "frame" and I will send it directly. Missed earlier worksheets? Reply "all" and I will send the full set (Audit, Trigger, Frame) in one message.
|
|
|
Next Week · Part 4 of 6
Layer 04 — Logic
With the trigger mapped and the frame written down, we get to the layer everyone thinks decision architecture is actually about — the criteria, the weights, and the reasoning that produces the call. It is the most technical layer of the method, and most teams have less of it written down than they think.
|
|
Doing the framing work on your own decisions and finding that two of your senior people use different ones? That is exactly the conversation a Discovery call is designed for. Bring the frame for one decision — including the disagreement — and we will work through how to reconcile it before encoding.
Or read this issue on LinkedIn.
|
|
|
|