CI-003: comments, questions and ideas from the same collaborator as CI-001 and CI-002
His review of the new design, the telemetry article and the risk graph after CI-002 shipped. Designs A to D as complementary experiences, not alternatives (which is what shipped in v0.14.0); a simple first step for newcomers before asking who they are; measure whether the redesign moves readers from the front page into briefings, guidance and evidence; a review workflow where people confirm or reject the graph's inferred links, with evidence and history; and before-and-after for the graph itself between releases. The editor's direction: align it with power users' keys recognised by the site, so feedback like this, and reviews, come through the site signed.
4comments
4ideas
0questions
1the offer
The record
From: the same collaborator as CI-001 and CI-002. Not named here until he agrees; the editor sets name_on_site when he has.
How it came: a message to the editor after the new design, the telemetry article and the risk graph's before-and-after, forwarded to the Sherpa in session; continues CI-002, 2026-10-24 to 2026-10-24.
Summarised; the collaborator's own words are quoted under each item below.
When
Who
What was said
2026-10-24
editor
Shares the new design (mockups A to D), the telemetry article and the risk graph's before-and-after.
2026-10-24
collaborator
The review below; he will send his mobile observations through the Feedback button.
At a glance
Each item: the collaborator's words, where the site stands today with links, what is missing, what the Sherpa recommends, and who could take it. Answers to the questions are the editor's; the Sherpa only says what exists.
I think A, B, C, and D work best as complementary experiences rather than alternatives. My preference is A's clean, executive-friendly presentation for high-level information, B's action-oriented layout for technical users, C's structured approach to detailed content, and D as a separate operational console.
Where the site stands today. Already decided and shipped: the editor chose all four as complementary tracks, and story-site built them in v0.14.0 (the brief 'the redesign, live'): A is the front page (Briefing), B is /ops/ (Operations), C is /analysis/ (Analysis), D is the team console around every admin page; the persona chosen in the bar sends a reader to their track's home. His preference matches what shipped, track for track.
What is missing. None: shipped. One inconsistency for the editor: the redesign puts the CTO in Operations, while the three-views brief (the editor's answer of 23 October) puts the CTO with the executive.
The Sherpa recommends. Tell him it shipped as he suggests. The editor settles where the CTO belongs, and story-site and the three-views brief follow the one answer.
I really like the separation between actual readers, crawlers, and automated agents. That's important because otherwise automated traffic can distort how we interpret engagement.
Where the site stands today. Since v0.8.4 every session is a reader, the editor, a power user or team member, synthetic or a crawler.
Seeing the graph grow from 442 nodes and 914 relationships to 713 nodes and 1,418 relationships is interesting, but the more important improvement is that those relationships are becoming explainable and actionable.
Where the site stands today. On v0.14.13: 721 nodes and 1,442 edges; every edge has a basis: 340 from a source, 287 from code, 815 inferred.
It's moving beyond a security information website toward something much more useful: an evidence-driven platform for understanding and acting on security risks.
One suggestion would be to give first-time visitors a simple starting point before asking them to select a role. Something like "Understand the incident", "Check what I need to do", or "Explore the evidence" could help people find their way naturally.
Where the site stands today. Partly there. The front page has 'Three ways to read this site' (Briefing, Operations, Analysis), which are his three doors under other names (understand the incident, check what I need to do, explore the evidence). But they are offered by role ('choose who you are'), not by task, and they come seventh, after the agencies: measured on v0.14.14, the section starts 9,218px down a 14,778px page on a phone (about twelve screens) and 3,643px down on a 1,440px-wide desktop.
What is missing. The three ways, named by task, where a first-time reader sees them.
The Sherpa recommends. Move the three ways to the first screen and name them by task ('Understand the incident', 'Check what I need to do', 'Explore the evidence'), each opening its track's home; the roles stay inside each, as they are now. The tracks exist, so this is placement and wording on story-site's front page: briefed (F035), for story-site, with the editor's design review.
It could be useful to measure whether the redesign improves progression from the front page into relevant briefings, security guidance, and evidence, segmented by device and reader persona.
Where the site stands today. The telemetry records journeys (a Sankey since v0.10.10), devices and the reader group; it does not yet split journeys by the persona a reader chose, or compare before and after a release. The Sherpa asked for the persona in the page event on 23 October (F007, board 121).
What is missing. Progression, by device and persona, before and after the redesign.
The Sherpa recommends. One measure, reported at every drain: of sessions starting on the front page, the share that reach a briefing, the guidance (If you run PHP, /stack/) or the evidence (claims, graph), by device and by chosen persona, for the week before the redesign and every week after. Briefed to dev.
One suggestion for the next iteration would be to add a verification workflow where reviewers can confirm or reject inferred relationships, with the supporting evidence and review history recorded. That could make the graph increasingly trustworthy as the agents continue expanding it.
Where the site stands today. 815 of 1,442 links are inferred and nobody can confirm one yet. The pieces exist: the Feedback pane signs with a power user's enrolled key, and the collaborators drain already knows a 'review' kind; the fact-check desk keeps a contradiction ledger.
What is missing. Confirm or reject an inferred link, signed, with the evidence and a history.
The Sherpa recommends. On every inferred link in /grc/explore/: 'Confirm' or 'Reject', with the evidence (a capture, a commit, a line of code) and a note, signed with the reviewer's enrolled key and sent through the collaborators lane as a 'review'. The drain checks the signature; the edge's basis becomes 'confirmed' (who, when, on what evidence) once enough reviews agree, and every review stays in its history. This is the editor's key work, made useful: power users' keys recognised by the site. Who may review, and how many confirmations a link needs, is the editor's call; the rest is briefed to dev.
CI-003.8: idea, graph changes, releases, before and after
I'd also love to see the before-and-after comparison approach extended to graph changes between releases, so we can visualize not just UI improvements but also newly discovered risks, relationships, and coverage gaps.
Where the site stands today. The site keeps every release's data in git; v0.10.14 built split, slider and diff blocks for articles. Nothing compares two releases of the graph.
What is missing. A graph diff between any two releases.
The Sherpa recommends. A 'what changed in the graph' view: pick two releases; the nodes and edges added and removed, the bases that changed (inferred to confirmed), the gaps opened and closed; drawn with the existing before-and-after blocks. Built from git at release time. Briefed to dev.
I'll also send the mobile layout observations and screenshots through the Feedback feature, as requested. ... Looking forward to seeing the next iterations and contributing more ideas.
Where the site stands today. The Feedback button signs with a key from an invitation; he has none yet. The editor's own bootstrap invitation is retired (its code appeared in drained rows), so he needs one of his own.
What is missing. An invitation for him, with the power-user role.
The Sherpa recommends. The editor makes him a power-user invitation on /join/invite/ and sends it; his key is enrolled at the Sherpa's next drain; his feedback and his reviews (item 7) then arrive signed, are drained every two hours and answered here. With his agreement, he becomes the first named power user.
Shared by the editor. Step 1 shipped in v0.14.22 (the phone header, 43px; checked live) and step 2 in v0.14.24, restored in v0.14.29 (/grc/changes/, checked live). His first step for newcomers is prototype E's 'Aim' setting (v0.15.0, /admin/design/lens/), waiting for the editor's go.