Behavior Patterns for Creating with GenAI

If you have spent much time working with a coding agent, you have probably had this experience:

• You explain what you want.
• You provide a specification.
• You describe the constraints.
• You tell the agent to work carefully and incrementally.

And then it wanders off and builds something technically related to what you requested, but not quite the way you wanted it approached. The natural response is to add more instructions. And then more instructions. Eventually the specification starts looking like an employee handbook written after a series of unfortunate incidents.

We have another tool available to us: established terms that name concepts we might otherwise need several sentences to describe:

• Vertical slice
• Walking skeleton
• Characterization test
• Back-of-the-envelope estimation
• Least privilege

A few words can carry more meaning than their token count suggests. At Renaissance Solutions, we call these Behavior Patterns. We can think of them as semantic compression: a short term standing in for a larger cluster of meanings and practices. When used well, they reduce friction and cognitive load for both humans and AI.

A Behavior Pattern does not replace a specification. It compresses part of one. Important constraints, local meaning, and success criteria still need to be stated and checked.

---

The Idea Started With Matt Pocock’s “Leading Words”

Matt Pocock’s work on writing instructions for coding agents gave us the starting point for this article. In his writing-for-agents skill, Matt uses leading words for compact concepts that can recruit associations a model already has and anchor a broader region of behavior with few tokens.

Matt also explains that the same vocabulary can work in two places. Inside a document, it can help anchor execution. When it appears across prompts, documentation, and a codebase, it can help connect those contexts.

Leading words is Matt’s name for this technique, not an industry-standard category. Behavior Patterns is our broader working label for exploring the same idea across prompts, specifications, coding agents, chatbots, and other disciplines. Neither term is canon. Most of the underlying vocabulary comes from established human practices.

---

A Behavior Pattern Is Semantic Compression

Consider this instruction: “Work on a small piece of functionality that crosses all the necessary layers of the system. Get that narrow piece working end to end before expanding outward. Use what you learn from implementing it to influence the architecture of the remaining system.”

There is nothing wrong with that instruction. But an experienced software developer might say: “Start with a vertical slice.”

Those two words, vertical slice, carry conceptual weight. The term appears throughout software writing and practice, so a model may associate it with:

• End-to-end functionality
• Incremental development
• Rapid feedback
• Early integration
• Reducing uncertainty
• Avoiding large amounts of disconnected infrastructure

We have compressed a paragraph of instructions into a recognized concept. But compression is not the same thing as precision. The model may associate the term with different interpretations. The surrounding context may cause it to emphasize one aspect and ignore another. Another model may respond differently. So a useful working definition is: A Behavior Pattern is an established term used as semantic compression to encourage a larger family of behaviors, assumptions, techniques, or ways of reasoning.

The word encourage is important. Using Behavior Patterns does not turn prompts or specifications into a programming language. When used consistently, they can give people, coding agents, and chatbots a shared conceptual vocabulary.

This is not a new category of software design pattern. It is a working name for established terms used to steer how people and AI approach a task.

An Example from Our Work

We recently encountered this while building an automated pipeline for our Glossary Shorts videos. The pipeline turns a structured term definition into narration, visuals, metadata, and ultimately a finished short video.

Early versions relied on instructions that amounted to “check everything before you publish it.” Those instructions were reasonable, but they left an enormous amount of interpretation to the agent.

We started describing parts of the workflow using more established concepts, including fail closed. For this pipeline, that meant an artifact should not advance simply because the automation reached the next step. Required checks had to pass first. If the system could not establish that something was correct, the workflow should stop for review rather than assume success.

That distinction mattered when we produced a short explaining race conditions. One version ended by saying that the outcome of a race condition depends on what finishes first. That sounded plausible, but it was wrong for the example we were showing. The important issue was the timing and ordering of operations, not simply which operation finished first.

A required review gate caught the mismatch before we treated the artifact as finished. We corrected the narration and kept the check in the pipeline, so the lesson applied to later videos instead of becoming a one-off repair. By preventing uncertainty from becoming approval, fail closed reduced repeated rework and the whack-a-mole of ghost blockers in later review cycles.

Fail closed did not tell the coding agent how to build our entire workflow. We still had to define what needed checking and what counted as passing. But the term gave us a compact way to express an important default: uncertainty does not silently become approval.

That is exactly what we mean by a Behavior Pattern.

---

An Aside About Piano Tuners

One of the Behavior Patterns that made this idea click for us was back-of-the-envelope estimation.

Consider a classic Fermi estimation problem: “How many piano tuners are there in Chicago?”

If we need an accurate count, we could search directories, check whether the businesses are active, remove duplicates, and decide whether the Chicago metropolitan area counts. But suppose we only need to know whether the answer is closer to 5, 50, 500, or 5,000. We can ask: “Give us a back-of-the-envelope estimate of the number of piano tuners in Chicago. Show your assumptions.”

Now we have invoked a different way of reasoning.

Using deliberately rough illustrative assumptions, start with 2.7 million residents and 2.3 people per household. That gives us about 1.17 million households. If 2% have a piano, we have roughly 23,400 household pianos. Add 6,000 pianos in schools, churches, studios, venues, hotels, and other institutions, and the estimate becomes about 29,000 pianos.

If the average piano is tuned once every two years, that creates about 14,500 tunings per year. If a full-time tuner performs 600 tunings per year, the result is roughly 24 full-time-equivalent piano tuners.

Is that the actual number? Probably not. That is not the point. We transformed the question into a model:

population → households → piano ownership → total pianos → tuning frequency → tuner capacity

Now we can challenge the assumptions. What if piano ownership is 1% rather than 2%? What if most household pianos are tuned once every four years? What if a tuner completes 400 tunings per year rather than 600?

The answer moves. More important, we can see why it moves.

The Behavior Pattern did not give the AI additional facts about Chicago piano tuners. It changed the route through the problem.

That is what makes these patterns interesting.

---

AI Makes Vocabulary More Valuable, Not Less

Generative AI lowers the barrier to entering unfamiliar disciplines. Someone who has never made a film can now create one. Someone who is not a programmer can build useful software. Someone who is not a statistician can explore a dataset.

That access does not make conceptual vocabulary less important. It may make the vocabulary more useful.

Consider filmmaking. We could tell an AI video system: “Make this shot feel more cinematic and have us notice the woman in the background.” Or we might learn about rack focus, motivated lighting, or diegetic sound. Each term gives us a more precise handle for discussing what we want, even if we have never operated a cinema camera.

The same thing happens in software with terms such as idempotency, characterization test, walking skeleton, blast radius, and backpressure. AI can lower the barrier to doing specialized work while increasing the value of the shared conceptual vocabulary around that work.

The same chatbot or coding agent can help us discover that vocabulary. We can ask:

• “What established filmmaking terms would help us describe the composition, focus, movement, lighting, editing, and sound we want? Explain each before recommending it.”
• “What established software architecture terms should we understand before designing this API? Explain what each term would encourage and what could go wrong if we apply it badly.”
• “What established reasoning terms might help us investigate whether this idea is plausible? Explain the method and its limits.”

Learning the name is not the same as learning the discipline. A short conversation does not make us cinematographers, security engineers, statisticians, database architects, or software engineers. It can help us ask better questions, communicate intent, notice what we do not understand, and decide what to learn next.

This creates a useful recursive relationship: Behavior Patterns can help us work with AI, and AI can help us discover Behavior Patterns.

Established Does Not Mean Ancient or Canonical

Some terms have been used for decades. Others spread quickly. Tiago Forte’s Building a Second Brain popularized one compact label for personal knowledge management. Matt Shumer’s Gauntlet Loop acquired a name and spread through the agent community much more recently. Both show how repetition, discussion, search, and hype can make a term usable in a short period.

That does not mean every model already knows the term, knows the same version of it, or learned it during training. A search-capable tool may retrieve a current definition. A model without search may guess from the words or produce an older or conflicting interpretation.

When a term is new or moving quickly, provide a definition or a reliable source. If the tool can search, ask it to show what it found. Recognition is something to verify, not assume.

---

Behavior Patterns Can Feel Like Spells

While a few carefully chosen words can produce large changes in an AI’s output or approach, that does not make them magic words.

Like spells in the better fantasy stories, knowing the words is not enough. We need to understand what we are invoking, when it fits, and what else it might bring along. We do not need to memorize a grimoire, but we do need to check unfamiliar terms against reliable sources before trusting them.

We are not turning prompts into Python. If we write “Use a walking skeleton,” we have not called a function named walking_skeleton().

The term appears in books, articles, documentation, discussions, and code, but those sources do not all define it the same way. We usually cannot establish which sources a proprietary model encountered during training. The response can also change with the model, model version, surrounding context, tools, codebase, agent harness, and previous turns.

Never let familiarity with a term masquerade as evidence that the AI interpreted it the way we intended.

When a Behavior Pattern produces an unexpected result:

• Ask the AI to state what the term means in this context.
• Inspect its plan or reasoning summary when the tool exposes one.
• Examine the artifacts it produces.
• Test the result.
• Replace the term with explicit instructions and compare.
• Refine the surrounding context.
• Decide whether the term earned its place.

The AI’s explanation is a report we can inspect. It is not proof of the hidden mechanism that produced the output.

This is how we develop a shared conceptual vocabulary with a probabilistic system.

---

Use Behavior Patterns Deliberately

There is a tempting conclusion: “If established terms work, we should put lots of them into every specification.”

Please don’t. A Behavior Pattern is useful because of what it brings with it. That is also its danger.

• Red-green-refactor selects a development process.
• Walking skeleton influences implementation order and architecture.
• One-way door changes the amount of deliberation a decision receives.
• Least privilege changes the system’s permission posture.
• Fail fast changes how failures are handled.

These are more than labels. They can direct how work gets done. Useful Behavior Patterns reduce ambiguity, not just tokens. Sometimes twelve explicit sentences are better than two clever words.

The semantic neighborhood around a term may also contain assumptions we did not intend. Before relying on one, ask:

• What does this term mean here?
• What behavior does it encourage?
• What assumptions come with it?
• What alternatives exist?
• What failure modes should we watch for?
• Does the concept fit this problem, or does it merely sound sophisticated?

Vocabulary can help us steer an AI, but unfamiliar jargon can create a false sense of control. Knowing what to say is not evidence that we understand what we summoned.

Discover, Learn, and Test

Every discipline has accumulated compact vocabulary for useful ways of thinking and working. We can ask a chatbot or coding agent to help us find it:

We are about to modify a large, unfamiliar codebase. What established terms describe useful ways of approaching this work? We are looking for compact concepts that could influence reasoning, process, design, or risk. Explain each term, when it fits, and what could go wrong before recommending that we use it.

For a filmmaking task, we can replace the software language with composition, camera movement, editing, lighting, pacing, and sound. The term Behavior Patterns does not need to appear in the prompt. What matters is asking for established terms, their meaning, and their limits.

A useful loop is: Discover → Learn → Choose → Experiment → Observe → Adjust.

The appendix provides a broad starting point. Most readers will recognize only a handful of its terms, and different readers will recognize different handfuls. That is the point. The catalog should help us latch onto a concept, not ask us to memorize the list.

Test the Idea

We should be cautious about turning a useful observation into folklore. If we think a Behavior Pattern improves an AI’s work, we should test it.

For a task we can safely repeat:

• Define the observable outcome before running the comparison.
• Record the model, version, agent harness, tools, and relevant context.
• Start each condition in a fresh session so one run does not teach the next.
• Run several trials with ordinary-language instructions and several with the Behavior Pattern when cost permits. Alternate the order rather than always running one condition first.
• Keep the task, available tools, and surrounding context as similar as practical.
• Compare plans, artifacts, tests, and outcomes. Give more weight to observable work than to polished explanations.
• Ask the AI what the term meant in that context, but treat its answer as a report, not proof of an internal cause.
• Record failures with the same care as successes.
• Treat another model as a separate comparison, not another trial of the same system.

Small trials can reveal useful differences. They do not prove that a term caused those differences. We are learning when a term helps, how it fails, and how much trust it deserves.

We may discover that a term changes the approach, only helps when paired with explicit constraints, activates assumptions we did not want, works with one model but not another, or loses to plain language.

What AI Changes About Vocabulary

AI may reduce the amount of specialized execution we need to perform while making conceptual literacy more valuable.

We may not need to become cinematographers to make a short video, but knowing enough to ask about rack focus, motivated lighting, diegetic sound, or match cuts can improve the conversation. We may not need to implement every software-engineering technique ourselves, but knowing when to ask about characterization tests, vertical slices, idempotency, blast radius, or backpressure can change how we and the AI approach a problem.

The value is not knowing more jargon. It is having more conceptual handles available when we need them. A chatbot can do some of the work and, in safe-for-AI contexts, help us learn the language of that work.

If this idea earns traction through real use, Renaissance Solutions plans to add useful terms to our glossary and develop at least one learning module and lab around discovering, applying, and testing them. Those resources should preserve each term’s source, scope, and observed failure modes rather than turn a working observation into canon.

What Behavior Patterns Have You Discovered?

The field guide will never be complete. We will keep encountering established terms, adapting them to new contexts, and watching newer terms spread. Recently coined terms may become useful quickly when models can retrieve or have encountered them. Others will remain unknown until we define them.

If you have found an established term that changes how an AI approaches a problem, we would like to hear:

• The term
• The discipline it comes from
• What you expected it to encourage
• How you used it
• What happened
• Which model, chatbot, or coding agent you tried
• Where it worked
• Where it failed
• What you learned

Especially send the failures. Failures help us distinguish useful semantic compression from words that merely sound impressive.

Behavior Patterns are not a new programming language for controlling AI. They are something familiar: vocabulary humans have developed for describing useful ways to think and work.

AI gives us a new reason to learn that vocabulary.

Semantic compression saves words. It does not save judgment.

---

Appendix: The Behavior Pattern Field Guide

This appendix is intentionally broad. Most readers will resonate with only a handful of these terms, and different readers will find different handfuls. Start with what is familiar or useful; there is no need to absorb the whole catalog.

These are established terms from several disciplines that we are exploring as Behavior Patterns. The categories and modes are our working organization, not a canonical taxonomy. Definitions vary by field and context, so confirm what a term means before relying on it.

Each linked pattern name points to a source definition or a trusted explanation of the intended concept. Wikipedia is used when it has a close match; otherwise the link goes to an originator, standard, institution, or established technical reference.

Six entries are marked Start here. They are not more important than the others. They are accessible places to begin experimenting with the idea.

The Mode label describes the main dimension the term may influence:

• Reasoning: how a problem is thought through.
• Process: how work proceeds.
• Design: qualities we want the result to exhibit.
• Risk: how uncertainty, consequences, and safety are handled.

The dimensions overlap. A term may influence more than one.

Reasoning and estimation

Back-of-the-envelope estimation — Start here

• Invokes: Quick approximation through explicit assumptions
• Mode: Reasoning
• Use when: You need to understand scale before investing in precision
• Watch for: False precision and hidden assumptions

Fermi estimate

• Invokes: Decomposition of a difficult quantity into estimable components
• Mode: Reasoning
• Use when: Direct data is not available
• Watch for: Errors multiplying across assumptions

Sanity check

• Invokes: Independent plausibility checking
• Mode: Reasoning
• Use when: Before trusting a result
• Watch for: Repeating the same reasoning and calling it verification

Order-of-magnitude analysis

• Invokes: Focus on scale rather than exact values
• Mode: Reasoning
• Use when: You need to distinguish 10 from 1,000 more than 47 from 52
• Watch for: Treating rough estimates as measurements

Sensitivity analysis

• Invokes: Examine which assumptions materially affect results
• Mode: Reasoning / Risk
• Use when: Several uncertain assumptions drive an answer
• Watch for: Varying assumptions that barely matter

First principles

• Invokes: Decompose assumptions and reason from foundational constraints
• Mode: Reasoning
• Use when: Conventional assumptions may hide the real problem
• Watch for: Reinventing well-understood knowledge

Counterexample

• Invokes: Search for a case that breaks a claim or rule
• Mode: Reasoning / Risk
• Use when: Testing generalizations and proposed rules
• Watch for: Treating one edge case as proof that the whole idea is worthless

Steelman

• Invokes: Construct the strongest reasonable version of another position
• Mode: Reasoning
• Use when: Comparing competing approaches
• Watch for: Inventing a stronger argument than anyone holds

Exploring and building

Spike

• Invokes: Time-bounded exploration intended to answer a question
• Mode: Process / Reasoning
• Use when: Technical uncertainty is blocking progress
• Watch for: Prototype code becoming production code

Proof of concept

• Invokes: Demonstrate feasibility before committing to implementation
• Mode: Process
• Use when: You are unsure whether something can work
• Watch for: Mistaking feasibility for production readiness

Tracer bullet

• Invokes: Narrow implementation that proves an important path through the system
• Mode: Process
• Use when: Integration or architecture is uncertain
• Watch for: Building a path that avoids the hardest uncertainty

Walking skeleton

• Invokes: Minimal functioning implementation connecting major system pieces
• Mode: Process / Design
• Use when: Starting a system with significant integration concerns
• Watch for: Excessive scaffolding before useful behavior exists

Vertical slice

• Invokes: Small end-to-end piece of useful functionality
• Mode: Process
• Use when: Building incrementally
• Watch for: Slices that are technically vertical but provide little learning

Thin slice — Start here

• Invokes: Reduce scope while preserving the essential experiment
• Mode: Process
• Use when: A task is becoming too large
• Watch for: Cutting away the part that matters

Progressive enhancement

• Invokes: Start with a functional baseline and add capabilities
• Mode: Design / Process
• Use when: Capabilities or environments vary
• Watch for: Avoiding a useful baseline by relying on later layers

Testing and verification

Red-green-refactor

• Invokes: Failing test, minimal passing implementation, then cleanup
• Mode: Process
• Use when: Implementing testable behavior
• Watch for: Tests becoming mirrors of the implementation

Characterization test

• Invokes: Capture existing behavior before modifying unfamiliar code
• Mode: Process / Risk
• Use when: Legacy or poorly understood systems
• Watch for: Encoding bugs as desired behavior

Regression test — Start here

• Invokes: Preserve a previously repaired behavior
• Mode: Process
• Use when: Fixing defects
• Watch for: Testing only the example rather than the failure class

Test seam

• Invokes: Create a controllable boundary around difficult dependencies
• Mode: Design / Process
• Use when: External systems make testing difficult
• Watch for: Distorting architecture solely for tests

Golden master

• Invokes: Capture current output and compare future output against it
• Mode: Process / Risk
• Use when: Refactoring complex systems with unclear behavior
• Watch for: Preserving undesirable behavior forever

Property-based testing

• Invokes: Verify invariants across generated inputs
• Mode: Reasoning / Process
• Use when: Many input combinations exist
• Watch for: Weak properties that pass while missing important failures

Differential testing

• Invokes: Compare independent implementations or systems on the same inputs
• Mode: Process / Reasoning
• Use when: Replacing or validating implementations
• Watch for: Shared assumptions causing both systems to be wrong

Design and architecture

Separation of concerns — Start here

• Invokes: Keep distinct responsibilities distinct
• Mode: Design
• Use when: Responsibilities are becoming tangled
• Watch for: Fragmentation into unnecessary abstractions

Single source of truth

• Invokes: One authoritative representation of important information
• Mode: Design
• Use when: State or configuration is being duplicated
• Watch for: Creating a centralized bottleneck

Information hiding

• Invokes: Conceal implementation decisions behind stable boundaries
• Mode: Design
• Use when: Designing modules and interfaces
• Watch for: Hiding information consumers need

Deep module

• Invokes: Simple interface hiding substantial useful complexity
• Mode: Design
• Use when: Abstraction boundaries are proliferating
• Watch for: Giant components with deceptively small interfaces

Loose coupling

• Invokes: Reduce unnecessary dependencies between components
• Mode: Design
• Use when: Components need to evolve independently
• Watch for: Building indirection for hypothetical changes

High cohesion

• Invokes: Keep strongly related behavior together
• Mode: Design
• Use when: Responsibilities are scattered
• Watch for: Components growing beyond reasonable scope

Composition over inheritance

• Invokes: Assemble behavior from components rather than rigid hierarchies
• Mode: Design
• Use when: Modeling reusable behavior
• Watch for: Creating needless wrapper layers

Risk and decisions

Blast radius — Start here

• Invokes: Consider how far consequences can propagate
• Mode: Risk
• Use when: Migrations, deployments, permissions, or destructive operations
• Watch for: Imagining catastrophic chains without considering probability

Guardrail

• Invokes: Constrain behavior while permitting useful freedom
• Mode: Risk / Design
• Use when: Agents or users have meaningful autonomy
• Watch for: Constraints that prevent useful work

Reversible decision

• Invokes: Prefer choices that are inexpensive to undo
• Mode: Risk
• Use when: Requirements remain uncertain
• Watch for: Using reversibility to avoid necessary commitments

One-way door

• Invokes: Increase deliberation for difficult-to-reverse decisions
• Mode: Risk / Reasoning
• Use when: Making schema, API, infrastructure, security, or destructive decisions
• Watch for: Treating ordinary decisions as constitutional amendments

Least privilege

• Invokes: Grant only capabilities necessary for the task
• Mode: Risk / Design
• Use when: Working with permissions, credentials, agents, or APIs
• Watch for: Making systems unusably restrictive

Defense in depth

• Invokes: Use multiple independent protections against failure
• Mode: Risk / Design
• Use when: Working with security and high-consequence systems
• Watch for: Layers that all fail for the same reason

Fail-safe defaults

• Invokes: Base access decisions on permission rather than exclusion, so lack of access is the default
• Mode: Risk / Design
• Use when: Designing access controls, permissions, credentials, or agent authority
• Watch for: Treating default-deny as a substitute for usable permission design

Threat model

• Invokes: Identify assets, adversaries, attack surfaces, and plausible failures
• Mode: Risk / Reasoning
• Use when: Security matters
• Watch for: Inventing dramatic attackers while ignoring mundane risks

Resilience and operations

Fail fast

• Invokes: Surface invalid states early
• Mode: Process / Design
• Use when: Continuing would compound errors
• Watch for: Killing recoverable work

Graceful degradation

• Invokes: Preserve useful function during partial failure
• Mode: Design / Risk
• Use when: Dependencies can fail
• Watch for: Hiding failures people need to understand

Backpressure

• Invokes: Prevent producers from overwhelming consumers
• Mode: Design
• Use when: Queues, streams, APIs, or agents can outpace consumers
• Watch for: Moving the bottleneck rather than controlling it

Idempotency

• Invokes: Produce a safe equivalent result when an operation is repeated
• Mode: Design / Risk
• Use when: Working with retries, APIs, migrations, or automation
• Watch for: Hidden side effects that are not idempotent

Observability

• Invokes: Make internal behavior inferable from outputs and signals
• Mode: Design / Process
• Use when: Operating or debugging systems
• Watch for: Instrumentation becoming the project

Circuit breaker

• Invokes: Stop repeated calls to a failing dependency
• Mode: Design / Risk
• Use when: Remote dependencies fail or overload
• Watch for: Opening too aggressively

Bulkhead

• Invokes: Isolate failures and resource exhaustion
• Mode: Design / Risk
• Use when: Shared resources can cause cascading failures
• Watch for: Wasteful isolation

Graceful recovery

• Invokes: Return predictably after failure
• Mode: Design / Process
• Use when: Restarting, reconnecting, or rebuilding state
• Watch for: Recovery introducing corruption

Communication and creative work

Show, don’t tell — Start here

• Invokes: Communicate through observable action, detail, or evidence rather than explanation alone
• Mode: Design / Process
• Use when: Writing scenes, examples, demonstrations, or explanations
• Watch for: Avoiding necessary explanation just because exposition feels inelegant

In medias res

• Invokes: Begin inside the action rather than with setup
• Mode: Design
• Use when: Stories, presentations, videos, or demonstrations need a faster entry
• Watch for: Confusing the audience because essential context arrives too late

Establishing shot

• Invokes: Orient the audience to place, situation, or relationships before moving closer
• Mode: Design
• Use when: Beginning a scene or changing location or context
• Watch for: Spending too long establishing what the audience already understands

Rack focus

• Invokes: Redirect visual attention by shifting focus between subjects or planes
• Mode: Design
• Use when: You want the viewer to notice a relationship or transfer attention within a shot
• Watch for: Using the technique decoratively when the attention shift has no narrative purpose

Match cut

• Invokes: Connect two shots through a shared visual, conceptual, or motion element
• Mode: Design
• Use when: Creating transitions that communicate continuity, contrast, or association
• Watch for: Choosing a clever visual match that muddies the intended meaning

Motivated lighting

• Invokes: Make lighting appear to arise from believable sources within the scene
• Mode: Design
• Use when: Generating or directing visually coherent scenes
• Watch for: Sacrificing readability or intent for strict realism

Diegetic sound

• Invokes: Treat sound as originating within the story world
• Mode: Design
• Use when: Sound source and audience interpretation matter
• Watch for: Confusing diegetic and non-diegetic sound when the distinction matters

Negative space

• Invokes: Deliberately preserve unused visual space to create emphasis, hierarchy, or mood
• Mode: Design
• Use when: Composing graphics, interfaces, slides, photographs, or video frames
• Watch for: Treating empty space as automatically good design

Visual hierarchy

• Invokes: Direct attention by making some elements perceptually more important than others
• Mode: Design
• Use when: Designing interfaces, graphics, slides, documents, or scenes
• Watch for: Making everything prominent and therefore nothing prominent

Progressive disclosure

• Invokes: Reveal complexity as it becomes relevant rather than all at once
• Mode: Design / Process
• Use when: Explaining complex subjects or designing interfaces and learning experiences
• Watch for: Hiding information people need to make an early decision

Rule of three

• Invokes: Organize information or creative elements into memorable three-part structures
• Mode: Design
• Use when: Writing, speaking, teaching, comedy, examples, or presentation structure
• Watch for: Forcing material into threes when the content has a more natural structure

Setup and payoff

• Invokes: Introduce information or an element early that gains significance later
• Mode: Design / Process
• Use when: Storytelling, demonstrations, teaching, presentations, or UX
• Watch for: Making the setup so conspicuous that the payoff becomes obvious

Callback

• Invokes: Reintroduce an earlier element with new context or meaning
• Mode: Design
• Use when: Writing, comedy, presentations, teaching, or longer conversations
• Watch for: Referencing something the audience no longer remembers or never noticed

Cold open

• Invokes: Begin with compelling material before formal introduction or context
• Mode: Design
• Use when: Videos, podcasts, presentations, articles, or demonstrations need an immediate hook
• Watch for: Creating an exciting opening that promises something the rest does not deliver

Beat

• Invokes: Treat a scene or sequence as a series of meaningful shifts in action, emotion, or information
• Mode: Reasoning / Design
• Use when: Planning scenes, scripts, presentations, conversations, or pacing
• Watch for: Mechanically chopping continuous material into artificial moments

Story arc

• Invokes: Organize material around development, change, tension, and resolution
• Mode: Reasoning / Design
• Use when: Narrative helps an audience understand or remember the material
• Watch for: Forcing inherently non-narrative information into a fake story

Foreshadowing

• Invokes: Introduce information early that prepares the audience for something later
• Mode: Design
• Use when: Stories, explanations, demonstrations, or presentations benefit from anticipation
• Watch for: Telegraphing the later event so strongly that nothing remains to discover

Contrast

• Invokes: Place meaningfully different elements together so the difference becomes salient
• Mode: Reasoning / Design
• Use when: Explaining alternatives, visual composition, storytelling, or persuasion
• Watch for: Creating false binaries or exaggerating differences

Audience surrogate

• Invokes: Use a character or participant whose questions and discoveries mirror the audience’s
• Mode: Design
• Use when: Teaching unfamiliar concepts through stories, simulations, or demonstrations
• Watch for: Making the surrogate artificially ignorant merely to enable exposition

Information gap

• Invokes: Deliberately create a gap between what the audience knows and wants to know
• Mode: Design / Reasoning
• Use when: Openings, explanations, mysteries, lessons, or demonstrations need curiosity
• Watch for: Withholding information artificially or drifting into clickbait

Pyramid principle

• Invokes: Barbara Minto’s structure of organizing supporting ideas under one main point
• Mode: Reasoning / Design
• Use when: Writing business documents, recommendations, analysis, or executive communication
• Watch for: Oversimplifying uncertainty because the conclusion appears first

Plain language

• Invokes: Prefer familiar, concrete language and direct structure
• Mode: Design
• Use when: Instructions, public communication, explanations, interfaces, or accessibility matter
• Watch for: Removing necessary technical precision

Active voice

• Invokes: Make the actor and action explicit
• Mode: Design
• Use when: Responsibility, instructions, or causal relationships need clarity
• Watch for: Treating passive voice as inherently wrong when the actor is unknown or irrelevant

Progressive summarization

• Invokes: Tiago Forte’s method of creating increasingly compressed layers of a note over time
• Mode: Process / Design
• Use when: Working with notes, research, knowledge bases, or long-running projects
• Watch for: Compressing away nuance that later turns out to matter