Rejected Proposals

This page lists anchor proposals that were evaluated but did not meet the quality criteria for semantic anchors. Each entry explains why the proposal was rejected.

Understanding why proposals are rejected helps contributors submit better proposals and avoids re-submission of already evaluated terms.

Rejection Categories

Structurally unsuitable

The term is too vague, has no defined methodology, or is a pure instruction rather than a concept. Fails the Precise and/or Rich criteria.

Insufficient training-data density

A legitimate concept or framework that is recognized (models can talk about it) but does not reliably activate in outputs: naming it does not structurally change the result compared to a generic prompt, or it triggers silent substitution / confabulation on weaker models. Fails the Consistent criterion. Terms here may become viable anchors as training data grows — until then, a Semantic Contract (which supplies its own meaning) is the right home. (Formerly "Not in training data".)

Too niche

A real methodology but too specialized for reliable activation across different LLMs and contexts. Fails the Consistent and/or Rich criteria.

Counter-consensus framing

The term reliably activates coherent knowledge (it passes all four criteria), but the activated framing contradicts the documented consensus of the framework’s own source field — admitting it would prime an LLM toward an approach its own canonical literature marks as misleading or superseded. This category requires citing that consensus source; it must not rest on a contributor’s personal disagreement. Where the term is still worth keeping, the alternative to outright rejection is to admit it with an :advisory: flag (a visible caution in the card/modal, detail in the anchor’s Criticism / Current Status section) — see the Eisenhower Matrix.

Rejected Proposals

Proposal Category Reason

TLDR

Structurally unsuitable

Underspecified instruction with no defined structure. Just means "be brief" without any framework for how. Not a methodology.
Now available as Semantic Contract: "Concise Response" — composes BLUF + Strunk & White.

ELI5 (Explain Like I’m 5)

Structurally unsuitable

Vague target level with no pedagogical framework. No consistent interpretation of what "5-year-old level" means technically.
Now available as Semantic Contract: "Simple Explanation" — composes Feynman Technique.

Spec-Driven Development (#356)

Structurally unsuitable

Relevant concept but no single canonical definition — different people mean different things (API-first, formal specs, our workflow). Not attributable to a specific proponent.
Now available as Semantic Contracts: "Specification" + "Requirements Discovery" — composes Gherkin, BDD, Socratic Method, MECE, PRD.

Explicit Contract Surface (#357)

Structurally unsuitable

Well-described design practice but not an established term in the literature. Combines existing anchors (Clean Architecture, Hexagonal, DDD, SOLID DIP/ISP) without adding new activation.
Now available as Semantic Contract: "Layer Boundaries".

MIRRR UX Framework (#150)

Insufficient training-data density

A real UX framework with defined methodology, but not widely enough documented for LLMs to reliably recognize it and activate the correct concepts.

YOLO (#443)

Structurally unsuitable

Ambiguous and not a methodology: either "You Only Look Once" (a computer-vision model, too narrow) or the "You Only Live Once" motto (a pure sentiment, like TLDR). No consistent activation, no actionable structure.
The "rapid exploration / permission to bypass" idea raised in the thread is better expressed by composing existing anchors (Spike Solution, Walking Skeleton, MVP) within the Cynefin Complex/Chaotic domains.

Terms that don’t qualify as semantic anchors can still be useful as Semantic Contracts. A contract defines what a term means in your project — either by composing established anchors or by providing custom definitions that only exist within your team.

How We Evaluate

Every proposal is tested against our four quality criteria:

  1. Precise — Does it reference a specific, established body of knowledge?

  2. Rich — Does it activate multiple interconnected concepts?

  3. Consistent — Do different LLMs reliably understand it the same way?

  4. Attributable — Can it be traced to key proponents or publications?

We test by prompting an LLM with:

What concepts do you associate with '<proposed term>'?

If the response is vague, inconsistent across models, or fails to activate a coherent body of knowledge, the proposal does not qualify.

See About for the full quality criteria and examples.