--- title: Notes from the flight, 25 September 2026 date: 2026-09-25 desk: Editor of record from: the editor of record, reading the site offline on a plane status: filed as issues (see admin/issues) --- The editor of record read v0.1.5 offline and dictated these notes. They are kept verbatim as the source every issue in `issues/` cites (the dictation's asides are trimmed; nothing else is changed). Filed by the Build desk on 25 September. ## On the site - On the page `stories/2026-09-24__brief-to-build-in-a-day.html`, work with /design to make it easier to read and to have a separation between where the main site UI is and where the article is (at the moment it is all on the same background). - On that page, I don't have a feedback section (which would be the natural place for me to provide feedback). See how we added the chat (and other sections) on the voicedebrief.ai/app page (we have done this on other sites). See the guidance on sgit.ai (and if not there, then based on the features we add here, like the chat and feedback, once finished, propose changes for that site so that other agents can pick that up). - Add that chat session, with access to tools that give easy access to the site's content and to the feedback and notes provided. This way I could also use the chat session to provide feedback. This should use (for now) OpenRouter models (sgit.ai does something similar). - One feature that would make it super powerful: when I finish reading an article (or section), I can mark it as read, which also hides it from the front page and other sections (maybe with a visual clue of what has been removed and a link to a page where I can see everything I have done that to). This would make a massive difference, since the site would then start to have only what I have not read, which dramatically helps the value I get (I don't spend context on things I have read and am ok with). - This means we also need undo, redo and history, where all actions done (read page, mark as read) can be seen and undone, with the history keeping it all. - The features above lead to a monetisation model like pt.newsroom.sgit.ai's: give the user a wallet, drained every time the user makes an action (read an article, or in our case act on an article). - The above also means a large number of pages (including the front page) need to be created dynamically from the intersection of the current layout (chosen and curated by the editor) and my usage data. A very powerful feature and a good example of personalised sites created in a scalable way. Later we add support for storing this usage data in vaults, so it is easier to brief the main agent that runs every day, and for me to use multiple devices with the same state. - A graph-based approach (which is the best way to implement the dynamic rendering of the pages) so that you have good context of what is also relevant, and can propose articles to go next or back (depending on what the user has already seen). - One of the core ideas here (capture it in a set of principles for this site): make the reader (which could also be another agent) have the best possible experience consuming this data (which represents the changes in our current projects). This becomes more critical as more agents and humans join the team. What we are solving is how to scale communications and sync context and memory between team members (agents or humans): the power of LLMs and communication systems like these to scale past the point where the previous model, mainly for communication and content overload, would not work well past the six-person "two pizza" team (as described in The Mythical Man-Month). - In a meta way, changes to this site (sgit.newsroom.sgit.ai) should also be described and be part of the universe that sgit.newsroom.sgit.ai reports on. - There is a lot of guidance, ideas and tasks in this note, which is why the admin section is a good place to a) capture all of this, b) create and maintain pages focused on it, and c) have provenance on the tasks. - As on other sites, use issues-fs-light here to manage tasks, epics (and other issue types), which can then be loaded (since the issues are JSON and markdown) on a kanban board (done on multiple sites). ## On content - `signals/2026-09-25__pt-agent-files-one-character-per-bullet.html` is a weird article: what exactly are we reporting? Each of these articles should have a JSON equivalent (if not already) containing the markdown, links to dependencies and images, and a semantic graph mapped to the key items we want from each one: Evidence, Ideas, Questions, Statements, Facts, Hypotheses, Observations, Comments, and so on (a graph version of the article, which, as in fractal semantic graphs, is the graph the prose is created from). Don't do this for all current content pages; experiment (this will take a couple of rounds) with the new content and the next batch of changes reported and added to the site. - On `signals/2026-09-24__voice-feedback-interview-came-first.html`: another important feature is a way for the agent processing this feedback to relay messages to (for example) the RiskMandate agent (currently managing the agent@riskmandate.ai inbox), so that I can give feedback like: "For the RiskMandate agent: we need to send an email to my contact that I sent the link to this voice questionnaire, with an introduction and asking for feedback, which could be 'this is too much, I don't have this much time, can this be simpler'." - Interesting that in that signal the agent that built it was not able to find the page on the RiskMandate.ai website, since it is there. This also means we need a different place to capture issues and questions, since that information was buried in the middle of a page whose title did not indicate any issue ("riskmandate.ai had a voice feedback interview two weeks before sgit.ai briefed the pattern"). - Add a note to ban the use of "rung(s)", which should sit beside key guidance and principles for this and other sites (do we have this, from a content point of view?). It is a weird word not used very often. - We should have quite a lot of screenshots of the pages or sections the reader is consuming, on the page that talks about them; that makes it much more visual and interesting (or else we have massive walls of text). Maybe also, in some cases, cards that are always in the same location on the page, with a good visual information design of what is important to know (one of the key objectives of these pages and this site is to brief the reader on what is going on). - `signals/2026-09-24__sovereign-ai-procurement-two-readings.html` is a great example of the cross-agent briefs and tasks we need to start creating. In cases like this it is better to have a page on this site (and the JSON and markdown files as needed) that we can point the respective agents to: a page per target site with these briefings (bearing in mind that in some cases, like this one, this site is briefing multiple agents at the same time). - For the Cartographer: add a requirement that every page that agent creates has a map, digraph or infographic, since it is a very visual agent. Ask the agent to create tooling and helper scripts for these visual representations so that the code and data needed to create them is minimal. - Reading and UX flow to improve (one of our principles is that the objective of this site is information consumption, and at the moment I am the main consumer). I go to `stories/2026-09-23__a-proposal-to-uk-sovereign-ai.html`, read "The partnerships index sets out how every page", click the partnership index link, and land on `src/sites/sgit.ai/partnerships/index.html`, a completely new layout where I lose the context of where I was. In cases like this the story page can be much wider (on my laptop, at the zoom level I am comfortable with, the content uses about 50% of the width), so we can add two or three columns used to show, for example, the contents of that link (loaded dynamically, as JSON or markdown). The reader should also have the option to open the target page as the main page, replacing the current UI. The key is an experience with as little context switching as possible. One column could be the feedback side panel (or chat), which appears (as on VoiceDebrief) when the reader clicks a vertical side button. Another could show more data, or graphs and maps of the current page. Also very important: a visual clue of the status of the processing of that target link (which is why this needs to be captured in JSON files locally and then submitted). - On changes to this site: for now assume I am the only main reader, and that when I submit the data stored in my local storage (or eventually a vault), the main site should reflect it. As an extreme example, if I have processed and reviewed all pages of this site, the main page should be mainly empty (at least the dynamic parts). What would be very powerful (if the front page and other pages are created dynamically by merging the site editor's view and my customised view) is to move easily between them. Maybe a better idea: name me as one of the official target audiences, and support natively in the main UI two views: the "site's editor" view and the "Dinis" view (allowing more target audiences later). - A good example of what the side panel can show: who is the author, what is their focus and what are they trying to say, as in `2026-09-23__a-proposal-to-uk-sovereign-ai.html`. One of my first questions was "who wrote this" (which agent). This page (and all the partnerships) are a good example of content written and published (as I asked) in the last couple of days, that I now need to read and define the next set of actions from. - `src/sites/sgit.ai/partnerships/index.html` is really cool, but make it visually easier to see that we are seeing a page from (in this case) the sgit.ai website (a screenshot with the target site's branding would help). I would expect the link `https://sgit.ai/partnerships/index.html ↗` to open the target site (not the local copy). This page is a good start for a system that captures key components and data of the target page, but the side panes and columns mentioned above will be a better way. - On `src/sites/sgit.ai/partnerships/vault-key-management.html`, the buttons "Read" (black) and "Mark read" (white) are weird: I have no idea which represents whether I have read this page, and which state to leave it in once I feel I have finished. - On the same page, the side panel would answer the first question I had when starting to read: who wrote that intro section? Is it from the target page, or a summary written by one of our agents (which one)? We need visual clues for what each section is: sgit newsroom content, target site navigation, target site content (the white works really well for the content, but at the moment the entire section is white). Also, the top mentions diagrams but I can't see them, so I can't really review this content. - Just read `stories/2026-09-21__the-performance-page-that-corrected-itself.html`: good, but I need a way to provide feedback and mark this page as read. - Improve `history/index.html`: it is dry, just bullet points. - On `history/lessons.html`: great content, but I need a way to mark what I have read, and next time mainly only see the new lessons (with the option to see everything if I want). - `maps/network.html` is very cool and powerful: with a wider view, support clicking on each site to see more about it and its relationships. A view like this per day (which relationships were added on a particular day) would be super powerful. Same for the table: click a site to see more, and make the columns sortable. - Another important feature and workflow (leveraging the other LLMs I have access to, like ChatGPT and Perplexity): a daily industry news feed, based on topics we define (around the vaults we have created: the EU AI Act, OWASP, risk and GRC news, security incidents, and so on), collected by an agent into JSON, then consumed by the agent that maintains this site. Eventually this moves to a separate site; since this newsroom is where we figure out the workflows, start here. - The reading room page already has some of these ideas. Use all the available width, and make the side panel width resizable with a vertical bar separator. - On the daily review, experiment with a couple of daily or thematic slide decks (see how we did it on other vaults, where there is a full UX for creating JSON and markdown slide decks that render in HTML and give a PDF easily). A great way to provide debriefs (including screenshots and infographics from the target pages). The PDFs are also a powerful way to share on LinkedIn (or Discord, Slack, email) what is going on, and they read well on a phone or iPad. ## Tasks for agent@riskmandate.ai - Start mapping and following up the content and integrations we have been adding (for example the ElevenLabs integrations, tools and dedicated website): in our vault-powered CRM, map out who to contact and what the best medium is (email, LinkedIn via my account, WhatsApp, Slack, Discord, and so on). - For the agent (mainly Claude agentic sessions) we also need connectors and digital twins for Slack, Discord, WhatsApp, and others (Telegram, Signal, Instagram?). - Kick-start a process and workflow (with a vault to manage it) focused on finding an AWS partner for sgit.ai and one for RiskMandate.ai. These companies and services have reached a level of maturity where we need the best partner (ideally in London) to help navigate inside AWS and find the best AWS account manager and partner. Also research which AWS Startup, AI and Marketplace programme fits us best.