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, 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, 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, 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, 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, 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, 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, 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: 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: 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.