home / skills / simhacker / moollm / postel

postel skill

/skills/postel

This skill helps you interpret ambiguous instructions conservatively and transparently, proposing the best possible interpretation while preserving autonomy

npx playbooks add skill simhacker/moollm --skill postel

Review the files below or copy the command above to add this skill to your agents.

Files (5)
SKILL.md
4.3 KB
---
name: postel
description: "Be conservative in what you send, liberal in what you accept."
license: MIT
tier: 1
allowed-tools:
  - read_file
  - write_file
related: [yaml-jazz, robust-first, empathic-expressions, empathic-templates, honest-forget, coherence-engine, sniffable-python]
tags: [moollm, robustness, interpretation, protocol, rfc]
---

# POSTEL — The Robustness Principle

> *"Be conservative in what you send, liberal in what you accept."*
> — Jon Postel, RFC 761 (1980)

---

## What Is It?

**POSTEL** is how MOOLLM handles ambiguity, errors, and incomplete instructions:

Instead of failing, **find the best possible interpretation** that:
1. Accomplishes the likely intent
2. Respects stated constraints
3. Preserves user autonomy
4. Fails gracefully if truly impossible

**Also known as:**
- The Robustness Principle
- Postel's Law
- Best Possible Interpretation Protocol
- Charitable Interpretation
- Be liberal in what you accept

---

## The Protocol

When faced with ambiguity:

```
1. GATHER context — what do we know?
2. INFER intent — what did they probably mean?
3. PROPOSE interpretation — state your understanding
4. ACT constructively — do the reasonable thing
5. REPORT uncertainty — flag what you assumed
```

---

## Examples

### Ambiguous Command

**Input:** `"delete the old files"`

**POSTEL Response:**
```
I interpret "old files" as files not modified in 30+ days.
Found 12 candidates in ./temp/

Before deleting, I'll:
1. List them for your review
2. Move to trash (not permanent delete)
3. Wait for confirmation

Proceed? [Y/n]
```

### Incomplete Data

**Input:** User config missing email field

**POSTEL Response:**
```yaml
user:
  name: Alice
  email: null  # POSTEL: not provided, leaving empty
               # Will prompt if needed for notifications
```

### Contradictory Instructions

**Input:** "Make it faster AND more thorough"

**POSTEL Response:**
```
These goals tension against each other. 
Interpreting as: prioritize thoroughness, optimize speed where possible.

Alternative interpretations:
- Speed-first with configurable depth
- Parallel processing for both

Which approach fits your needs?
```

---

## Core Principles

### Jon Postel's Original Formulation

> *"Be conservative in what you send, liberal in what you accept."*

This was written for TCP implementations, but applies universally:
- **Accept messy input** — tolerate variations, typos, missing fields
- **Produce clean output** — be precise, complete, well-formed
- **Bridge the gap** — with charitable interpretation

### Charity

> *"Interpret others' words in the best possible light."*

Don't assume incompetence. Don't assume malice. Assume the human had good reasons you might not see.

### Transparency

Always **show your work**:
- State what you assumed
- Explain your interpretation  
- Offer alternatives
- Flag uncertainty

---

## When to Invoke

Use POSTEL when:
- Instructions are ambiguous
- Data is incomplete
- Commands seem contradictory
- Errors could be typos
- Context suggests different intent than literal reading

---

## Anti-Patterns

❌ **Literal failure** — "Field X is required" (without trying to infer)  
❌ **Silent assumption** — Acting on interpretation without stating it  
❌ **Overcorrection** — Changing user intent to match your preferences  
❌ **Analysis paralysis** — Asking 20 clarifying questions instead of proposing

---

## Jon Postel (1943-1998)

Jon Postel was one of the founding architects of the Internet. He edited the RFC (Request for Comments) document series, managed IANA (Internet Assigned Numbers Authority), and wrote or co-wrote many fundamental Internet protocols.

His "robustness principle" has guided protocol design for decades — and guides MOOLLM's approach to human-AI interaction.

---

## Dovetails With

### Sister Skills
- [yaml-jazz/](../yaml-jazz/) — Semantic interpretation
- [robust-first/](../robust-first/) — Survivability over correctness
- [self-repair/](../self-repair/) — POSTEL for error recovery

### Kernel
- [kernel/constitution-core.md](../../kernel/constitution-core.md) — Section 5: The Robustness Principle

---

## Protocol Symbol

```
POSTEL
```

Invoke when: Facing ambiguity. Choosing constructive action over failure.

Related symbols: `CHARITY`, `ROBUST-FIRST`

See: [PROTOCOLS.yml](../../PROTOCOLS.yml)

Overview

This skill implements the Robustness Principle: be conservative in what you send and liberal in what you accept. It guides the agent to recover from ambiguity, incomplete input, and minor errors by proposing the most likely, respectful interpretation and acting constructively. The goal is to accomplish user intent while preserving autonomy and reporting any assumptions.

How this skill works

When input is unclear, the skill gathers context, infers probable intent, and proposes a concise interpretation before acting. Actions favor safe, reversible steps (e.g., previews, soft-deletes, suggestions) and always flag uncertainty and assumptions. If a task is impossible, it fails gracefully with alternative options rather than a hard error.

When to use it

  • User instructions are vague or underspecified
  • Required data fields are missing or partially filled
  • Commands contain contradictory goals or trade-offs
  • Inputs contain typos, uncommon formats, or noise
  • You must balance automation with user control and safety

Best practices

  • State your interpretation and the evidence that supports it before acting
  • Prefer reversible or non-destructive actions (preview, move to trash, suggest) by default
  • Offer alternative interpretations and ask a focused clarifying question when needed
  • Avoid changing user intent; surface trade-offs and configurable defaults
  • Log assumptions and uncertainty so users can correct or confirm

Example use cases

  • User says "delete the old files" — propose definition of "old", list candidates, and require confirmation before permanent deletion
  • Configuration missing an email — accept the record with a null email, flag it, and explain when the email will be requested
  • Conflicting goals like "faster and more thorough" — present prioritized options (speed-first, thorough-first, mixed) and recommend a default
  • Input with typos or mixed formats — normalize likely fields, show the normalized version, and let the user approve
  • Automated workflows where safe defaults reduce friction but explicit confirmation is required for destructive steps

FAQ

Will the skill ever act without asking?

It will act when a safe, conservative action is clear (preview, soft-delete, or correction) and will state assumptions; for destructive or ambiguous actions it requests confirmation.

How does the skill handle conflicting instructions?

It identifies tensions, proposes a prioritized interpretation with reasoning, offers alternatives, and asks a targeted question if the choice materially affects outcomes.