frontend-patterns/research/catalog/ClassificationCoverage.md

# Classification coverage

Generated by `python3 scripts/classification_coverage.py`; assessment: 2026-09-27.

17 developed drafts; 16 original seeds at `2a5dabd`. 7 original seeds developed, 9 without dedicated drafts, 10 later additions. All current candidates remain hypotheses; classification confers no admission or new evidence.

The original comparison above is the compact 16-entry table. The broader initial [patterns README](../../patterns/README.md) lists 59 seed names; it is a separate discovery inventory, not 59 developed records or a release quota.

Families/scales come from current candidate metadata. Responsibilities and forces are provisional author-model interpretations in [ClassificationCoverage.json](ClassificationCoverage.json), with candidate hashes and per-record rationale. They are separate from canonical metadata.

Count a candidate once per assigned label; labels overlap. Responsibilities describe the direct mechanism, not every prerequisite or downstream effect. Forces are selected trade-offs, not exhaustive coverage or measured outcomes.

A zero means no assigned direct coverage, not absence of discussion. Force direction describes an intended favorable effect or accepted cost, not a measured result. A classification refresh requires reading changed candidates; do not merely replace hashes.

## Families

| Family | Original seeds | Developed drafts |
| --- | ---: | ---: |
| authority | 3 | 2 |
| address | 1 | 1 |
| projection | 4 | 4 |
| affordance | 2 | 6 |
| mutation | 0 | 4 |
| synchronization | 2 | 5 |
| composition | 2 | 4 |
| execution | 0 | 3 |
| quality | 2 | 3 |

## Scales

| Scale | Original seeds | Developed drafts |
| --- | ---: | ---: |
| L0 | 0 | 0 |
| L1 | 0 | 1 |
| L2 | 3 | 6 |
| L3 | 7 | 5 |
| L4 | 2 | 3 |
| L5 | 1 | 2 |
| L6 | 4 | 13 |
| L7 | 0 | 0 |
| cross-scale | 1 | 0 |

## Responsibilities

These are direct-mechanism assignments, not family aliases. In particular, reconciliation is a responsibility and quality is a family.

| Responsibility | Drafts |
| --- | ---: |
| address | 1 |
| authority | 2 |
| projection | 4 |
| affordance | 6 |
| mutation | 4 |
| synchronization | 2 |
| reconciliation | 4 |
| composition | 3 |
| execution | 3 |

## Forces

Selected trade-offs only. Counts are unique candidates per force, even if a force appears on both sides. Unassigned forces remain research questions; the mapping does not certify a benefit.

| Force | Intended benefit | Cost / tension | Distinct drafts |
| --- | ---: | ---: | ---: |
| interaction-latency | 0 | 0 | 0 |
| perceived-responsiveness | 0 | 1 | 1 |
| continuity-of-interaction | 3 | 1 | 4 |
| discoverability | 0 | 0 | 0 |
| addressability | 1 | 0 | 1 |
| accessibility | 1 | 0 | 1 |
| recoverability | 7 | 0 | 7 |
| offline-usability | 2 | 0 | 2 |
| authoritative-consistency | 2 | 0 | 2 |
| freshness | 1 | 1 | 2 |
| cacheability | 0 | 0 | 0 |
| conflict-probability | 0 | 0 | 0 |
| collaborative-concurrency | 0 | 0 | 0 |
| data-locality | 0 | 0 | 0 |
| privacy | 0 | 2 | 2 |
| information-completeness | 3 | 0 | 3 |
| first-content-latency | 0 | 0 | 0 |
| hydration-cost | 0 | 0 | 0 |
| client-compute-cost | 1 | 1 | 2 |
| server-compute-cost | 0 | 0 | 0 |
| bandwidth-cost | 0 | 1 | 1 |
| connection-lifetime | 0 | 0 | 0 |
| network-reliability | 0 | 0 | 0 |
| startup-cost | 0 | 0 | 0 |
| incremental-update-cost | 0 | 0 | 0 |
| feature-change-frequency | 1 | 0 | 1 |
| schema-change-frequency | 0 | 0 | 0 |
| independent-deployability | 1 | 0 | 1 |
| team-autonomy | 1 | 0 | 1 |
| release-coupling | 0 | 0 | 0 |
| compatibility-pressure | 0 | 2 | 2 |
| implementation-complexity | 0 | 9 | 9 |
| reconciliation-complexity | 0 | 2 | 2 |
| cognitive-load | 0 | 3 | 3 |
| testability | 1 | 0 | 1 |
| observability | 0 | 0 | 0 |
| debuggability | 0 | 0 | 0 |
| portability | 1 | 0 | 1 |
| security-exposure | 0 | 0 | 0 |
| scalability | 0 | 0 | 0 |
| fault-containment | 1 | 0 | 1 |
| deployment-complexity | 0 | 1 | 1 |
| cache-invalidation-complexity | 0 | 2 | 2 |
| telemetry-quality | 0 | 0 | 0 |
| incident-recoverability | 0 | 0 | 0 |

## Per-candidate responsibility and force rationale

| Candidate | Responsibilities | Intended benefit | Cost / tension | Rationale |
| --- | --- | --- | --- | --- |
| [Conflict Copy](../candidates/ConflictCopy.md) | reconciliation | recoverability, information-completeness | cognitive-load, reconciliation-complexity | Preserves divergent content for later semantic resolution; unresolved copies impose review and merge work. |
| [Derived State](../candidates/DerivedState.md) | projection | authoritative-consistency | client-compute-cost, cache-invalidation-complexity | Projects coherent inputs without separately mutable derived copies; recomputation and cached dependency tracking cost work. |
| [Explicit Reconciliation](../candidates/ExplicitReconciliation.md) | reconciliation, affordance | information-completeness, recoverability | cognitive-load, continuity-of-interaction | Makes semantic resolution an explicit comparison task; deciding among versions interrupts ordinary work. |
| [Failure Boundary](../candidates/FailureBoundary.md) | composition, affordance | fault-containment, continuity-of-interaction | implementation-complexity | Contains declared failures and supplies recovery interaction; partial-state recovery and escalation add complexity. |
| [Focus Return](../candidates/FocusReturn.md) | affordance | continuity-of-interaction, accessibility | implementation-complexity | Restores a meaningful keyboard continuation; disappearing targets and nested ownership require lifecycle handling. |
| [Independent Feature Boundary](../candidates/IndependentFeatureBoundary.md) | composition, execution | independent-deployability, team-autonomy | compatibility-pressure, deployment-complexity | Separates release and activation through composition contracts; version compatibility and session transitions add obligations. |
| [Invalidate and Reproject](../candidates/InvalidateAndReproject.md) | synchronization, projection | freshness | bandwidth-cost, cache-invalidation-complexity | Refreshes affected observations after accepted writes; scope and ordering of network/cache work need explicit management. |
| [Islands of Interactivity](../candidates/IslandsOfInteractivity.md) | projection, execution | client-compute-cost | implementation-complexity | Scopes activation to selected regions; intended compute savings compete with loading and inter-region coordination. Savings require measurement. |
| [Local Commit Boundary](../candidates/LocalCommitBoundary.md) | authority, mutation | recoverability, offline-usability | implementation-complexity, perceived-responsiveness | Defines acknowledged local acceptance separately from visual input; atomic persistence and waiting for completion add cost. |
| [Local Draft State](../candidates/LocalDraftState.md) | affordance, mutation | recoverability, continuity-of-interaction | implementation-complexity, privacy | Preserves editable intent separately from refreshed observations; lifetime management adds complexity and sensitive-data retention risk. |
| [Mutation Outcome Tracking](../candidates/MutationOutcomeTracking.md) | mutation, reconciliation | recoverability, information-completeness | implementation-complexity | Tracks uncertain write outcomes and resolves them through receipt lookup or bounded replay; identity/retention state adds cost. |
| [Pending Synchronization](../candidates/PendingSynchronization.md) | synchronization | offline-usability, recoverability | freshness, reconciliation-complexity | Keeps locally accepted work queued across disconnection; remote freshness is delayed and retry/reconciliation contracts are required. |
| [Presentation Model](../candidates/PresentationModel.md) | projection, affordance | testability, portability | implementation-complexity | Separates presentation decisions from widget APIs; model/view binding and synchronization add a failure surface. |
| [Progressive Enhancement](../candidates/ProgressiveEnhancement.md) | execution, affordance | recoverability | implementation-complexity | Preserves an essential baseline when optional scripts fail; equivalent task semantics and recovery across paths add design work. |
| [URL-addressable State](../candidates/URLAddressableState.md) | address | addressability | privacy, compatibility-pressure | Makes selected views reconstructible from addresses; exposure and evolving URL contracts constrain what can be encoded. |
| [Version-Checked Mutation](../candidates/VersionCheckedMutation.md) | authority, mutation, reconciliation | authoritative-consistency | cognitive-load | Checks stale bases at commit and exposes rejected proposals for reconsideration; contention adds repeated user review. |
| [Vertical Feature Slice](../candidates/VerticalFeatureSlice.md) | composition | feature-change-frequency | implementation-complexity | Localizes a capability change behind an interface; shared concepts and interfaces require maintenance. Benefit means coping with frequent changes, not changing their frequency. |

## Original seeds without dedicated drafts

- Server Authority
- Local Authority
- Replicated Authority
- Server Projection
- Client Projection
- Streaming Projection
- Local Interaction State
- Optimistic Overlay
- Persistent Subscription

## Research implication

The developed corpus concentrates on interaction/recovery; authority placement and basic projection choices remain underdeveloped. Family membership alone hides this gap. The [completed authority/projection comparison](../reviews/AuthorityProjectionComparison.md) separates scoped acceptance, projection placement and delivery; it retains all six seeds without adding drafts. Keep the navigation fixture paused; pending Zulip applicability questions remain in WP-0003 T01.

This inventory is a coverage aid, not a maturity score, empirical learning cycle, graph export or proof that the initial ontology is sufficient.