Living Document · Architecture
The code is fixed.
The contents are not.
A permanent QR points at one permanent Google Doc. Everything a visitor reads inside it rotates on its own clock — so the printed code, scanned a thousand times, always resolves to today's authorized information. Nothing is ever reprinted.
The two layers
What never moves, and what always does
The whole design rests on one separation. Confuse the two and the system breaks: replace the file instead of its contents and the QR dies inside a day.
The wall
Set once, encoded into the QR, touched again only if you abandon the whole system. None of it is editable in daily use.
- The QR image
- The file ID — 1tdSIEkFt2GM9Oh5…
- The /view URL
The contents
Replaced continuously, each block on its own cadence. This is the only layer anyone edits.
- Key Info — event-driven
- Announcements — weekly sweep
- Program — weekly
- Newsletter — monthly
The flow
What happens on a scan
Four hops, every time, with no moving parts on the printed side.
Scan
A visitor scans the printed code. The same code, on every surface, forever.
→Fixed URL
It resolves to one immutable document URL. The file ID never changes.
Living doc
The Google Doc opens, view-only. Editors maintain it; link-visitors can only read.
→Fresh content
The visitor sees today's authorized set. Stale content is gone from view, the top block stamped current.
The model
The wall and the sheet
It works exactly like the paper version you already run. The wall the sheet is pinned to is permanent; the sheet rotates. Here the document is the wall, and its body text is the sheet.
Clearing the body removes content from every viewer's view — and because revision history is reachable only by owners and editors, a link-visitor has no path to yesterday's links. Content leaving the visible body satisfies "destroyed" for everyone who scans.
The four blocks
Four blocks, four clocks
Ordered top to bottom by volatility — the most-changing, most trust-critical block sits where a phone scanner reads first. The ladder narrows as it descends: fast at the top, near-static at the bottom.
Verified, currently-true operational facts only. Replaced the moment anything changes and stamped "Current as of …". Nothing unverified is allowed to land here — that gate is what makes it trustworthy.
A rolling feed in five horizon buckets. New goes on top of its bucket; past items deleted. Re-bucketed in the Sunday sweep, never daily. Signup links ride inline here, beside the item they belong to.
Replaced every Sunday with the coming week's program link. One swap, on the same beat as the announcements sweep.
Replaced once a month. Persists, always live, between issues — the slowest sheet on the wall.
The trust mechanism
Reliability isn't claimed. It's shown.
A scanner cannot tell current-and-true from stale-and-abandoned by looking. The timestamp on Key Info is the only thing that closes that gap — it converts "trust me" into evidence. The block you most need believed is the one most prone to silent staleness, so the stamp is the load-bearing detail, not decoration.
And it cascades: one rotten bucket label — a "Today" still showing yesterday — poisons the credibility of the whole surface. That is why the weekly sweep is the architecture, not housekeeping.
Maintenance
Who does what, and when
No daily wipe. Each block runs on its own clock, and the human work clusters into a small number of named rituals a non-technical maintainer can hold in their head.
The Sunday beat
- Replace Program with the new week's link.
- Sweep Announcements: push each bucket down a notch — Later → Next Month → This Month → Upcoming Week → Today.
- Delete anything now in the past.
The monthly swap
- Replace the Newsletter link with the new issue.
- Leave it; it stays live until next month.
Key Info update
- Change the fact the moment it changes.
- Re-stamp "Current as of …" with the new time.
- Verified facts only — nothing speculative.
Empty windows are fine by design. A block with bare headers and nothing under it reads as "not posted yet" — which is true. The program for Sunday goes up when it's ready; an unfilled block communicates rather than looks broken.
Worked example
The document, to spec
What the live prototype becomes: reordered by volatility, Key Info stamped, signups inline. Example content shown.
This week's session meets in the Annex — main hall closed for floor repair.
Overflow parking lot is open; enter from the south side.
Setup crew arrives 8:00 AM — side entrance is unlocked.
Service project June 28 — details to follow.
Summer schedule begins; times shift one hour earlier.
Fall registration opens in August.
Sunday, June 14 — this week's program:
https://drive.google.com/example-program-jun14Decision record
What we ruled out, and why
The trail, kept so the reasoning survives. Each was considered and rejected for a concrete failure mode, not taste.
Rented redirect
The redirect lives on a vendor's domain, can be deactivated, and usually costs a subscription. A static QR to the fixed doc URL needs none of it — no vendor, no expiry, no recurring cost.
Silent staleness + a script dependency
Edits don't go live until someone clicks Publish — the step non-technical maintainers skip, leaving the page silently stale. And a link-update script is a technical dependency no volunteer can carry when the author moves on. Docs auto-saves with no publish step.
Fine only when everything was day-of
Once the cadences turned out mixed, a daily wipe would force re-pasting the month-old newsletter and week-old program every single day — the opposite of low-maintenance. Replaced by per-block clocks.
The step volunteers skip
Horizon buckets quietly require a third operation — promotion — beyond add and remove. Done continuously it gets skipped and fails invisibly. Folded into the one weekly Sunday sweep instead.
Unnecessary for this audience
Revision history is owner/editor-only and unreachable by anyone with just the link. Content leaving the visible body already satisfies "destroyed" for every scanner. True deletion is the only move that breaks the QR — so it's off the table.