CI-002: comments, questions and ideas from the same collaborator as CI-001
The collaborator's response to the mockups and the risk graph: an editorial design for the main experience and a graph-oriented interface for depth; and five ideas to turn the risk graph from a picture into a tool: start small and expand, trace end to end, mark what is verified and what an AI inferred, run impact analysis from a vulnerable function, and serve each persona the same graph at its own depth. Plus one: let the graph find what is missing, such as requirements without tests or code without an owner. Five of the steps need no decision from the editor and are briefed to dev; the design direction and the persona views wait for the editor's review of the mockups.
4comments
6ideas
0questions
0the offer
The record
From: the same collaborator as CI-001. 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 redesign mockups and the risk graph, forwarded to the Sherpa in session; continues CI-001, 2026-10-23 to 2026-10-23.
Summarised; the collaborator's own words are quoted under each item below.
When
Who
What was said
2026-10-23
editor
Shares the redesign mockups (/admin/design/) and the risk graph.
2026-10-23
collaborator
The comments, ideas and closing thoughts below.
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.
My preference would be for a clean, editorial-style design for the main experience, with a more technical, graph-oriented interface for deeper exploration. I haven't been able to compare all the individual design mockups yet.
Where the site stands today. The redesign is up for the editor's review (v0.10.0, /admin/design/): two dials, who you are and how much of the site you see (Focus, Standard, Everything), with mockups for a board member's front page, a security lead's three columns and a team console. His split (editorial first, graph for depth) maps onto the Focus and Everything ends of the second dial.
What is missing. A decision, not a gap: which mockup, and where the graph interface lives.
The Sherpa recommends. Taken to the editor with the mockups: the collaborator's vote is editorial for the main experience and the graph behind an explicit 'explore' step. Not briefed to dev until the editor decides.
The risk graph is particularly interesting. Connecting stakeholders, risks, weaknesses, vulnerabilities, and source code creates a much more useful view of security impact than isolated findings.
Where the site stands today. The risk graph has 442 nodes and 914 edges, every edge a verb with its named inverse: 43 stakeholders, 34 risks, 14 weaknesses, 2 vulnerabilities, 6 remediations, 16 code nodes, 95 controls, 62 claims and 71 sources.
Overall, I think the biggest opportunity is turning the graph from a visualization into an actionable tool for understanding security impact and making decisions.
Where the site stands today. Agreed, and it is the thread through items 3 to 8: start from what you hold, see what it reaches, know how sure each link is, see what is missing.
I also appreciate how the project is connecting the ideas from our LinkedIn discussion to actual implementation. ... Really looking forward to seeing where the agents take this next!
Where the site stands today. CI-001 recorded that discussion, and its items 5 and 8 (a basis on every edge, tests as nodes) are steps 2 and 3 of the brief to dev.
With 442 nodes and 914 relationships, the full graph could become overwhelming. Starting with a specific CVE, risk, or stakeholder and progressively expanding its connections would improve usability.
Where the site stands today. Half there. The overview draws every layer at once (stakeholders, risks, weaknesses, vulnerabilities). Each risk's own page draws only its path, and 'Walk the graph' steps through the code review graph one node at a time; nothing starts from any node and expands.
What is missing. A view that starts from one node and grows on request.
The Sherpa recommends. A focus view: open the graph at one node (a CVE, a risk, a stakeholder, a function, a control), show its direct neighbours by verb, expand any neighbour with a click, with the path back to the start always shown; the address carries the focus and the expanded nodes, so a view can be shared. Built in the browser from data/grc-graph.json, no new data. Briefed to dev (step 1).
CI-002.4: idea, traceability, requirements, user stories, tests
I'd love to see a navigable path from security requirements and user stories through implementation, tests, vulnerabilities, and business risks.
Where the site stands today. Partly. Risks reach weaknesses, vulnerabilities, remediations and code; controls (the security requirements, 95 of them) govern risks; 20 of the 34 risks join a story directly. Not yet in the graph: user stories (as distinct from the site's own stories), tests, and any join from a control to code. The same idea as CI-001 items 3 and 8.
What is missing. Tests and user stories as nodes; controls joined to the code that implements them.
The Sherpa recommends. Tests first, because they need no editorial call: the fix commit's tests become nodes, joined to the remediation and code they exercise (briefed to dev, step 3). User stories next, which need the editor's call on their scope (whose stories: PHP's, or a reader's application's).
It would be valuable to distinguish relationships verified through source code or evidence from those inferred by AI agents, with links to their supporting sources.
Where the site stands today. Not yet. Asked in CI-001 item 5 too. The fact-check desk grades every claim from A0 to A6, but every one of the 914 edges carries only from, rel, inverse and to: an edge read from the diff and an edge an agent inferred look the same.
What is missing. A basis on every edge, with its source.
The Sherpa recommends. Every edge gets a basis (source: a capture's slug; code: the commit; inferred: the agent; confirmed: who checked), checked by the build (build_grc already stops on an unknown reference, so the check needs no change to the gate's files); inferred edges drawn dashed, with a switch to hide them; each edge links to its support. Briefed to dev (step 2).
Selecting a vulnerable function could reveal affected user stories, dependent components, relevant controls, and stakeholders.
Where the site stands today. Possible today for everything except the user stories: the graph runs code, realised by remediations, fixing the vulnerabilities, which weaknesses arise from, which risks arise from, which stakeholders bear and controls govern. Only the direction is missing: every view runs from risk down, none from code up.
What is missing. The climb from a function to the risks, controls and stakeholders above it.
The Sherpa recommends. An impact view: pick a function or file, climb the graph upwards, group what it reaches by kind (remediations, vulnerabilities, weaknesses, risks, controls, stakeholders), each with its path. User stories join when they exist (item 4). Briefed to dev (step 4).
Developers, security engineers, and executives should be able to explore the same underlying graph at different levels of detail.
Where the site stands today. This is the direction of two pieces of work already in hand: the three views (executive, security leader, operator; the brief of 23 October) and the redesign's two dials. Neither is applied to the graph yet.
What is missing. Which nodes and verbs each view shows by default.
The Sherpa recommends. Wait for the editor's review of the redesign, then give each of the three views a default depth on the graph (executive: risks, stakeholders, decisions; security leader: plus weaknesses, controls, evidence; operator: plus code, tests, versions). Not briefed to dev yet.
One particularly exciting possibility is using the graph to identify missing relationships, such as security requirements without tests or critical code paths without clearly mapped ownership.
Where the site stands today. The graph already shows this, if asked. Measured on v0.10.10: none of the 16 code nodes has an owner one step away; none of the 95 controls reaches code or a test; there are no tests in the graph; 14 of the 34 risks join no story directly. The GRC page lists some gaps by hand; none is computed.
The Sherpa recommends. A gaps page, recomputed at every build from rules written down (a control with no path to a test; code with no owner; a risk with no story, no treatment or no holder; an edge with no basis once item 5 lands), each gap with its count, its list and who could close it. Briefed to dev (step 5); the rules are data, so the GRC desk can add more.