The Intuition Audit

A senior editor reviews a draft proposal submitted by a junior associate. Within ten seconds, the editor frowns, highlights a paragraph, and rewrites it. When the associate asks why the change was made, the editor hesitates, searches for the words, and finally says, "It just didn't feel right. My gut told me it was too soft. You need to develop a feel for these things." While this explanation is common, it is also an operational bottleneck. It leaves the junior associate confused, the editor exhausted by endless editing rounds, and the agency unable to scale its standards.

This reliance on "gut feeling" is a major barrier to leverage in the automation era. Every experienced professional possesses a reservoir of tacit knowledge—intuitions built over years of trial, error, and client interaction. We know when a design layout is unbalanced, when a code architecture is fragile, or when a strategic pitch lacks tension. But because we treat this knowledge as a mystical quality rather than a systematic process, we fail to capture it. We remain the sole gatekeepers of quality, spending our days manually correcting outputs instead of designing the systems that prevent those errors in the first place.

The hidden thinking failure here is the assumption that expert intuition is unexplainable and therefore uncodifiable. In psychology and decision theory, "intuition" is recognized not as magic, but as rapid, subconscious pattern recognition. The brain compares the current situation against a database of past experiences, identifies micro-signals of success or failure, and delivers a conclusion as an emotional signal—a gut feeling. The cognitive error lies in accepting this signal as the end of the process. By failing to audit our own reactions, we miss the opportunity to translate our subconscious expertise into explicit rule systems that can be taught to our teams and programmed into our automation tools.

To bridge this gap, we must perform an intuition audit. This is the process of deconstructing our immediate, subjective reactions to a piece of work and translating them into objective, repeatable logic. We must move from saying "this feels wrong" to defining exactly what structural, syntactic, or visual rules have been violated. The better question to ask is: What is the specific, repeatable rule my brain is using to evaluate this asset, and how can I state that rule as a constraint for a model?

Consider the difference in practice between vague prompting and an audited constraint system.

A professional who has not audited their intuition might prompt a model like this:

Write a short executive summary for our project proposal. Make it sound strategic, professional, and convincing.

The model returns a standard, corporate response:

In order to maximize operational efficiency and align with strategic business objectives, we propose a comprehensive optimization framework. By leveraging our industry-leading methodology, we will facilitate cross-functional synergy and drive sustainable growth across your core business units...

The professional reads this and immediately feels their stomach drop. It feels bloated, insincere, and empty. But instead of deconstructing this reaction, they simply tell the model:

That sounds too corporate. Rewrite it to be more direct and engaging.

The model tries again, but because "direct and engaging" is just as vague as "strategic and professional," the second draft is only marginally better. The user is trapped in a loop of trial-and-error prompting, frustrated by the model's inability to read their mind.

An acumen-driven professional approaches the same task by auditing their gut reaction to the corporate draft. They ask themselves: Why did I reject this?

They identify three specific rules:

1. Every sentence must start with a concrete action, not an introductory clause like "in order to."
2. No paragraph may contain passive voice (e.g., "we propose" instead of "a framework is proposed").
3. We must ban generic business nouns like "synergy," "growth," "methodology," and "framework."

They codify these rules into a system prompt:

Write an executive summary for our project proposal. Follow these three structural constraints:

1. Start every sentence with an active verb. Do not use introductory clauses (e.g., "To do X, we will Y").

2. Write in the active voice. Identify who is performing the action in every sentence.

3. Do not use any of the following words: synergy, growth, methodology, framework, leverage, optimize, or maximize. Focus instead on concrete operational changes (e.g., reducing support tickets, moving data, training staff).

The resulting draft is clean and sharp:

"We migrate your legacy client records to a secure cloud database in forty-eight hours. This migration reduces your customer service response times by thirty percent because your support team accesses transaction history on a single screen. We train your staff on the new database interface during three scheduled workshops."

This draft matches the professional's taste on the first try. The difference was not the model's capability, but the professional's clarity. The intuition audit allowed the user to extract their tacit standards and enforce them as hard logic constraints.

We must accept that our gut is not a black box. It is a highly optimized sorting mechanism that operates on rules we have forgotten we know. Our job is to remember those rules. By deconstructing our taste, we do not lose our creative edge; we gain the ability to scale it. We turn our private intuition into a shared, durable asset that can guide both human teammates and automated models toward consistent excellence.

Behavioral Takeaway

• Keep a red-pen log: The next time you edit a junior colleague's work or reject a generated output, write down the edit. Next to it, write the rule behind the edit. Do not allow yourself to write "it sounds better." Force yourself to explain the syntactic or logical reason for the change.
• Draft an exclusion list: Build a list of words, phrases, or design patterns that consistently trigger your professional disapproval. Share this list with your team and paste it into the system prompts of your automated workflows.
• Run a post-mortem on success: When a project or asset succeeds, run an audit on what went right. Deconstruct the specific decisions that contributed to that success and write them down as a set of design constraints for future projects.