The 1-3-1 Communication Rule for Technical Decisions

Overview

The 1-3-1 Communication Rule is a structured decision-making format for tasks with multiple viable approaches. It produces a concise problem framing, three options with trade-offs, and an actionable plan for the recommended path. Use this when a user explicitly asks for a "1-3-1" response, says "give me options" or "what are my choices" for a technical decision, when a task has multiple viable approaches with meaningful trade-offs (architecture, tooling, migration strategy), or when a user needs a proposal they can forward to a team or stakeholder.

Do not use this format for simple questions with one obvious answer, for debugging sessions, or for tasks where the user has already decided on an approach.

Procedure

The 1-3-1 Communication Rule follows five ordered steps:

1. State the core decision or desired outcome in one concise sentence. Focus on the "what", not the "how" — no implementation details, tool names, or specific technologies. Keep it tight; if you need "and", you are describing two problems.

2. Present three distinct, viable approaches labeled A, B, C. Each option gets a brief description, pros, and cons. Options must represent genuinely different strategies, not minor variations of the same approach.

3. State which option you recommend and why, based on the user's context and priorities. Be direct — this is your professional judgment, not a hedge.

4. List the specific success criteria for the recommended option. These are concrete, verifiable outcomes — not vague aspirations. If the user picks a different option, revise this section to match.

5. Provide concrete steps to execute the recommended option. Include specific commands, tools, or actions where applicable. If the user picks a different option, revise this section to match.

Parameters

The format produces exactly these five parameters:

• Problem: One sentence stating the core decision or desired outcome, focusing on "what" not "how". Required.
• Options: Three distinct, viable approaches labeled A, B, C, each with brief description, pros, and cons. Required.
• Recommendation: One recommended option with reasoning based on user context and priorities. Required.
• Definition of Done: Concrete, verifiable success criteria for the recommended option. Required.
• Implementation Plan: Concrete steps to execute the recommended option, including specific commands, tools, or actions. Required.

Constraints and Caveats

• The Problem sentence must not contain implementation details, tool names, or specific technologies.
• The Problem sentence must not use "and" (this indicates two problems).
• Options must be genuinely different strategies, not minor variations.
• The Definition of Done and Implementation Plan must align with the recommended option.
• If the user selects a different option, the Recommendation, Definition of Done, and Implementation Plan must update accordingly.

Failure Modes

A response fails if any of these conditions are met:

• The response does not have exactly one Problem sentence.
• The response does not have exactly three Options (A, B, C) with pros and cons for each.
• The response does not have a single Recommendation that picks one option with reasoning.
• The Definition of Done and Implementation Plan do not align with the recommended option.
• The user selects a different option but the Recommendation, Definition of Done, and Implementation Plan are not updated.

Prerequisites

• The task must have multiple viable approaches with meaningful trade-offs.
• The user must need a clear recommendation or proposal for a team or stakeholder.

Example: Adding Retry Logic to an API Client

The following example illustrates how the 1-3-1 format works in practice. A user asks for a 1-3-1 for adding retry logic to an API client.

Problem

Intermittent failures in external API calls need graceful retry handling without degrading overall system performance.

Options

Option A: Exponential backoff with jitter in a shared utility Create a dedicated utility function that wraps any API call with exponential backoff and random jitter. Pros: reusable across all API clients, consistent behavior, easy to test in isolation. Cons: requires refactoring existing call sites to use the utility.

Option B: Retry library as a decorator Use a third-party retry library (e.g., tenacity) applied as a decorator to each API call function. Pros: minimal code changes, rich feature set (retry conditions, timeouts). Cons: introduces an external dependency, less control over jitter implementation, may not integrate well with existing error handling.

Option C: Queue-based async retry with dead letter handling Push failed API requests to a queue that retries asynchronously, with failed requests after max retries sent to a dead letter queue. Pros: decouples retry logic from request path, handles backpressure naturally. Cons: significant architectural change, adds operational complexity (queue infrastructure, monitoring).

Recommendation

Recommend Option A: exponential backoff with jitter in a shared utility. This provides the best balance of simplicity, reusability, and testability without introducing external dependencies or architectural overhead. The utility can be adopted incrementally across the codebase.

Definition of Done

• A utility function api_retry() exists in utils/api_retry.py that handles transient errors.
• The utility retries up to 3 times with exponential backoff and jitter using random.uniform(0, base_delay).
• All API calls in api_client.py route through the utility.
• Each retry attempt is logged with attempt number and delay.
• Unit tests cover: successful first attempt, retry on transient error, max retries exceeded, and jitter randomness.

Implementation Plan

1. Create utils/api_retry.py with the api_retry() function implementing exponential backoff and jitter.
2. Add logging for each retry attempt.
3. Wrap existing API calls in api_client.py to use api_retry().
4. Write unit tests covering all scenarios.
5. Verify behavior under load testing with simulated transient failures.

If the user selects a different option, the Recommendation, Definition of Done, and Implementation Plan must update accordingly.