frontend-patterns/research/reviews/AuthorityProjectionComparison.md

# Authority, projection and delivery — bounded comparison

Date: 2026-09-27 Europe/Berlin. LEARN-0015 preregistered at `2df1d94`.
Reviewer: Codex, author-model. Six primary documents, four source families; documentary
interpretation only. No application, library tests, model inference or usability trial
executed. Living documentation accessed 2026-09-27; exact revisions unknown.

## Result

Revise how we use the six seed labels: authority placement, projection placement and
delivery timing are separate decisions with compatibility constraints. The initial
catalog mixes these categories. They are useful discovery terms, but six nouns do not
establish six recurring pattern contracts. **No new draft is justified by this slice.**
The corpus remains seventeen hypotheses; all six seeds remain available for research.

This strengthens the earlier [authority pilot](AuthorityPilot.md), which already
scoped authority by data/decision and separated acknowledgements. The new contribution
is an explicit comparison across projection phases and partial delivery, with two
synthetic decision traces. It does not establish universal independence of all axes.

## Primary claims and limits

The following are paraphrases of located documentation. Interpretations in the last
column are ours. These sources describe mechanisms, not independent full-pattern uses.
Section anchors are locators on living pages; they do not pin historical content.

| Claim | Source / locator | Located statement | Interpretation and limit |
| --- | --- | --- | --- |
| AP01 | SRC-0041, [Firestore offline data](https://firebase.google.com/docs/firestore/manage-data/enable-offline), introduction, Configure cache size, Listen to offline data | Clients can access and modify cached data offline, then synchronize. Cached observations may be stale/incomplete; cache cleanup is configurable. | Local availability does not establish a complete, permanently retained local record or global acceptance. This is a cache mechanism, not proof of VC-02's durable note contract. |
| AP02 | SRC-0042, [Firestore transactions](https://firebase.google.com/docs/firestore/manage-data/transactions#updating_data_with_transactions), Updating data with transactions; Batched writes | Transactions atomically apply writes, may rerun on contention and fail offline. Batched writes have different offline behavior. | Acceptance must be specified by operation type. Offline display or a queued write cannot stand in for a connectivity-dependent transactional decision. We did not inspect authorization rules or prove end-to-end acceptance. |
| AP03 | SRC-0043, [Automerge introduction](https://automerge.org/docs/hello/), introduction and Design principles | Devices can change local copies offline and later exchange/merge changes; networking can use client/server or peer connections. | A server transport need not be the sole semantic decision-maker. Convergence is not evidence that arbitrary approval rules, permissions or storage crash guarantees are satisfied. The high-level introduction does not resolve field-level merge conflicts for our briefs. |
| AP04 | SRC-0021, [SvelteKit page options](https://svelte.dev/docs/kit/page-options#ssr), ssr/csr/prerender | Initial server rendering, browser rendering and prerendering are configurable; disabling both SSR and CSR leaves no rendered view. | Projection can vary by phase and route. A rendering switch says nothing by itself about which domain mutations are accepted. |
| AP05 | SRC-0044, [SvelteKit loading](https://svelte.dev/docs/kit/load#Universal-vs-server), Universal vs server; Streaming with promises | Server loaders execute server-side; universal loaders can run during SSR and later in the browser. Server promises can stream; documented limits include buffering, script dependence and committed response headers. | Data acquisition, view computation and delivery schedule need separate contracts. A stream is not automatically a no-script continuation. Deployment buffering limits apply to the inspected mechanism, not every streaming protocol. |
| AP06 | SRC-0045, [React renderToPipeableStream](https://react.dev/reference/react-dom/server/renderToPipeableStream), Parameters, Streaming more content as it loads, Setting the status code | Shell-ready and all-ready callbacks permit different emission schedules. Later content uses scripted fallback replacement; response status cannot change after streaming starts. | Streaming qualifies delivery and recovery within a projection strategy. A shell or HTTP status does not establish completion of all content or a business operation. No latency benefit was measured. |

Source families are Firestore, Automerge, SvelteKit and React. The two Firestore pages
and two SvelteKit pages are not separate implementation families. Existing SRC-0021
is reused rather than assigned a second identity. All six documents reached the
registered cap; no linked tutorials, SDK source, security rules or merge-rule pages
were opened as additional evidence.

## Six-seed decision matrix

Each row states the contract that would be needed, not an established implementation.
“Not fixed” means the label alone leaves that decision unspecified.

| Seed | Authority scope / acceptance | Replica or cache meaning | Projection inputs / execution | Delivery | Disposition |
| --- | --- | --- | --- | --- | --- |
| Server Authority | Named shared decision accepted by a designated service; UI feedback is separate | Local observations may be cached or tentative | Accepted snapshot and separate draft; server or browser computation possible | Not fixed | Retain seed as a scoped context choice; no generic whole-application authority draft |
| Local Authority | Named local record accepted under an explicit device storage contract | Primary local record must be distinguished from evictable cache | Locally available accepted state plus unsaved input; remote projection cannot be required for offline continuation | Not fixed | Retain seed; define durability and external acceptance scopes before a new pattern |
| Replicated Authority | Specify which replica operations are admissible and how shared meaning is resolved | Multiple writable histories; replication alone does not define decision rights | A declared replica/version may feed a view; convergence and current knowledge differ | Not fixed | Refine seed question: convergence mechanism versus domain authority; do not equate CRDT use with universal acceptance |
| Server Projection | Does not itself specify mutation acceptance | Could consume a snapshot, cache or replica | A server computes a declared representation from identified inputs | Complete or incremental | Retain as projection strategy; a dedicated pattern needs forces, recovery and recurring context |
| Client Projection | Does not itself specify mutation acceptance | Could consume remote observations or a local primary record | A client computes the representation from available inputs | Initial, subsequent or incremental updates | Retain as projection strategy; no implied offline durability or domain authority |
| Streaming Projection | Does not itself specify mutation acceptance | No replication/acceptance guarantee | Identify what is streamed: view fragments or data used to compute a view | Partial delivery with completion/error and fallback rules | Treat as a delivery qualifier for this study; retain the seed for a possible partial-delivery pattern after independent evidence |

No seed is rejected or merged into an existing draft. These are provisional research
dispositions, not a rewrite of the canonical ontology. Server/client strategies can
coexist over an interaction's lifecycle. The offline requirement constrains feasible
placement: separate dimensions are not a claim that every combination works.

## Synthetic trace A — VC-01 transactional administration

Reuse the [fixed brief](../walkthroughs/VC01-TransactionalAdministration.md): shared
approval records, server-validated writes and recoverable concurrent edits. These
steps are design reasoning, not new execution evidence.

1. Name two scopes: shared approval status and the user's unfinished proposal. The
   service accepts changes to the former; typing changes only the latter.
2. Load a versioned observation. Hold this authority contract constant while varying
   projection: return a ready representation from the server, or return observations
   for a browser-computed view. Neither presentation choice authorizes a new approval.
3. Edit and submit using the existing Local Draft State / Version-Checked Mutation /
   Mutation Outcome Tracking configuration. A lost response leaves acceptance unknown
   regardless of where the view was computed. Refetch separately after acceptance.
4. If the connection fails, cached content may remain useful, but the original brief
   does not permit the device to grant final approval. Introducing that capability
   would change the acceptance contract, not merely switch to client rendering.
5. Consider partial delivery only for nonessential sections. Decide what must be
   known before exposing actionable approval controls, and how late failure is shown.
   A successful shell is not the approval result. No performance ranking is inferred.

**Rejected alternative:** treating a responsive local display as acceptance of the
shared decision. **Remaining assumption:** the service actually enforces the stated
version, authorization, business-rule and receipt contracts; rendering documentation
does not verify them. This trace remains development reasoning, not held-out testing.

## Synthetic trace B — VC-02 offline field notes

Reuse the [fixed brief](../walkthroughs/VC02-OfflineFieldNotes.md): work while offline,
restart, preserve divergence, reconnect and distinguish local save from propagation.

1. Name the locally accepted note revision, pending propagation and any externally
   accepted publication as different states. “Saved on this device” needs the existing
   Local Commit Boundary contract; “visible in a local cache” does not establish it.
2. Require the offline editing path to compute its working view from locally available
   input. An initial online server-generated view is compatible with that path, but
   cannot be its only way to reconstruct new offline edits after restart.
3. Keep the local persistence and retry assumptions explicit while varying presentation:
   browser-only projection versus online server projection followed by local projection.
   Both still need local recovery; the choice does not remove synchronization work.
4. If multiple writers are allowed, keep the existing divergence/reconciliation path
   unless a domain-appropriate automatic merge has been justified. The selected
   Automerge introduction is insufficient to replace our note-resolution policy or
   certify crash-safe storage. One writer removes this concurrency requirement only
   under the brief's explicit assumptions.
5. Reconnection may deliver new observations incrementally. Show progress and unresolved
   divergence without claiming all replicas agree. A remote projection of the latest
   unsent local revision is unsupported without transferring it; no source here supplies
   an offline remote-computation guarantee.

**Rejected alternative:** remote-only computation for required offline interaction.
**Remaining assumptions:** persistence, retained data, privacy, replay identity and
recovery contracts still require implementation evidence. No new validated walkthrough.

## Reusable questions for the next walkthrough

For each user-visible statement or action, record:

1. Which data/decision scope is involved, and who may accept a change?
2. What acknowledgement is available: displayed, locally committed, remotely accepted,
   propagated, or reconciled? Which of these is still unknown?
3. What exact observation/version feeds the view, and is it a cache or retained record?
4. Where is the representation computed during entry, subsequent interaction and offline work?
5. Is delivery complete or partial, and how are incompleteness, failure and recovery exposed?
6. Which new constraint would invalidate this configuration?

These questions help apply the existing vocabulary; they are not a new mandatory
component architecture or a demonstrated improvement in practitioner decisions.

## Disposition and follow-up

One **revision** to the research classification/decision aid, not six discoveries.
No candidate content, maturity, profiles or direct responsibility/force assignments
change: this evidence qualifies undeveloped seeds rather than verifying existing
full contracts. Counts remain 17 developed drafts, 7 original seeds developed and
9 original seeds without dedicated drafts. Preserve zero additions as a useful result.

WP-0003 T01 next: test this decision aid against one pinned application containing
both remotely accepted shared state and locally editable state, tracking one acceptance
path and one projection transition. Preregister a bounded static study; target selection
must follow the claim, not a preferred framework. Locate contrary behavior and unknowns.
Do not start another local navigation fixture. The Zulip auxiliary continuation question
remains a separate residual. WP-0002 T03 owns independent seed/usefulness review;
WP-0003 T02/T03 retain case/ontology gates. WP-0006 T03 retains comparable-cycle and
review-date work. This fifth prospective protocol supplies no diminishing-returns trend.