# Provider → data → replica: one writer, protected projections
> Checked · 20 October 2026 · Wiki version 2026.10.20.2
Providers remain authoritative for their own transactions. The main mini writes internal company state; Cloudflare protected replicas and the Vercel staff PWA consume projections rather than replacing the master record.
## Purpose
Make the provider-to-data-to-replica architecture legible, especially the difference between source freshness, publication success, and a recent dashboard repaint.
## Diagram text alternative
Hospitable, Turno, and PriceLabs provide their own authoritative observations. The main mini writes internal company state and publishes protected Cloudflare replicas. The Vercel staff PWA and passive TV consume projections. Hermes is a separate adapter boundary.
## Current / proposed status
- Current: Checked — ownership boundaries are documented; provider freshness needs current evidence and must not be inferred from a display.
- Proposed: Exercise source windows and publication outcomes with explicit fresh, stale, failed, and duplicate cases.
## Safe example
### A freshness-safe investigation
If a dashboard says a provider snapshot is recent, inspect the source-window result and publication result before trusting it. A reopened tab or a newly painted card is not a complete source read.
## Responsibilities
- Hospitable, Turno, and PriceLabs remain authoritative for their own supported observations and transactions.
- The main mini writes internal tasks, decisions, identity links, and audit state.
- Cloudflare Worker, D1, and KV hold protected replicated data and selected summaries.
- The Vercel staff PWA consumes projections; it does not become the master record.
## Checklist
- Name the authoritative provider for every provider-originating field.
- Distinguish a source read from publication to a protected replica.
- Show stale, failed, duplicate, and unresolved-identity conditions visibly.
- Do not use a cache, replica, or freshly opened screen as freshness proof.
## Provider observations and company state travel through different responsibilities
**Status:** Checked
Company documents provide business context. Hospitable, Turno, and PriceLabs provide supported observations, while each provider remains authoritative for its own transactions. The main mini writes the internal tasks, decisions, identity links, and audit state that connect those observations to company work.
Cloudflare Worker, D1, and KV distribute protected replicated data and selected summaries. The Vercel staff PWA and passive TV consume these projections. Replicas and caches can be useful, but they are not the master record.
**Current / proposed status**
- Current: Checked — this is the stated architecture boundary, not a claim about every individual field or live deployment.
- Proposed: Document source ownership and publication behavior when adding a provider, field, or projection.
**Expected outcome**
A change proposal can preserve source authority and avoid a competing writer.
**Meaningful tests**
- Check every diagram node has a text-equivalent and focused-page link.
- Check architecture exports mention the mini, Cloudflare, and Vercel roles without credentials.
## Freshness requires a complete read and successful publication
**Status:** In progress
Freshness means the relevant source window was read completely and then published successfully. It is not established by a recent screen repaint, a reopened browser tab, or a timestamp without source coverage context.
The data-health screenshot is a dated example that shows why labels such as live, unverified, stale, or reconciled need interpretation. It does not prove current provider freshness on its own.
**Current / proposed status**
- Current: In progress — provider freshness must be verified against current source windows and publication evidence.
- Proposed: Use explicit freshness fixtures and show the source-read and publication outcome in the relevant staff view.
**Expected outcome**
A user can ask whether data is current enough for the decision at hand instead of assuming it is.
**Meaningful tests**
- Run complete, stale, incomplete, and failed-publication fixtures.
- Assert a screen repaint alone never changes a stale state to fresh.
## Protected replicas improve access without changing authority
**Status:** Checked
Protected replicas let staff use a dashboard without each person operating the mini. This is a distribution benefit, not a reason to move company writes into a cache, replica, or client surface.
When a projection disagrees with a source, investigate the source read, identity mapping, publication result, and exception owner. Do not quietly patch the replica and lose the underlying cause.
**Current / proposed status**
- Current: Checked — the documented design separates writing from protected projection consumption.
- Proposed: Keep access protection, source pointers, and refresh semantics explicit as new views are added.
**Expected outcome**
The architecture stays understandable under failure, not only when a dashboard looks normal.
**Meaningful tests**
- Check a replica-disagreement fixture opens an investigation path rather than a direct data edit.
- Check no generated prompt asks for a token or a production write.
## Related pages
- [The Mac mini: authoritative writer and local operating core](/systems/mac-mini/) — The office Mac mini holds internal company state and runs configured operating processes. It is the authoritative writer for internal tasks, decisions, identity links, and audit state.
- [Dashboard and passive TV: shared views, not source authority](/systems/dashboard-and-tv/) — The staff dashboard and passive TV surfaces make a shared operating picture visible. They consume projections; they do not become the authoritative writer for company state.
- [Hermes: an adapter boundary, not a company identity](/systems/hermes/) — Hermes is an adapter in the operating architecture. It does not replace the company Official Account, employee operations bot, provider authority, or a reviewed record boundary.
## Source pointers
- Handoff / pages/infrastructure.html
- Handoff / pages/app-tour.html
- Handoff / START-HERE.html
## Context export
- Page context: ./exports/systems--data-replicas.context.json