Introduction

This series is written for VPs of Futures, search and browser leads, platform PMs, and staff engineers. It collects short, precise essays that outline and test a possible path for the web from "pages" to "proofs."

We treat this as an academic project. We propose ideas, build minimal examples, and invite critique. The goal is clarity: exact links, verifiable answers, and change-aware content that does not surprise users or tools.

Authors

RobAI is an alter-ego research collaborator, powered by ChatGPT (OpenAI).

Rick Kuzik is a Calgary technologist with 55+ years of experience. Highlights include early Java training for the Hubble retrofit team at Boeing, email over Inmarsat satellites, tools used during Hibernia oil field discovery, and multi-million dollar IT budget leadership with large documented savings. He co-authors the browser-native work at jit-tr.com.

Context: why look again

The current internet pattern (multi-tenant to one platform) scaled distribution, but it also concentrated rendering, mixed persuasion with proof, and made deep linking to exact lines fragile. As models and crawlers multiply, drift between "what is shown" and "what is indexed" widens.

We ask a simple question: what would change if we made exact-line navigation, provenance, and updates first-class concerns at the page level, without asking servers to do everything?

What if we adopt mm1

mm1 = multi-tenant, multi-site, one controller. Instead of one platform hosting everyone, each origin keeps its truth, while a controller composes add-ons across many origins. The controller is allowed to assemble server-side modules (for example, page summary, altref, qna.json, locale canonicals, changefeed) so that humans and crawlers see the same output.

Servers do not need to do everything. A SaaS layer can supply add-ons; the origin selects only what it needs. Effort is diversified across providers instead of duplicated at every origin.

• Ownership: the canonical remains on the customer domain.
• Parity: if it is indexable, a visitor can see it (no hidden version for bots).
• Replaceable parts: add-ons are swappable without full redesigns.
• Governance: provenance and licensing travel with answers.

This is a design prompt, not a mandate. We explore consequences if mm1 were common.

If mm1 is adopted, what might Web 4/5/6 look like

• Web 4: self-describing content - manifests, structured data, and provenance at the page level. Still page-centric, but machine-legible. Limits remain without exact-line addressing.
• Web 5: exact line, verified - the Tri-Anchor Protocol "p;s;h": paragraph anchors, runtime sentence resolution, short-hash verification, and drift handling. One click to the right place, highlight the sentence, verify it survived edits.
• Web 6: agent-native navigation - a deterministic navigation system where sentences are addressable primitives and actions are reproducible under policy (capability, consent, limits).

These are sketches meant to be tested and revised. They are intentionally conservative and browser-native.

What these papers cover

• Web 3 — a retrospect — Documents and APIs: what scaled, what stalled, and where discoverability broke.
• Web 4 — SaaS-first, portable truth — Why the web must prioritize SaaS assembly and sentence-level truth; pragmatic steps and optional MM1 assist.
• Web 5 — exact line, verified (Overview) — Why decisions live at the sentence; land, open, highlight, verify; drift signaling and locale-true resolution.
  • Web 5 — Proof & verification — Coverage %, verified-link rate, time-to-clarity, locale parity, drift latency, and a lightweight changefeed.
• Web 6 — MM3 — An open, SaaS-first web with a governed Super-Admin AI and an add-on cart; same-day capability as a research target.
• What if we adopt MM2? — Radical proviso for Web 5: AI-guided implementation of MM1 under a site charter to ship portability in ~15 days.
  • Conclusion — pages to proofs, proofs to production — Operator checklist, KPIs, and next steps: assemble SaaS, prove the line, standardize upgrades.
  • Introduction — pages to proofs — Audience & frame: from pages to proofs; why sentence-level truth and SaaS-first matter.
  • TAP — Tri-Anchor Protocol — #p;s;h — paragraph anchor → runtime sentence resolution → short-hash verification; UI open-state hints and fallbacks.

How to read

Start anywhere. For the shortest path to "why this matters", begin with Web 5 overview, then skim Proof and Changefeed. Each essay stands alone; together they outline a browser-native bridge from Web 4 to Web 5.

TL;DNS: a design prompt for pages and proofs.

mm1 pattern (multi-tenant, multi-site, one controller)

Site pages drop a <script src= ... > at the bottom; that script “takes control,” fetches content/config from the platform and SaaS providers, then mutates the page with $('head').append() / $('body').append().

1) What it is (in one line)

One remote script, owned by a central platform, is injected on every customer page and then performs client-side composition: it pulls add-ons/config/data from the platform and third parties and patches the current DOM.

2) ASCII sequence (happy path)

User → Origin (customer site):  GET /page.html
Origin → User:                  HTML … <script src="https://platform/js/loader.js"></script>

Browser:                        Parses HTML; reaches loader.js at end of <body>

User’s Browser → Platform:      GET https://platform/js/loader.js  (cacheable)
Platform → Browser:             loader.js

loader.js:
  1) Fingerprints page (URL, lang, data- attributes)
  2) Fetches config & payload plan
  3) Optionally preconnect to SaaS

Browser → Platform:             GET https://platform/config?site=...&page=...
Platform → Browser:             JSON plan (what to inject, from where)

loader.js executes plan:
  - fetch() addon bundles, JSON blocks, templates
  - $('head').append(…); $('body').append(…)
  - init widgets, hydrate Q→A, attach events

Browser → SaaS endpoints:       GET scripts/styles/data as directed by plan
SaaS → Browser:                 responses (JS/CSS/JSON)

loader.js finalizes:
  - mark "ready", log metrics, heartbeat
  - optional A/B flags, feature gates

3) What could be injected

Not just widgets, but small, verifiable micro-apps with sources, anchors, and clear licenses.

• Content & micro-apps: short-video rail (“TikTok-in-a-box”), canvas annotator (“paint-in-a-box”), spreadsheet calc block, notebook/chart viewer, query composer.
• Proofs & navigation: exact-line citation chips (#p;s;h), proof ribbon (coverage %, verified-link rate, time-to-answer), drift badge, changefeed tile.
• Personalization & locality: local weather/conditions, inventory/ETA, currency/tax mirror, locale-true deep links.
• Commerce & conversion: one-click quote wizard, comparison composer (exports CSV/link), financing/eligibility checker with audit trail.
• Community & comms: inline Q&A (also publishes qna.json), voice-note capture → transcript + summary, live session/webinar banner with ICS.
• Governance & safety: consent/license bar (agent.json/charter.json), policy badges resolving to exact lines, agent rate-limit meter.
• UX & performance: instant-answers band (pure HTML mirror), smart summary carousel, keyboard palette with ARIA-true anchors.
• Internationalization: locale guard + self-canonical with hreflang, altref citations per language, glossary chips.
• Data & experiments: friction logger (anon aggregate), A/B flags controlled from the platform.
• Integrations: map/routing micro-app, calendar hooks (deterministic ICS), lightweight doc-sign/ack.

4) Why people would want it

• Zero-touch rollout: one tag enables many features across all customers.
• Centralized control: flip flags/platform config once; all sites update.
• Fast iteration: ship experiments without asking each origin to redeploy.

Why the web wants this

The web is moving from pages to precise, reusable units. Let specialists ship small, verifiable capabilities that any site can adopt. Segment the work now so it can be AItomated (AI-automated) later.: once a task has a clean interface, provenance, and exact-line references, agents and search can operate on it safely and at scale.

• Specialists, not silos — small teams build narrow, excellent add-ons (pricing calc, exact-line citations, locale guard) that any site can plug in, instead of every site rebuilding the same thing.
• Segment, then AItomate — define each task as a clear input/output unit with sources and limits; once segmented, it can be run by people today and AItomated tomorrow without changing the page.
• Deterministic interfaces — exact-line deep links and stable anchors form a contract: “open here, highlight this, verify this hash.” That makes integrations reliable for users and agents.
• Provenance and trust — every answer carries source, license, and time. Verifiable claims beat opaque widgets, and satisfy legal/compliance reviews.
• HTML-first for crawl fidelity — answers exist in server-rendered HTML (mm1 style), so search and AI index the same thing visitors read. JS enhances, not replaces, the truth.
• Global by construction — locale-true links, self-canonical pages, and hreflang parity ensure the same deep link works across languages and regions.
• Governed capability — consent and rate limits are declared up front (what agents may do, how fast, under which license). Enterprises need guardrails, not guesswork.
• Economics that compound — maintain once, serve many. Platforms get predictable costs; sites get better features at lower prices.
• Operational resilience — decouple feature rollout from the site’s release cycle. Patch once, fix everywhere. Roll back cleanly if needed.
• Agent-ready content — small, machine-readable units (Q&A, proofs, metrics) are easier for assistants to discover, verify, and act on than whole pages.

Bottom line: a modular, verifiable layer on top of existing sites lets the web evolve without rewrites. People get faster, truer answers; search and AI get stable targets; operators get control and speed.