How the observability works: lanes, LETS, keys and the browser drain

Written by observability@web-summit.dinis, 5 November 2026, as it was built, at Dinis Cruz's word: "remember we need to start documenting when you do this kind of stuff."

The flow, end to end

 a browser on any page             dev.send.sgraph.ai              the drain (hourly, or Dinis's browser)
 assets/obs-dinis.js  ── sealed ──► lanes 1-2 of kuuqr3do ──┐
 an agent, end of run                                       ├─► L load (list, fetch: enum key)
 agent-log.mjs        ── sealed ──► lanes 3-4 of kuuqr3do ──┘   E extract (open: drain key; verify: site and agent keys)
                                                                S save raw: kuuqr3do events/<day>/<hh>/events.jsonl (private)
                                                                T transform: each new hour once, then its day, then latest/
                                                                S save: aym98gsm <day>/<hh>/hour.json, <day>/day.json, latest/*.json
 /observability/ in a browser ◄── ciphertext ── aym98gsm, read with its published read key, decrypted with Web Crypto

LETS: load, extract, transform, save

The drain does the analysis when it drains, not when someone looks: a page loads one small JSON file that already holds everything for its view.

• Load: list every lane with the enum key, fetch in batches of 50.
• Extract: open each record with the drain key; verify a page event's signature against data/person-keys.json and an agent run's against the agent's own key on data/keys.json; a failure is kept and marked, never dropped.
• Save, raw: each record goes to the private vault under the hour it happened in: events/<YYYY-MM-DD>/<HH>/events.jsonl (a page event by its ts, a run by its run), once (by file id). Each tab's group is kept in state/sessions.json.
• Transform: only the hours that received new records (and the current hour) are computed again; a finished hour is computed once. Then its day is summed from its hour files, and latest/ from the day files, never from raw rows.
• Save, public: to the public vault aym98gsm:

latest/ is the cache: replaced on every drain, so the first file a page reads is always small and current; the dated folders below it are the history, and do not change once their hour is over.

The vaults and their keys

The three vault keys and the SG/Send access token are sealed, at Dinis's word, to the site keys of the four people who may drain: Dinis, Jose, Angelo and Silvio (people/dinis/observability/sealed/<person>.json, ws-ecies-1, one file each), so only a browser holding one of those keys opens them. Note (WS-138): the conductor that issued his key holds its private half too.

The explorer, and Behind the scenes

The pages of this section are one explorer (assets/obs-view.js), its state in the URL: #view=page&path=/start/, #view=day&day=2026-11-05, #view=hour&day=2026-11-05&hour=14, #view=agent&agent=…, #view=person&person=…, #view=graph, &group=readers to filter. Every page, person, agent, day and hour is a link to its own view; ↗ opens the page itself.

It reads the public vault lazily: it computes the HEAD's id from the read key, decrypts the commit, and walks only the folders on the path it needs (latest/, then a day or an hour), so a view costs a handful of objects. Behind the scenes (the tab on the right) shows each encrypted object fetched, each file decrypted, its size and time, who the browser is by key, and links to open each vault.

For Dinis, Jose, Angelo and Silvio: when the browser holds one of their site keys, it opens the sealed vault keys, links each vault opened with its vault key, and offers Drain the lanes now: it opens the data vault with the SG/Vault library (pinned copy), derives the enum key, lists and fetches the lanes, opens each record with the drain key to show it (your own page views appear), writes them still sealed to the data vault's inbox/ (the file named after the person who drained), pushes, and marks them processed. The hourly drain then opens and verifies them like any other, and they reach the stats.

What runs

The lanes

The append tokens and the drain's public key are in assets/obs-dinis.json, public on purpose: a token can only write to its lane and the key can only encrypt. The vault key, the enum key and the drain's private key never enter this repository.

People, by their key

A team member whose browser holds their site key (WS-136) signs both events; the drain verifies the signature against data/person-keys.json, so a row says "Vicky read the newsroom brief for 4 minutes, to the end", not a guess. Anyone without a key stays anonymous and is counted only. A signature from a key a conductor issued can also have come from that conductor's session (WS-138).

Agents, by their own run logs

Required of every agent from 5 November (the agents page). One record per run:

{ "type": "web-summit.agent-run/v1", "v": 1, "agent": "pm@web-summit.vicky", "session": "<Claude session id>",
  "run": "2026-11-05T09:30Z", "trigger": "schedule", "repo": "SGit-AI/SGit-AI__Website__Web-Summit",
  "read": [ { "url": "https://web-summit.sgit.ai/brief-vicky/index.md", "as": "md", "bytes": 5120 },
            { "url": "repo:board/WS-153-vicky-s-vault-keys-to-the-conductor-over-the-inbox.md", "as": "md" } ],
  "did":  [ { "commit": "ab64608", "subject": "..." }, { "release": "v0.2.430" } ],
  "tokens": { "input": 48211, "output": 5120 }, "notes": "one line",
  "sig": { "key": "sha256:<the agent's signing fingerprint>", "alg": "ECDSA-P256-SHA256-P1363", "sig": "...", "over": "..." } }

The drain accepts the signature only from an active key on the keys page whose label is that agent; anything else is kept and counted, marked unsigned, with the reason. What it will answer: did Indi's and Vicky's agents read the newsroom brief, and as Markdown or HTML? Which agents never read their own section of the agents page? Which act without having read the board?

Privacy

No IP address, no cookie, no user-agent string (automation is recorded by class: webdriver, headless, a crawler's name). Do Not Track, Global Privacy Control and the footer's Pause switch stop this sender too. Time visible and scroll depth are measured in the browser and sent once per page per tab. An agent record carries URLs without their query strings, commit ids and counts: nothing private. Per-person reads are for the team only, for people with a key; nobody outside the team is ever named.

Who is who: the four groups

Each tab is put in one group, from declared signals first, then inferred ones (the PHP newsroom's rules):

Why the private vault stays private: its read key would also give out the lanes' enum key (derived from it) and the drain key kept inside it, so anyone could empty the lanes or read raw rows of anonymous readers. So the drain publishes what is meant to be public into a second vault, and only that vault's read key is on this page.

Next

1. Where and how to present it (a section on the home page, the stand-up show, each person's dashboard): Dinis to decide.
2. A page per agent: its runs, what it read, what it never read.
3. The newsroom's sender (lane 5), as a patch for newsroom@web-summit.dinis.
4. The calibration loop: from the agent runs, findings per agent for Dinis and the mentors.
5. The security review by security@web-summit.dinis of the sender, the lane and the drain.