# Pattern Schema

Each pattern consists of structured metadata plus explanatory prose.

## Canonical metadata

```yaml
---
id: FEP-AFF-001
name: Optimistic Overlay
family:
  - affordance
  - mutation
scale: L6
status: hypothesis

context:
  - remote authority
  - perceptible mutation latency

forces:
  improves:
    - interaction_latency
    - perceived_responsiveness
  worsens:
    - reconciliation_complexity
    - implementation_complexity

requires:
  - identifiable_mutation
  - authoritative_state

relations:
  refines:
    - local_interaction_state
  enables:
    - immediate_feedback
  conflicts_with:
    - destructive_uncompensated_mutation

known_uses: []

evidence:
  maturity: hypothesis
  sources: []
---
```

## Human-readable structure

Every pattern should contain:

```text
# Pattern Name

## Context

## Problem

## Forces

## Solution

## Dynamics

## Resulting Context

## Consequences

## Failure Modes

## Known Uses

## Related Patterns

## Evidence

## Implementation Notes
```

## Requirements

A pattern should:

- describe a recurring problem,
- expose at least two meaningful forces,
- propose a reusable configuration,
- explain consequences,
- identify failure modes,
- create or refine a context in which other patterns apply.

A useful technique is not automatically a pattern.

A framework feature is not automatically a pattern.

A pattern name should identify a reusable architectural idea rather than a product-specific API.