Encoding Taste in Practice

An experienced person can often explain why a piece of work is wrong long before they can specify everything that would make it right. The email sounds evasive. The proposed workflow makes the customer do our administration. The analysis answers the question in the brief while missing the decision that prompted it.

That judgment is useful material for working with AI. Writing it down gives another person or an assistant something more specific to work from than “make it good.” It also makes the judgment available for disagreement, which is part of making it better.

Taste consists of choices

We use taste to mean the accumulated judgment that shapes a person’s or a group’s work. It includes aesthetic choices, but extends to what they notice, what they protect, which compromises they accept and what they consider a useful result.

A taste package makes some of that judgment explicit. Four kinds of material are particularly useful:

• Philosophy: positions that affect a decision. “Start with the person receiving the service” should change what a team chooses to build.
• Constraints: boundaries that rule out an otherwise tempting choice. “Do not turn a customer example into a public case without permission” is more useful than a general promise to be responsible.
• Output standards: what someone should be able to do with the result. A recommendation should explain the decision, its reasoning and the material uncertainty.
• Behavior: how the work is approached. Look at a real example before proposing a system. Explain a disagreement. Bring something useful to a conversation.

Examples make those statements less ambiguous. A paragraph that works, an output someone rejected, and the reason for the rejection can teach more than another page of adjectives. The explanation matters: copying the surface of good work will not reliably reproduce the judgment that made it good.

The rules have to survive contact with one another

Before our October 2026 revision, our Goose Group package asked us to end every interaction with a clear next step. It also asked us to protect gifts: cultural objects and writing should be good in their own right, without being forced into campaign logic.

Applying that first rule mechanically to Gift, Not Asset could turn its ending into an invitation to buy something. The sentence might be clear, actionable and completely wrong for the essay.

Reviewing the writing exposed the conflict, and we changed the rule: the ending should fit the purpose of the work. A recommendation should make the next decision easier. A cultural essay can earn its ending by leaving the reader with an idea worth carrying. The package needs enough context to distinguish them, and the person using it needs permission to notice when a general rule does not fit.

This is what encoding taste asks of us. Writing down a preference is a beginning. Explaining where it helps, what it protects and when another concern matters more makes it usable.

Different lenses can point in different directions

Our former public feedback-triage playbook included this advice: “No feedback today? Good. Meeting’s over in 2 minutes.” It wanted people to get help quickly and allowed the frequency to fall as a tool settled into use. Even so, its starting assumption was that the meeting happened.

A Rory Sutherland reading asks what removing it might lose. A dependable place to get help can reassure people who are trying something unfamiliar. Its value may exceed the decisions made during it.

A Mark Fisher reading asks whether attending has become evidence of responsiveness while the actual problems remain untouched. A recurring meeting can let everybody feel that feedback is being handled without anyone having to change the work.

A David Graeber reading asks who prepares for it, who has to explain themselves, and who is allowed to say it is no longer useful. Two minutes on the calendar can still require someone else’s preparation and interruption.

These readings expose different things worth preserving or changing. A team may value a regular conversation enough to keep it. Another may get better support from a direct question and an inspectable record of the response. The choice depends on the people using the arrangement.

For our own public guidance, we retired the prescribed playbook. Our account of how the work happens starts with the task, the people, and the help they need. Someone still has to respond to problems. Removing a template does not establish that support improved; that would require following the work into use.

The reusable judgment is to preserve useful support while questioning the ceremony. The local choice is how a particular team does that. A package should help people see the difference without turning either choice into a universal rule.

Start with the people who make the judgments

The source material is already in the work: drafts and corrections, decisions, examples people return to, and things experienced colleagues refuse to let through. We ask them to explain a few of those choices.

Why was this proposal convincing? Which detail made that customer response feel careless? What did the new person miss? Which apparently inefficient step is doing something valuable?

A first package can be small. It needs enough material to improve one recurring task. Trying it will reveal the vague rules, missing distinctions and examples that merely looked representative. There is little value in extracting every document in the company before someone has used the first page.

Nor should the most senior person’s preferences automatically become the company’s judgment. People receiving the work, handling its exceptions and maintaining what follows know things its author may never see. Their corrections belong in the process. A package that nobody is allowed to challenge is an unusually well-documented prejudice.

Keep judgment separate from the current facts

A package can describe how to make a recommendation. It cannot, by itself, tell us which decision a customer made yesterday or which version of a design they approved.

Those facts belong in their owning systems. A current project discussion, an approved asset and a reusable principle have different lifetimes and different authorities. Copying all three into a single body of “context” makes it harder to know which one to trust when they disagree.

We use Smaak for reusable judgment. Basecamp holds our situated company and customer context, including the reasoning around decisions. Customer systems, documents and workbenches hold their own records and outputs. The assistant retrieves the relevant material for the task and points back to its source.

A customer’s recurring standards can be reusable judgment. Their latest project status is still project status. A useful pattern learned in one engagement does not become a general principle merely because we can copy it into a package.

The distinction also makes revision easier. If the customer changes a decision, we should be able to update its authoritative record without hunting down several competing summaries. If a principle changes, we should know which principle changed and why.

Use a procedure when it saves work

Judgment, procedure and tools do different jobs. The judgment explains what matters. A procedure describes a useful way to perform a recurring task. Tools let a person or assistant act on the relevant material.

For a review, a procedure might retrieve the current brief, inspect the work, identify the consequential differences and explain a proposed change. It can be written down because repeating those mechanics from memory adds little value. The review still needs judgment about which differences matter.

The AI assistant’s working environment brings these pieces together. It might be a chat, a coding tool or a more specialized application. The useful part is that it can find the appropriate judgment and source material, use the tools it needs and make its work understandable to the person receiving it.

Not every task needs a new interface, a search index or a knowledge graph. Start in the environment people already use. Add machinery when a real difficulty gives it a job.

Test the decision, not just the voice

An output can sound exactly like us while being wrong. Familiar phrasing is a weak test of whether the package helped.

We look at real work. Did the assistant notice the important constraint? Did it distinguish a fact from an inference? Did it help someone see an option they had missed? Was the result useful enough to act on, and what did the person still have to correct?

A correction is especially informative when it exposes the reasoning. “This feels off” starts a conversation. “This recommendation saves us time by moving three tasks onto the customer” identifies a problem the package can help catch again.

The next step is to decide what kind of correction it was. A missing fact belongs in the relevant source. A one-off preference may belong to the immediate task. A recurring judgment may improve the package. Treating every edit as a new universal rule produces a system that accumulates prohibitions until it can barely move.

Keep useful examples, including failures, and try the changed judgment on another task. A rule that improves one answer can damage the next. The point is to develop a better way of seeing, with enough history to understand how it changed.

The person should become more capable too

There is a difference between making someone’s judgment available and making that person unnecessary to understanding it. A written rule cannot contain every circumstance that gave it meaning.

Working through a result together lets a less experienced colleague learn why a choice was made. It lets the experienced person notice what they had been taking for granted. AI can help prepare and compare the material, while the conversation does work a polished final answer cannot do on its own.

That is one reason we treat taste packages as working material. People should be able to inspect them, change them and carry them into another environment. Their value comes from helping people do better work, including when the right move is to question the package.

Start with one recurring task and a few examples whose quality someone can explain. Write down the choices that matter, use them, and pay attention to the disagreement. That is where the next useful rule is likely to be.