Reading room · history

sgit.ai version log

Every sgit.ai release since v0.1.1, newest first: 166 entries. The notes record what went wrong and how it was caught.

Release	Note
v0.6.8 2026-09-24 this release	COMPANY X-RAY: A BUSINESS PLAN, WITH ONE COMPANY X-RAYED. New vault page and a new row in the business plans for founders. The service reads a company's own documents together: the customer drops them into an encrypted vault, agents run a catalogue of twelve analyses, a person reviews, and within five working days the customer gets their questions answered, a one-page board pack, findings that each name the file and row they rest on, and a Claude setup to keep asking. No connectors, no integrations. The vault holds an invented company X-rayed end to end, fourteen findings labelled read, computed or inferred, and a script that re-runs all 46 figures from the documents. Four levels from £50 to £1,500 reuse RiskMandate.ai's pricing pattern. Read key published on purpose; vault key in the gitignored tier; all-zeros control empty. Thirty-six published vaults.
v0.6.7 2026-09-24 git 63f3e72c	A BRIEF FOR RISKMANDATE: INTERVIEW PAGES, AND A CHATGPT VOICE PROMPT. New build brief in /docs/briefs/, and an open cross-team ask. It defines a reusable interview page for riskmandate.ai: a link sent to one person, a prompt they paste into ChatGPT and continue in voice mode, about twenty minutes of interview, and a structured written summary they send back. The first page is for a founder strong in UK events, marketing and content that spreads, testing the value proposition, the name, who to reach first, events, content angles and a thirty, sixty and ninety day plan, with candid criticism asked for explicitly. The full prompt is in the brief, describes RiskMandate only in the words riskmandate.ai already uses, and is ready to send today. A later step proposes returning summaries through a write-only append lane instead of email.
v0.6.6 2026-09-24 git 23096e71	LESSON LOOP: A BUSINESS PLAN FOR COACHES. The thirty-fifth vault (3s9q7zl7, 27 files) is a business plan for padel coaches, and any teacher with students: capture the coach's picture of the player at the end of the lesson, when it is most complete, as a voice memo; an agent turns it into a lesson note and three points for the player's next games, in the player's own data vault; the player adds match notes and clips; and the next coach, in any club or country, starts from a two-minute briefing. The app replays one invented player's record across four lessons with three coaches in London and Lisbon, with the raw memos, the notes, the player view, briefings, and a themes matrix showing what each coach saw. The plan sets out four phases (capture first, nothing else until it works), the two-vault architecture with a write-only lane per coach, what exists today, pay-on-demand credits instead of a subscription, new coach income (remote reviews, drill plans, follow-ups, content), the club variant and its tension, other teaching domains, risks (children, other players in clips, undisclosed commissions) and a calculator that shows a small business at 200 coaches. The coach-memo prompt is ready to paste for phase one. Listed on the business plans page.
v0.6.5 2026-09-24 git 138dbe4e	EVERY RISK IS ALREADY ACCEPTED, AND A COMPANY TO RUN THE LOOP. A first-person foundation article for readers new to risk acceptance: no deny button; accept, fund or fix, with silence escalating; the interval as the decision (the risks.sgit.ai ladder, 1 hour to 6 months); accepted versus acceptable, with the EU AI Act's Article 9(5) quoted and scoped to providers of high-risk AI systems, which never defines acceptable; every risk with a boss and every path to the board; fractal risk registers from the board to the bytes; established by facts and ended by facts; a vault per material risk as the evidence pack of governance (proposed here); twins as the direction (designs, not built); why executives resist; and why it fits beside every GRC platform. Three new diagrams plus Risk Graph Explorer views. The thirty-fourth vault, Risk Acceptance Office (odn10gfp, 32 files), replays one invented risk over six weeks with a hash-chained decision record verified in the browser and a side-by-side of the register row, and carries the business plan: operating model, the GRC gaps, services priced per material risk, a calculator, go-to-market starting from the resistance, ninety days, risks and open questions. Research found four places where the published method disagrees with itself; the plan picks a position on each and says so. Listed on the business plans page.
v0.6.4 2026-09-24 git 9f174c35	PARTNERSHIPS WITH THE CLOUDS AND THE AI PROVIDERS, AND A BRIEF FOR RISKMANDATE. Sixteen new pages under /partnerships/, written from the vault side and each one forwardable on its own. The cloud platforms hub says what sgit needs from a cloud (mostly storage, a little compute), where it stands on each, honestly (Docker everywhere; AWS templates in beta; Google Cloud planned; Azure deployed by the founder but undocumented; the S3 mode targets Amazon S3 and S3-compatible stores are untested), the two partnerships in one (vaults in the cloud's environment, and services on top of vaults), and one page each for AWS, Azure, Google Cloud, IBM Cloud, the European clouds (OVHcloud, Scaleway, Hetzner, IONOS, STACKIT), DigitalOcean, Rackspace and Netlify. The AI providers hub sets out three meeting points (agents read and write vaults through a connector, vault apps call models without a key, vaults carry the agent's work) and one page each for OpenAI, Anthropic, Mistral AI, Google Gemini, OpenRouter and ElevenLabs. Every provider fact is from the provider's own pages, researched today; credit amounts are left out because several could not be confirmed. Research corrected two first drafts: this site is served from GitHub Pages, not AWS, and the server's S3 mode is only proven on Amazon S3. The brief for RiskMandate.ai, built on a survey of its 79 pages and 16 policy vaults, asks for the risk side of every partnership as two behaviour policies and a delta, and for sgit written up as a control against GDPR Articles 32, 25, 34(3)(a), 28 and 17.
v0.6.3 2026-09-24 git ae3f8714	BEFORE YOU GIVE AN AGENT A CONNECTOR, GIVE THE CONNECTOR A TWIN, AND BUSINESS PLANS GET THEIR OWN PAGE. A first-person article argues that a twin of the connector, a journal of every request and response an agent makes, appended to a write-only lane, processed later and replayed into the inbox and calendar as the agent saw them, is the minimum requirement for deploying an agent with provenance, explanation and undo. Every claim about Gmail and Calendar is Google's own and linked: the API delete 'cannot be undone', Undo Send is an interface feature, trash keeps 30 days, the administrator's bulk restore 25, Vault 'isn't designed to be a backup or archive tool' and keeps one Calendar revision a day. Research corrected two first assumptions (Vault has covered Calendar since November 2023; the admin audit log does record some earlier values) and the text says so. The thirty-third vault, Connector Twin (7tkvspwp, 31 files), opens on a working replay of an invented seventeen-call Gmail and Calendar session: a slider rebuilds the inbox and calendar at any step, before and after for every write, a graded revert plan, what the agent said against what the journal shows, and a hash chain verified in the browser, which ran inside the vault host's sandbox. Behind it, the business plan: facts with sources, architecture, three capture modes, packages per agent, a calculator, go-to-market, ninety days, risks, open questions, the journal specification, revert rules and three prototypes. New page /startups/business-plans.html gives the plans their own home, listed in the Why menu, with Agent as Webmaster and Connector Twin, how to take one, and the offer to build them with partners.
v0.6.2 2026-09-24 git 42d40e9f	A CALL FOR COLLABORATION ON VAULT KEY MANAGEMENT. New page in Partnerships, /partnerships/vault-key-management.html, written to be sent to password managers, identity providers and platform credential managers who have never heard of sgit. It opens with the short version, then what we are looking for in order of preference (something that already exists, a joint pilot, an open specification), the requirements in plain terms (browser first, key kinds kept apart, release only on the user's approval, end-to-end sharing, names in plain words that are addresses and never keys, revocation, scoped keys for agents), sgit in two minutes, three new diagrams (keys travelling by hand today, what a vault is and where the key sits, a seven-step share-by-name flow), and then the detail: the key formats, why the word-based share token was removed in August (about thirty bits, recoverable in a tenth of a second on a GPU), why a vault of keys still needs a first key, and what exists against what does not. The partnerships index lists it as an open call.
v0.6.1 2026-09-23 git 277b41b1	THE DSIT AI RISK TOOLKIT PAGE STARTS WITH THE READER'S DECISION, AND PLAYS THE DECK. Rebuilt from a brief: the vault has moved on since 20 September (155 files, a use-case-led journey at v0.2.0 as the home page, reference edition v0.2.3, a decks/v2 deck 'A decision before a risk list'), and the page still opened on four worlds and 617 nodes. Now: an outcome headline, three actions (live vault, eight-slide walkthrough, PDF), the site-owned decks/v2 viewer mounted on the page reading manifest, slide source, styles, five screenshots and the PDF from the vault, a five-step 'what you can try', the vault embed, then the architecture material moved below with the four-world screenshots dated, a status table separating journey v0.2.0, reference v0.2.3, the research graph (941/4,735) and the reference graph (1,051/1,289) without merging them, the licences stated (OGL v3.0 for DSIT text; no licence assigned to the new code), and the read key, derived facts, audit and the dated 20 September snapshot in an expandable provenance section. VIEWER: keyboard navigation (arrows, PageUp/Down, Home, End), a live region announcing the slide, aria-current on the slide list, titled frames, focus-visible outlines, and a counted 'N screenshots could not be read' status instead of a plausible-looking gap. Verified through the mirror: 8 slides walked, 0 unresolved images, PDF bytes match SHA-256 36f9e16c…, parse frame allow-scripts only, render frame no scripts.
v0.6.0 2026-09-23 git ec7bcad8	THIRTY-SECOND VAULT, AND THE FIRST BUSINESS PLAN PUBLISHED FOR SOMEBODY ELSE TO RUN. Agent as Webmaster (ikrqeu5t): give small businesses a website they can change by asking, with an AI agent as the webmaster and GitHub Pages as the host. The vault carries the plan as a single-page app with a unit-economics calculator, the same plan as eleven markdown documents, three drawn diagrams, three invented customer sites and the operator's sales site as standalone mock-ups, and the prototypes to serve the first customer (the agent's playbook, the GitHub Pages setup, six worked change requests). permissions {}. Published under the method: classified, derived one-way, audited from a read-key clone (nothing found), negative control run, facts derived. The startups section gains 'Business plans to build on'. THE PUBLISH FOUND TWO CLI BUGS: the auto transport treated a fresh vault's object 404 as 'no live API' and flipped push to the read-only static transport; and push, pull, fetch, status and delete ignored --transport. Both fixed in the CLI repository with a pinning test. Vault counts across the site move to thirty-two; measured estate figures keep their 21 September date.
v0.5.9 2026-09-23 git 62148934	THE SOVEREIGN AI PAGE SAYS WHAT IT IS IN ITS TITLE. A reader landing from a forwarded link had no way to know this was a proposal from sgit.ai's side. Title is now 'A proposed partnership between sgit.ai, RiskMandate.ai and UK Sovereign AI', the eyebrow names both parties and calls it proposed, the lead opens by saying so and introduces the two products in a clause each before introducing the fund. Index link, page title and About cross-link follow.
v0.5.8 2026-09-23 git ff7de798	THE SOVEREIGN AI CASE GETS ITS ANCHORING, FROM THE FOUNDER'S OWN MEMO. New section on the partnership page, stated in the first person because only the founder can supply it: thirty years in the UK as practitioner, CISO for UK companies and founder; one UK exit; The Cyber Boardroom Limited, UK-registered and trading for almost two years, as the commercial vehicle behind sgit.ai and RiskMandate.ai; the intent to grow more UK companies on the technology. Plus the sovereignty argument: no sovereign AI without open source, because a closed champion is one acquisition away from not being sovereign, while an open substrate cannot be bought out from under the country that runs on it. The honest section now says anchoring is stated first-hand rather than documented here; the lead and the fit table carry the argument; the About page gets the same facts in one row.
v0.5.7 2026-09-23 git 3aa131f4	NEW SECTION: PARTNERSHIPS, THE BUSINESS CASE MADE IN PUBLIC. /partnerships/ states the method (start with what they are trying to do, public material only, evidence not pitch, the fit stated precisely, what is not public marked) and carries the first case: UK Sovereign AI. Their mission in their words (the sovereign edge, five frontiers, the offer beyond investment, the R&D procurement scheme and its four challenge areas, the anchoring test), what sgit.ai and RiskMandate.ai have published, a fit table that maps each stated priority to vaults that can be opened now (Licence to Operate, Agentic Browser Isolation, Risk Mandate, AIUC-1 conformance, the DSIT toolkit, Regulation Graph, the performance page), three concrete partnership shapes sized to their instruments, and a section on what the page cannot tell them (anchoring, certification, stage, the partial fit). Written to be forwarded to anyone who knows somebody there. In the Why menu.
v0.5.6 2026-09-22 git b4213542	THE BYLINE NOW LINKS TO A PROFILE PAGE ON THIS SITE. New /about/index.html, About the author, in the Why menu: the record (the companies, OWASP, the O2 platform), the signed articles here, writing elsewhere (docs.diniscruz.ai, LinkedIn, open-source.sgit.ai's fuller version of the page, wardley-maps, graphs, newsroom, GitHub), interests declared, and how to reach or correct the author. author_url may now be site-root relative; the byline renders it as a relative link and the JSON-LD Person gets the absolute URL. The four signed articles point at the new page instead of LinkedIn.
v0.5.5 2026-09-22 git 49aa9407	ARTICLES GET A BYLINE. The author noticed that the news article is written in the first person and his name appears nowhere on it, on a site whose argument is provenance. New optional frontmatter, author and author_url, rendered as 'By <name>' with the link first on the date line, emitted as a schema.org Person in the page's JSON-LD, and carried in articles.json. The build refuses an author without a URL, because a byline without a link is a name, not provenance. Applied to the four first-person articles (news, SaaS, startup model, fractal semantic graphs); the site-voice articles stay unsigned.
v0.5.4 2026-09-22 git 73408357	THE NEWS ARTICLE, THIRD PASS: THE FRACTAL SEMANTIC GRAPH WAS MISSING. The author read it halfway and noticed the piece said graph without saying which kind. Two new sections: the graph is fractal and meaning comes from connectivity (edges are verbs, relates_to is banned, every node opens into its own world, bridges not merges, provenance comes free when the leaf is a word tied to a byte range and a hash, corrections propagate, the empty doors are knowledge too), and the ladder stated once: trust through provenance, provenance via evidence, evidence is bytes with a hash, and every rung can be sold because none is asserted. A fourth diagram draws a story zoomed through three altitudes and sideways into a source's identity world. Links to the FSG page and graphs.sgit.ai; summary and executive summary updated to match.
v0.5.3 2026-09-22 git 1ddfae52	THE NEWS ARTICLE, SECOND PASS, ON THE AUTHOR'S NOTES. The first pass described the problem well and the solution thinly. Now: an executive summary section up front with the eight key ideas; a section on why advertising and subscriptions are both bad for the reader (product, hostage); the objective stated once, a commercial model that rewards investigative journalism so usage funds it and it earns the usage, drawn as a third diagram against the race to the bottom; the two clocks compressed, since that part is known; and the five things to sell each given their mechanics (read key, licence to transform, evidence vault per licensee, the cut not the content, the two prices and freshness of the verification API). The word prose is gone from the text and the diagrams, replaced by content or the words, because the readers this is for are the people who write it.
v0.5.2 2026-09-22 git fcd0de3a	NEW ARTICLE: THE FUTURE OF NEWS IS THE STORY VAULT, NOT THE PAYWALL. Written from a voice memo, the seven future-of-news pieces on docs.diniscruz.ai (Feb to Jul 2025, dates kept on purpose), newsroom.sgit.ai, subscriptions.sgit.ai and pt.newsroom.sgit.ai, and the published vaults. Two clocks: Google traffic to publishers down 33% in a year and Cloudflare's billion 402s a day; the UK subscription regime brought forward to 1 Jan 2027. Reuters 2026: 17% pay, 71% of non-payers say nothing would persuade them. The counter-arguments to micropayments (Ball 2020, Guay 2026) are quoted and answered: they are about paying for prose. The story is a graph, the article is a projection, five things to sell, 60/25/10/5, x402 rails, and an honest note that no sgit.ai site is wired to any rail. Two drawn diagrams, link-preview card generated, linked from the startups section.
v0.5.1 2026-09-21 git a8f931aa	THE GUARD SHIPPED IN v0.5.0 DID NOT GUARD THE CASE THAT MATTERS, AND THE NOTE FOR IT OVERCLAIMED. The author asked the right question: will this work for new articles that have an image? Tested rather than assumed, and the answer was NO. og_card() falls back to og/default.jpg when an article's card is missing, so a new article with a hero, published without running the generator, would build clean, validate clean, and ship with the GENERIC card. The v0.5.0 entry said the validator catches a forgotten generator run. It does not: it only checks that the file an og:image names exists, and the fallback always names a file that exists. Simulated to confirm, and the build printed no complaint while the new article's og:image pointed at the default. NOW THE BUILD REFUSES. After ARTICLES is loaded, any article whose body has a !shot figure but no og/<slug>.jpg stops the build, names every offender and prints the command to run. Same shape as the LLMS_SECTIONS check, which is the house pattern: the build refuses rather than guessing. og_card()'s fallback is now documented as safe precisely because that check has already run, so the only pages reaching the default are the ones meant to. AND release.sh RUNS THE GENERATOR, so in practice it is automatic: step 1 calls make_og_cards.mjs before the build when sharp resolves, and says so and skips when it does not, at which point the build's own refusal is what catches it. PROVED BOTH WAYS: a test article with a hero and no card stopped the build with its name and the fix; running the generator produced the card and the same article then built with its own og:image. So the answer to the question is: yes for a new article, automatically via release.sh, and if the generator is ever skipped the build stops instead of quietly shipping the wrong picture.
v0.5.0 2026-09-21 git 7403bdaa	SHARED LINKS HAD NO PICTURE, BECAUSE og:image WAS MISSING ENTIRELY. Reported from a LinkedIn compose box: pasting the SaaS article gave a title-and-domain card with no image. The head carried og:type, og:site_name, og:url, og:title and og:description, and NO og:image at all, with twitter:card set to the small 'summary'. So there was nothing for a crawler to show. AND THE OBVIOUS FIX WOULD NOT HAVE WORKED EITHER: every figure on this site is WebP, and LinkedIn's crawler does not read WebP. It drops the image without a word, which is the trap, because the page looks correct and the preview is silently plain. So the cards have to be JPEG. NEW TOOL, admin/build/make_og_cards.mjs, writes 1200x630 JPEGs, the size LinkedIn documents for the large card, below which it can fall back to the small one. Every article's FIRST !shot becomes that article's card, parsed from the same markdown the page is built from so the two cannot disagree. Our heroes are wider than 1.91:1, so they are fitted rather than cropped, on a background sampled from each image's own corner, which makes the letterbox invisible on the cream covers. Eight article cards, 38 to 109 KB each, plus a drawn default card for the other 138 pages, carrying the wordmark, the tagline and pip install sgit-ai. THE HEAD now emits og:image as an ABSOLUTE url, og:image:width, og:image:height, og:image:alt, twitter:image, and twitter:card upgraded from summary to SUMMARY_LARGE_IMAGE, without which the picture is shown small or not at all. AND A GUARD, because the preview is invisible from the page itself and both failure modes are silent: validate.js check 3e fails the build if any page has no og:image, if it points at a .webp, or if the file it names does not exist, which is what would happen when somebody adds an article hero and forgets to run the generator. Proved by deleting the default card: 138 pages failed, and all passed again when it was restored. ALSO, SIXTEEN PAGE TITLES HAD AN UNBALANCED BRACKET, found because og:image:alt is built from the title and the homepage's read 'sgit (the encrypted git for humans and AI agents' with nothing closing it. Same em-dash-rewriter collateral as the article title template in v0.3.9: the paired rule opened a bracket where a dash had been and had no closing dash to convert. All sixteen closed, which fixes the browser tab and the preview alt text together. NOTE FOR SHARING: LinkedIn caches previews hard, so an already-posted link needs a pass through linkedin.com/post-inspector before it picks the image up.
v0.4.9 2026-09-21 git e5263c4c	THE PHONE MENU WOULD NOT SCROLL, AND TWO GRIDS OVERFLOWED SIDEWAYS. Reported from an iPhone: opening the top menu, you could not scroll it, unless you first scrolled the whole page, after which the menu moved. REPRODUCED AND MEASURED at iPhone 13, SE and Pixel 5 profiles. The open menu is 42 links and stands 1536px tall against a 664px viewport, with max-height none and overflow-y visible, inside a nav.site that is position:sticky. So the menu had no scroll of its own and the sticky bar pinned it at the top, leaving the last item, Security, 855px BELOW THE FOLD and reachable only by scrolling the page underneath it. Exactly the reported behaviour. THE FIX caps the open menu to the viewport and lets it scroll itself: max-height calc(100dvh - 7rem) with a 100vh line above it as the fallback, overflow-y auto, and overscroll-behavior contain so the gesture stops at the end of the menu instead of chaining to the page. The 7rem is the worst-case closed bar, 92px on an iPhone SE where the row wraps rather than the 55px it takes when it does not, plus this element's own border, padding and margin, another 17px, which on the first attempt left the nav 12px taller than the viewport. MEASURED AFTER: the menu scrolls 913px internally on an iPhone 13, 1009px on an SE, 850px on a Pixel 5; the page does not move at all (scrollY stays 0); the last item is visible; and the nav now fits inside the viewport on every profile. AND A SECOND BUG FOUND WHILE VERIFYING, unrelated to the menu and present with it closed: the homepage ran 28px wide at 320px (iPhone SE). Cause was grid-template-columns repeat(auto-fit, minmax(330px,1fr)) on .jobs, a hard floor wider than the ~285px of content box a 320px phone has, which does not shrink, it overflows. .netpick, the component behind the new fractal band on the home page and the startups section, had the same bug at 310px. Both now use minmax(min(Npx,100%),1fr), which collapses to the container below that width and changes nothing above it: desktop columns are identical at 1280. A comment records the rule, because the next person will reach for a bare minmax again. Four pages checked clean at 320 and 390.
v0.4.8 2026-09-21 git 99b37799	A HERO IMAGE THAT ARGUES THE THESIS, AND THE FOUR WORDS THAT SUMMARISE IT BETTER THAN THE ARTICLE DID. The author made a cover for the inertia piece and revised it after review. The first version put both carts on the same railway track, which said same race, different speed; the revision has the newcomer OFF THE RAILS on chunky tyres with its own tyre tracks curving away across open ground, which is the actual argument, that the newcomers build on ground the incumbent cannot move onto, and it turns the rails into the incumbent's constraint rather than a shared destination. The revision also drops a decorative Mediterranean landscape that carried no meaning, and the rugged tyres remove a reading in which the newcomer looked like a toy. What survives from the first version is the load-bearing choice: BOTH CARTS CARRY THE SAME TEAL AI BLOCK, which is the 'AI is available to both sides' claim made visual, while the difference between them is a stack labelled PAST SUCCESS with a ball and chain attached, which is Wardley's climatic pattern drawn literally. Shipped as the article's first figure, above the Wardley-axis diagram: the picture carries the hook, the diagram carries the mechanism. Re-encoded from 2.26 MB PNG at 1915 wide to 63 KB webp at 1600. AND THE STRAPLINE BECOMES A PULL-QUOTE: 'Same AI. Different inertia.' states the thesis in four words, better than any sentence in the piece, so it now sits as a block quote between the lead and the diagram.
v0.4.7 2026-09-21 git 7ec295ce	THE SAAS ARTICLE'S FILE NAME NOW MATCHES ITS TITLE. The slug had stayed at what-saas-refused-to-build through three retitlings so that links already handed out kept working; the author has now asked for the name to follow the title, with no redirect from the old one. The article lives at /articles/saas-apocalypse-decided-by-inertia-not-by-ai.html, the old built page and its markdown twin are deleted rather than left as ghosts, the startups section's link follows, and the old address returns 404 on purpose.
v0.4.6 2026-09-21 git c6819b40	THE SAAS ARTICLE TAKES ITS FINAL TITLE, AND THE ARGUMENT IT IMPLIES. 'The SaaS apocalypse will be decided by inertia, not by AI', chosen by the author from the inertia set, and the reason it is the right one is a claim the piece had not yet made explicitly: AI IS A CONSTANT, AVAILABLE TO BOTH SIDES. The incumbents have the same models as the newcomers, plus more data, more engineers and more money, and if the technology were the deciding factor they would already have won; two and a half years in, they have not. So the variable is inertia, in the Wardley sense: where a company sits on the evolution axis and how much past success it has to protect, which is what decides which side of the Nokia path each SaaS provider ends up on. FOUR PASSAGES CHANGED TO CARRY THAT. The lead now states it outright as the reason for the title. The market section gains a paragraph observing that the February panic and the September recovery were both staring at the wrong variable: the panic said AI would hollow out SaaS, the recovery said it would not, and the same models were available to the largest incumbent and a two-person company on the day the plug-ins shipped. The incumbents section adds that they have the same AI and more data to point it at, and that the constraint is not the models. The closing separates the two: the strategy question is not about AI, which both sides have, but about inertia, which only one side has. Abstract and startups link follow the title. Slug unchanged.
v0.4.5 2026-09-21 git 75773920	OPTIONAL WAS THE WRONG WORD, AND THE AUTHOR SAID WHY. Nokia did not opt into either of its outcomes: the first time it had nothing to protect and moved, the second time it had fifteen years of success to protect and did not, and the mechanism is the climatic pattern Wardley names, success breeds inertia. A title built on choice misdescribed the argument, and so did the three passages in the body that leaned on it. The article is now 'The SaaS apocalypse belongs to whoever has the least inertia', which names the mechanism and makes the newcomers' opportunity immediate, since the incumbents have the most inertia and the newcomers have none. The lead, the abstract and the closing were rewritten around inertia rather than choice: the apocalypse is a forecast about inertia, not technology; it will happen to the companies with the most to protect and belongs to the ones with the least; the fatal version is not a decision anybody takes but the default behaviour of a business with success to protect; and the strategy question it poses is one the newcomers have already answered, because for them there was never anything in the way. The word does not survive anywhere in the piece, checked by the build. Slug unchanged; the startups section's link follows the title.
v0.4.4 2026-09-21 git 647938a5	THE STARTUP ARTICLE TAKES THE TITLE IT WAS GIVEN ON LINKEDIN. When the author republished it there, the title gained a prefix, 'For a startup, the most important question is whether they miss it', which says who the piece is for before it says what it argues, and the two versions should match. Sentence case here, to match every other title on the site. The slug is unchanged, the startups section's link text follows the new title, and nothing else about the article moved. The SaaS article's title is under discussion and stays as it is until the author picks one.
v0.4.3 2026-09-21 git ca1e56f8	THE SAAS ARTICLE GETS ITS REAL TITLE, AND EVERY ARTICLE GETS AN ABSTRACT. Three notes from the author on the two new articles. (1) THE TITLE NEEDED THE WORDS SAAS APOCALYPSE IN IT, with an ironic twist, because the key move in the argument is that it has not happened yet and remains a very strong possibility depending on how the incumbents behave. The article is now 'The SaaS apocalypse is optional', and the twist is carried by Nokia, twice: Nokia met the arrival of the mobile phone by becoming the mobile phone company and dominated for fifteen years; Nokia met the arrival of the iPhone and was gone from the category within seven. Same company, two responses. The apocalypse is optional in exactly that sense, a forecast about behaviour rather than technology, and every company gets to choose which Nokia it is. Added to the summary, the lead and a new closing paragraph; the slug is unchanged so the link already given out still works. (2) THE FIRST PARAGRAPH IS AN ABSTRACT, AND NOW SAYS SO. The author republished the startup article on LinkedIn with the summary prefixed 'Abstract:' and set in italics, which reads better than a bare lead, so the article template now does the same for every article: the summary renders as an italic paragraph with a bold Abstract label, and the markdown twin carries the same emphasis. (3) THE INFOGRAPHIC BECOMES THE HERO. The author made a cover image for the startup article (a hand lifting one app tile out of a grid, leaving an empty slot and a speech bubble asking for it back, over the three pillars) and asked for it on the page, compressed. It is now the first figure of 'The most important question is whether they miss it', re-encoded from 174 KB at 1733 wide to 94 KB at 1600 wide, above the flow diagram rather than instead of it: the picture carries the hook, the diagram carries the mechanism. The startups section's link to the SaaS article was updated to the new title.
v0.4.2 2026-09-21 git ef990399	THE SAAS APOCALYPSE, ARGUED WITH DATA RATHER THAN VIBES. A second article from the author's voice memos, 'What SaaS refused to build is exactly what the agents need', and the brief was to find evidence for the claims about quality, usability, satisfaction and value for money of medium to large SaaS. Every figure was fetched from its source rather than recalled, and each is linked. THE MARKET HAD THIS ARGUMENT ALREADY: in the first week of February 2026, after Anthropic shipped Claude Cowork plug-ins, roughly $285 billion left software stocks in about 48 hours, a Jefferies trader named it the SaaSpocalypse, Thomson Reuters fell 16% in a day, the S&P software index dropped 13% in five sessions, and Forrester titled a piece 'SaaS as we know it is dead'. Then it recovered, about 40% off the April low by September, on the narrative that systems of record and proprietary data are durable moats. The article's reading: that recovery concedes the point, because it says the DATABASE is the moat and stops defending the screen and the seat. J.P. Morgan's Mark Murphy is quoted approvingly: it is 'an illogical leap' to expect every company to write AND MAINTAIN a bespoke product, and the article agrees, because that gap is where the opportunity lives. USERS WERE NEVER HAPPY, MEASURED: Freshworks 2022, 8,698 respondents, 91% frustrated with workplace technology, 57% of the unsatisfied say software makes them less productive, 68% of leaders name hard-to-use apps as the biggest adoption problem. Pendo 2019, 615 instrumented products, 80% of features rarely or never used, up to $29.5 billion spent building them; the older Standish 64% is cited WITH Mike Cohn's caveat that it came from four internal apps in a 2002 keynote and should never have been generalised. Zylo 2025, $21M a year wasted per organisation on idle licences, up 14.2%, $4,830 SaaS spend per employee, 660 apps in a large enterprise, lines of business controlling 70% of spend. And the spreadsheet: Deloitte 73% prepare VAT returns in Excel, YouGov 78% of British companies say spreadsheets support key financial decisions, read as the clearest evidence that SaaS failed its users, since Excel is where they control the shape of the thing. WHY, IN WARDLEY'S WORDS: past success breeds inertia, quoted from the doctrine chapter ('the pre-existing installed base causes inertia to the change'), and the map claim stated so it can be argued, per wardley-maps.sgit.ai's thesis that maps are claims not pictures: the SaaS product has slid right into a substrate of database, message bus and state machine, on which higher-order things now get built. EVERYBODY WAS ALREADY VIBE CODING, SLOWLY: Karpathy's term from February 2025, Collins word of the year by November, described as people writing very good briefs, which product owners always did in an environment with a catastrophically slow loop. WHY INCUMBENTS CANNOT SIMPLY DO IT: non-functional requirements were never funded, with Stripe's Developer Coefficient (17.3 hours a week, 42% of developer time, on maintenance and bad code, $85 billion a year) and DORA 2024 (19% elite, high cluster shrunk 31% to 22%, low cluster grown 17% to 25%, elite deploying 182 times more often) as the evidence, and the line the author stands behind: show me a SaaS company and I will show you a company that is highly inefficient at developing software. THE IRONY IN ONE PARAGRAPH: portability, open schemas, a real API and data you can take out were starved for twenty years as churn risks, and are precisely what a customer's agent turns up needing. THE MISTAKE AND THE MONEY: confusing the brief with a product, because SaaS was bought for being MAINTAINED, and the person who vibe coded the replacement does not want to maintain it, so the future is village and town-planner companies that take the brief and keep it running, paid by consumption, plus the few incumbents who pivot to a platform for exactly that, with sgit and Fractal Semantic Graphs named as one shape it can take. Closes on more engineers not fewer, and on Brooks: the two-pizza limit existed because communication did not scale, and with humans and agents it now can. ONE DIAGRAM: the SaaS product sliding right on the evolution axis into a substrate, the explorer to villager to town planner handover on top, and the mistake drawn in red. Linked from the startups section as the description of the market a founder is building into.
v0.4.1 2026-09-21 git 09c06a53	THREE DISCLAIMERS STOOD BETWEEN A VISITOR AND THE MOST POWERFUL PAGE ON THIS SITE. The author's note: /demos/vaults/ is one of the strongest things here, and a first-time visitor met four boxes of process, policy and incident text before a single openable vault. Measured before the change, the table of 31 vaults began 919 px down at 1280 wide and 2,000 px down at 390. MEASURED AFTER: 492 px and 832 px. A cut of 427 px (46 percent) on desktop and 1,168 px (58 percent) on a phone, and five vault rows now sit above the 900 px fold where previously not even the table header did. No horizontal overflow at either width, and the table's sort still asserted working rather than eyeballed. WHAT CHANGED ON THE PAGE: the lead cut from 86 words to 50 and rewritten to start with the instruction rather than the description ('Open any of these in your browser right now'); the fractal note turned from a box into a component, a new .vt-orient strip carrying the sentence and its two links in one flex row, 95 px down to 38 px at 1280 and 252 px to 127 px at 390, with hidden .hv-sep separators so the markdown twin still reads as prose; and one duplicated pointer to the publishing method deleted outright rather than moved. NOTHING WAS THROWN AWAY, which was the author's actual instruction: the three notes were interesting, they were just in the wrong place. They are now full entries on a new LESSONS LEARNED page at /lessons/, in the Evidence menu beside Case studies, built on the premise that a rule with no origin is only a preference and the first person who finds it inconvenient will drop it. Each entry states THE RULE and WHERE IT CAME FROM: classify a credential before it touches anything (from the submission that was a vault key described as a read key), read keys yes and vault keys never, audit every vault before its key appears anywhere, and write the method down rather than just the outcome. It links to the existing case studies rather than repeating them. AND A COUNT CORRECTED ACROSS THREE PAGES while checking the work: the ladder has NINE vaults on it, counted from the table rather than recalled, but the vaults page said eight and the fractal page's lead said 'seven more' beside the origin vault, which is eight. Both drifted when the DSIT vault became a rung in v0.3.1 and the surrounding prose was not updated. The homepage band added in v0.3.8 already said nine, so the three pages now agree.
v0.4.0 2026-09-21 git 5f8da5b0	A STARTUPS SECTION, BECAUSE A LARGE PART OF WHY SGIT EXISTS IS TO LET OTHER PEOPLE BUILD ON IT. New top-level section at /startups/, in the Why menu beside Investors, and it opens by pointing at the operating model rather than the technology: the article shipped in v0.3.9 is its centrepiece, because a founder's journey starts with the model and only then needs the substrate. WHAT YOU GET ON DAY ONE, framed as the four costs a vault removes: a database to run (none, nothing runs between requests so nothing is billed between requests), hosting for your reader (none, the vault carries its own app and also runs from a plain bucket, so deployment is a copy), an account and an install (neither, a read key is the whole credential), and versioning bolted on later (already there, so you can take something away and put it back). Plus the audit story: the server cannot read it, by default rather than by tier. THE LOOP FROM FIRST VAULT TO FIRST CUSTOMER in five steps, each linked to the page that owns it, ending on the one the stack deliberately does not do: billing. With an honest caveat on step four, that rotating a key ends a trial but REVOCATION IS NOT RETROACTIVE, so anybody who cloned keeps what they cloned. WHAT YOU STILL HAVE TO BRING, which is the section that makes the rest credible: billing and payments (not here, not planned), identity and per-user accounts (a read key is a capability, not a login), server-side search and query (the server cannot read the content so it cannot index it), and the judgement about what to ship. AND THE ARGUMENTS THIS RESTS ON POINT OUTWARDS rather than being restated: open-source.sgit.ai and subscriptions.sgit.ai already own two of the three pillars, and they are linked as sibling cards. The section says outright that it is new, deliberately small, and will become its own site when it outgrows a page, the way nineteen others have. Registered in pages.json, NAV and LLMS_SECTIONS; the build's own guard caught the missing llms.txt section before the validator caught the sitemap, which is the guard working as designed.
v0.3.9 2026-09-21 git d856aa88	A NEW ARTICLE ON THE STARTUP OPERATING AND INVESTING MODEL, FROM THE AUTHOR'S OWN VOICE MEMO. 'The most important question is whether they miss it' states the model in three pillars. ONE, be profitable: a startup is simply a product somebody wants to buy at a price that is profitable to you, and if the PRODUCT is not profitable it does not scale whatever the company's accounts say. The skill that matters is SHIPPING, daily, and not a proof of concept or a demo or a video of a demo but a thing a stranger can use alone and get value from, tape and vibe coding entirely acceptable. Keep the running cost near nothing (serverless, as little live state as you can stand) which is why the file system is the database here, and the performance page is cited for what that costs. THEN THE PART ALMOST NOBODY DOES DELIBERATELY: give it away for a short window, then TAKE IT AWAY, and ask the only question that matters, DO THEY MISS IT. A shrug means no product yet, only something people accept when free, which is a much weaker signal than it feels from the inside. Coming back is the why now, and the moment the model turns on. Then two questions rather than one: is the price inside their value-added zone, AND is it a profit for you, with the honest caveat that it may only be profitable at scale and the gap should stay small enough to self fund. Revenue first; no revenue at all is not a marketing problem. TWO, investors should be calling you: the worst time to raise is before profitability, which is exactly when most companies do it. You bargain from weakness with a clock running, and the worst terms are not the money, they are the CONTROL handed to people whose job is to make money rather than to understand your business, whose opinion now carries weight and is structurally misaligned. Stated as one of the most common and most self-inflicted ways companies fail. The analogy is music: do not get signed before you have the album, write the songs, record them in a bedroom studio, play locally, get people buying, THEN take the deal as somebody who does not need one. Not 'never raise', raise from strength. THREE, open source everything, with five reasons that each stand alone: the technology is not the moat and believing it is shapes every decision badly; code written to be read by strangers has cleaner boundaries; a team that has never deleted a component will defend one too long; it is plainly better for the customer, who can read the thing rather than trust a promise; and it is a better FOUNDER EXIT, because building proprietary accumulates technology, much of it not even specific to the startup, that you cannot take with you. Links out to subscriptions.sgit.ai (a subscription is a discount for regular use, not rent on something ignored) and open-source.sgit.ai (open source is a strategy, not a charity) rather than restating arguments those siblings already own. ONE DIAGRAM, drawn for it: the loop from ship to give away to take away to the miss test, with a red return path for no and the paid path for yes, and the third pillar running underneath. AND A BUG FIXED ON THE WAY, present on EVERY article since v0.3.0: the article title template read '{title} (sgit.ai' with no closing bracket, so nine pages shipped a malformed title tag. It is em-dash-rewriter collateral: the paired-bracket rule opened a bracket in one place and closed it in another, the same failure class caught in table cells at the time but missed in the build script because the validator's prose check does not read .py. Two more orphans from the same pass fixed in comments, and a stale '#25 the newest' in the vaults docstring corrected to #31.
v0.3.8 2026-09-21 git e4761f4d	THE FLAGSHIP CONCEPT PAGE WAS NOT ON THE HOMEPAGE AT ALL. Fixing the routes into the performance page in v0.3.7 surfaced a larger omission: FRACTAL SEMANTIC GRAPHS, the idea this site's whole vault collection is evidence for, had no homepage presence whatsoever. It now has its own band, placed after 'What people actually ship' because that is the natural escalation: here are the things people ship, and here is what nine of them turn out to be when you look at them together. THE SECTION states the definition in one paragraph (every node opens into a graph with its OWN ontology, a regulation then its articles then the words they define, each world using vocabulary the one above never agreed to; the grammar is constant, the schema never is; for years we called it graphs of graphs of graphs) and then splits into two routes: the idea and the evidence (the jump test, a ladder of twelve rungs from the text of a law down to one compute instance, nine published vaults openable with a read key) and what it costs, measured (no live database, a 1,051-node graph opening in 94 KB and three requests, 11.2 MB of source down to a 4 KB ontology with nothing discarded). Counts were checked against the pages rather than recalled: nine rows in the open-them table, twelve linked rungs on the ladder. AND A LAYOUT BUG FIXED ON THE WAY: the homepage bands alternate background between band and band alt, and inserting a section would have broken the rhythm for everything below it, so the classes from proof through network were reassigned in order. That also corrected a pre-existing double-alt between network and the articles band.
v0.3.7 2026-09-21 git 99f0cbb8	THE BEST PAGE ON THE SITE WAS ALSO THE HARDEST TO FIND. Six releases of measurement went into /demos/fractal-graphs/performance.html and it was reachable from one nav entry under Vaults plus three content links, none of them on a landing page: the fractal page's closing section, docs/vault/reading-a-vault-file.html, and api/vault-objects.html. The author asked where the link actually was, which was the right question. NOW LINKED FROM FIVE MORE PLACES, all editorial rather than nav: the HOMEPAGE, in the agents card that already mentions sparse clones for fast cold starts, and again in that section's footer line; the DOCS INDEX, under Concepts beside the security model and credentials, where somebody looking for reference material will actually look; COMPARISONS, with a note saying outright that the performance comparison lives on its own page because it needs more measurement behind it than an entry allows, which is also the honest reason it is not an entry there; the VAULTS INDEX, in the note that already points at the fractal ladder; and the FRACTAL PAGE'S OWN LEAD, not just its closing section, since a reader who wants the engineering rather than the concept should not have to reach the bottom of a long page to find out it exists. ALSO ADDED TO THE EVIDENCE MENU beside Comparisons, in addition to its existing place under Vaults beside Fractal graphs. A page about how fast something is and what it costs belongs where people look for evidence, not only where its sibling happens to live. No content changed in this release, only the ways in.
v0.3.6 2026-09-21 git f0a8d430	THE API IS A CONVENIENCE OVER THE STORE, NOT A REQUIREMENT OF IT, AND THE PAGE NOW PROVES IT WITH A NUMBER. The author's point: if performance really matters, expose the objects directly through a CDN and skip the function entirely, which is safe precisely BECAUSE everything is encrypted. MEASURED, same client, same vault, same 106 objects, same decryption, only the path to the bytes changed: full clone through the serverless API 65.4 s; full clone against PLAIN GETS WITH NO API IN THE PATH 2.63 s; straight off a local folder 2.05 s. TWENTY FIVE TIMES FASTER with nothing about the vault changed. Honest caveat on the page: the static host was localhost so the network was free and a real CDN adds edge latency, but the client and the work were identical in both rows, so the difference is the function in the middle. IT ALREADY SHIPS: sgit clone --transport static points at any GET host, sniffs which of two published layouts it uses on the first successful read, fans out EIGHT PARALLEL REQUESTS at a time, and records every URL it touches so a test can assert no request ever carried key material. WHY IT IS SAFE: every object is ciphertext under a key the server never had and every name is a hash of those bytes, so public GETs disclose object sizes and request timing, the same side channel the API already has and which the security model already names, and nothing else. AND THE DIRECT PATH IS ALREADY IN PRODUCTION FOR LARGE FILES: anything over 4 MB (the safe margin under the serverless base64 response limit of ~4.7 MB) is handed out as a presigned URL and fetched STRAIGHT FROM STORAGE, which is also the fallback when a batch 502s. So there are already two paths to every byte and the only reason the small case goes through a function is that nobody has needed it not to. FOUR ORDINARY STORAGE OPTIONS listed: a CDN in front of the bucket, where immutable hash-named objects are the ideal cache key; ranged and parallel GETs, which is how a 100 MB or 500 MB object should be read; lower-latency storage classes such as S3 Express One Zone, named WITHOUT a number because we have not benchmarked one; and another provider entirely, since what is served is opaque bytes at deterministic paths. FINDING THE OBJECT: usually you already know the id because it is pinned in the page, and when you do not the walk is ref to commit to tree to blob, a couple of requests rather than a clone. Counted against the static host, reading one named file out of a sparse clone cost TWO requests, one of which was the client re-probing the host layout, a 404 it could skip. This is the thing git cannot do, because git packs its objects and negotiates its transport, so one file usually means cloning the repository. AND ONE GAP STATED OUTRIGHT: there is NO HISTORY-DEPTH FLAG. --sparse skips content (256 KB, 7.3 s) and --bare skips the working copy, but a full clone still takes every version, 106 blobs where the current tree is 42 files, and a sparse clone still walks all 7 commits and 28 trees. Depth control is the single change that would most improve clone time.
v0.3.5 2026-09-21 git 11fafba1	THE HEADLINE LATENCY WAS A COLD START PRESENTED AS AN ARCHITECTURE COST, AND THE BATCH OPTIMISATIONS WERE MISSING. Both flagged by the author, both wrong on the page, both now measured properly. THE FIXED COST IS NOT ABOUT BYTES: six runs each, best of run, a GET returning 340 bytes took 0.331 s and a GET returning 41 KB took 0.309 s. The same. At 2.3 KB it is 0.347 s. Only at 1.0 MB does transfer appear at all, and then it is 0.300 s of a 0.647 s total. One request in the run returned in 4.8 s, which is what a cold start looks like. So the floor of about a third of a second is THE PER-INVOCATION COST OF RUNNING THIS API SERVERLESS, a deployment choice, not a property of reading encrypted data. SG/API also runs on EC2 with a warm process already listening, where that cost does not exist; not measured here, so the page puts no number on it and says so. The v0.3.4 table said 'cold network fetch 1,210 ms' as though the architecture cost that: it was the CLI figure, and it is now split into 347 ms of fixed overhead plus 300 ms of transfer, with the raw GET of the same object (0.65 s) shown beside the client one (1.21 s). BATCHING, WHICH IS THE ANSWER TO THE FIXED COST, measured on small objects so only the per-object term shows: 1 object 0.590 s, 2 in one batch 0.394 s, 5 in 0.560 s, 10 in 0.872 s, 18 in 1.528 s. That is a straight line, TIME = 0.25 s FIXED + ABOUT 71 ms PER OBJECT + TRANSFER. Eighteen objects one at a time would be roughly 6.3 s; in one batch 1.53 s, FOUR TIMES FASTER, and the saving grows with the count. THE BATCH ENDPOINT DOES MORE THAN READS, which the page had not covered at all: up to 100 operations per request, MIXED READS AND WRITES, authorised per operation, with op types read, write, write-if-match and delete. write-if-match carries the SHA-256 of the content you believe is there and IF ANY MATCH FAILS THE WHOLE BATCH IS REJECTED, which is optimistic concurrency across a set of files in one round trip with no lock anywhere. Large blobs route through presigned URLs rather than the response body. AND THE NEXT OPTIMISATION IS NAMED RATHER THAN GLOSSED: 71 ms per object inside a batch is close to linear, the signature of objects being fetched from storage one after another in the handler; fetching them concurrently would bring a 20-object batch near the cost of a 1-object batch. That, plus chunking by accumulated size rather than file count so the 502 stops happening, are the two changes that would move these numbers most, and both are in the API and the client rather than the design.
v0.3.4 2026-09-21 git 2e7f594a	THE BIGGEST PERFORMANCE FACTOR IS THE DESIGN, AND THE PAGE HAD BURIED IT. The author's point: performance here comes from architectural decisions and the design the site promotes, because you start by asking WHAT DATA DO I NEED FOR THE TASK AT HAND. The page now opens on that and gives it a section of its own. STANDING ON GIANTS, three layers that are already fast and are composed rather than replaced: the file system, a high-performance indexed store with the OS page cache in front; a content-addressed hash store on top of it, where a name is a hash so lookup is a path, dedup is free and a cache entry cannot be wrong; and the graph on top of that, which is the part that tells you WHICH BYTES to ask for. AND THE FAIR VERSION OF THE DATABASE COMPARISON: a database is fast largely because it keeps the working set in memory, which is the same insight, not cheating. The difference is who picks the working set. A buffer pool guesses it in advance from access patterns for every reader at once; we pick it per question at the moment the question is asked and throw it away after. MEASURED, BECAUSE THE HABIT ONLY MAKES SENSE IF LOADING IS CHEAP, on the 1.0 MB file holding the whole DSIT graph: cold network fetch 1,210 ms; local disk read 2.5 ms at 418 MB/s; AES-256-GCM DECRYPT 0.351 ms at 2,978 MB/s; JSON parse 3.2 ms. So decryption is 0.03 percent of the cold fetch and about a TENTH OF THE JSON PARSE, and on a 59 KB shard it is 0.025 ms. Encryption is free at these sizes and the network is everything, which puts the question back on how many bytes you asked for. THE DESIGN RULE AS A BUDGET: under 100 KB is an answer, around 1 MB is a whole world, 10 MB and up means you are loading a store rather than an answer, and gigabytes is a design error that no tuning will fix. SAVE IS WHERE THE LOOP COMPOUNDS, the LETS step people skip: saving is not filing the answer away, it is leaving an artefact cut to the shape of the NEXT question. The Article 9 slice exists because somebody asked about Article 9 once, so asking again costs 29 KB instead of a megabyte. Build time replaces query time one question at a time, paid by whoever asked first, with nothing decided in advance. RESTRUCTURING INTO CONTEXT IS COMPRESSION, the fractal property argued as volume rather than meaning, with the measured ladder in the Regulation Graph vault: raw Formex source 11,216,043 bytes; the graph, 1,523 nodes and 1,944 edges, 1,073,915 bytes, 10x smaller; one article's pre-cut slice 29,638, 36x smaller; the ontology 4,217, another 7x. Top to bottom 11.2 MB down to 4.2 KB, a factor of about 2,660, WITH NOTHING THROWN AWAY, because every level keeps the edge down to the one below. Query the small thing, follow the link only when the answer needs it. WHICH IS WHY IT SCALES IN THE DIRECTION THAT BREAKS SCHEMA-FIRST SYSTEMS: there, more data means a bigger index and a bigger machine; here the store can be terabytes while what a question loads stays in megabytes, because the graph is what tells you which bytes matter. Adding a terabyte adds nodes you did not load. ALSO: a real SQL engine comes along wherever the slice lands, and the managed services already work this way, loading a dataset into an in-memory SQLite or MySQL when an instance wakes, so we do explicitly what they do implicitly, chosen per question rather than per instance lifecycle. AND A CORRECTION FOUND BY MEASURING: this page said 617 nodes and 694 edges, quoting the vault's page. The file as cloned today has 1,051 NODES AND 1,289 EDGES across five worlds, because the vault released 0.2.1 on 21 September and the graph grew. Every count on the page is now counted rather than quoted, and the drift is only visible because the vault keeps its versions rather than overwriting them. The vault's own page still carries the figure it was published with.
v0.3.3 2026-09-21 git 4b468e61	THE PERFORMANCE PAGE WAS MISSING THE THREE THINGS THAT MAKE IT FAST. The author read v0.3.2 and named them: reading an encrypted file takes a couple of requests and the site should have the guidance; the append mode has its own performance implications; and the immutability of the data files is what allows client-side caching of ENCRYPTED data, which is what the website and the vault web app already do. Plus a live example to point at, sgraph.ai/en-gb/library/, a high-performance site running entirely from encrypted data. FOUR NEW SECTIONS, all measured or read from published source on 21 September 2026. (1) ONE REQUEST: file ids are derived by HMAC-SHA256 over the read key under named domains (sg-vault-v1:file-id:ref, :branch-ref, :branch-index), identical constants in the CLI and the browser client, so a holder of the read key COMPUTES the address of the ref, the index and the settings before issuing any request. No discovery round trip. Reading is then a plain CORS GET with no auth header: measured 2,364 bytes of ciphertext in 0.86 s and 59,324 in 0.63 s, best of five 0.33 s. One POST to /api/vault/batch/ returned FIVE objects in 0.87 s and TWENTY objects, 3.76 MB, in 2.79 s, all in a single round trip; 42 objects returned 502, the server's response-size limit, which the CLI already handles by splitting the chunk. Encryption costs a FLAT 28 BYTES per object (12-byte nonce, 16-byte tag), confirmed on both measurements, not a percentage. And two ways to address a file, pin the content-addressed id for one GET forever, or resolve HEAD to tree to blob for always current, which is a design choice rather than a default. (2) THE 65 SECOND CLONE IS CORRECTED, because the new numbers disprove the explanation v0.3.2 gave. The clone log shows 7 commits, 28 trees and 106 BLOBS, not 42 files, because a full clone takes the history; then one batch of 50 hit the response-size limit and degraded to 50 individual fetches, which is most of the 65 seconds. The transport moved 3.76 MB in 2.79 s when asked in one request, so this is a client-side chunking bug (chunk by accumulated size, not file count) and not a property of the architecture. Said on the page in those words. (3) APPEND MODE: lanes live at bare/append/{token}/pending/, OUTSIDE the commit tree, so appends never touch a branch and never conflict with a push. A write is one account-less POST with the token in the body: no session, no read-modify-write, no commit, no tree rebuild, no lock. The response is deliberately blind (ok true, no id, no count), so the server does no extra work and leaks nothing by size or timing. Writes never contend with reads because a reader walking the graph never looks at a lane. Several anchors means several lanes, so one flooding sender cannot bury another. (4) CACHING ENCRYPTED DATA, the easy case: the cached bytes are CIPHERTEXT, so a cache is not a trust boundary and the browser cache, IndexedDB, a CDN edge and a corporate proxy can all hold vault objects without widening exposure; and an obj-cas-imm- id is SHA-256 OVER THE CIPHERTEXT, so an entry under that name can never be stale or wrong and no invalidation logic exists anywhere. Mutable refs are the exception and the failure is silent. (5) LIVE EVIDENCE: the sgraph.ai library is a 270 KB static shell (28 KB HTML plus 242 KB of CSS and components, measured) whose every article, nav entry and blog post comes out of two encrypted vaults, decrypted in the tab, with the server unable to read a word of what it serves. Its blog entries pin their content-addressed object ids in the page for a single GET, while its navigation is deliberately NOT pinned and resolves HEAD to tree to blob at runtime so it stays current. Its cache script keeps immutable objects in IndexedDB for later page loads with no network at all, collapses concurrent callers into one request, and labels every response idb-hit, inflight or network. AND A GAP FOUND WHILE MEASURING, reported rather than smoothed over: our own caching contract page says immutable objects are served Cache-Control public, max-age=31536000, immutable, and refs no-store. On 21 September 2026 the read endpoint returned NO Cache-Control header at all for an immutable object and the CDN reported a miss. The mechanism is unaffected because the client cache keys on the id rather than trusting a header, which is the more robust design, but the documented header is not live on that path today and the page now says so.
v0.3.2 2026-09-21 git 5cdd3071	A READER ASKED FOR THE PERFORMANCE NUMBERS, SO THEY WERE MEASURED RATHER THAN ESTIMATED. The question, after the fractal graphs page went out: what is the performance of this against ordinary graph engineering? /demos/fractal-graphs/performance.html answers it, and every figure on it was taken on 21 September 2026 from an ordinary cloud container against two live published vaults, using the read keys printed on their own pages. FROM THE COMMAND LINE, against the 42-file 3.2 MB DSIT vault whose graph is 617 nodes and 694 edges: full clone 65.4 s; sparse clone, meaning every path, size and hash with no content, 7.3 s and 256 KB; one 59 KB file that answers one question 0.49 s; a second file 0.87 s; the entire graph as one 1.0 MB file 1.21 s; an already-fetched file 0.18 s with no network at all. So cloning everything costs 65 seconds and answering a question costs 7.8 seconds and 315 KB. The same sparse call against the 207-file 14.9 MB Regulation Graph took 7.06 s and 360 KB, because the index does not grow with the content. IN THE BROWSER, by instrumenting the page and recording every response, so these are exact byte counts: the landing view of that 617-node graph is 94 KB in 3 requests, guidance 295 KB in 4, the graph view 1.12 MB in 5, data and queries 1.19 MB in 6, against a 3.2 MB vault that no view ever loads whole. The ontology is 2 KB, 4,217 bytes in the Regulation Graph, which is the entire price of arriving in another world and learning its rules, and that is what makes the jump affordable rather than theoretical. The 859 KB query engine loads only if you query. THE ARCHITECTURE IS NAMED: no live database, files in object storage read directly, and LETS, meaning Load, Extract, Transform, Save, where Save writes new immutable files instead of overwriting, which is why every cache in the path is correct forever and why there is no server. THE COST MODEL IS THE OTHER HALF the author asked for: zero instance hours, zero replicas, zero index memory, no separate backup line because every version is already kept, no staging copy because a clone is a clone; storage and egress only; query compute paid by the reader's own device. The whole published estate is 2,662 files and 295 MB. Cost scales with what is read, not with what exists and not with time. RUN EVERYWHERE, on one read key: a browser tab, a terminal, a serverless function, a CI container, a static host with no backend, plus fractal deployment, where the deployment unit is a set of files and a key, so putting a graph inside a regulated environment or an air-gapped machine is a copy rather than a project, and two organisations can join their graphs by exchanging an edge and a read key without either adopting the other's schema. AND SIX PLACES IT IS SLOWER, stated plainly, including the one a graph database wins outright: six hops across a hundred million edges in one schema. The commands to repeat every measurement are on the page.
v0.3.1 2026-09-20 git 85f20a76	VAULT #31, AND IT ARRIVED AT THE SAME CONCLUSION THIS SITE SPENT A WEEK REACHING. An independent reference edition of the UK DSIT AI Risk Management Toolkit, submitted under the sgit_public_read_ prefix, which is the form the credentials page now asks for and the first submission to use it. The vault models the guidance, the official workbook, the risk method and the cited frameworks as FOUR SEPARATE WORLDS with named bridges, 617 nodes and 694 edges, and states as the first of its four declared limits: 'containment alone is not fractality. Cross-world edges make the semantic transitions inspectable.' That is the same correction the author made to the fractal graphs page on 19 September, reached by a different author in a different vocabulary, so the page now cites it and the ladder gains the rung. THE HONESTY IS THE OTHER REASON IT IS HERE: every edge is labelled curated or lexical, with the limit 'lexical mentions are not validated meaning' written down; five source snapshots are retained with their URLs, retrieval dates and SHA-256; two of its eight checks exist only to prove the official XLSX and ODS bytes were not touched; and it publishes six gaps about itself, including a correction of its own earlier count (208 formula cells, not 227), a version contradiction in the source preserved rather than resolved (the filename says v1.1, the Welcome sheet says v1.0), two broken defined names left broken because repairing somebody else's document is an edit, and the refusal to read starter rows as evidence of adoption. AUDIT: no credentials, no personal data, two published DSIT institutional contacts, OGL v3.0 acknowledged, official status disclaimed on the front page and in NOTICE.md, and an all-zeros negative control that produced no clone where the real key produced 42 files.
v0.3.0 2026-09-20 git 8b46d285	TWO SITE-WIDE NORMALISATIONS THE AUTHOR ASKED FOR, AND A GUARD FOR EACH. (1) THE EM-DASH IS GONE FROM PROSE: 3,200 of them, because a good many readers now find the character off-putting. Not a find-and-replace. A rewriter classified every occurrence by context and chose the punctuation the sentence actually wanted: brackets or commas around a parenthetical pair, a colon before an explanation, a full stop with the next word capitalised where the tail was an independent clause, a comma otherwise. Code was left alone by construction, and the same exclusions were written into the validator so the two agree: pre, code, svg, fenced and inline markdown code, inline script, the assets folder, the skills folder (upstream artifacts shipped verbatim) and team/board (rendered from a vault this site does not author). FOUR BUGS FOUND BY CHECKING RATHER THAN ASSUMING: a whitespace tidy reflowed the ASCII diagrams inside pre until it was made mask-aware; the pair rule bridged adjacent table cells and left seven brackets opening in one cell and closing in another, each found by a balance check and fixed by hand; the try page's JavaScript compared against placeholder text the markup no longer had, which would have broken its terminal; and a colon in front of a conjunction reads badly, so 35 became commas. (2) THE LEGACY KEY PREFIX IS GONE: 102 published read keys under sgit_rk1_ and 24 bare ones now carry sgit_public_read_, which declares the intent. The bare ones were bare for a reason worth recording: the prefixed form used to FAIL on the CLI, which is an open brief to the CLI team. Re-running the comparison suite today closed it, all six checks pass on sgit-ai v0.16.2 including prefixed clone succeeded. Only real keys were rewritten, so documentation that names the legacy prefix still names it.
v0.2.99 2026-09-20 git 8aadadf9	THE NEWEST FOUR VAULTS WERE AT THE BOTTOM OF THE TABLE, AND THE MACHINE LIST HAD THEM AT THE TOP. The author asked for the order on the published-vaults page to be fixed. Three bugs behind one symptom. (1) vaults_table() read vaults.json directly, in FILE order, while its own docstring claimed 'the rows ship newest-first in the HTML'. Vaults 27 to 30 had been appended to the end of the file rather than inserted at the top, so they rendered last: the page opened at #26 and ended at #30. (2) The llms.txt generator sorted by ordinal and was therefore correct, which means the human table and the machine list had DISAGREED for four releases, on a page whose own footnote says the two are generated from the same file and cannot drift. (3) Found on the way: the routine that lifts each read key out of its vault page knew sgit_rk1_ and sgit_private_read_ but not sgit_public_read_, so the two keys relabelled in v0.2.98 were being published in llms.txt stripped of the declaration they had just been given. THE FIX IS ONE ORDER FOR THE WHOLE SITE: _vaults() now sorts newest-first and everything reads it, and it asserts what makes that trustworthy, ordinals unique, running 1..N with no gaps, and in the same order as the published dates. Both assertions were tested by breaking the data on purpose: a duplicate ordinal and a date that contradicts its number each fail the build by name. The homepage is untouched because its hero row and its job bands use a hand-curated order, which is why this went unnoticed there.
v0.2.98 2026-09-20 git 245934e7	WE PUBLISHED READ KEYS UNDER A PREFIX THAT DECLARES THEM SECRET, AND AN AGENT CORRECTLY REFUSED TO OPEN THEM. The author sent a screenshot: another agent, asked to inspect the two AIUC-1 vaults, declined because their credentials were labelled private read, and said it would not work around the restriction. It was right and our label was wrong. The CLI defines three current prefixes and says which is which in its own source: the private vault one is a WRITE credential, the private read one is read-only and KEPT SECRET, and the public read one is read-only and DELIBERATELY PUBLISHED. Seven published credentials across the two AIUC-1 pages carried the middle one. Relabelled to the public form, with a dated line on each page saying what changed and that the bytes, the access and the vault are identical. VERIFIED BEFORE RELABELLING, on sgit-ai v0.16.2: bare, legacy rk1, private read and public read all clone the same 699-file vault, an all-zeros key under the same prefix produces nothing, and the SG/Vault web loader strips all five prefixes in its own format module. THE STRUCTURAL FIX MATTERS MORE THAN THE SEVEN STRINGS. The validator now bans both current private prefixes in tracked files, using the same trailing-character rule the write-key tripwire already used, so documentation can still print a prefix as a NAME while a real key fails the build. check_credential.py learned the public prefix (publishable, and the form to use) and now REFUSES the private read one: read-only, leaks no capability, and still not publishable, because the label says the opposite of what publishing it does. NEW PAGE /docs/credentials/ explains the whole thing for the first time: two capabilities with a one-way derivation between them drawn as a diagram, the five prefixes in a table with publish-or-not per row, classification by declaration and never by shape (the CLI's own lesson: guessing from shape is what once misrouted a 64-hex passphrase to a read-only clone), why the word matters when the bytes do not, and what a read key can and cannot do including that revocation is never retroactive. Linked from the docs index, the nav, the gallery intake note and the publishing method. NOT DONE, AND A DECISION FOR THE AUTHOR: 99 published keys across 27 pages still carry the legacy rk1 prefix, which is neutral rather than wrong.
v0.2.97 2026-09-20 git d460cd58	THE ARTICLE THAT INTRODUCES THE TERM, WITH THE PICTURES LINKEDIN CANNOT CARRY. The author had another agent write 'Fractal Semantic Graphs: everything connects to everything, and nobody has to share a schema' from the sgit.ai page, for LinkedIn, and asked whether this site had a place to publish it with the missing images and infographics. It does: /articles/. The text is published as written, in the author's voice, with one italic line added at the top naming it the canonical copy and pointing at the page and the VoiceDebrief vault, and one at the bottom on reuse. Nine figures placed where the prose earns them: the three inline SVG diagrams rendered to images at two times scale (the zoom, the jump, the ladder), the GDPR atlas at altitude zero with its own 'you are at the top of the fractal' panel, the Regulation Graph landing view, the AIUC-1 explorer with two vaults on one canvas, the ThreatModCon zoom ladder, the role risk map, and Article 45's timeline of rulings over an unchanged article, which the article calls its favourite picture in the set. The bare URLs in 'Open them' became links, with the VoiceDebrief vault added to the list. No em-dashes; the article had none and none were introduced.
v0.2.96 2026-09-20 git 88f73d67	THE VAULT NAMED AFTER THE CONCEPT WAS NOT ON THE CONCEPT'S PAGE. Asked whether the GitHub repository VoiceDebrief/VoiceDebrief__Fractal-Semantic-Graphs was in the collection, the answer was yes: it is the plaintext mirror of vault k6xy9z4d, row 11, published on 22 August, and cloning both showed the repository's 90 content files matching the vault's HEAD file for file, both last moved on 10 August. What was missing was the reverse link. The Fractal Semantic Graphs page walked seven graph vaults and never cited the one that carries the name, the fifteen-principle register (P4 everything is a node, P6 fractal descent, P7 the junction rule, P11 altitude, P15 structure points down and meaning radiates out), the leading brief of 6 August whose sentence 'each level is the same operation applied to a larger span, which is what makes the structure fractal rather than merely nested' says in one line what this page took five revisions to reach, and the notation spec's two laws (read aloud as a sentence and decompose into triples; link to the span you compress, because claims from memory are not allowed). A new section, 'where the idea was worked first', quotes all of that with a principle-to-page table, credits the Article 9(2) example in the zoom diagram to the vault that works that provision to exhaustion, and adds the vault to the open-them table. THE VAULT'S OWN PAGE gains a mirror section: the vault practises its own guide, plaintext tree and encrypted store side by side on GitHub, three commits all on 10 August; the consequences stated are that the content is public twice over (the read key adds history and the app, not access), that the repository is a snapshot which will drift if the vault moves, and that the encrypted store is safe in the open for the reason the guide gives. The page's line saying this site 'is built' the same way now says 'was built until v0.2.84'. Counts updated: the concept card and gallery note say eight graph vaults; the graphs.sgit.ai brief asks that site to cite the principles register directly.
v0.2.95 2026-09-19 git 2724d757	THE FOLDER TREE WAS THE WRONG CONTRAST. The fractal graphs page said a hierarchy 'gives you more detail but no new meaning, because the only verb is contains'. The author's objection, in four parts: a single layer's ontology can have a very large number of verbs, each carrying meaning; as long as the links make sense inside that ontology, knowledge is gained one link at a time and it is massive; what the fractal architecture adds is the ability, on one of those links, to jump into another universe with its own rules and definitions; and what makes that fractal is that every such self-contained world is built from the same blocks, nodes, edges, ontologies, taxonomies, triplets. The test section is rewritten on his worked example, given as a voice memo: a risk register (its own rich verbs: gives_rise_to, owned_by, reports_to, mitigates, backs) whose incident fact jumps into security operations (alerts, signals, ATT&CK, attack trees), whose suspicious DNS entry jumps into the DNS estate (zones, records, every logged request; possibly millions of nodes served through an abstraction layer over SQL, a graph database or GraphQL), whose one record jumps into a packet capture. Then the two consequences he drew: every connection followed should teach you something, even 'nothing to see here', with the observer or the query deciding whether value was added; and more granularity means a better representation of reality, chosen per context, with custom views on top being what makes it scale. Plus the upward direction (all of it one node in a bigger graph, graphs composed from graphs treated as a graph all the way up, the schema itself fractal in the Mandelbrot sense). A THIRD DIAGRAM draws the jump: four worlds in a row, each a small graph in its own vocabulary, joined by a jump link on one node each, a bracket above for the bigger graph. Its texts are measured against the viewBox like the other two. The graphs.sgit.ai brief's corresponding bullet and its diagram count are updated to match.
v0.2.94 2026-09-19 git f3476af0	A BRIEF FOR GRAPHS.SGIT.AI, IN PLACE OF A FOOTNOTE. The fractal graphs page carried a small 'one wording to pass upstream' paragraph about the boundaries page on graphs.sgit.ai having the fractal test backwards. The author asked for it to go, and for a proper brief instead, since the sgit.ai page is now the fullest worked application of that site's two theses. The paragraph is gone; /docs/briefs/graphs-sgit-ai-fractal-semantic-graphs/ is the brief. It quotes the boundaries page's four-row table and shows that the page contradicts itself: the Recursion row says 'identical rules, no new format, no special case' while the author's own quote two paragraphs below says an article may be 'so meaty that it requires its own ontology and taxonomy, and that's the power of the fractal element'. Replacement text for the table, the test and llms.txt's sentence nine separates grammar (invariant) from ontology (free). Then: adopt the name and its lineage (already item 1 of their review r001, state 'commented'); lift the precise form of meaning-through-connectivity for the fractal case, 'the deeper you go the more you learn', and 'nobody is forced to conform'; six places to link the page; the two SVG diagrams and the Standards Atlas screenshots to reuse; the four graph vaults their evidence estate does not yet analyse (Standards Atlas GDPR, AIUC-1 conformance, Licence to Operate, ThreatModCon) and the AIUC-1 crosswalk join as a second cross-vault finding; three small corrections found on the way (5 versus 7 stakeholder altitudes in their llms.txt, sentinel.sgit.ai still named where sg-sentinel is the host, the vault count); a section on what not to change; and the prompt to paste, verbatim, at the end. No em-dashes in the brief.
v0.2.93 2026-09-19 git 96afb763	The fractal graphs page description, which the markdown twin prints as its blockquote, had one em-dash left; a colon now. The ', sgit.ai' suffix on every page title is a site-wide convention and stays until the site-wide pass is decided.
v0.2.92 2026-09-19 git 44f819a2	NO EM-DASHES ON THE FRACTAL GRAPHS PAGE. The author asked for the dash to go, since a good many readers now find it off-putting. Eighty-two of them on forty-six lines, each rewritten by hand rather than by substitution: a parenthetical pair becomes commas or brackets, a dash before an explanation becomes a colon, a dash before a new thought becomes a full stop, the section headings go 'Altitude 0: the law', the diagram headers take a colon, and the ladder's header takes a middle dot. The one table cell that was a bare dash now says 'not measured'. Site-wide there are about 3,300 more across 212 source files; that pass is a separate decision and has not been made here.
v0.2.91 2026-09-19 git 318e41d6	'THE DEEPER YOU GO THE LESS YOU LEARN' WAS WRONG, OR AT LEAST WRONG ENOUGH TO CONFUSE. The author read the folder-tree sentence in the fractal graphs test and asked whether it should not be the MORE you learn, since depth brings connectivity. It should, for a fractal graph, and the sentence was trying to say something narrower about hierarchies: depth adds detail but no new meaning when the only verb is 'contains'. Rewritten to say exactly that for the hierarchy, and then to state the fractal case outright: the deeper you go the more you learn, because every altitude brings its own vocabulary of relationships and connectivity compounds instead of nesting. A new paragraph puts the cross-domain behaviour precisely, in the author's words. It means one thing: the core meaning of a node is supplied by the ontology at the altitude where it sits, and that ontology is free to change between altitudes (Article 9 is a binding provision, a container of paragraphs, and a source of definitions, depending on the level you read it from), and closes with nature as the example nobody finds strange: universe, galaxy, star system, planet, ecosystem, organism, cell, molecule, atom, particle, the vocabulary changing completely at every altitude while each level stays connected to its neighbours. No schema describes a galaxy and a cell; one grammar describes both.
v0.2.90 2026-09-19 git 05c3286d	Captions on the zoom diagram shortened: panels two and three overran their columns after the v0.2.89 rewording, and the footer line was a pixel from the edge. Checked by rendering the SVG at two widths, not by eye on the source.
v0.2.89 2026-09-19 git e733f91a	THE DEFINITION HAD THE WORD BACKWARDS. v0.2.87 defined a fractal semantic graph as one where 'every node is itself a semantic graph built by the same rules', and stated the test as 'if zooming into a node needs a new format or a special case, the system is hierarchical'. The author's reading of the page caught it: same types, same verbs, same rules at every level IS a hierarchy, a folder tree, one schema all the way down. It becomes fractal at the moment zooming in lands you somewhere different: a node whose inside has its own node types, verbs and taxonomy (a new format, a special case) and that new world is still joined by an edge to the one above. Graphs of graphs, ontologies of ontologies; the plural is the point. What stays constant is the GRAMMAR (edges are verbs with inverses, meaning in connectivity, provenance kept), never the schema, and that is exactly what lets everything connect to everything without anyone being forced to conform: an organisation, a division, a person, a regulator each define their own world and connect by declared edges, not a merged schema; granularity is a per-situation decision, so a paragraph can be a mini-world with more definition than the document around it. REWRITTEN ACCORDINGLY: the lead, the 'what it is' paragraph, the three-panel diagram's captions (panel 2 is now labelled a legal ontology, panel 3 a lexical one, and the footer reads 'the grammar never changes; the ontology does'), the test paragraph, a new bullet under 'why connect everything' on every unit keeping its own world, the four-word table, the how-far lead, the ladder intro ('eleven altitudes, eleven ontologies, one grammar'), and the rule section's heading and consequence paragraph. ONE WORDING TO PASS UPSTREAM: graphs.sgit.ai's boundaries page states the test with the word 'format'; read as 'stops being a semantic graph' it agrees with this page, read as 'schema' it says the opposite, and this page read it the wrong way first. It should say 'grammar'. Recorded on the page with the date rather than silently corrected.
v0.2.88 2026-09-19 git e8edf935	THE LADDER'S RIGHT COLUMN LOOKED LIKE LINKS AND WAS NOT. Second read of the fractal graphs page: the 'why this page exists' note (the LinkedIn back-story) is gone, the page stands without it; and the ladder diagram's right-hand column was long blue monospace text that read as a row of links nobody could click. It is now two lines per rung: the vault's name as a real link (an SVG anchor, underlined, taking you to that vault's page and its read key, the Acceptance rung points at the seven-views page, the Agent rung at abp.sgit.ai) and the detail beneath it in plain grey. Twelve links, each tested by clicking it in a browser and checking the URL it landed on. The rule it re-learns: if it is blue, it must be clickable; if it is not clickable, it must not be blue.
v0.2.87 2026-09-19 git bcabde64	THE FRACTAL GRAPHS PAGE NOW LEADS WITH THE DEFINITION. The author's first read of v0.2.85 made three points: the title should be Fractal Semantic Graphs, since 'how far down does the graph go' is a section; the page must start by defining and visualising the term and the power of connecting everything with everything, down to the smallest node that makes sense for the use case (in most of ours a word, a number or a symbol); and the first screens must work for a visitor who knows graphs, semantic graphs and ontologies but has never met the FSG idea, which the author used to call 'graphs of graphs of graphs' and 'ontologies of ontologies of ontologies'. Done in that order: a lead that defines the term in three sentences; a section on what it is, with a three-panel inline SVG that zooms from a four-node semantic graph into the Law node (articles, paragraphs, an amendment as an edge) and then into one paragraph (the terms it uses, each an edge from the article that defines them), with the rules unchanged at every zoom; the hierarchical-versus-fractal test borrowed from graphs.sgit.ai; a section on why connect everything with everything, every file format is already a graph, so questions cross formats without a join table, corrections propagate instead of being republished, the smallest node is whatever the question needs, and provenance comes free when the leaf is a word tied to a byte range and a hash, with the verb rule as the discipline that keeps it from being noise; and a four-word table (graph, semantic graph, ontology, fractal semantic graph) saying what each adds and where it stops. The former opening became the 'How far down does the graph go?' section, unchanged below its heading. Title, description, nav card, gallery note and the llms.txt START HERE line renamed to match.
v0.2.86 2026-09-19 git c80e73cc	THE HISTORY PURGE, DOCUMENTED AS THE SCENARIO IT WAS. Asked to confirm the force push had really happened (it had: '+ e70d582d...b5ae665d dev -> dev (forced update)') and to write down the exact situation (files we no longer want, in every commit, on a repository with more than one branch) a new case study draws it out in ASCII: the working tree with .git and .sg_vault side by side, the remote with dev and a forgotten August branch, the 15,933 files and the 276 MB to 21 MB pack, why git rm leaves every earlier snapshot intact, what filter-repo does to every commit id (not one of 112 survived), why the push is refused as non-fast-forward and how --force-with-lease pinned to the old id turns it into a compare-and-swap. THE PART PEOPLE MISS IS GIVEN ITS OWN SECTION: reachability. The stale branch was fully merged and dated 23 August, and it still pointed at the old chain (68 commits, 6,191 encrypted files in its tree) so a fresh clone after the force push still downloaded the purged objects, old commit URLs still rendered, and one fetch re-imported the lot into a clean clone (verified by doing it). Forks and refs/pull/N/head are named as the two places a branch deletion does not reach. Then what deletion does on three timescales: clones stop receiving the chain immediately; GitHub's garbage collection makes old ids stop resolving on its own schedule, or on request to Support; clones made before keep the objects forever. Recorded plainly: the branch deletion was refused three times by the session's git proxy and is pending in the GitHub UI, so the 'still downloadable' section is true as published. The recipe is written in the order that matters, and the page opens with the rule that this was housekeeping because only ciphertext was purged, for a secret, rotate first, rewrite second.
v0.2.85 2026-09-19 git 5ebdd8af	HOW FAR DOWN DOES THE GRAPH GO? A DEDICATED PAGE FOR THE QUESTION THAT GOT THREE BARE URLS ON LINKEDIN. Asked whether the dimensions and layers had been defined 'all the way down to the EA and system configurations', the author answered with links to three vaults. The answer was right and the form was poor, so /demos/fractal-graphs/ now gives it properly: an eleven-rung ladder drawn as inline SVG from law to compute instance, each rung mapped to the published vault where that altitude is a live graph; the one grammar (every edge a verb with an inverse, relates-to banned, properties never carry meaning, supersede never delete) that makes the word fractal a testable claim; and walkthrough rows for seven vaults with their own screenshots and counts, Regulation Graph, Standards Atlas GDPR, AIUC-1 conformance, Risk Graph Explorer, Agentic Browser Isolation, Licence to Operate, ThreatModCon 2025, plus sibling cards for graphs.sgit.ai, standards.sgit.ai and abp.sgit.ai. THE NEW SCREENSHOTS ARE REAL: the GDPR atlas refuses to run outside a vault host, so a read-key clone was served locally behind a shim implementing sg.vfs over fetch, and its graph view was captured at three altitudes; the panel's own text, 'You are at the top of the fractal', is the page's epigraph. The vault's page gained those views too. THE HONEST SECTION IS THE POINT: the bottom four rungs (environment, runtime, compute) are modelled layers rather than imports from a CMDB or IaC; no published vault holds an enterprise-architecture repository as a graph; AIUC-1 crosswalks resolve at article level only; the GDPR atlas is a dated seed pass and uses the banned relates edge six times (counted from graph/edges.json: 6 of 227); standards.sgit.ai models one instrument and has zero crosswalks; abp.sgit.ai's capability grammar is a vocabulary not yet joined to a real grant. Named gaps get filled. ALSO FIXED, FOUND WHILE PURGING THE MIRROR: the footer on every page still said 'this site is itself served from an encrypted SG/Send vault', false since v0.2.76 and in fact never true of the deployed pages, which GitHub Pages has always served. It now says what is true: thirty vaults open in your browser with published read keys; the pages describing them are static files. Nav: Fractal graphs added under Vaults; llms.txt START HERE block points at the page.
v0.2.84 2026-09-19 git b5ae665d	THE SITE'S OWN VAULT MIRROR IS GONE, DELETED FROM THE TREE, PURGED FROM EVERY COMMIT, AND THE BRANCH FORCE-PUSHED. Asked whether the mirror was still needed, the answer at v0.2.83 was no: it had no reader (every session that built the site cloned it from GitHub), no published read key (the one vault on this site nobody could open), and it had been dead since v0.2.76 without the site noticing, seven releases went out over git alone and the live pages were correct throughout. It was also 258 MB in 15,933 files against 24 MB of content in about 750: 91% of the repository. The author's call was delete, with a forced push authorised. Done with git filter-repo over all 112 commits; the pack went from 276 MB to 21 MB, and the one other remote branch (fully merged, dated August) was removed so no ref kept the old objects reachable. The purge is safe for the same reason the mirror was: everything removed was ciphertext under a key that was never in the repository, and the vault itself on the server is untouched. EVERY PAGE THAT DESCRIBED THE PATTERN AS CURRENT WAS REWRITTEN: the one-tree-two-remotes case study is now a retrospective with a 'why we stopped' section and the numbers; the why page, the admin page, the git-and-vaults note, the release-engineer role and the release prompt no longer say 'both remotes'. Historical release notes were left as the dated records they are. THE TOOLING FOLLOWED: release.sh no longer requires .sg_vault or pushes sgit (it still pulls the board vault and still refuses to finish until sgit.ai serves the new version); the key-leak tripwire now reads demo vault write keys from a gitignored admin/local/demo-keys/ folder instead of the dead vault's local tier, and check_credential.py and the publishing method point there too. The release history's commit column switches from vault commit ids to git ids from v0.2.77 on, which also filled the seven PREV_UNFILLED rows the missing key had left. THE THREE PAGES IN THE VAULTS MENU WERE STALE: the demos page listed three vaults as 'published' when there were thirty, and pointed at a plan already delivered, it now leads with the gallery and keeps the three walkthroughs as walkthroughs; the catalogue, which renders a vault, turned out to hold nine entries against the gallery's thirty, so the page now says so with the date and names the gallery as the complete list until the catalogue's key holder catches up; the gallery's footer stopped calling the catalogue the place where new entries start, because for twenty-one of them it was not.
v0.2.83 2026-09-19 git 45b99758	THE ROOT LLMS.TXT WAS POINTING AGENTS AT TWO 404s, AND BURYING THE GUIDANCE IT SHOULD LEAD WITH. Asked to check that an agent reading /llms.txt finds the newest guidance, the answer was that COVERAGE was complete and ROUTING was broken. The guidance front door sat at line 149 of 239, as page entry 83 of 138, indistinguishable from installation.md, while the orientation block at the top still sent agents to /use-cases/ for 'task-shaped guidance and agent briefs', which is where that guidance lived before it moved to /docs/guidance/ and /docs/briefs/. None of the six scoped llms.txt files were advertised at all, so an agent reading the root had no way to learn that /docs/guidance/llms.txt or /demos/vaults/llms.txt exist. Fixed with a START HERE, BY WHAT YOU ARE DOING block before the page list (four entry points by intent, plus the list of scoped indexes) and the stale /use-cases/ pointer corrected. TWO BROKEN LINKS FOUND BY THE GUARD, NOT BY READING: the routing block is hand-written prose naming generated files, which is the exact drift this site warns about, so the build now asserts that every path the preamble points at is a file the build produces. It failed immediately on /docs/exposed-vault-key.md, the line telling agents never to write a vault key into a tracked file, pointing at a 404 for six months; the page is at /case-studies/exposed-vault-key.md. Widening the guard to every section then caught /security.md, referenced twice, where the page is /security/index.md. Both were 404 on the live site and the site's own validator had never looked, because it checks links inside pages and llms.txt is not a page. ALSO CORRECTED: the preamble claimed this site 'is itself served from an encrypted vault'. The vault mirror last moved at v0.2.76 and six releases have gone out over git alone, so the claim came out rather than being left to rot.
v0.2.82 2026-09-18 git bd8300e2	VAULT #30: THE SAME PACK, WRITTEN FOR AN ARCHETYPE INSTEAD OF A COMPANY. A sibling of #29 from the same generator one day later (a fractional CISO pack, two days a month on a retainer for a company that is already certified) and the interesting thing is how it solves the publication problem. #29 described a real role and WITHHELD the company, which meant auditing whether an unnamed FTSE 250 client could be inferred from what was said about it. #30 describes A TYPE OF COMPANY in six rows derived from public sources (what it does, who buys it, where the risk sits, what it has, what it lacks, who governs it) and everything after follows from the archetype, so there is nothing to redact. The rule that generalises: a document written for a class can be published; a document written for an instance has to be scrubbed. New in this one: an ENGAGEMENT document with the monthly rhythm, a twelve-month map, and a section headed 'what two days a month is not', not cover, not a DPO, not delivery, not an audit, not a substitute for a full-time hire; a one-page INFOGRAPHIC rendered from content.json rather than drawn separately, which is the page's hero because it is the pitch on one sheet; and the three 2019 decks rendered in the viewer rather than only archived. The HONEST TENSIONS section names how the offer could be misused against the buyer (cheaper than a permanent hire, and that economy can defer a hire the company needs) which a sales document rarely does. Audit run and stated: no company named or implied, no rate or tax status ('retainer' appears as a word with no figure), one public email, no secrets, read key verified against an all-zeros control. The two packs are worth reading as a pair: the same machinery giving two answers to how you publish a document about a job.
v0.2.81 2026-09-18 git 866c39dc	THE SUMMIT SHEETS GET A PREVIEW GRID, AND THEIR NUMBERS ARE DATED RATHER THAN CORRECTED. The four Lisbon handouts now appear on the parent page as four A4 previews (page one of each printed sheet, rendered from the PDF at build and shown as a card) so a reader sees all four at a glance and clicks through to the page with the table, the embed and the download. THE AUTHOR'S CALL ON THE STALE VAULT COUNT: the previous release made a point of '26 public vaults' having become 29 during summit week. The author's instruction is that the sheets are a dated record of what was said in September 2026 and should be kept as printed, so the correction became a dating note. The figures are those that were true when printed, the live table is the current answer, and the sheets are the historical one. Which is the right call: a printed artefact that gets silently re-edited to match today stops being a record of anything.
v0.2.80 2026-09-17 git 0817be5b	THE LISBON SUMMIT SHEETS, AS PAGES AND AS THE PDFS THEY WERE HANDED OUT AS. Four audience sheets (founders, startups, investors, corporate) written for a startup summit and published here with a parent page, one page each, the capability table rendered as real HTML, and the PDF both embedded and downloadable. THE PDF IS THE DOWNLOAD, NOT THE PAGE, for the reason this site keeps giving: a PDF is invisible to a search engine, to llms-full.txt and to any agent reading the site, so the content is HTML and the handout is an artefact beside it. What makes them worth publishing rather than filing is the WHAT EXISTS TODAY column, which is unflattering on purpose, 'no payment link', 'not yet packaged as its own product', 'research design; implementation not claimed', 'write-only intake built, never sold'. A capability sheet that cannot say which rows are unfinished is a brochure. TWO THINGS THE CHECK TURNED UP, both while the sheets were being handed out: the PDFs are named RiskMandate.ai while every page inside them is branded sgit.ai and every footer points at sgit.ai/network, the copies here are renamed to match their contents; and the printed line '26 public vaults' is now 29, because three vaults were published during the week of the summit. The pages here do not restate the number and link the live table instead, which is the general rule worth extracting: A PRINTED ARTEFACT SHOULD POINT AT A COMPUTED ONE FOR ANYTHING THAT MOVES.
v0.2.79 2026-09-17 git 368d47d8	A JOB APPLICATION AS A VAULT, AND THE PRIVACY AUDIT PUBLISHED BESIDE IT. Vault #29 is an interim CISO candidate pack delivered as an encrypted vault instead of a CV attached to an email. THE IDEA WORTH STEALING is that the pack is the evidence for its own claim: it says the candidate works with a team of agents and ships encrypted versioned artefacts, and it IS one, so a reviewer does not have to believe the claim, the thing in their hands is the test of it. Three routes split at the front door rather than one document compromising between audiences: the recruiter gets a submission summary to copy and answers to screening questions, the company gets eleven sections including BEFORE SIGNING, a conflict disclosure and one titled TENSIONS, and anyone gets the skills map and the history. Four documents each exist as PDF, Word, Markdown AND JSON, the fourth being the one that matters, a CV as structured data so a machine reading the pack gets fields rather than a page to parse. The pack's own build refuses what the vault authoring contract refuses, including a JavaScript syntax check of every inline script, the check that caught a shipped bug on riskmandate.ai the day before. THE AUDIT IS ON THE PAGE, not merely performed: the submitter's position was that the vault holds nothing sensitive, does not identify the company and reuses public material. Checked and it holds, client not named anywhere and described only as FTSE 250, no day rates or off-payroll analysis (removed before publication, with the removal disclosed in the brief's own editor's note), no phone or address, one long-public email, no credentials, read key verified against an all-zeros control. One point stated rather than waved through: thirteen named third parties appear in the recommendations with their 2019 titles, public twice over via LinkedIn and the candidate's own CC BY-SA 2019 deck which ships in the vault, labelled title_2019 throughout, and this site quotes the pack's framing rather than reproducing the individual recommendations.
v0.2.78 2026-09-16 git f4e330f6	THE SYNTHETIC-USER METHOD RUNS A SECOND TIME, AGAINST A SECOND PRODUCT, AND THE SECOND RUN IS THE BETTER ARGUMENT. Vault #28 applies #27's method to riskmandate.ai one day later, which matters because one run is an anecdote and two sites is a method. It is not a repeat: the first vault NARRATED and this one MEASURES, words above the fold, character offsets, scroll positions in pixels and screens. Its headline is that THE PRODUCT IS NEVER NAMED WHERE IT IS SOLD: above the fold the home page says policy six times, insure three times and underwriters once, shows a 5 pound price, and never says Agent Behaviour Policy, which first appears 58% of the way down. Two of five read 'buy one, from 5 pounds' as buying an insurance policy for five pounds, and the one who held that reading longest was the insurance professional, the reader best equipped to recognise the vocabulary and therefore the most confidently wrong. THE CLAIM WAS RE-MEASURED RATHER THAN REPEATED: the live page was fetched, rendered at the same viewport and measured independently, and every structural number reproduces to the character, 9,270 characters, first mention at 5,387, 6,481px and 7.2 screens, zero mentions above the fold. Two count lines differ and the page says why they differ rather than hiding it: a broader insur* pattern and a fold-boundary word. THE MOST USEFUL FINDING IS NOT AN OPINION: the first pass recorded a JavaScript error on EVERY page visited, both shipped, the insurance page broken since launch, and every existing test passed because the HTML still rendered and only the console knew, fixed the same session with a test added that parses every inline script and fails the build. One persona, Priya Raghavan, walks both vaults, which is what turns two studies into a comparison. NOTED, NOT FIXED: the site's sgit vault mirror is behind its git mirror, the container holding the write key was recycled, .sg_vault/local is gitignored by design, and these releases have gone out over git alone.
v0.2.77 2026-09-15 git 44323549	SYNTHETIC USERS, THE 27TH VAULT, AND THE MOST USEFUL ONE HERE THAT CONTAINS NO REAL DATA. Five invented buyers were walked through store.sgit.ai one screenshot at a time, asked what they made of each screen, and interviewed at the end: 43 steps, 15 questions the site did not answer, 10 recorded confusions and 18 findings, THREE OF THEM COSTING A SALE. THE IDEA WORTH STEALING is a deliberate handicap. The agent is handed the SCREENSHOT, never the DOM, because an agent reading the DOM finds the buy button every time and therefore finds no confusion, which is the only thing the exercise is for. The protocol is published inside the vault so two runs a month apart are comparable rather than merely sequential, 'where did you guess' is a required field, and a run with no confusion anywhere is treated as a run done badly rather than a site that passed. READ THE VIEWPORT COLUMN: the persona carrying the largest decision one person makes alone on that site did the whole thing on a 390-wide phone, and produced the most questions and the most confusion of anyone, a finding the vault never states, which falls out of the table once the five runs are counted in one place. Zero page errors across all five runs, so none of the confusion was a bug; it was the copy. Four findings are already marked FIXED and kept rather than deleted, on the stated grounds that a findings list that loses the fixed ones cannot be compared with the next set of runs, and the best fix answered a request for a number with a disclosure instead, saying the duration has never run for a paying buyer so there is no measurement to quote. CREDENTIAL HANDLING: what was submitted was a VAULT KEY, not a read key. It was classified before it touched anything, the read key was derived one-way, only the derived key is published, and the derivation was proved with an all-zeros negative control that produced an empty directory against the same vault id. The one credential-shaped string in the vault is a discount code the store publishes itself.
v0.2.76 2026-09-10 git 005361e8	THE TRANSFER API GETS DOCUMENTED, AND A DANGLING REFERENCE CLOSES. The SG/API team wrote an integration guide for sending an encrypted bundle to SG/Send and asked whether it belonged here. Checking rather than assuming turned up something worse than a missing page: the authentication reference already listed x-sgraph-transfer-delete-auth as one of its six headers, describing it as 'transfer deletion, SG/Send transfers, not vaults', while the API section documented ZERO transfer endpoints. The reference named a header for an API it never described, and the index's lead claimed the section was 'the protocol surface' while covering one of the two families on this host. Both are fixed: a transfers page now exists and the header links to it, and the lead says plainly that two families share the host. WHAT WAS TAKEN AND WHAT WAS NOT: the protocol is canonical and belongs here, the two secrets that must never be confused (an access key authorises YOU to upload and lives in a header; a decryption key authorises ANYONE to read and lives in the URL fragment, which no browser sends to the server), the SGMETA envelope that keeps the filename off the server, the three calls, the two traps in the create body (expires_at is MILLISECONDS, and max_downloads 0 means unlimited rather than none), the download_url that returns 404 so you build the link yourself, revocation that is opt-in at create time and impossible after, and the ~4 MB working limit with the reasoning behind it. The workflow half (credential wiring, node shapes, one product's bundle layout) stays with the product it was written for. The page opens with a TRANSFER OR VAULT decision table, because the useful editorial contribution is not restating their endpoints but saying when not to reach for a vault: a vault is the wrong answer for a handover that happens once. Their verification is attributed rather than adopted, every status code on the page was executed by them against production on 9 September 2026, and we have not re-run it.
v0.2.75 2026-09-09 obj-cas-imm-f21130f2246b	A BRIEF FOR THE VAULT MAP INFOGRAPHIC, WHICH SPENDS ITS FIRST HALF ON WHY NOT TO START WITH THE PICTURE. An image-model infographic of the sites was made and is good; the ask was for a companion covering the 26 published vaults, grouped by use case and industry. Two blockers sit upstream of any image, and the brief leads with both. FIRST, THE MODEL IT COPIES HAS ALREADY ROTTED: the network infographic's footer reads '19 sites, 18 published, 1 forthcoming' and its cell for skills.sgit.ai says Forthcoming, the network now lists 27 and skills has been live for some time, so a picture about a week old is wrong in its headline number and in one of its cells. The brief turns that into design constraints rather than an objection: every count computed at generation time, the image stamped with the version and date the way a vault app is, the live table linked beside it, and regeneration on the release checklist as a diff on the vault count. SECOND, NEITHER REQUESTED GROUPING EXISTS: vaults.json carries category on all 26 (which is the vault's SHAPE, not its use case) job on only 6, and no industry field at all. So the first deliverable is two fields, not an image, with closed vocabularies the build enforces and 'cross-industry' as a real answer rather than a fabricated sector. Then the accuracy rules for a model that renders text as shapes: generate the caption list from the data first and treat the image as a rendering of it, read every string back character by character, count the cells, and let no vault appear that is not in the file, a plausible invented name being the most dangerous output the process can produce. Plus the publishing rules this site already imposes: the validator bans img src, so the data-shot pipeline applies; real alt text; and the grouped list in HTML beside the picture so the markdown twin carries substance rather than a reference to pixels.
v0.2.74 2026-09-09 obj-cas-imm-0f820c930549	THE AGENT CHIP BECOMES ONE OBJECT, AND THE NETWORK CATCHES UP WITH THE ORG. The llms.txt chip shipped last release as three loose fragments (a pill, a boxed path and a long sentence) floating in dead space between the nav and the breadcrumb, belonging to neither. Four directions were drawn against the site's real tokens and one was chosen: a SINGLE BORDERED CONTROL with a tinted FOR AGENTS cell, the path in mono as the only emphasised element, and the version and date behind a dashed rule. It reads as one thing you can click rather than three things you cannot. The always-on sentence moved into the link's tooltip, it renders on all 124 pages, and as visible text it was instruction noise sitting above every headline on the site. THE NETWORK LIST WAS EIGHT SITES BEHIND. Checked against the organisation's 31 repositories rather than against memory: games, what-can-it-do.games, providers, ungovr.providers, elevenlabs.providers, teams, threat-modeling and chrome-extensions all had repositories, all answered 200, and none was listed. Each entry is written from what that site says about itself (its own title, description and version, fetched) rather than from a guess. TWO CORRECTIONS FELL OUT OF THE CHECK: skills.sgit.ai was still described here as 'GitHub Pages has not published yet, so there is nothing to read at the address', and it has been live for some time, the entry now carries its real thesis and version; and the ElevenLabs repository describes its domain as elevenlabs.provider.sgit.ai, singular, which does not resolve, the live host is elevenlabs.providers.sgit.ai. The site list is 27.
v0.2.73 2026-09-09 obj-cas-imm-5569e595ea36	THE LLMS.TXT STOPS BEING A URL YOU HAVE TO GUESS. Six llms.txt files are published across this site and the only way to find one was to type it onto the end of an address. Every page now carries a small chip above its title naming the one that covers it, FOR AGENTS, the path, and the version and date it was generated. Resolution is deepest-folder-wins, so a page under /docs/vault/ points at that section's index rather than at /docs/llms.txt, and a page with no closer index falls back to the site-wide one; every page therefore has exactly one, and it is always the most specific one that exists. THE STAMP IS THE POINT, not decoration: these files are regenerated on every release, so the chip says which release produced the index a reader is about to fetch, and an agent editing a page can see at a glance whether the index has caught up with it. The chip is chrome rather than content, emitted between the nav and the page body, so it does not reach the markdown twins and cannot drift from them. A build assertion now fails the build if the chip ever points at a folder no generator actually writes, which is the failure this feature would otherwise introduce quietly. CAUGHT BY BUILDING IT: the guidance page still SAID /guidance/llms.txt in two places after last release moved the file to /docs/guidance/, the href had been rewritten by the move script, the prose had not, so the page displayed a path that 404s while linking correctly. Fixed. A reminder that a link rewriter fixes links and not the sentences around them.
v0.2.72 2026-09-09 obj-cas-imm-92130ad84859	ONE FRONT DOOR FOR VAULT GUIDANCE, AND EVERY DOCUMENT MOVED UNDER /docs/. The guidance had accumulated across three top-level folders (/briefs, /vault and a new /guidance) which is three places to look for one kind of thing. Everything readable now lives under /docs/: /docs/briefs, /docs/vault, /docs/guidance, alongside the existing CLI docs. Fourteen pages moved, links rewritten by resolving each one through the move map rather than by prefixing , a blanket prefix would have broken every link that stayed inside the moved subtree. No redirects, by instruction: the estate is in flux and has few external users. Two hand-written .md briefs that live only in the built output, not in the content tree, were nearly lost to the cleanup and were restored from git into the new location. WORKING ON A VAULT: START HERE is the front door that did not exist, and the first thing on it is the guidance that gets repeated to agents most often: VERSION EVERYTHING, SHOW THE VERSION, LINK WHAT CHANGED. The number belongs in the app chrome, small and always visible, and it must link to that version's OWN details rather than a generic changelog; versions live in the vault as versions/index.json plus one file per version, each naming the commit it was built from and saying whether it was recorded or reconstructed. The AIUC-1 conformance vault is named as the reference implementation because it already does exactly this. Seven more practices follow, each with the failure that produced it. /docs/guidance/llms.txt is the same thing shaped for an agent: five rules, a reading order, the briefs, reference implementations to go and check, and edges out to coding.sgit.ai, nfrs.sgit.ai and graphs.sgit.ai, because a page about vaults should not try to also be the style guide, the resilience argument or the grammar of semantic graphs. The page closes by saying why it is mostly links, quoting graphs.sgit.ai's thesis back at itself: a node is just a node, meaning lives in the edges.
v0.2.71 2026-09-09 obj-cas-imm-771aa698c057	GUIDANCE NOW SPLITS BY SURFACE, AND THE THIRD SURFACE FINALLY HAS ITS OWN BRIEF. The guidance on this site had been organised by TASK (decks, markdown, file viewers) which hid the fact that every one of those questions has three different right answers depending on where the code runs. THREE SURFACES is the new router: _page.json inside a vault, an HTML vault app inside a vault, and a page on a *.sgit.ai site outside every vault host, compared on where they run, who reads the vault, which credential is used, what the reader needs, whether search engines and agents can see them at all, and, the row people get wrong, TRUST DIRECTION. Inside a vault host the host protects the reader and sandboxes the app; on a site page there is no host, you ARE the host, and vault bytes are untrusted input arriving in your origin. A second table does the same job across the three surfaces: markdown, file browsing, decks, PDFs, computing over data, and being findable by someone who has never heard of you, which only one surface does at all. READING A VAULT FROM A SITE PAGE is the brief that did not exist, for the devs coding the estate's sites. It leads with the enabling fact: the vault API answers plain CORS GETs with NO AUTH HEADER from any origin, which the server can afford because it returns ciphertext under a key it never held, so no proxy and no backend. It says do not write the reader and names the four house files to copy instead, states the inverted trust rule with a table of how to render each kind of vault content, covers the ref-caching trap that fails silently by rendering an older commit from valid ciphertext, and says what should NOT go on a site page: duplicated vault prose, a rebuilt vault app, and any arrangement where the site is the only way to read the vault. SIX GUIDANCE PAGES ARE NOW LABELLED with the surface they apply to, so the distinction is visible where someone lands rather than only on the router.
v0.2.70 2026-09-09 obj-cas-imm-0a8b264f2c4e	THE SECOND BUILD BRIEF, AND IT MOSTLY SAYS DO NOT BUILD IT. Two of the most common things an agent is asked to add to a vault, a markdown viewer and a file/folder browser with raw views, already exist in the platform, and most requests for them are answered by publishing files in the right shape and writing no code at all. The brief is therefore a DECISION rather than a syntax reference: a four-rung ladder (publish .md and stop; add a _page.json if you need a designed page rather than a document; build an app only when a view must COMPUTE something the host cannot know; build a site viewer only when the content must live outside a vault host) with the instruction to stop at the first rung that works. It names the three surfaces that render markdown natively, and the rules that actually catch people rather than the full syntax: raw HTML is stripped and shows as escaped text, images size through the pipe syntax inside the alt text, folder links must go through folder/README.md because a bare folder link resolves by sort order, nested and task lists are unsupported. THE RAW-VIEW CONTRACT, taken from a vault that already lives by it: the AIUC-1 conformance vault's own source says 'raw is the point, a catalog that asks to be trusted has to be readable in the form it was written', and the brief adopts that whole, raw always available for every file, a reader as an addition and never a replacement, the tree driven by a build-time manifest, files fetched on click. Generalised as the estate's habit: anything rendered should be one click from the thing it was rendered from. CORRECTED WHILE CHECKING THE SCHEMA: the content-authoring page said ELEVEN component types and then listed twelve. It says twelve.
v0.2.69 2026-09-09 obj-cas-imm-d896dff05cc1	THE BUILD BRIEF FOR PUTTING A VAULT'S DECKS ON A WEBSITE. v0.2.67 documented the MECHANISM, reading one file out of a vault, and v0.2.68 built the pages, but there was nothing telling another agent how to do this to THEIR vault. There is now: a build brief in the same shape as the telemetry one, which is the shape that worked when another team's agent built from it. It states the decks/v2 contract a vault must publish (the manifest and where it may live, deck sources pushing t/notes/html onto S, screenshots named symbolically rather than pathed, the CSS in the shell's style block, the PDFs), the rule that governs the whole design, A VAULT MUST BE ABLE TO CHANGE WHAT IS SHOWN AND NEVER WHAT THE PAGE DOES, the two sandboxed frames with their exact CSPs, why the deck source must be handed over by postMessage rather than baked into a srcdoc, and why a decrypted PDF cannot go in an iframe at all. It publishes BOTH BUGS we hit rather than only the finished design: the image-name pattern that excluded underscores and failed silently on fifteen slides, and the unscoped closest() that killed every button on the single-deck pages. It ends with a done-means checklist and a prompt to hand the builder. The reference page now points at the brief for anyone who arrived wanting instructions rather than an explanation. Caught in review: the .md twin rule strips inline code spans but not fenced blocks, so tag names inside the prompt failed the build, rewritten to the site's uppercase-placeholder convention, which is the third time that rule has earned its keep.
v0.2.68 2026-09-09 obj-cas-imm-b7b0f80752be	A PAGE PER DECK, A FOCUS MODE, AND SCOPED LLMS.TXT FILES. Eleven new pages: each of the nine published decks now has one of its own (four under the AIUC-1 conformance vault, five under Licence to Operate) plus an index for each vault. A deck page opens that deck alone, with the tab strip gone, and carries what the slides cannot: the level it answers, the vocabulary it introduces, who it is for, where it deliberately stops, the question it ends on and which deck picks that question up. Each has a NOTES ON THIS DECK section that is deliberately empty and says so, that room is the reason a deck deserves a page rather than a tab. FOCUS drops the slide list so the stage takes the full width, for presenting and for screen recording, and the stage is re-fitted rather than merely revealed. A BUG THE PER-DECK PAGES EXPOSED IMMEDIATELY: the mount element carries data-deck on a single-deck page, and the click router used an unscoped closest('[data-deck]'), so it matched the mount for every click inside the viewer, prev, next, notes, focus and the PDF button were all silently dead on exactly the pages just built. Scoped to the tab strip. SCOPED LLMS.TXT: /demos/vaults/llms.txt is the catalogue as an agent index (all 26 vaults with id, category, published date, size, file count and published read key) generated from vaults.json, the same file the table on that page is built from, with each read key lifted from the vault's own page rather than kept in a second list that could disagree. Vault keys appear nowhere, as always. Three more sections got one: /vault, /api and /docs.
v0.2.67 2026-09-09 obj-cas-imm-daf0dde2fed2	DECKS AND PDFS READ STRAIGHT OUT OF A VAULT, WITH THE VIEWER OWNED BY THE SITE. The vaults publish presentations (four on the AIUC-1 conformance page, five on Licence to Operate) and until now the only way to see them was to open the vault's own app. They now play on the vault pages themselves, fetched as ciphertext with the read key already printed at the top of each page and decrypted in the reader's browser. THE SPLIT IS THE POINT: from the vault come the manifest, the slide sources, the speaker notes, the screenshots and the printed PDF; from the site come every control you can click (deck tabs, slide list, prev and next, notes, the PDF button, the deep links) so a vault decides what is SHOWN and never what the page DOES. Vault content reaches the page through two opaque-origin frames: a deck builds its slides by running JavaScript, so it runs in a sandboxed frame with default-src none and posts back a plain array, and the slide markup then renders in a second frame with scripting switched off entirely. WHY THE PDF IS A DOWNLOAD, MEASURED RATHER THAN ASSUMED: Chrome refuses to render a PDF in a sandboxed frame at all ('failed to load as a plugin, because the frame into which the plugin is loading is sandboxed') tested across every sandbox combination, so an inline PDF would mean handing vault bytes this origin. The bytes are decrypted in the page and handed to the browser's own download instead; a 2.1 MB PDF arrives byte-identical. Two published deck shapes are handled, because the two vaults differ: one shipped its sources, the other only its built decks. A REAL BUG FOUND BY WALKING EVERYTHING: the first image-name pattern excluded underscores, so fifteen slides rendered with a silently missing screenshot and no error anywhere, all 113 slides across the nine decks are now walked in the browser test, and the count of missing images is zero. New page: READING ONE FILE OUT OF A VAULT, the primitive under every live embed here, written down on its own with the sandbox rules for what comes back.'
v0.2.66 2026-09-09 obj-cas-imm-d2f92005581d	THE SHORTS PAGE REWRITTEN FOR SOMEONE WHO ARRIVES WITH NO CONTEXT. A video page is a landing page whether or not it was designed as one: traffic comes from a feed, lands on it directly, and has never seen the vault, the site or the argument. What sat above the seven players was an apology about missing transcripts and a note explaining why a row number in the table could not go stale, two pieces of internal housekeeping addressed to readers who already knew everything the page had to sell. Both are gone from the top. In their place: FOUR WORDS, AND THE GAP BETWEEN TWO OF THEM, grant, mandate, delta, licence to operate, defined in a table with the counts from the demo beside each (12 capabilities, 4, 8, priced per turn), so the whole model is legible before a single video plays. Then two calls to action, in the order a cold visitor needs them: OPEN THE VAULT, with its read key printed as the whole credential and both routes offered (its page here, or straight into the vault UI); and RISKMANDATE.AI, named as where this goes commercially, the business risk layer for autonomous systems, every autonomous system mapped to its blast radius, given a business owner and driven to a time-bound decision: accept, fund, or fix. The vault is the demonstration; RiskMandate is the product it demonstrates, and the Risk Graph Explorer is the same engine already published as a vault. THE TRANSCRIPT GAP IS NOT HIDDEN, IT IS RIGHT-SIZED: still stated in the footer, in one sentence, with the board card still open. A gap worth disclosing was not worth the first screen. Nothing changed about the seven videos, their order, or the three movements.
v0.2.65 2026-09-09 obj-cas-imm-9407711950c8	SEVEN SHORTS ON THE LICENCE TO OPERATE VAULT, INDEXED AND PUT IN ORDER. The author recorded a vertical-video series walking through vault posrhzp3; none of the seven was on the site. They now have a page under the vault, collected in the order they are meant to be watched rather than the order a feed would show them: THE MECHANISM (1-3: grant against mandate, what a block looks like, who in the organisation accepts which risk), THE ARTEFACT (4: how to find and open the vault, the one to send someone who wants to poke at it), THE MODEL (5-7: the gap as the place risk lives, the insurance framing, then policies, claims and premiums). Each carries the author's own description, lightly edited, plus a line mapping it to what it demonstrates in the vault or the estate, the delta for 5, the AIUC-1 conformance layer's insurability query for 6, risks.sgit.ai's no-deny-button position for 7. WHAT THE PAGE REFUSES TO PRETEND: these are descriptions, NOT transcripts. All four of YouTube's timedtext endpoints return empty for every one of the seven, so there is no caption track to pull and the words spoken are absent from the site, from llms-full.txt and from the chat pane's read_page tool. That is the exact failure the risk-graph-explorer walkthroughs page was built to avoid, so the gap is stated in a box at the top, measured rather than guessed, and opened as board card T12. A NUMBER THAT CANNOT ROT, DEMONSTRATED: video 4 tells the viewer to look for 'Vault #23'. Checked, Licence to Operate is still #23 and always will be, because v0.2.58 made that column a permanent publication ordinal rather than a row position. A recorded video naming a row number would have been stale within a day; naming an identity is safe. Embeds go through youtube-nocookie.com with loading=lazy, so opening the page sets no YouTube cookie until somebody presses play. New portrait 9:16 player CSS, since the existing .vembed is a 16:9 box and a Short in it is two black pillars.
v0.2.64 2026-09-07 obj-cas-imm-80636cf90122	THE BOARD MOVES INTO A VAULT OF ITS OWN, AND ITS READ KEY IS PUBLISHED. Two releases after the board appeared as files in the site repository, it was clear the shape was right and the home was wrong: moving a card from review to done cost a full site release. So the seventeen cards moved into vault pdulwi6i, issues/<id>-<slug>.md, a README with the card format, a five-column board app (index.html, permissions {}) that lists issues/ through sg.vfs and falls back to issues/index.json when served outside a host, and tools/reindex.py to regenerate that index. THE VAULT IS THE TRUTH; THE SITE IS A READER: release.sh now pulls the vault before it builds (step 0), the loader reads admin/content/team/issues/issues/, which IS the vault's working tree, cloned in place with its encrypted store gitignored and its card files tracked as the build's input, and the board page labels its columns as a snapshot at the site version, with the read key and one open-live button above them. Moving a card is now sgit push, and the board is live the moment it lands; the site catches up at its next release. PUBLISHED AS ROW #26 on the vaults table with its own page, following the method: the write key escrowed in the gitignored tier, the audit run (nothing secret-shaped beyond the read key in its own README), the app screenshotted by driving it, permissions stated. The Sherpa's board prompt and the team page's 'where things are' now point at the vault. One design note: the app works in two places on purpose (under a vault host it reads the files directly and needs no index, served flat it reads the index) because a board that only renders inside one host is a board nobody can screenshot, test or read from a script.
v0.2.63 2026-09-07 obj-cas-imm-d523226f4c7a	A CHAT PANE ON EVERY PAGE WHOSE MODEL CALLS TOOLS OVER THIS SITE'S OWN CONTENT. Asked for the pane the sibling sites have; built the stronger version of it. 'Ask this site', bottom right of every page, three tiers like the network chooser. TIER 0, no key: seven tools run directly in the page, type words to search everything (pages, vaults, sibling sites, release notes, board cards), or /vaults, /sites, /updates, /board, /read PATH, /here, instant, private, no network after the index loads. TIER 1, bring-your-own OpenRouter key: the model is handed the same seven tools as OpenAI-style function definitions (search_site, read_page, list_vaults, list_sites, latest_updates, get_board, current_page) and calls them; every call executes HERE over the build-emitted index and the .md twin of any page, so the model can only say what a tool returned, and THE PANE SHOWS EVERY CALL IT MADE as a trace line. Up to six tool rounds, then a plain-prose answer ending in the paths it used, as links. TIER 2, sg.llm inside a vault, is detected-not-wired and on the board as T11, blocked on one fact about the bridge's tool contract. THE INDEX is assets/site-index.json, written beside llms.txt from the same data as the vaults table, the network directory, the feed and the board, one derived file, so an answer in the pane is an answer the site already gives somewhere. LOADED THROUGH THE BOOT BLOCK after site.js, by the same vfs-or-fetch loader, with the loader exposed as window.__sgitBoot so the module resolves the index and the twins the same way on a blob: origin; never a script src. The key goes to openrouter.ai and nowhere else and the pane says so in the same words the chooser uses. Model output is escaped and links are allowed only to http(s) or paths on this site. The validator now parses the chat modules too. The chat-on-a-static-site article gains an addendum and its 'shared component: not started' row becomes 'partly': one site's copy, not yet the versioned module the other eighteen could load.
v0.2.62 2026-09-07 obj-cas-imm-e27526f11c99	TWO SECTIONS: THE TEAM, FOR THE AGENTS; AND INVESTORS, IN THE OPEN. Asked for a full agentic section briefing agents on how to work on this site, with roles and pages like the sibling sites, a board like the ones done before, and the starting prompts for the regular work, plus an investor section on the same open-materials model the founder's other companies use, for an event next week. THE TEAM (team/): nine roles, each a file under admin/content/team/roles/ with mission, what it owns, what it must not touch, the files it works in, the checks it runs, the rules it enforces WITH THE MISTAKE THAT PRODUCED EACH, and a starting prompt; the grid and the nine pages derive. The roles mirror the Explorer team in the CLI repo, specialised for running a site: Sherpa, Publisher, Auditor, Journalist, Cartographer, Ambassador, Designer, Release engineer, Historian, the Publisher and Auditor exist because this site publishes read keys on purpose. TWELVE STARTING PROMPTS (team/prompts.html) for the work that recurs, publish, audit, update, article, sibling site, inbound brief, release, phone bug, markup-to-data, correction, board, read-key sweep, each written to be pasted into a fresh agent, each ending before the release step on purpose. THE BOARD (team/board.html): issues as files under admin/content/team/issues/, five columns rendered from a status line, Needs (only the author can supply) kept apart from Tasks, in the spirit of issues-fs.sgit.ai and the comms board on open-source.sgit.ai; seeded with sixteen real items including the six things only the author can answer. INVESTORS (investors/): the structure of investor.myfeeds.ai, problem, what it is, architecture, traction, business model, market, the ask, use of funds, what could go wrong, materials, with traction COMPUTED from the site and THE ASK LEFT VISIBLY OPEN in a dashed box tracked as board item N1, because nothing on that page may be a number the founder has not supplied; the business-model section quotes the founder's published open-source position through a sibling-site card rather than restating it. NAV: Try folds into Docs; Why becomes a group (Why, Investors); Team is a new group (overview, roles, prompts, board), eight top-level items, as before. TWO BUILD LESSONS: the content loader gained a generic one-file-per-thing reader (roles and issues are three lines each); and angle-bracket placeholders inside code spans broke the markdown twin twice while being regex-wrapped, so the whole team section uses UPPERCASE placeholders with no angle brackets, one convention, every renderer. Verified: 105 pages, validator clean, no overflow at 390 on any new page.
v0.2.61 2026-09-07 obj-cas-imm-595486afe042	A CORRECTION TO THE RELEASE BEFORE IT, CAUGHT BY COUNTING. v0.2.60's article, its update post and its version-log entry all said the homepage went from nine bands to eight. It did not: git show of the previous content file counts nine sections, the new one counts nine, three were cut (features folded into the walkthrough, the abstract use cases, the three doors) and three were added (the hero vaults, what people ship, the team). What changed is the ORDER and the first screen, not the length; words went 1,370 to 1,332. The claim was written from memory of the plan rather than from the file, which is exactly the failure this site says it does not permit, so all three places now carry the corrected count and the article says in its own text that it was corrected and why. Second catch, same class: the update post restated the team band's four numbers in prose and was off by one within the hour, because a release had happened; the prose now names the numbers without repeating them. Nothing else changes.
v0.2.60 2026-09-07 obj-cas-imm-19a2bbeb1375	THE HOMEPAGE REBUILT: PROOF BEFORE MECHANISM. Follows the diagnosis published in v0.2.59 rather than a fresh opinion, so the two can be compared, and the 'after' article puts each new band beside the screenshot of what it replaced. HERO: the sentence changed from 'the encrypted git for humans and AI agents' to 'a vault is a unit of work: data, app, history and sources, shipped as one string' (encryption becomes the subordinate clause, which is where a property nobody can look at belongs) and FOUR REAL VAULTS sit directly under it, screenshot each, one click from open, chosen by a hero field in vaults.json so changing the front door is a data edit. NEW BAND 'what people actually ship': six vaults chosen by the JOB they do (hand over a report, publish a standard as data, give a talk, pitch an investor, ship a game that reports back, give an agent a workspace), each with one line on why it is hard any other way, and none of those lines is about encryption. NEW BAND 'one human, a team of agents': four numbers COMPUTED at build (releases from the version log, vaults from the data, sites from the network directory, briefs by counting the briefs page) and the collaboration loop told in three beats with the artefacts linked. CUT: the abstract use-case band (the pages remain, in the nav), and the 'three doors' band (now one pill in the trust strip pointing at the page that already explained it). MOVED DOWN: the terminal walkthrough, under a heading ('under the hood, it is git') because for a visitor who has just opened a real vault, how is now the question; it gained the feature card 'apps live inside the data', which was never on the list. The band count did NOT change (nine before, nine after; three cut, three added) so what changed is the order and the first screen, not the length; bytes went UP because ten screenshots replaced paragraphs, words went down 1,370 to 1,332. IMAGES GO THROUGH shots.js, never a static image src attribute: the validator refuses a static src because a relative one does not resolve inside a vault, and the build injects the loader wherever data-shot appears. Card text carries hidden separators so the .md twin reads 'Reference, name, line, open it' instead of one run-on. ONE CORRECTION CAUGHT BY THE COMPUTED NUMBER: the network heading had been retyped as 'Twenty sites' while the tile said 19. The tile was right (nineteen siblings; twenty with this one). THE GAP STANDS: no published vault yet shows two agents on one vault with a human merge, and the team band is written not to pretend otherwise. Verified at 1400 and 390 wide: 10 figures loaded, 0 failed, no horizontal overflow.
v0.2.59 2026-09-07 obj-cas-imm-ddba86527bec	THE DIAGNOSIS BEFORE THE REBUILD, PUBLISHED AS AN ARTICLE, AND A CARD FOR POINTING AT THE SIBLING SITES. Asked to step back and say how the site should present the twenty-five vaults, the answer was a diagnosis before a redesign: the homepage leads with encryption, which cannot be looked at, and a terminal walkthrough of commands every git user has seen; the twenty-five artefacts a stranger can open in one click sit two clicks away as a table; the use cases are categories while concrete examples of each exist one level down; and the strongest story, agents building for agents, a brief published here turned into a vault the same day and reviewed by the team that owns the API, is filed under Docs as a log. One gap named plainly: the homepage's strongest multi-agent claim, a branch per agent and a human merge, has NO published vault behind it. The article carries the evidence as screenshots of the current site, captured before anything changed so the 'after' article can be compared against them honestly, and sets out the fix in order: proof before mechanism, reorder and cut rather than add. NEW DIRECTIVE, !site, a card for referencing a page on another *.sgit.ai site. Author writes host \| path \| title [\| line]; the card pulls that site's category and thesis from its entry in the network directory, so it describes the site the way the site describes itself, and carries a 'part of the sgit.ai network' cue a bare link cannot. The whole card is the pointer target via the title anchor's ::after, so the markup stays a plain link for the .md twin and for screen readers. Debuts in the article pointing at open-source.sgit.ai/about, which is also the decision recorded there: this site gets an About page about sgit, and links to the fuller record rather than duplicating it. An unknown host degrades to host + title with no lookup.
v0.2.58 2026-09-07 obj-cas-imm-b61899966f9d	THE SG/API TEAM REVIEWED OUR BUILD BRIEF AND FOUND IT WRONG, SO THE CORRECTION IS NOW MORE PROMINENT THAN THE MISTAKE. Two days after v0.2.55 published the telemetry brief, an agent built the games vault from it and could not get events out. The team that owns the append code read it against the brief and returned a line-referenced review. Both of the things this brief told a builder to VERIFY, it had already answered wrongly. (1) We said sg.append.write fails closed in a read-only session: it does not, there is NO read-only gate on append anywhere, and permissions.append.write is the entire requirement. (2) We steered to a direct fetch instead, which is blocked by the frame's default connect-src blob: data: escapable only by permissions.network, which the reviewer notes appears 'zero times' in the authoring guide and zero times here, and which is the WRONG fix because it reopens every egress from a frame holding decrypted vault content. The brief now recommends the bridge, carries the correction in a box above the original section, and its hand-to-the-builder prompt is reversed. THIS RESOLVED AN OPEN FINDING: the games vault's telemetry is built and never sent, because its app.json declares no permissions at all, which matches the author's report that nothing arrived, and replaces the 'unresolved' note we published rather than guess. Its page now leads with that status instead of claiming it phones home. THREE FACTS THAT EXISTED NOWHERE PUBLIC are now on the API reference: only write takes a vault_id while the other five verbs bind to the currently open vault, so cross-vault listing is impossible by design; fetch maps to append.read, not append.fetch; and the inbox field in a listing is the lane folder, which today is the raw append token while config stores its hash. A follow-up of seven questions went back, which hosts serve the append routes, whether the enum-key derivation is stable enough to publish as a spec, and whether any non-destructive way exists to tell an append token from a read key, since they are the same shape and confusing them would be a serious leak. THE # COLUMN IS NOW AN IDENTITY, NOT A ROW POSITION: it was renumbering 1..25 on every sort, which said nothing. It is a permanent publication ordinal, 1 is the first vault ever published here, so it never changes, and sorting by it is by construction the same order as sorting by date. Asserted in the check rather than eyeballed.
v0.2.57 2026-09-06 obj-cas-imm-27f13ad369ff	THE VAULTS TABLE STOPS BEING A KEY DUMP AND BECOMES SOMETHING YOU CAN SORT. Reported from an iPad, where the failure was obvious in a way it never is on a desktop: the read-key column is a 64-hex string, and giving it room squeezed the vault id down to ONE CHARACTER PER LINE, 'ookq4mn4' rendered as a vertical stack. The fix was not narrower columns, it was noticing that the two widest columns were the two nobody needs on an index: the read key and the 'open live' link are both already on each vault's own page, one click away. So the index now answers 'which of these do I want' and the vault page answers 'how do I open it'. GONE: read key, open live, and the dense contents blob. NEW: a # column, a one-line WHAT IT IS, a CATEGORY pill (8 categories over 25 vaults), files and size as separate numeric columns, and a PUBLISHED date. CLICK ANY HEADING TO SORT, default newest-first because the recent ones are the interesting ones. The count line states the total and the category breakdown, which is worth seeing on its own. GENERATED, NOT HAND-WRITTEN: 25 hand-written table rows could not be sorted, counted or kept consistent, so the table comes from admin/content/vaults.json through a VAULTS comment marker, the same mechanism the homepage articles band uses. The published date is NOT a date anybody typed. It is the commit date on which each vault's page first appeared in git, recovered with git log --diff-filter=A, after two weaker sources were tried and rejected: update posts missed ten vaults and false-matched health-score against a later release that merely mentioned it, and the version log had no line for two of them at all. SORTING IS PROGRESSIVE ENHANCEMENT: rows ship newest-first in the HTML, so with JavaScript off the table is still correct and still in the most useful order; the headings are keyboard-operable. On a narrow viewport the 'what it is' column drops out rather than wrapping to nothing, because that sentence is on the vault's page too. Verified at 1280 and 390 wide: 25 rows, zero 64-hex strings on the page, zero 'open live' links, no horizontal overflow, and sorting checked by asserting the order actually flips.
v0.2.56 2026-09-06 obj-cas-imm-dd4f74725ece	THE BRIEF CAME BACK AS A VAULT, AND IT IS THE FIRST ONE PUBLISHED HERE THAT PHONES HOME. Two days after v0.2.55 published the build brief on telemetry from a published vault, another agent read it and shipped the thing: two deterministic games about grants, permissions and mandates, sending anonymous usage events over an append lane to a separate private vault. That makes this the first end-to-end test of whether a brief written for an agent produces what it describes, and the answer is yes, including the part the brief was least sure about: it took the FALLBACK path, a direct fetch to the account-less write endpoint with credentials:'omit' and keepalive on the final flush, rather than sg.append through the bridge, which is what the brief said to do if a read-only session fails closed, and app.json declaring no permissions key at all is consistent with that. CREDENTIAL AUDIT, run against the brief's own claims rather than the vault's self-description: no private keys, no enum/write/vault/read key fields, no third-party secrets, no personal data, and EXACTLY ONE 64-hex string in the whole vault, the append token, in five places. It was tested rather than trusted, because an append token and a read key are both 64 hex and a mistake between them would be invisible: cloning the telemetry vault with it yields no clone_mode.json and decrypts nothing. A METHOD CORRECTION THAT COST NOTHING ONLY BECAUSE THE CONTROL WAS RUN: the first version of that test called a LEAK on the strength of sgit clone creating a directory, then an all-zeros key produced the identical result, proving the directory is created regardless and the test discriminated nothing. The marker that actually discriminates is .sg_vault/local/clone_mode.json. Any credential test that has no negative control is not a test; this now goes in the publishing method. TWO FINDINGS PUBLISHED RATHER THAN FILED: (1) two of the four pages still tell the player 'nothing sent', what-can-it-do was fixed to say 'nothing stored', the home page and which-agent-is-it were missed, and the latter contradicts itself on a single screen; nothing leaks, but the subject of the vault is informed consent, which raises the stakes on leftover copy. (2) The write endpoint could not be confirmed from this container, 404 on both hosts under both the append and inbox names, while inbox/list returns 403 on production, which our own API page says is gone. One data point, recorded as unresolved rather than dressed as a conclusion. Screenshots were captured with the telemetry aborted at the network layer so photographing the games did not put junk in somebody's real lane.
v0.2.55 2026-09-06 obj-cas-imm-5e5e76eaf7d0	BRIEFS BECOMES A SECTION WITH TWO KINDS IN IT, AND MOVES FROM EVIDENCE TO DOCS. The /briefs page has been a single scroll of cross-team asks since v0.1.13, each addressed to another team, each with a status, each closing when answered. A brief arrived that is a different species: not a request to anybody, but a durable reference an agent executes, on how one vault sends messages to another and how a vault whose read key is public reports anonymous usage back to its author. Filing it as another ask would have been wrong, so the page now declares the two kinds and separates them: BUILD BRIEFS (executed, never close) above CROSS-TEAM ASKS (addressed, status-tracked), with the seven existing asks untouched and demoted one heading level. The new group starts with two entries rather than one, because demos/vaults/publishing.html was already a build brief, 'written to be followed by another site's agent', misfiled in the vaults section where nobody looking for a method would find it, the same misfiling that created case-studies/ in v0.1.14. It stays at its URL and is listed from both places. NAV: Briefs moves out of the Evidence group and into Docs, beside Skills, the section's centre of gravity is now agent-facing documentation rather than a collaboration record, and Docs is where an agent looks. Evidence keeps comparisons, case studies and use cases. ONE EDITORIAL CALL WORTH RECORDING: the source brief opened by answering 'is there a doctor/patient case study for this?'. There is not; the health-score vault is one vault with three audiences, not two vaults messaging. In the repo brief that section earned its place because the question was asked. On a published page the reader never asked it, and listing that vault among the pages to read implies it is a source for cross-vault messaging, which would send the next reader somewhere useless. Cut from the reading list, kept as one line of signposting, because the health-score vault is exactly where somebody will go looking, and a named absence beats a hidden one.
v0.2.54 2026-09-05 obj-cas-imm-f56c7c51361e	THE AIUC-1 VAULT, FORKED AND LAYERED, AND TWO PAGES FOR TWO ARTEFACTS, ONE ROW ON THE LIST. Vault 2wzct4k7 arrived as an updated version of the AIUC-1 catalogue (hq21tlqu) and the first instinct was to replace the page. Reading its own CONFORMANCE.md changed the shape: it copies every byte of the catalogue and adds one directory above it, answering a DIFFERENT question, not 'what does the standard say' (evidenced_by) but 'does this subject do it' (attested_by), and then what would be insurable on a given date. Two artefacts, not two versions. So the catalogue page stays exactly as it was, carrying a note that names the fork; the fork gets its own page; and the vaults table carries ONE row , the fork, whose description links back to the catalogue page, because a table of published vaults is a list of things to open, not a changelog. VERIFIED RATHER THAN REPEATED: the fork's claim is that it did not edit what it copied, so before publishing we ran both suites in the clone, the catalogue's tests/run.py reports 21/21 passed, including the one that rebuilds every source document to the word, and the layer's tests/test_conformance.py reports 19 tests, 0 failed. Neither opens the network. That is the difference between quoting a vault's self-description and checking it. Audit clean: no vault keys, no third-party secrets, no personal data; the two sgit read keys inside it are both already published here by design (regulation graph, Risk Graph Explorer). Four screenshots captured against a local clone rather than the live host. One correction to a claim we nearly made: this is NOT the first vault here to ask for a permission, the VoiceDebrief pitch and Licence to Operate got there first, but it IS the first to ask for a WRITE grant (fs.write scoped to chat/ and nothing else) and the first to ask for the sg.llm bridge, which is the more interesting claim anyway.
v0.2.53 2026-08-27 obj-cas-imm-d889737f4500	ONE OPEN BUTTON PER VAULT PAGE, NOT THREE. Reported from a phone, which is where it actually hurt: the three pages carrying the open-in-a-new-tab button (AIUC-1, VoiceDebrief pitch, Licence to Operate) placed one under the lead, one above the embed and one at the foot. On a narrow viewport the first two sat within a single scroll, separated only by the read-key note, two identical full-width buttons doing the same thing, which reads as a layout bug rather than an offer. Reduced to ONE per page, positioned immediately above the embed, because that is the only point where the reader is genuinely choosing between the frame and a tab; the caption there now carries the REASON that had been sitting on the button removed above it ('a full application', 'a presenter app', 'an interactive simulation'), so nothing was lost by deleting two thirds of the buttons. The early exit is still available and always was: all 24 vault pages carry 'open it read-only in a new tab' as a text link inside the read-key note, which is what made the button under the lead redundant twice over. Verified at 390x844 with a mobile user agent rather than by eyeballing a desktop render: one button per page, no horizontal overflow, text link present. The general lesson, since this will recur as more vaults arrive: repeating a call to action is only helpful when the repetitions are far enough apart that a reader has forgotten the first one, at one scroll's distance it is just clutter.
v0.2.52 2026-08-27 obj-cas-imm-618e386c76b0	LICENCE TO OPERATE, an insurance policy for an agent, simulated, and the 24th published vault. THE IDEA WORTH STEALING IS THE DELTA: the grant is what the agent CAN do (12 capabilities), the mandate is what the user expects and the only thing the policy insures (4, crm:read, kb:search, llm:generate, mail:draft), and the delta is the 8 that sit inside the agent's reach and outside its authority with no policy covering them, including crm:write, crm:export, mail:send and shell:exec. The mandate is 'answer a customer's question from their own record and the help centre, and draft, never send, a reply'; the grant includes shell:exec. That is nhi.sgit.ai's blast-radius argument made COUNTABLE, and priced rather than described. The simulation makes a reader spend it: three replies per turn, each showing its cost before commitment (in band, claims against the pool, or outside cover) over a live rate table with a normal band, an ask-above threshold, an untouchable reserve and customer records marked uninsurable above 20. ARCHITECTURE PROVED BY THE GRANT: the vault holds the terms and the browser holds the run, and app.json requests fs.read plus downloads (READ, NO WRITE, AT ANY PATH) so an app that simulates spending against a policy is structurally incapable of editing the policy it spends against. INTAKE: the credential submitted was a VAULT KEY in the legacy passphrase form, not the read key the handover was written for, the classifier refused it, the read key was derived, and only that is published. PROCESS NOTE WORTH KEEPING: the authoring agent supplied its own audit of all 16 commits, and it was accurate, but it was CHECKED rather than accepted. Three claims re-verified against a fresh read-key clone: no credentials or third-party secrets (confirmed), the /home/claude/ build paths baked into the PDF are gone (confirmed, zero occurrences, fixed upstream in v0.3.1), and the single full-length credential in the vault is the vault's OWN read key, established by deriving it independently and matching it byte for byte rather than by trusting the label on it. That check briefly looked like a finding, which is the argument for running it: a supplied audit is evidence, not a substitute for the check.
v0.2.51 2026-08-27 obj-cas-imm-a13b6654c800	A PITCH DELIVERED FROM A VAULT, and the first non-empty permission grant on the site. The VoiceDebrief pitch to Founder Institute (2 Sep 2026) is the 23rd published vault and the first that is a live presentation rather than a document set: opening it launches a presenter app with twelve timed slides, a 3:00 countdown, speaker notes, Focus and Fullscreen, five backup Q&A slides, one of which is titled 'WhatsApp / ChatGPT already does this', the obvious objection answered rather than avoided, and a Materials view over everything else. What makes it a vault rather than an export is that the WORKING ships with the conclusion: the approved outline and its claims-to-keep-exact list, the spoken script per slide with timings, the fifteen-part pitch pack, the research notes, the product screenshots and the PDF/PPTX exports, with the deck itself generated from deck/src/deck.template.html by a script in the vault rather than hand-maintained. THE PERMISSION STORY IS THE REASON IT EARNS A PAGE: every other vault here declares permissions {}, and this one declares downloads:true and externalLinks:true, it offers PDF and PPTX buttons so it asks for downloads, it links to the live product so it asks for external links, and that is the entire request, with NO FILESYSTEM ACCESS AT ALL at any path. One readable line that maps one-to-one onto two visible affordances is the permission model working as intended, and it reads better against the Risk Graph Explorer's empty grant than any amount of explanation. AUDIT: credentials and third-party secrets clean. Three disclosures are named on the page rather than left to be found, since a fundraising deck is a different category from the rest of the estate, the unit economics and commercial terms, the author's contact address on the closing slide, and the THREE NAMED JUDGES of the session with their affiliations. That last one was checked before publishing rather than after: the sources were read for tactical notes about the named individuals and contain none, only names, roles and affiliations, which is the difference between publishing a fact about a public event and publishing research about people.
v0.2.50 2026-08-27 obj-cas-imm-2de78eaae20b	OPEN THE VAULT IN A NEW TAB, and a path that sent a reader to a 404. The AIUC-1 catalog is a full application and has far more room in its own tab than in the embedded frame, so the page now carries a prominent button at the three points where a reader is actually deciding whether to leave: under the lead, at the embed, and at the end. All three open in a new tab with rel=noopener, verified in a browser rather than assumed. THE 404: the page referred to `NOTICE.md` and `docs/source-policy.md` as bare filenames, and a reader reasonably went looking for them in a GitHub repository, where they do not exist, checked, the CLI repo has no docs/ directory at all and zero matches for source-policy. Those files live INSIDE THE VAULT and nowhere else, which is the whole point of the vault, and the page now says so at the point of reference. Worth recording because the site itself was not at fault: sgit.ai renders both as plain <code>, never as links, in the HTML and in the .md twin, the failure was that a filename with no stated home invites a reader to guess one, and a guess against a repository is the obvious guess. Naming the container is part of naming the file.
v0.2.49 2026-08-27 obj-cas-imm-133059705000	AIUC-1 AS A CITABLE GRAPH, an unofficial, derivative machine-readable catalog of the public AIUC-1 agent standard, and the twenty-second published vault. 53 controls, 144 requirements, 1,126 crosswalks to 13 external frameworks, 1,238 nodes and 3,526 edges over five releases, with every field naming the official page or commit it was read from, the SHA-256 of the retrieved bytes and the retrieval time. A control renders as its EDGES rather than a property bag (has_requirement, maps_to, evidenced_by, applies_to_capability) which is the graphs.sgit.ai grammar applied to a compliance standard. THE BEST THING IN IT IS A REFUSAL: it publishes the five places where the official website and the official changelog repository disagree, classifies each as presentation rather than meaning, and declines to resolve them, 'resolving one means choosing a source, and that is not this build's to choose'. A derived artefact that silently picks a winner has stopped being derived and become an opinion the reader cannot detect. Also: a release AIUC names but which carries no commit is recorded as UNBUILT rather than dropped, and 194 derived change events are kept separate from the 104 change rows AIUC publishes itself. Collection policy is explicit and worth copying, identifying user agent, one request per second, no auth, no slug guessing, every page reached from a page already fetched, and robots.txt fetched first (404 at capture time, with the manifest recording that observation verbatim rather than the conclusion alone). INTAKE NOTE: the credential arrived as a sgit_private_read_ READ key inside a vault URL, the first submission in that form since the classifier learned the prefix, and it classified correctly as publishable rather than coming back 'unrecognised'. Nothing had to be derived. THE HOLD THAT WAS RAISED AND THEN CLEARED BY THE AUTHOR: the vault's own NOTICE.md and docs/source-policy.md state that reuse rights for the full AIUC-1 control text have NOT been confirmed with AIUC and that anyone republishing publicly should confirm them first. Publishing a read key is exactly that republication, so the work stopped and asked rather than proceeding past a warning the vault carries about itself; the author chose to publish as-is. The page therefore reproduces the vault's disclaimers in full above the fold instead of summarising them away, and repeats its removal undertaking. Audit otherwise clean: no sgit credentials, no third-party API keys, no private keys; permissions {}.
v0.2.48 2026-08-27 obj-cas-imm-2d922c5fe406	BOTH PRESENTATION VAULTS NOW LINK THEIR PUBLIC SOURCE. Confirmed by the author that the-cyber-boardroom/Presentation__BlackHat-EU__Dec-2025 and DinisCruz/Presentation-Threat-Mod-Con-2025 are public repositories. This settles a question left open when the Black Hat vault shipped: the branding note was written without being able to establish whether the material was already in the open, because github.com returns 403 to this container's proxy for any repo outside the session's scope, the same 403 for both repos, which is a proxy behaviour and not a signal about either. The consequence is worth stating precisely: the vault is a SECOND copy of material that already sits in public, not the thing that first exposes it, and the Black Hat speaker-template assets in particular are therefore not published here for the first time. The branding note itself is unchanged and still stands, the deck uses the official template because it is a talk that was given there, published as the speaker's own material and not as anything endorsed by or affiliated with the conference. On the ThreatModCon page the link earns its place for a different reason: that vault repairs two upstream files that are invalid JSON, and a repair expressed as a proof (four stray brackets removed, one `],` added, multiset of content lines unchanged) is only auditable if a reader can fetch the broken originals, so the link sits in the repair section rather than in a footer. Both URLs were taken verbatim from each vault's own README rather than retyped.
v0.2.47 2026-08-27 obj-cas-imm-dac438a3ef81	THE DIRECTORY ANSWERS QUESTIONS, and a second conference vault. Nineteen sibling sites is past the point where a list helps, so /network/ now carries a chat panel whose only job is routing, which of these is mine. THE DEFAULT TIER NEEDS NO KEY, NO ACCOUNT AND NO NETWORK CALL, a deterministic scorer running in the browser over a catalogue emitted at build time from admin/content/sites/*.md, the same data the cards and the table are built from, so the answers cannot drift from the directory underneath them. It also SHOWS ITS WORKING: a hit in a site's thesis or domain outweighs one in its summary, and the reply names the matched terms, which an LLM answer does not give you. Tier 1 is opt-in BYOK against OpenRouter, streaming, reusing the pattern already proven in the SG/Vault workbench vault (same endpoint, same versioned sg-llm-request module on dev.tools.sgraph.ai) rather than inventing a client; on failure it falls back to the local matcher and says so. The cost is stated on the panel, not buried: with no host there is no permission floor, so the key sits in the page's origin, never sent to sgit.ai, which has no server to send it to. Tier 2 (the vault-app build, where sg.llm.chat keeps the credential in .vault/llm/config.json below the permission floor) is NOT BUILT and is scoped in a new article including the rows that are not started. ONE REAL MISS FIXED: the matcher routed 'I need to cite a regulation precisely' to wardley-maps, because it knew only each site's own vocabulary, standards.sgit.ai says 'provision' and the reader types 'regulation'. Site entries gained an `aliases` field for the words readers actually arrive with; five real questions now give five correct first hits, and nonsense still returns nothing rather than a confident wrong answer. TWO BUILD RULES CAUGHT ME on the way, both correctly: the validator refused a forward link to the unwritten plan article, and then refused a script tag with a src attribute outright, these pages must also render inside a vault on a blob: origin where a relative src does not resolve, so the loader is fetch+eval like every other component here. ALSO PUBLISHED: ThreatModCon 2025 Barcelona, 'Scaling Threat Modeling with Semantic Knowledge Graphs', eleven linked threat models from customer to compute instance (51 nodes, 179 threats, 3 critical), five interactive views and five Wardley walkthroughs, libraries inlined at identical versions so no page touches the network. Two of its layer files are INVALID JSON UPSTREAM and are repaired in the vault, with the repair expressed as a proof rather than a changelog entry: four stray closing brackets removed, one `],` added, multiset of content lines unchanged, originals kept alongside. Its explorer screenshot was CAPTURED AND THEN DISCARDED, outside the vault host there is no sg.vfs.readText() to answer it, so the page sits on a loading spinner, and a screenshot of a spinner would have misrepresented the vault.
v0.2.46 2026-08-26 obj-cas-imm-057b0451154a	A CONFERENCE KEYNOTE AS A VAULT, the twentieth published vault and the first that is a TALK rather than a document set or an app. AI vs. AI: Building Resilient Enterprises in the Age of Autonomous Threats, Black Hat Europe 2025, AI Security Summit, ExCeL London, 9 December 2025. What makes it a good demonstration is that the whole chain travels together under one credential: the deck as presented (26 slides, ~976 KB self-contained app), six PDF exports v0.1.1 to v0.2.0, the eight research papers the talk was built from, and the slide system's own source at ten versions v0.1.0 to v0.1.9. A deck emailed as a PDF is a snapshot with its working removed; this is the working. The load-bearing design detail is that SLIDE CONTENT IS DATA: deck/blackhat-eu-2025.json is read through the vault bridge at load time, so editing a slide is a commit and needs no rebuild, which is also why ten renderer versions can sit beside one deck without either owning the other. permissions {} with present:true. INTAKE: the submitted credential carried the sgit_private_vault_ prefix and was refused as a WRITE credential by the classifier, the prefix family added in the v0.2.40 batch, working as intended on its first real submission since. Read key derived one-way, vault key to the gitignored tier. AUDIT clean across all four passes: no sgit credentials, no third-party API keys (the broadened sweep added after the OpenRouter miss), no private keys, no emails, no external company or client. AWS, Azure, Cloudflare and CrowdStrike appear cited for publicly documented outages, which is the subject of the slide. One judgement recorded rather than buried: the deck uses Black Hat Europe's OFFICIAL SPEAKER TEMPLATE, logo and trademark included, because it is a talk that was given there, published as the speaker's own material with the page stating plainly that it is not endorsed by or affiliated with the conference. Screenshots were captured by serving the cloned vault locally and driving the deck with its own arrow-key bindings, after keypresses sent to the hosted surface failed to reach the deck through the shadow DOM; the first three captures were also named one slide out of step with what they showed and were renamed to match rather than shipped with captions that did not describe the picture.
v0.2.45 2026-08-26 obj-cas-imm-598b21e85f91	ARTICLES GET A HOMEPAGE BAND, A NEW ARTICLE ON THE SPLIT, AND A LAYOUT BUG FIXED FROM YESTERDAY. The network band shipped in v0.2.44 ran the FULL VIEWPORT WIDTH: the homepage bands each carry their own measure on the component (.eco is max-width:1100px itself, there is no wrapper convention here) and the new band had none, so it stretched edge to edge on a wide screen while every other band stayed in the column. Reported from a screenshot rather than caught by the validator, which has no opinion about layout. Fixed and MEASURED: .eco, .netpick and the new .artcards all report exactly 1100px at a 1440px viewport with scrollWidth == innerWidth, and the five area cards now lay out 3+2 instead of 4+1 so the last card does not sit alone. NEW ARTICLE, 'Twenty sites in fifteen days, and what that did to the writing': the repositories were created between 11 and 26 August, fifteen of the twenty in the final five days, and the piece is about what that did to the writing rather than the count, what forced the split (an argument needs its own version history; nineteen arguments through one changelog produces a record nobody can read), what it cost (discovery got worse before it got better; consistency became discipline rather than construction; cross-site links became claims that can rot, as the sentinel.sgit.ai typo showed), and why the directory now opens with a question. ARTICLES BAND on the homepage, DERIVED from the articles list via an <!--ARTICLES--> marker the build fills, a new article appears there by being written, no list to maintain, the same one-file rule as updates and sites. Also: influences.sgit.ai went live mid-session and is now a full entry with its hero screenshot, taking the family to 18 live of 19; skills.sgit.ai still has DNS and a repository with nothing published and is still listed as such.
v0.2.44 2026-08-26 obj-cas-imm-d629c8d66421	THE NETWORK BECOMES A DIRECTORY. The sibling-site section was built for four entries and there are now NINETEEN, 17 live, 2 with repository and DNS in place but GitHub Pages not yet published (skills, influences), enumerated from the SGit-AI org and probed one by one for DNS, HTTP status and their own stated thesis. At four, a list of cards was the right shape; at nineteen it is a directory a reader has to read before it helps them. So the page now LEADS WITH THE QUESTION: seventeen lines, each one something somebody actually arrives with ('I need to give an AI agent an identity', 'I have to sign off a risk and I do not want to rubber-stamp it', 'I want an issue tracker with no database'), mapped to the site that takes it seriously. Under it, five thematic groups (Agents & AI, Risk & governance, Graphs & method, Security & infrastructure, Business & publishing) then a full scannable table of all nineteen. Every thesis is the SITE'S OWN WORDS, quoted from its H1 or lede rather than paraphrased here, so an entry cannot drift into describing a site that no longer says that. Engine: the sites content type gained `listing: true` (a directory row with no page of its own), plus `category`, `stage` and `thesis`; the four sites with a full write-up keep their pages and the other fifteen are one short markdown file each. Network promoted from the third child of Updates to a top-level nav group, and the homepage gained a network band with five doors in by area, a reader who does not know these sites cannot pick one from a list of domains. Thirteen new hero screenshots captured from the live sites through the local mirror. The two unpublished sites are listed AS unpublished, linking their repositories, rather than omitted. One engine bug found and fixed on the way: the first attempt to add the new fields landed in load_articles instead of load_sites, because the `'status': ...` + `'body': body` pair appears in both loaders and the articles one matched first, caught immediately by a KeyError at build, which is the argument for the build failing loudly rather than defaulting a missing field.
v0.2.43 2026-08-25 obj-cas-imm-48fd5df1d329	SIX VAULTS PUBLISHED, THREE HELD, and one audit gap found the hard way. Nine credentials were submitted; intake classified seven as WRITE keys and two as read keys, the seven read keys were derived one-way, and all nine were cloned and audited with the credential that would actually appear on the page. New pages: PENETRATION TEST REPORT (a pentest as a vault not a PDF, eight audience-specific views over one engagement, and a retest script per finding that exits 0 if fixed and 1 if not; entirely fictional and badged SIMULATED DEMO on its own front page), STANDARDS ATLAS GDPR ('the standard is the graph', rulings, guidance and per-country variation as first-class nodes, corrections scoped to feedback/ so a reviewer can never alter the graph under review), RISKMANDATE FILE SECURITY (risk acceptance moved from end-of-flow rubber stamp to the centre, over versioned JSON queried live by SQLite in the browser), CONTENT-TRANSFORMATION PROXY, SG COMMERCIALISATION (whose most credible artefact is an engagement register with no rows) and the SG/PAYMENTS BRIEF PACK (ten documents stamped PROPOSED). HELD: one vault carrying two live vault keys in plaintext INCLUDING ITS OWN WRITE KEY (publishing its read key would have handed out write access, defeating the entire read/write split) and one private working log. THE THIRD HOLD IS THE FINDING: a vault whose app reads an LLM key from a file passed the first credential pass CLEAN, and was caught only because a screenshot of it showed a chip reading 'key: vault key.json'. The file held a live OpenRouter API key. The scan had looked for vault-key shapes, sgit_ prefixes, PRIVATE KEY blocks and the literal string api_key; the field was named openrouter_key and matched none of them. This is a genuine gap in the tooling, not a near miss to be reframed, the credential checks were built for sgit credentials and had no opinion about third-party API keys, which leak just as expensively. A broader sweep (OpenAI/Anthropic/GitHub/AWS/Google/Slack/JWT shapes, placeholders filtered) now runs over every candidate; across all nine it found exactly one further hit, a forged alg:none token in the pentest vault that IS the finding it documents. Content checks answered two specific questions asked at submission: the commercialisation vault holds no real data (empty register, no emails, no rates, and its 'team' files are agent role definitions, not people), and the proxy vault names no external company or project, verified in text and BY EYE across 120 slide and diagram images a text scan cannot read. The GDPR atlas does name real companies, and correctly so: they are published CJEU and FTC case records. Article updated: nineteen vaults, 1,389 files re-cloned and verified, plus the LinkedIn republication link.
v0.2.42 2026-08-25 obj-cas-imm-75af1686df3e	AN INTRODUCTION ARTICLE, and the first CLI imagery on the site. /articles/what-sgit-is.html is the piece to hand somebody who has never heard of this: the category of file that has nowhere good to live, the vault key as address+auth+encryption in one string, the one-way read key that makes sharing possible, and then the proof rather than the claim. Two new terminal screenshots carry that proof and are the first of their kind here, every one of the 73 existing screenshots was of a browser. Both were captured from real runs, not mocked: a clone of the published EU AI Act vault (273 objects, 207 files) and the same vault's stored object rendered as a hexdump, 786 bytes of AES-256-GCM ciphertext whose name is a SHA-256 of those encrypted bytes. Also written up: apps in vaults running under permissions {}, capability without credential, and the four-site network. VERIFIED BEFORE PUBLISHING: all eleven published read keys were cloned from scratch, 781 files total, zero failures. That check first reported the opposite. Every clone failed with 'no named ref on the server', which looked like every vault page on this site instructing readers to run a command that could not work, and the real cause was a stale CLI in the authoring container, v0.15.0, where sgit clone cannot reach these vaults. v0.16.0 clones all eleven. The finding was retracted rather than shipped, which is the whole reason the check exists: an intro article is exactly the page that must not repeat an instruction nobody re-ran. A LinkedIn-newsletter edition of the same piece was produced alongside it as plain text with image placement markers, since that editor renders no markdown and asterisks would paste literally.
v0.2.41 2026-08-22 obj-cas-imm-f401ef7115e0	GRAPHS.SGIT.AI RESOLVES, the CNAME landed hours after v0.2.39 shipped the entry, so the `url:` override comes back out and the card links the subdomain directly. Deleting one frontmatter line was the entire change, which was the point of adding the field: a site finished before its DNS should be linked at the address that answers, and should not need rewriting when the real one starts working. The DNS-pending chip and the note both disappear on their own because they were derived from url != domain rather than written into the page. Verified before and after: graphs.sgit.ai returned nothing from a resolver on 21 August and answers 200 today. The sentinel.sgit.ai correction on that entry was re-checked rather than carried forward on trust and still stands, the graphs site links to a host that does not resolve, and the site is sg-sentinel.sgit.ai. Also settled this release, for the record: the 34 historical tags CI could never push (v0.1.9-v0.2.16, blocked because GITHUB_TOKEN cannot push a ref at a commit carrying a different workflow blob) are now on the remote, pushed from a workflows-scoped credential. The first attempt was a plain `git push --tags`, which reported 'Everything up-to-date' and did nothing: the tags only ever existed inside destroyed CI runners, so no clone had them to push. They had to be recreated locally from the commit subjects first. All 58 release commits are now tagged, each verified to point at the commit whose subject names it, and the backfill loop is a no-op from here.
v0.2.40 2026-08-22 obj-cas-imm-550fd7d8bac2	THE TAG GATE TOOK THE SITE DOWN, and this release fixes the gate and publishes what it held back. Two good commits landed on dev after v0.2.39, the VoiceDebrief vault (the ninth published vault, ten screenshots driven from its published read key) and a check_credential fix, and sgit.ai served neither for a day. Nothing was wrong with either commit. The CI tag job read SITE_VERSION, found v0.2.39 already tagged on the EARLIER commit, and failed with 'SITE_VERSION was not bumped for this release', when the truth was that this was not a release at all. Because the deploy job needs tag-release to be success OR skipped, and a FAILURE is neither, the publish never ran. Re-running could not help: the check is deterministic, and attempt 2 failed identically. THE FIX: what makes a push a release is now its commit subject, which is where release.sh already writes the version. A commit carrying no 'site vR.M.N:' subject is an ordinary push, tagged nothing, published anyway. A commit that DOES claim a version is held to the full contract, and to a stricter one than before: the subject and SITE_VERSION must agree (previously only inferred, via whether the backfill loop had produced the tag), the version must not already have shipped, and it must be the next minor. The reasoning behind the asymmetry is recorded in the workflow: a missing tag is a bookkeeping gap, a blocked deploy is an outage. Verified before shipping by extracting the job's script and running it over five cases in a throwaway clone, the exact commit that failed today now exits 0; a proper release tags; subject/SITE_VERSION disagreement, a reused version and a skipped minor all still fail, each with a message that names what is actually wrong. SECOND CONSEQUENCE, less visible and worth recording: those commits went to git only, so the vault remote never received them and the two stores had drifted, sgit status showed all fifteen VoiceDebrief files as uncommitted. That is the invariant release.sh exists to hold and the reason CI does not author commits itself. This release carries them across. Also in: the VoiceDebrief vault page goes live, check_credential now recognises sgit_private_vault_/sgit_private_read_ (the prefixes the CLI actually prints on init and clone, where the classifier previously called a good read key 'unrecognised', fail-closed, but the kind of refusal that tempts an operator to reach for the vault key instead), and validate.js skips node_modules.
v0.2.39 2026-08-21 obj-cas-imm-3d8cf0d26b96	Fourth site in the network: GRAPHS.SGIT.AI, a grammar for semantic graphs argued in increasing depth, five rules you can apply tomorrow, a working edge set with numbered gaps, then a full positioning against schemas and vector search. Its opening move is to disown the category a reader arrives expecting: 'this is not a graph database pitch… there is no graph database anywhere in the work behind this site'. The thesis is that two nodes both holding 8080 differ not in the value but in the connectivity, and the strongest argument on the site needs no technical background at all: 10,000 hours was an AVERAGE in a 1993 violinist study, not a threshold, half the top group had not reached it, and the author spent his career correcting the popularisation, but the correction never attached, because by then the claim had been carried through 242 papers and 200,000+ citation paths. A document cannot fix that; a graph can mark a claim superseded and turn 'what did we build on this?' into a query. Grammar highlights: every edge is a verb with a distinct inverse, the test being 'would a person in this business say this sentence?', and relates-to is BANNED for a mechanical reason, an edge with no verb carries no constraint, so it cannot narrow a traversal; it costs fan-out and buys nothing. Relevant here because the one indisputably shipped item on that site is sgit's own object model: a content-addressed commit DAG (SHA-256 over CIPHERTEXT, multi-parent, wave-BFS merge-base) plus *.link.json commit-pinned cross-vault edges and the sg.history read-only query API exposed to untrusted sandboxed apps. The grammar argument and the vault are not neighbours by theme; they share a data structure. It is also the FIRST SIBLING WITH A RECIPROCAL LINK, an '↗ part of sgit.ai' chip in its nav and a footer pointing back at /network/, so the index stops being one-way. Engine change: a site entry may now carry a `url:` that differs from its `domain:`. graphs.sgit.ai does not resolve yet (verified: no DNS), and a finished site should be linked at the address that answers rather than held back for a CNAME, so the page states which one it is instead of shipping a dead link and needing a rewrite later. The network audit also found a broken link on the new site itself: it points at sentinel.sgit.ai, which does not resolve. The site is sg-sentinel.sgit.ai. Recorded on the entry for upstream.
v0.2.38 2026-08-20 obj-cas-imm-b270f3424691	Third site in the network: SG-SENTINEL.SGIT.AI, a design for an app-coupled edge guard replacing rented AWS WAF + CloudWatch/Firehose with a layer you own. Its central inversion is that a generic WAF is blind to the app it protects and must denylist, whereas an edge that knows the valid request space can ALLOWLIST, no invalid request reaches the origin. Two things make it worth a page rather than a link. First, a governing correction stated as a constraint: 'Layer 1 never acts and never writes, it only decides and signals; Layer 2 is the sole actor and the sole I/O owner', because a CloudFront Function physically has no network and no filesystem, and the site names its own earlier design, where L1 blocked inline, as a category error. Second, rules are the engine rather than configuration on it: six deterministic rules, each a pure function mapped to an ATT&CK technique, run first-block-wins, with a prototype exercise running the same engine across three targets under a parity matrix asserting identical decisions. It also carries the most honest status language on the network. The pill reads NOT BUILT, and where the prototype's 149 passing tests are cited the site immediately bounds them as 'not deployed anywhere, not in production use, not maintained, not packaged for you to install'. Adding it cost one markdown file and three screenshots, which is what the content type was built for. One engine gap surfaced doing it: the markdown renderer had no TABLE support, so the six-rule core rendered as a paragraph of vertical bars. Pipe tables now parse (header, separator, body) and emit into the site's own .tablewrap, so they scroll on a phone and survive print like every other table here. Caught by looking at the output rather than trusting the validator, which had nothing to object to: badly rendered markdown is still valid HTML.
v0.2.37 2026-08-20 obj-cas-imm-1b229ee71709	REGULATION GRAPH, the EU AI Act as a citable graph, and the first vault here whose publication the audit STOPPED rather than cleared. Regulation (EU) 2024/1689 parsed from official Formex XML retrieved from CELLAR, hash-verified to the source bytes: 113 articles, 500 paragraphs, 180 recitals, 68 definitions, resolving to 1,523 nodes and 1,944 edges across eleven views, browse, Cytoscape citation graph, in-browser SQLite over sql.js, RDF via rdflib, concepts, external instruments, and an experimental Art 9 lab as the declared entry point. WHAT HAPPENED: the submitted credential was a VAULT KEY, not a read key, the fourth time, caught by the intake check. The read key was derived and the audit run with it across 204 text files, which is when it found a LIVE VAULT KEY IN PLAINTEXT inside a handoff document, granting write access to a DIFFERENT vault. Publishing our read key would have handed that away. No page was written; the finding was reported first. Deleting the file would not have been enough, because vault objects are content-addressed and immutable, so a credential committed once may stay reachable from history, the only clean remedy is history that never held it. So this is a REDACTED REPUBLICATION into a new vault: same 206 files, two credentials replaced in place with visible <VAULT-KEY-REMOVED> and <READ-KEY-REMOVED> markers rather than silent deletions, a PUBLIC.md stating the rules and the removals, and a re-audit from a fresh read-key clone: 205 files, zero findings. The second removal was a judgement call, a read key is publishable by its OWNER, and that one belonged to a third vault, so it goes and the decision stays with a human. RULE 3 VERIFIED RATHER THAN ASSUMED: the Graph REPL is an LLM chat, and repl.js looks for an OpenRouter key at /key.json INSIDE THE VAULT before falling back to device storage, so a shipped key would be an open tab on somebody else's budget. No key.json exists, confirmed in the read-key clone rather than in our working copy. The 370-plus bare 64-hex strings the scan flagged were all sha256 provenance hashes, checked individually, a scan that never produces a false positive is not scanning hard enough. The rule that caught all of this came from Risk Graph Explorer's own PUBLIC.md, not from us; it has now paid for itself.
v0.2.36 2026-08-19 obj-cas-imm-18bcdab6db5d	A NETWORK section for the sibling *.sgit.ai sites, built as a content type rather than as two pages, because many more are coming. nhi.sgit.ai argues that 'how do I give my agents an identity' splits into agents you RUN and agents you RENT, and that the industry answers only the first, SPIFFE for workloads you can attest, an open feature request for the agents anyone actually names. pki.sgit.ai designs a key registry from the 2019 keyserver failure and publishes four rules BEFORE the registry exists, reaching a resolution worth borrowing: append-only is safe when a writer appends only to objects it owns and fatal when anyone may append to somebody else's, so the rule to carry is not 'append-only' but 'the writer owns what it writes', which is append lanes, already shipped. Six screenshots captured from the live sites through the curl mirror the sandbox needs, since Chromium cannot egress here. Adding the next site is ONE markdown file plus its screenshots: the index, the cards and the per-site page are derived, same contract as updates and articles. Two engine fixes fell out of building it. The generator now WIRES THE SCREENSHOT COMPONENT AUTOMATICALLY for any page containing figures, a markdown author has no place to put a script tag, and the views page had already shipped once with figures and no loader, which errors nowhere and simply shows nothing. The first version of that check matched on 'figure class="shot"' and missed 'class="shot net-shot"', leaving the new index in exactly the state the check existed to prevent; it now matches on data-shot=, the attribute the component actually selects on. Detect on what the consumer looks for, not on how it happened to be written.
v0.2.35 2026-08-19 obj-cas-imm-1f3ce8d32a28	Two new sections and the navigation restructure they forced. UPDATES and ARTICLES, both built on the VoiceDebrief journalist pipeline's central rule, which was worth adopting verbatim: PUBLISHING IS ADDING ONE FILE. No index to update, no manifest to hand-edit, no decision about where a post goes, ordering, permalinks, updates.json and feed.xml are all derived. That is not tidiness, it is the property that makes an unattended journalist agent safe: two agents publishing on the same day touch two different files and cannot conflict. Frontmatter is flat key: value with no YAML parser, the folder path must agree with the date, and slugs must be unique or the build fails. ONE DELIBERATE DIVERGENCE from their contract: they author root-relative links because their site sits at a domain root; ours must also render INSIDE A VAULT at an arbitrary mount path, where a leading slash escapes the app, so posts are still authored root-relative and the build rewrites each to a depth-relative path. Authors keep the simple rule; the vault still works. Updates are one entry per STORY rather than per release, which is the whole reason this is not the version log with a nicer stylesheet, v0.2.31 alone carried three separate stories. Five seeded from recent releases; the version log stays the complete technical record behind them. Articles carry two anti-rot rules stated on the page: never restate a fact you do not own (link to the page that does, so it cannot start lying when the fact changes), and link the test behind any testable claim. Two to open: GREEN DOES NOT MEAN LIVE on the deploy that reported success twice while serving a two-release-old page, and SEVEN VAULTS, ONE METHOD on what publishing seven vaults taught, including the three vault keys submitted as read keys. NAVIGATION: 14 flat items became 7 groups with a second level. The old bar wrapped to THREE ROWS on an iPhone before the page began, measured on a real screenshot, not guessed. Every group label is itself a link to that section's index, so nothing is reachable only by opening a menu. Desktop opens on hover and :focus-within in CSS alone; the phone collapses behind one button. The first mobile attempt made every submenu inline and measured 498px of navigation before the content, worse than what it replaced, so it was rebuilt as a collapsed menu: 91px, against 54px on desktop. Also adds an RSS feed and a JSON manifest, the first machine surfaces here aimed at a human follower rather than an agent.
v0.2.34 2026-08-18 obj-cas-imm-97c957112852	Acts on an inbound fix pack from the SG/API team, who audited this site against their route tables at v0.33.54 after an agent asked how to send a message between vaults and could not find the answer here. Their central finding was right: the site documented the TRANSPORT (sg.append) and the CRYPTO (sgit pki) on pages that never referenced each other, and never wrote the sentence saying they compose into vault-to-vault messaging. There was also no HTTP API reference anywhere, which is awkward for a project whose argument is that the API is the whole surface. SEVEN NEW PAGES: /docs/vault-messaging (the keystone, append lanes composed with PKI, worked end to end in CLI, curl and sg.append), /docs/pki (keypair lifecycle), and a /api/ section: index, authentication, vault-objects, append-lanes, errors. The security page gains the asymmetric layer it never had; sg.append is retitled as the message transport and cross-linked; limitations gains what PKI does NOT do; the skills page flags that the shipped agent skill still has both halves and no join. THREE OF THE PACK'S FINDINGS DID NOT SURVIVE CHECKING, which is the part worth recording. (1) It reported that the security page 'actively denies PKI'. It did not, a sweep for symmetric, asymmetric, public key, PKI and keypair returned zero occurrences. The page was SILENT, not wrong; publishing a correction for a claim we never made would have put a false statement in this log. (2) It asked us to hunt stale 'inbox' naming; there is none, two hits, both ordinary English, and no /api/vault/inbox/* path anywhere. (3) It described X25519 sealing throughout. Running sgit pki keygen on v0.15.0 prints RSA-OAEP 4096 and ECDSA P-256. Publishing the draft as written would have told integrators to build against the wrong primitive. Two further corrections came from running the CLI rather than reading about it: export emits a JSON BUNDLE of two PEM blocks, not a .pem file, so the draft's sha256sum-the-pem derivation of the lane address is not well defined; and keygen requires a passphrase, which no draft step mentioned. The one genuinely unshipped step , append_token = H(public key), is labelled PROPOSED with an interim recipe rather than quietly documented as working, and the two endpoints their audit could not resolve (/api/vault/zip, /join/*) are listed as unresolved rather than described. The pack's own acceptance test, give a fresh agent only llms.txt and ask how to send an encrypted message from vault A to vault B, now passes, including the lane-address fact and its PROPOSED caveat, answered in the preamble so it survives an agent that cannot follow a link.
v0.2.33 2026-08-17 obj-cas-imm-ab458fd8611d	A release now ends by asking the live site what version it is serving, because 'both remotes in sync' turned out not to mean 'published'. v0.2.31 and v0.2.32 both pushed cleanly, both reported success, and NEITHER reached sgit.ai: GitHub Pages failed to deploy them because codeload returned 429 (Too Many Requests) for actions/configure-pages@v5, and the deploy job died in 'Set up job' before running a single step. Validation passed, tagging passed, the push was verified against both remotes, and the site served a two-release-old page for forty minutes, which is how long it took a human on a phone to notice the version pill still said v0.2.30. The failure was invisible to every check the release ran, because it happened in a job neither remote knows about. So release.sh gained a sixth step: poll the live URL with a cache-buster until the version pill matches this release, up to eight minutes, and ABORT LOUDLY if it does not, naming the Actions page and the fact that a 429 on the action download is transient and just needs a re-run. The cost is up to eight minutes of waiting per release. The alternative, demonstrated twice in one afternoon, is telling somebody a fix is live when it is not. Same principle as the orphan-page rule and the llms.txt guard: a page nothing links to, a page the index omits, and a page the deploy never published are all equally unpublished, so the build refuses all three. Ships the content of v0.2.31 and v0.2.32, which had been written but never served.
v0.2.32 2026-08-17 obj-cas-imm-7f84b9ee6727	The walkthroughs page becomes a document rather than a list of links. Each of the three videos now carries the recording at the top and THE SAME SESSION READ BACK underneath it: fifteen moments, each one a timestamp that deep-links into the video, the frame the screen was showing at that moment, and an explanation of what is happening in it. The transcripts are still there, folded away at the foot of each. The reason for the format is the one thing a transcript structurally cannot do: these recordings are full of 'this guy here' and 'look at this', and the words alone name neither end of what is being pointed at. Pairing each phrase with its frame is what makes the argument survive being read instead of watched. TWO SOURCES OF FRAMES, and the page says which is which. The Graph Browser moments are frames of the recording, from a narrated-review export the author produced with tools.sgraph.ai, nine timestamped stills paired with the narration spoken over each. Risk Chains and Role risk map have no such export, so their six frames were captured from the LIVE VAULT with the published read key, driven to the exact state being described, including the entry he names out loud ('you have risk 6'). What the frames turned up is most of the value, because none of it is audible: negative answers produce NAMED EDGES (never-exercised-on, never-timed-for, absent-for) rather than silence; 'no egress' draws a single assurance-coloured edge in a field of amber, so a good answer is a finding rather than the absence of one; one selection can carry two fact ids; and every risk ships with a CEASES WHEN ANY OF THESE HOLD list, its own falsification condition, cited to facts. The role dashboard also separates three arrival routes where the video describes two: held, arrives by the risk chain, and arrives by the org chart. TOOLING: the capture rig gained appProbe (ask the running app what its elements are called instead of guessing and burning a capture run per guess, it found g.cnode for chain entries and g.role for roles) and appClickMatch (substring match plus a real MouseEvent, because the graph nodes are SVG). Videos print with the player hidden and the moments intact.
v0.2.31 2026-08-17 obj-cas-imm-17f0b2693daf	Corrects v0.2.30 on three counts, two of them reported and one of them the reason the report was possible at all. (1) THE LAZY-LOAD BYPASS IS NOW ONLY ON PRINT. v0.2.30 prefetched every screenshot once the page went idle, which fixed printing by making every reader pay for images they never scrolled to, the wrong trade, and correctly rejected. It is now driven entirely by the print itself, and it works because of a change one layer down: on the ordinary web the loader no longer fetches bytes and builds a blob: URL, it just sets img.src. That makes each screenshot an ordinary pending document resource, which the print pipeline knows to wait for, where a fetch-and-blob is invisible to it. Cmd/Ctrl-P is caught on keydown as well as beforeprint, because the keystroke lands a few hundred milliseconds before the dialog does and that head start is what removes the race. Measured on a page that was never scrolled: 1 image loaded while reading, 9 of 9 in the PDF. The blob path remains for pages served from inside a vault, where it is the only option. (2) THE PRINT-ONLY SOURCE LINE AND LANDSCAPE HINT ARE GONE, printing these pages is an uncommon case and did not warrant instructions on the page. (3) ASSETS ARE NOW CACHE-BUSTED PER RELEASE. GitHub Pages serves them with max-age=600, and the bootstrap fetched them by bare path, so for ten minutes after every release a returning reader ran the NEW html against the OLD css and js. That is not a hypothetical: it is exactly what produced the v0.2.30 bug report, new markup whose print-only elements the cached stylesheet did not know to hide, and a cached loader without the print handler. Every fetched asset now carries ?v=<site version>; the in-vault sg.vfs path stays unversioned, since a vault lookup is by path, not URL.
v0.2.30 2026-08-17 obj-cas-imm-81dc22613ddf	Print and save-as-PDF, prompted by an export of the seven views page that came out wrong. TWO DEFECTS, one reported and one found while looking at it. (1) The top nav is position:sticky; Chrome paints a sticky box ONCE, wherever it happens to fall in the paginated flow, so the whole nav landed across the middle of page 2, translucent, with the prose showing through it. It is static in print now and flows once, at the top of page 1, as a masthead with the link list dropped. (2) WORSE, AND NOT REPORTED: screenshots are lazy, a figure starts at opacity:0 and its img is only created when an IntersectionObserver fires, so printing a page without first scrolling to the foot of it exported blank gaps where the pictures should be. Nothing errored; the img simply never existed. beforeprint cannot fix that alone (it is synchronous and will not wait for a fetch and decode), so the figures are now prefetched once the page goes idle, with beforeprint kept as the backstop. The export that prompted this was only correct by luck: it was taken after reading the whole page. Beyond the fixes: @page margins so Chrome's Default is ours rather than its own; print-color-adjust:exact, because on this site the tints carry meaning (amber exposure, green assurance) and Chrome drops backgrounds unless asked; break-inside:avoid on walkthrough rows, figures, notes, tables and transcripts, which fixes captions stranded on the page after their picture; orphan/widow control; live vault embeds hidden and labelled rather than exported as empty boxes; and a print-only source line carrying the canonical URL, since Chrome's own header and footer are frequently switched off. Finally, any page containing walkthrough rows now asks for LANDSCAPE, in portrait the two-column grid falls below the 820px breakpoint and collapses, which loses the alternating left-right rhythm that is the entire design of those pages. The reader can still override it. None of this was tested before; all of it is now.
v0.2.29 2026-08-17 obj-cas-imm-8a68f249bd9f	The first vault to get depth rather than a page. Risk Graph Explorer now has three: the overview, THE SEVEN VIEWS EXPLAINED, and THE AUTHOR'S WALKTHROUGHS. The views page captures each of the seven tabs from the live vault under the Exposed preset (the estate, context, role risk map, risk chains, the register, acceptance, what happens next) and explains the mechanism behind each, matched to how the author describes it in his own recorded demos. Highlights the screenshots alone would not carry: 'assigned' versus 'through' on the role map (what you personally hold, versus what arrives because the graph says it must), so that no risk is orphaned and every path terminates at the board; risk chains running inherent-to-corporate left to right, clickable in both directions ('leads to' navigates up, 'led by' walks back to the answers that caused it), with cycles drawn as dashed edges because the cycles are real; and acceptance as the place where the register stops being a document, with the author on camera disagreeing with his own tool, which resolves into WHICH FACT IS WRONG rather than whose judgement wins. Also captures the same organisation under the Typical and Governed presets, because that comparison is the whole argument: the org chart does not change, only what is true about the agent. The walkthroughs page carries all three videos with FULL TRANSCRIPTS, a video is invisible to a search engine, to llms-full.txt and to any agent reading this site as documentation, so the transcript is the content and the video is one rendering of it. Tooling: the shots component gained a data-dir override so deeper pages under a vault share ONE image folder; the site now runs to 53 pages. Three bugs caught by testing rather than assumption, a malformed selector expression that silently created no images at all, escape sequences leaking as literal text, and a page that never loaded the component it depended on.
v0.2.28 2026-08-17 obj-cas-imm-6008b0bdfe27	Seventh vault, and the method written down. RISK GRAPH EXPLORER (3simlnqe) is the fact-to-risk explorer extracted out of the risk-mandate work into a vault of its own, answer questions on the left, seven views recompute on the right, nothing leaves the page. Its argument is visible in two screenshots: empty at 0 facts / 0 risks, then 18 / 37 / 14 under the Exposed preset, because a register that produces the same output for a scratch service and a payments platform is a checklist, not a register. Unanswered relationships are drawn as ghosts, recording absence as information rather than as an implicit pass. It is the first vault here PUBLIC BY DESIGN: it carries its own PUBLIC.md whose three rules its build enforces, nothing private committed (the gate scans every file, not just the artefact), no write token, and NO METERED CAPABILITY, because a published read key in front of an LLM config is an open tab on somebody else's budget. That third rule is not in our guidance and is the one to adopt. It also sent us back to re-audit ourselves: risk-mandate does carry an LLM config, so we took its sealed credential and attempted to open it with the read key we had published, AES-GCM refused (InvalidTag), so no budget was exposed; the rule is satisfied there by sealing and here, more conservatively, by absence. Checked rather than assumed, and recorded either way. Its app.json is `permissions: {}`, the floor of a scale the catalogue now spans end to end. Zero audit findings, the cleanest yet. NEW PAGE: /demos/vaults/publishing.html, the seven steps behind every vault published here, written to be followed by another site's agent: classify the credential before it touches anything, derive rather than refuse, audit with the read key across every file, derive the facts, capture evidence by driving the real product, write the page (describe, show, then admit), and record what outlives it. It names the five tools and, more usefully, the five mistakes that produced each rule.
v0.2.27 2026-08-17 obj-cas-imm-6f1decd85ad3	Sixth vault: AGENTIC BROWSER ISOLATION (0610gsp9), a living risk graph for one decision, does an AI agent browse inside the user's browser with their logged-in sessions, or inside an isolated browser with a scoped identity of its own. It is this site's own ambient-authority argument made by somebody else and in much more detail, so it is linked from the AI-agents use case. Seventeen app entry points, the most in the catalogue: a numbered narrative spine, one page per stakeholder altitude (IT · CISO · DPO · CFO · COO · CEO · Board), an explorer, two graph views and the raw data, over ~70 JSON files with RDF tooling vendored in so graph exploration works offline. The mechanism is the part worth copying: every altitude has one named owner, a risk stays PENDING until that owner accepts it personally, only an accepted risk escalates, and there is no deny button, the screenshots show IT holding five pending while every altitude above reads 'waiting', because nothing has been passed up. Its app.json declares fs.write: [], an app that requests no write capability at all, which with supplement-stack (one folder) and risk-mandate (LLM use without the key) gives the catalogue three distinct points on the permissions scale, each declared in the vault rather than configured on a server. The intake check earned its keep on arrival: the submitted credential was again a vault key, refused for publication by shape, and only the one-way derivation published. Audit clean across 104 files, the six scanner hits were all digit runs inside a minified RDF library matching a phone-number pattern, recorded because ruling hits out by reading them is what an audit actually is. Also: upgraded the CLI to v0.15.0 (latest) specifically to re-test the prefix gap; it still derives the wrong ref from the canonical read-key prefix while the bare form clones correctly on the same binary, so the brief now says 'confirmed on latest' rather than 'may be a stale install', and the machine-verified check updated its own evidence from v0.14.27 to v0.15.0 with nobody editing the claim.
v0.2.26 2026-08-17 obj-cas-imm-6958c20644d8	Credential intake becomes a check rather than a habit, prompted by yesterday's near-miss: a vault key was submitted for publication described as a read key, caught by shape, and only its derived read key published. The catch depended on somebody looking. New admin/build/check_credential.py classifies a credential BEFORE it touches a page, a catalogue entry or a commit, exit 0 means read-only and publishable, exit 1 means a write credential and stop. It works two ways because the problem has two eras: by PREFIX for vaults new enough to emit one (the canonical write prefix, which is exactly the change being rolled out, and the reason it is worth rolling out), and by SHAPE for everything older, where a read key is 64 hex characters and anything else before the colon is a passphrase. Verified against all eight real forms we have handled, including the actual key from yesterday, which it refuses with no prefix to help it. If a submission IS a vault key the entry is not blocked, the documented one-way derivation is printed instead. The rule is now in the catalogue vault's SCHEMA, so it renders on /catalogue/ with no site deploy, and summarised on the vaults index. Also: the release tripwire got more precise rather than more strict. Banning the bare write prefix outright had caught its own author three times, each time writing it in prose, and guidance that cannot show a reader what a write credential looks like cannot teach them to spot one. It now fires on the prefix followed by a CREDENTIAL character, so documentation may name it while every real key still fails the build; the bare passphrase:vault_id shape catches the body independently. Both directions proven before shipping (\S was tried first and failed, because in documentation the prefix is followed by markup).
v0.2.25 2026-08-17 obj-cas-imm-8b39926aadb1	Risk Mandate joins the catalogue, the most complete project ever published here, and the first to demonstrate CAPABILITY WITHOUT CREDENTIAL. It is a Black Hat field demo (hand someone an iPad, answer eight questions, a risk register assembles) built AS a vault app: 124 files, 98 commits, eight entry points, a test suite, build tooling, releases pinned to commit ids and offered as a live selector in the app chrome, and offline operation after one cached load. Its app.json grants llm:chat/models/usage/listen and fs.write over field/workspace/ and nothing else, while the OpenRouter credential itself is SEALED under the vault key in .vault/llm/config.json, so the host decrypts and calls and the app frame is handed results, never a secret. Auditing with the published read key, that field is ciphertext we cannot open, which is the claim demonstrating itself. The /compare/ privilege vocabulary gains the shape this revealed: ops and bearer come apart, so ops:llm-chat can be granted while bearer of the key is withheld, something most sharing models cannot express, because handing over the capability and handing over the credential are the same act. IMPORTANT PROCESS NOTE: the credential submitted for this vault was a VAULT KEY (format 3, passphrase:vault_id), not a read key, it matched this site's own banned-shape tripwire exactly. It was not published. It was stored in the gitignored local tier and the read key was derived from it one-way via the library's own Vault__Crypto.derive_read_key; only that derivation appears on the site, in the catalogue, and in the capture rig. The independent audit across all 124 files was clean, with two findings of the good kind recorded publicly: the sealed LLM key, and a single secret-scanner hit that turned out to be a deliberately fake sk-test- key inside a test asserting that a reachable API key IS caught.
v0.2.24 2026-08-17 obj-cas-imm-244c5ecdeecf	Comparisons, built as reproducible tests rather than as claims, the concrete proposal answering the 16 Aug comparison brief. New /compare/ section carrying (1) the entry format: task, steps, prerequisites, privileges granted, where it runs, survives-the-vendor, verified date, and how to re-run; (2) a PRIVILEGE VOCABULARY, which is the part most likely to be argued with and the reason it is published first, seven properties that make two grants comparable (scope, operations, bearer, mediation, duration, withdrawal, observability), under which a published read key reads scope:vault · ops:read · bearer:any-holder · mediation:key · duration:forever · withdrawal:future-only · observability:none, three of them WORSE than a mainstream sharing link; (3) three worked entries, printing a markdown file (small, checkable in a minute, we win), taking access back after sharing (WE LOSE, plainly: rotation protects future commits and reaches nothing already fetched, while a server-mediated platform simply refuses the next request), and letting a program record data without letting it alter records (the differentiator, where step counts tie and privileges separate). Behind it: admin/build/compare_tests.py executes the our-side claims against the live service with published read keys only, and writes compare/results.json, six checks, each stating what would make it FAIL. Five hold; one records an ABSENT capability and is kept until it stops reproducing: the installed CLI v0.14.27 does not strip the canonical sgit_rk1_ prefix the web loader now accepts, deriving the wrong ref id, while the bare form works on the same version, now also filed as a brief to the CLI team. The freshness mechanism is real rather than a date in small print: results carry an expiry threshold and a past-threshold result renders as UNVERIFIED instead of as fact, proven by forcing the dates old and watching all six rows flip. The page states its own asymmetry up front (our rows are machine-verified, rows about anyone else's product are hand-checked on a date) and lists what is deliberately absent, including the deployment comparison, which waits until our own portable-artefact/hosted-viewer caveat is resolved.
v0.2.23 2026-08-16 obj-cas-imm-8af209891454	Structure for scale, and the most interesting vault yet. (1) Every published vault is now a self-contained folder, demos/vaults/<slug>/index.html with its screenshots in demos/vaults/<slug>/images/, so adding the hundredth vault is adding a folder, and a vault's page and pictures move together. The old flat /vaults/ section is gone (URLs lived one day). Two engine changes made it possible: the root-prefix was computed as 'one ../ if nested at all', which silently pointed the nav, stylesheet and every asset at the wrong level once pages nested three deep, now it is ../ times the depth, the same formula the markdown twins already used; and the screenshot rig writes per-vault, with a --vault filter. Image paths in the walkthrough are page-relative for the same reason. (2) New vault: SUPPLEMENT STACK (r7zes477), and it is the strongest healthcare demonstration on the site. Its idea: every label describes one product, nothing describes the sum, so the model extracts (fuzzy, with every amount traceable to the label photograph it was read from) and the code adds up (deterministic, rules stated in the open, a missing value flagged and never guessed), producing a briefing for somebody qualified and never a verdict. It is also the first vault here to use SCOPED WRITE PERMISSIONS: app.json grants write over adherence/ only, so the app that logs what was taken cannot alter the regimen, the labels or the references, least authority as a property of the vault rather than a server setting. Five walkthrough rows captured from the live vault, including its app.json permission block. The healthcare use case now opens with this as a worked example: who holds the data, how it reaches a clinician (a read key, not an account or a PDF), where AI fits safely, and why the reference set is UK RNI/EFSA rather than US Daily Values. The published audit: clean on credentials, no personal identifiers found, but it publishes a real regimen and the health context inferable from it, deliberately, and revocation is not retroactive.
v0.2.22 2026-08-16 obj-cas-imm-b1d27e3295cf	The walkthrough: six alternating rows at the foot of the Algarve page that explain what a live embed cannot say for itself. The app is real HTML (not a viewer template); clicking a photo opens the vault's own lightbox with captions from gallery.json; the debug pane's Vault tab times the decryption step by step; its REPL tab is a console over the sg.* bridge where vfs.write is refused because no write capability exists in a read key; the vault browser shows photos/originals and the app's own SOURCE; and the SGit tab carries 36 commits, because the history IS the storage. New tool behind it: admin/build/capture_shots.mjs drives the real product with only a published read key, performs each row's navigation (scroll to a chapter, click a photograph, open the debug pane through the HUD's shadow root, type vfs.list into the REPL, expand a folder, switch to the SGit view), crops the result and writes WebP, so the pictures are of the actual vault and regenerate when it changes. Getting there needed four fixes worth recording: the app frame must be identified by a selector it contains (the shell frame also has text and was winning the race), the REPL input sits two shadow roots deep and is reached with a shadow-piercing locator typed into for real, the file tree rows are .sb-tree__folder-name, and the slow test mirror needs navigation timeouts well past the 30s default. Images load through assets/shots.js, lazily, and via fetch-or-sg.vfs rather than <img src>, because the authoring contract forbids declarative refs so every page survives being served from inside a vault. Also adds a direct 'open the gallery app in its own window' link using the read-key fragment the UI now accepts.
v0.2.21 2026-08-16 obj-cas-imm-10164a7a31ab	Two reader reports from an iPhone, both fixed with the cause named. (1) The vault pages now open both surfaces ON LOAD, the reader lands on the vault, not on a row of buttons. The opens are sequential by design: the browser surface starts once App Mode reports vault-ready (grace-capped), so its objects come out of the client's encrypted-object cache and the second open mostly decrypts rather than fetches, the caching architecture demonstrating itself on every page view. Buttons are gone; each frame carries a label and its own status line, and a failed handshake leaves a retry control instead of a dead page. (2) The landscape-iPhone report, site and iframe not using the full width after a pinch-zoom, was hunted down empirically rather than guessed at: one unbreakable 702px token (the sgit clone command with its 90-character credential) on a 393px viewport made the page 743px wide, which drops Safari's fit-to-width scale below 1; pinch out and the entire site sits narrow with a white gutter. Fixed with overflow-wrap:anywhere on inline code (breaks only when a token would overflow) plus the html canvas painted the site colour so any zoomed-out or overscrolled area reads as the site rather than as white margin. Verified at iPhone viewports: every checked page now measures exactly the viewport width, and the auto-open completes with zero clicks.
v0.2.20 2026-08-16 obj-cas-imm-23e6ea08a77d	Both surfaces at once, reader-requested: on the vault pages, App Mode and the vault browser now each open in their OWN frame, stacked (the app first, the FILES/SGIT/SETTINGS browser under it) instead of one frame the buttons fought over. The second open is fast by design and the component says so: the encrypted objects are already in the client's cache from the first surface, so the second mostly decrypts rather than fetches, the caching story demonstrating itself. Each frame carries its own status line from its own handshake (one listener, replies routed by which frame sent them). The Full screen button is gone from these pages, with each surface getting a full-width, viewport-height frame of its own, it earned nothing. Verified headless: both surfaces open (5.0s through the slow test mirror, faster live), app above browser, two independent vault-ready events.
v0.2.19 2026-08-16 obj-cas-imm-2773e0dfba35	The site starts doing the thing it was building toward: publishing vaults. New /vaults/ section, an index of every read key this site has deliberately published, and one page per vault (five at launch: Field Notes, Strategy Maps, Deploy Docs, the Catalogue itself, and, new, Algarve · May 2026) with a real description, the features that vault exercises, what the shape is good for, the derived facts, the key as a copyable sgit_rk1_ credential with a CLI command and an open-in-the-official-UI link, and the vault RUNNING LIVE in the page via the reusable embed component (assets/vault-ui-embed.js, the two-surface embed-protocol host from the demo page, now attribute-driven; App Mode hidden for vaults without an app). Pages load the component contract-compliantly (fetch+eval, no script src, every page must survive being served from inside a vault). The Algarve vault is the first entry processed through the catalogue's submission queue as designed: read key supplied in chat, everything else derived, 71 files, 29 MB (60 WebP photos in originals/web/thumbs), 36 commits, auto-opening gallery app with a chaptered narrative. Its pre-publication audit is published on the page per the rules: one finding (a live delete_auth token in public-preview bookkeeping, narrow scope, the owner advised to rotate) and one counterpoint worth showcasing (the same vault's readonly-tokens bookkeeping decrypts to further ciphertext: owner secrets double-encrypted, the pattern that fixes the finding class). Catalogue vault updated in the same breath (new entry, trip-gallery-1 ticked off the awaiting list (7 remain)) and /catalogue/ picked it up with no site deploy, which is that design working.
v0.2.18 2026-08-16 obj-cas-imm-68578f7b1bf4	The tag pipeline's first contact with a real GitHub rule, fixed within the hour. v0.2.17's run DID tag itself, the first CI-authored tag, but the historical backfill push was rejected wholesale: a workflow's GITHUB_TOKEN cannot push any ref pointing at a commit whose tree carries a different version of a workflow file, and the `workflows` permission that would allow it is not grantable to that token. Every pre-v0.2.17 release predates the current deploy-pages.yml, so all 33 backfill tags bounced, and because the tag job failed, the deploy was skipped and v0.2.17 never reached the live site (this release carries its changes out). The fix splits the pushes by what they are: THIS release's tag at HEAD is load-bearing and fails the job if rejected (it never should be, HEAD's workflow blob matches the branch, which is why v0.2.17's own tag went through); the historical backfill is best-effort per tag, warns per rejection, and emits one notice with the single human command that completes the set, `git push origin --tags` from any workflows-scoped credential. Once a human has done that once, the backfill loop becomes a chain of no-ops. Lesson recorded for the case-studies pile: the same both-remotes discipline that made CI verify-and-tag instead of commit-and-tag also meant the failure cost nothing but a skipped deploy, no bump commit was stranded on one side of the two-VCS split.
v0.2.17 2026-08-16 obj-cas-imm-24876be44e37	Two reader-driven fixes and the release pipeline grows tags. (1) Layout: the embed buttons and their status line sit back in the text column where they belong, only the vault surface itself breaks out wide, since it is the thing with the big UX. (2) CI tagging, ported from the VoiceDebrief website pipeline (validate → tag → publish, every push to dev a minor release tagged v{release}.{major}.{minor}) with one deliberate adaptation: the upstream OSBot action has CI commit a version-file bump, but this repo is simultaneously an sgit vault, and a CI-authored commit would exist only on the git side, breaking the both-remotes-in-sync invariant release.sh enforces. Here CI verifies-and-tags instead of owning: SITE_VERSION (bumped once per release by release.sh) must match the release commit's subject and be the next minor after the latest tag, then the commit is tagged. No CI commits, no drift, same discipline, and a forgotten bump now fails the pipeline loudly instead of shipping quietly. The first run backfills tags for every historical release by parsing the commit subjects, so the whole v0.1.9→now history becomes navigable by tag. Also: validate.js now runs in CI as the gate before tagging and publishing, which puts the key-leak tripwire on the deployment path as well as the release path. (Tags could not be pushed from the authoring session, the session's git proxy authorizes branch pushes only, which settled the design question of who owns tags: CI does.)
v0.2.16 2026-08-16 obj-cas-imm-34ed83dd03e6	The embed grows up: both official surfaces, one click each, over the UI's new embed protocol. Reading the deployed bundle found what the addendum's Phase 3 had shipped, embed-protocol.js and a shared embed-receiver on BOTH shells: the host page loads ?embed=1&parent=<origin>, the frame proves itself with vault-embed-ready, and only then is the key sent by postMessage with the targetOrigin pinned. Strictly better than the URL-fragment flow shipped yesterday: the key never appears in any URL, is never written to the frame's storage (verified, sessionStorage and localStorage empty after open, memory-only as the protocol promises), and the host gets structured vault-ready/vault-error events instead of guessing from load timings. The demo page now has two buttons: App Mode, and, new, the vault browser with the FILES/SGIT/SETTINGS rail, which previously needed a two-step trick because /en-gb/vault deliberately strips URL hashes and root is the only inbox. Headless-verified both: App Mode ready in 2.7s, browser in 9.7s, rail present, R1 W0 badge, no horizontal scroll. The embed area breaks out of the text column (94vw up to 1680px, height tracking the viewport) because the vault browser is a full working surface, plus a full-screen button, both asked for by a reader with big-UX vaults. What is still not possible is stated precisely on the page: vault-open carries {key, mode, deepLink} where deepLink is a file path, so a host can select a SURFACE but not a VIEW, SGIT and SETTINGS remain in-page events. The briefing gains an addendum thanking the UI team, recording the verification, and sharpening the last ask to one optional field: view:'files'\|'sgit'\|'settings' on vault-open, applied after mount. Also fixes a stale paragraph v0.2.15 left behind (a silent curly-quote replace failure), the page no longer promises a swap that already happened.
v0.2.15 2026-08-15 obj-cas-imm-576ba8a1a09f	The gap closed: the official SG/Vault interface now opens from a published read key, and this site embeds it. Our v0.2.7 experiment had isolated the blocker to exactly one thing, the loader documented a read-only credential but rejected it, and the CLI shorthand was parsed as a passphrase and PBKDF2'd into the wrong ref id. The UI team shipped the fix: a read-key credential is now its own format (<64-hex>:<vault_id>, the shape sgit clone already accepted) and is tested BEFORE the passphrase formats, which was the precise ordering bug; canonical CLI key prefixes are stripped first. Re-running the same experiment against the deployed build, read key only, no vault key anywhere: all three credential forms parse; App Mode boots the Field Notes demo under full chrome with its six studies rendered and the bridge live; the vault browser opens with the FILES/SGIT/SETTINGS rail over the real decrypted tree; and the SGit view lists both commits with real object ids, all inside a cross-origin iframe, with an explicit R1 W0 / Read-only badge. So /demos/vault-app-embed.html now carries TWO hosts and keeps both on purpose: the ~170-line minimal host that shows the protocol with nothing hidden, and the official UI opened with the same published key. One ask stays open and is stated as such, no URL selects a view, so the SGit inspector cannot yet be framed in isolation. Also: the release tripwire learned the CLI's canonical WRITE-key prefix (its read-only sibling is deliberately exempt, we publish one), proven by making it fail before trusting it; it promptly caught this very release note's first draft, which had spelled the banned prefix out while explaining it. The hub capability audit is updated with verified evidence, row 1, the entry point for everything, flips from partial to present, which settles the spec's assembly-not-construction question for the forge's read-only tier.
v0.2.14 2026-08-15 obj-cas-imm-2f3c360b2de1	Ask B of the 14 Aug pack begins: the hub.sgit.ai briefing-pack plan lands in admin/plans/, and, per the spec's central instruction, the capability audit comes before any architecture. The audit table is already 13 rows deep, seeded entirely from evidence this project has produced: verified present (open-from-read-key in our readers, single-object decrypt, the app runtime under a sandboxed iframe, sparse per-object fetch, cross-session caching with the 120s ref window, frameability), verified partial with the exact gap named (the official UI parses but rejects its own documented read-only credential format), and honestly unknown (client-side merge, the in-UI diff and history views, enumerated in the bundle, never driven). The partial rows are flagged as the dangerous ones, because a partial capability gets assumed complete. The plan also fixes the pack's shape: six parts in order, the four absences stated up front, surfacing/adding/absent applied per feature (blame is adding, not surfacing), permissions as worked key topologies, and the private-vault key-handling flow named as the one needing a considered position. The crawler question is closed as answered: full text in the served HTML, noscript reveal since v0.1.26, and Google indexing confirmed.
v0.2.13 2026-08-15 obj-cas-imm-35d4e3e3a906	Fix: the catalogue page shipped without the vault debug panel markup that the shared reader wires unconditionally, so the reader threw on two missing elements and the first document never rendered (navigation and clicked entries worked; the initial body stalled at the fetching message). The panel is now on the page (which it should have been anyway, since watching the ciphertext arrive is half the point) and the headless check confirms the README renders on load with zero page errors.
v0.2.12 2026-08-15 obj-cas-imm-15dbcf053020	The catalogue: a vault indexing vaults, including itself. The 14 Aug briefing pack's Ask A lands as designed, a submission queue whose per-entry cost is a read key and one line, with everything else derived by opening the vault. The deriver (admin/build/catalogue_derive.py, ~120 lines, read-only, no token) turns a read key into file count, plaintext size, commit depth, HEAD, top-level layout, file types, app entries and browser-renderability; proven on all three published-key vaults (Field Notes 4bshby5n, the strategy/maps vault ookq4mn4, both app entry points detected, and the deploy-docs vault fyofmkvr, markdown-only). The catalogue itself lives in a new vault (kc67yhgw) published with its own read key and listed in itself: README (how to submit), SCHEMA (supplied-vs-derived, and the two rules, read keys yes, vault keys never; escrow the write key BEFORE publishing, because a frozen vault can never be corrected), three processed entries, and the two public to-do lists the brief asked for, awaiting-a-read-key (seeded with eight vaults named in the memos, each carrying the pre-publish audit instruction the strategy-maps case taught) and awaiting-processing (the agent's queue, currently empty). /catalogue/ renders it live via the same reader as the deploy docs, updated by pushing to the vault, no site deploy. Write-key status is a first-class field: 'known and escrowed' or 'lost', stated publicly per entry.
v0.2.11 2026-08-15 obj-cas-imm-1f8635c410ef	sgit gets its own Wardley map analysis, six maps starting with git at full strength, because a map that flatters its author is not a map: version control today (git's moat is the platform layer, resting on readable storage), the files that cannot follow (a hole in the map where their foundation should be), sgit's move (no new verbs, invert the bottom layer), the boundary on one map (two chains from one team, split by 'may the store read this?'), agents as the new user (the serialised diff versus ambient authority), and the strategy (commoditise private version control). The maps are drawn as inline SVG by a ~90-line renderer (no images, no dependencies) and the analysis ships as a SECOND app inside the same vault as the SG/Send strategy essay (ookq4mn4): one encrypted store, two entry points, one published read key; the embed opens it by passing entry to the same host. The embed shim gained link handling, in-page anchors scroll manually (assigning location.hash re-navigates a srcdoc frame) and relative .html links remount the frame on the new entry, so the two apps cross-link inside the embed; verified headless: 6 maps, 42 nodes, 12 evolve arrows, and clicking the companion link lands on the strategy essay. Linked from the Why page's boundary section. Also: Google has confirmed indexing sgit.ai, which unblocks the component registry when its turn comes.
v0.2.10 2026-08-15 obj-cas-imm-cedfb3d06f6a	Plan bookkeeping: the why-expansion plan's status table now reflects reality, Why reframe done, serialised PR done with its CLI brief, two of three demo vaults live, embed at the minimal-host stage pending the UI team's credential fix.
v0.2.9 2026-08-15 obj-cas-imm-2ce42cfd214e	The two remaining pieces of the briefing-pack plan land. (1) The Why page is reframed from rebuttal to boundary map: it now opens with where git wins, then draws the boundary precisely. The operations are not the gap (commit through merge all exist; proposing reviewable changes without write access is present, as a serialised diff, and is a differentiator); what is absent is the hosted review interface and the ecosystem above the protocol; and git is also client-side, so the real difference is that the objects are encrypted there, with the losses stated as a given-up/in-exchange-for table. New protocol section: the six-step read path verbatim, the two keys named explicitly, the three modes (Local/API/Web), and the two-implementations proof point. The LinkedIn comment and the market answer move below the boundary, kept whole. (2) New lead use case: the serialised pull request, no credential issued at all, grounded in the 5 Aug Black Hat disclosure, with an honest shipped-vs-pattern table (emit exists as history diff --json; import is not first-class) and evidence status PARTIAL. The matching brief to the CLI team asks for sgit diff export/apply, a published diff format, and ignore-file support, the latter now a prerequisite for the one-folder-two-VCS pattern the site publishes.
v0.2.8 2026-08-15 obj-cas-imm-4060eca3121d	Second demo, and the first with real content: The Strategy in Seven Maps (the actual SG/Send strategy, published on LinkedIn in May 2026) served live from a vault with a published read key. The page also publishes the audit that made this interesting: the original vault could NOT publish its read key, because its own read-write credential was written inside its content (a production briefing quoted the clone command verbatim), server-side bookkeeping under .vault/owner/ carried live delete_auth tokens, and the vault's keys derive from a legacy low-entropy token. The fix is the pattern the page teaches: republish, don't retrofit, sanitised copy, credentials redacted with a visible note, fresh full-entropy vault (ookq4mn4), and only then a published read key; a republish also sheds the history you cannot publish. The embed host gained vault-path image support (a MutationObserver swaps img.src vault paths for blob: URLs read over the bridge, the same job the real host's interceptor does), verified: all eight Wardley Map PNGs travelled as ciphertext and rendered.
v0.2.7 2026-08-15 obj-cas-imm-1b9cd77fb6d7	The full-UI embed experiment, run and published. Driving the real SG/Vault interface framed inside a page: the UI is frameable (no X-Frame-Options, no frame-ancestors), and App Mode works completely inside a cross-origin iframe, with a valid credential the official app-shell booted the Field Notes demo under the full HUD chrome. The one gap is the credential: the loader documents a read-only format (vault_id + 64-hex read key) but the client rejects it, and the CLI's 64hex:vault_id shorthand gets PBKDF2'd as a passphrase and derives the wrong file ids. No URL selects the SGit view, either. Both are now precise, evidence-backed asks in the UI-team briefing, honour the documented format (which alone makes the official UI embeddable with only the published read key) and add a \|view:sgit deep-link. The demo page carries the findings table.
v0.2.6 2026-08-15 obj-cas-imm-966aed3bd862	The first demo ships: a vault app running live inside a sgit.ai page from a published read-only key. A new vault (Field Notes, 4bshby5n) was created from scratch for it (a self-contained app following the authoring contract, generative SVG art, content in content.json read over the bridge) and /demos/vault-app-embed.html is the complete walkthrough: init, commit, push, derive the read key, publish it deliberately, embed. The embed host is assets/vault-embed.js (~170 lines): HMAC-derived ids, ciphertext over CORS, Web Crypto decryption, the app booted in a sandbox=allow-scripts iframe with an opaque origin, and its sg.vfs/loadCss/loadJs calls answered over postMessage, the same shape as SG/Vault's vault-in-vault, minimal by design until the UI team answers the reuse briefing. Also rewrites the one-tree-two-remotes ordering section as a clean rule (the discovery narrative is gone), adds the Demos nav section, and extends the key-leak tripwire to scan for every demo vault's passphrase, not only the site's own. Verified end to end in headless Chromium: bridge live (the app's status line reads content via sg.vfs.readText from the vault), six tiles rendered, frame origin opaque, mutations impossible by construction.
v0.2.5 2026-08-14 obj-cas-imm-fedcfbd348c0	Corrects the one-tree-two-remotes case study, prompted by a reader question: if sgit pushes first and git commits after, don't the files match? They do, tested rather than argued. With that ordering git captures the freshly written ref every time and a clean tree is the normal end state of a release; reads (ls, history, status, vault info), no-op commits and pushes, pull and fetch were all tried and none rewrites the ref. The section is now a rule about ordering rather than a claim of permanent drift, keeping the part that is true and useful: when the ref IS dirty, the bytes tell you nothing, because a rewritten ref never byte-matches even when it decrypts to the same commit.
v0.2.4 2026-08-14 obj-cas-imm-854db222f8cb	Wider layout across the site. The reading column was a classic 720px prose measure, which squeezed the content into the middle of a modern display and made every page longer than it needed to be. The measure is now 960px and the wide container 1360px, with the body type up a step (.93rem to .98rem) so the longer line keeps a comfortable character count; the home-page sections (hero, terminal, feature grid, cards) scaled in proportion, and the deploy-section nav column widened with them. Verified at 1600px (no overflow, content fills the frame) and at 390px (no horizontal scroll).
v0.2.3 2026-08-14 obj-cas-imm-6deb6376d9bd	Plans and briefs from the 14 Aug briefing pack. Publishes the implementation plan for the Why reframe (boundary map), the serialised-pull-request lead example (with one honesty gap found while planning: the diff emit exists as history diff --json, but the CLI has no apply/import command, so the page will ship as PARTIAL and a brief goes to the CLI team asking for sgit diff export/apply plus a published diff format), three end-to-end demo vaults with deliberately published read keys, the embed-reuse work, and the component registry (components, never plugins, plugin stays reserved for capability grants; registry gated on indexing being observed). Files a briefing to the SG/Vault UI team with six concrete questions about reusing their app-iframe host code inside sgit.ai pages, linked from the briefs page.
v0.2.2 2026-08-14 obj-cas-imm-29aa935bd44a	New case study: one working tree, two version control systems, the workflow this site is actually developed with. One folder is both an sgit vault and a git repository; a release is two pushes of the same tree. The page covers what each remote carries, the one-file .gitignore boundary that makes it safe (everything encrypted is committed; only the plaintext local/ tier is excluded), and the finding that surprised us: the encrypted ref always looks modified to git because AES-GCM uses a fresh IV per write, so for that one file git status cannot detect staleness, proved by decrypting both sides to the same commit id. Ships admin/build/release.sh, which makes the discipline mechanical: build, validate (the key-leak tripwire gates BOTH pushes, not just the deployed one), push sgit, push git, and refuse to finish unless both remotes report in sync. The script deliberately never invokes commands that echo the vault key.
v0.2.1 2026-08-14 obj-cas-imm-49cf3a524b0c	Fixes a gap the v0.2.0 restructure opened: llms.txt is generated by walking a list of known sections, and the new case-studies section was not in it, so all three of those pages were silently absent from the machine index, present on the site, invisible to any agent reading llms.txt. The section is added, and the generator now refuses to build if any page would be omitted, which is the same guard as the orphan-page rule and for the same reason: a page nothing links to and a page the index does not list are both unpublished.
v0.2.0 2026-08-14 obj-cas-imm-d8f580db4d0f	Structural release, the middle digit moves, as the numbering note below promised it would. Two changes. (1) The root held 19 files and every page body was inlined in a 2,709-line generator; bodies now live one-per-file in admin/content/ with a pages.json manifest, and the generator is a 648-line engine that does not grow as the site does. Adding a page is a content file plus a manifest row; the build then produces the HTML, the markdown twin, the llms.txt row, the llms-full.txt section, the sitemap entry and the canonical/OG/JSON-LD tags. The refactor was verified output-preserving before any page moved: all 31 pages byte-identical. (2) Sections became folders (why/, try/, security/, skills/, briefs/) leaving 9 files in the root, all of them ones that must be there. New case-studies/ section, which is where the leaked-key incident and the live-vault architecture now live; they were filed under docs/ and deploy/ where nobody looking for a case study would find them. Links were rewritten mechanically by resolving each href against the old path and re-expressing it from the new one, then verified by crawling every internal URL from the homepage: 29 URLs, zero broken.
v0.1.27 2026-08-14 obj-cas-imm-87daa0751f0d	Entity disambiguation, after checking what search actually returns. Google's AI Overview for the bare query already knows this project, and sources it from PyPI, because the PyPI page never linked here and this site was not in the index. "sgit" is also an Android Git client, an Indian engineering college and a class of shell shortcut, so the job is not only being indexed but being resolved to the right thing. Every page now carries JSON-LD: a SoftwareApplication node with sameAs pointing at the PyPI and GitHub identifiers that already rank, an explicit disambiguatingDescription naming the collisions, and a per-page TechArticle node. Google's own 2026 guidance says structured data is not required for generative-AI features. This is here for entity resolution, not ranking. The validator now fails the build if a page has no structured data or if any JSON-LD block does not parse.
v0.1.26 2026-08-14 obj-cas-imm-5da2eb791bb2	Acts on an inbound brief from an agent that tried to use this site as documentation and could not. It reported that the site did not rank for its own positioning language and guessed the pages might be client-side rendered. They are not, the full text is in the served HTML, but the fade-in that hides the unstyled flash left body{opacity:0} until a JavaScript bootstrap ran, so any client applying our CSS without running that bootstrap rendered a complete but entirely invisible page (measured: 15,733 characters at opacity 0), which is also a hidden-text signal to an indexer. Fixed with a noscript override and a CSS-only reveal failsafe, both now enforced by the validator. Adds the crawler surface that never existed: robots.txt, a generated sitemap.xml covering every page, and canonical plus Open Graph tags. Adds llms-full.txt, every page in one document, for the very common agent harness that will not follow a link out of a fetched file, and makes llms.txt self-sufficient: inline answers to the common questions (including exactly which git operations exist and which do not) and per-page key facts, on the brief's observation that for such an agent the descriptions are the only content it will ever see. The brief and what changed are published on the briefs page.
v0.1.25 2026-08-14 obj-cas-imm-1861dd16dd11	Three changes that go together. (1) Every page now has a .md twin at the same path, generated from the same content so the two cannot drift, with internal links rewritten to point at markdown, an agent can traverse the whole site without parsing HTML, and llms.txt is now generated from the page registry rather than hand-maintained. (2) A git-and-sgit comparison on the Why page that says plainly where git is better (performance at scale, ecosystem, bisect/blame/rebase, partial commits) and how the two run side by side, as they do on this site. (3) Use cases moved to /use-cases/ with a page per situation: the problem, a working recipe on shipped commands, an honest evidence status (proven / partial / pattern), and a brief you can hand to an agent. Validator gained three rules: every page has a markdown twin, markdown links resolve, and no raw HTML leaks into the markdown.
v0.1.24 2026-08-14 obj-cas-imm-3c426ddbe9e9	Why page rewritten around the right question. The first version answered "is there a market" with verticals and a comparison table; the sharper answer is what sgit makes possible that was not possible before, so that is now the headline: six capabilities running on this site, a live site its host cannot read, read access as a publishable capability, two agents sharing a workspace neither host can read, private data with CDN economics, storage as untrusted commodity, and transit security that does not rest on the CA system (including where that goes next: the read key never leaving the client, or PKI with a client-only private key). The page now assumes the reader knows git and only covers the delta. Also corrects the business-model answer: the client being open source IS the distribution strategy, with services built on top, not "no revenue attached".
v0.1.23 2026-08-14 obj-cas-imm-89a142ee3598	A freshness window on the mutable HEAD pointer. The ref was the last per-page-view network request left; it is now checked at most once every ref_ttl_s seconds (120 by default, configurable in deploy/vault.json), so reading inside the window costs zero requests and server load scales with readers rather than page views. The cost is a bounded propagation delay, a new commit appears within the window at worst, and "check for new commit" forces a fetch that ignores it. The vault panel logs the reused ref as TTL and counts down live to the next check.
v0.1.22 2026-08-14 obj-cas-imm-d9ac70d78c31	Kills the load-time flicker of the vault panel. The panel's remembered width and open state were restored by the reader script, which loads asynchronously, so the panel painted at its CSS default width, then jumped and slid open a beat later. Restoration now happens synchronously, before the first paint, and the slide transition is suppressed until state has settled. Opening and closing the panel by hand still animates; restoring it never does.
v0.1.21 2026-08-14 obj-cas-imm-5a60bc3bf25b	Object bodies in the vault panel are now syntax-coloured like an editor (keys, strings, numbers, literals and punctuation each get their own colour) and word wrapping is off, so structure survives and long values (base64 ciphertext, object ids) scroll horizontally instead of folding into a wall of text. Highlighting is applied only when the decrypted object actually parses as JSON, so markdown blobs stay plain.
v0.1.20 2026-08-14 obj-cas-imm-78146d2f4f86	The vault panel now links to the page that explains it. There is a compact “how this works” link in the panel header (always visible) and a fuller card at the foot of the panel pointing at deploy/how-this-works.html. The panel is where you are when the question occurs to you, so it is where the answer should be offered.
v0.1.19 2026-08-14 obj-cas-imm-fe67d9589a2e	Fixes the resize grip, which shipped in v0.1.18 but was unusable: it was absolutely positioned inside the panel's scrolling area, so it scrolled out of reach as soon as you moved down the object list, and at 6px fully transparent it was invisible anyway. The panel is now a flex shell (a fixed 12px drag rail with a visible handle, plus a separately scrolling body) and dragging uses pointer events with capture (mouse, pen and touch). Double-click the rail to reset the width.
v0.1.18 2026-08-14 obj-cas-imm-6eded1c95732	Vault panel becomes an object inspector: every row now shows what the object IS (ref/commit/tree/blob), WHY it was read, and, on click, its decrypted contents, pretty-printed for JSON. The panel is width-resizable (dragged from its left edge, remembered). Plus a real optimisation the panel made obvious: the path→blob index is a pure function of the commit id, so it is now memoised in localStorage, a first visit walks every tree to learn the encrypted filenames, but subsequent visits to an unchanged commit read zero tree objects.
v0.1.17 2026-08-14 obj-cas-imm-9d5b50f68679	Vault panel: a "clear list" button that resets the request log and counters without touching the caches (so you can see exactly which objects one page needs); the panel's open/closed state now persists across navigation and reloads; cached objects record when they were stored and the panel shows their age. Navigation now scrolls to the top of the content rather than the top of the document. New page: deploy/how-this-works.html, the full architecture with hand-drawn SVG diagrams of the two-session publishing pipeline and the client-side read path.
v0.1.16 2026-08-12 obj-cas-imm-34684a789fe6	New /why page answering the sharpest public criticism of the project ("I see no market or value whatsoever") directly and without marketing: who actually has the problem, why git-crypt/Dropbox/S3+KMS do not cover it, the market question answered plainly (the CLI has no revenue attached; hosting is the commercial layer; no TAM claims), where the criticism is right, and a twelve-question FAQ pre-answering the promised follow-ups.
v0.1.15 2026-08-12 obj-cas-imm-0959988dd4fe	New Deploy section: self-hosting guidance rendered LIVE in the browser from an encrypted SG/Send vault, using a published read-only key, ciphertext over CORS, AES-256-GCM decryption via Web Crypto, no copy stored on this site and no rebuild when the SG/Send team pushes. Includes a three-tier cache (session memory, permanent Cache API for immutable objects, always-fresh ref) and a vault debug panel showing the HEAD commit, per-object request log, and cache hit/miss stats.
v0.1.14 2026-08-12 obj-cas-imm-3b54c02dbb96	Two new pages, both linked this time: docs/exposed-vault-key.html (the rotation runbook plus the case study of this site's own key leak) and briefs.html (cross-team briefs, which v0.1.13 built but never registered, so nothing linked to it). New validator rule: every generated page must be reachable from another page, or the build fails. Added a fourth CLI-team ask: history-preserving rekey.
v0.1.13 2026-08-12 obj-cas-imm-5168ef3fe1a7	SECURITY: the vault passphrase had been written into admin/build/validate.js as an anti-leak tripwire regex, which put the literal secret into a tracked, public file (present in 3 commits). Removed; the tripwire now reads the secret from the gitignored local/ tier and scans for it, so it can never be hardcoded again. The key must be treated as compromised and rotated. Also: a /briefs page collecting the cross-team briefs (multi-agent collaboration log), and a "contacting the server" notice before network commands in the browser terminal.
v0.1.12 2026-08-11 obj-cas-imm-e8ceb3fc2239	In-browser clone completes: serial-executor shim for Pyodide (WebAssembly cannot spawn threads, so all parallel blob transfers run sequentially in the browser), validated natively against the live server with thread creation disabled: full 225-blob clone of this site vault. A serial/auto-detect mode is proposed upstream to the sgit CLI.
v0.1.11 2026-08-11 obj-cas-imm-c9afa76a79cb	Browser-transport fix for in-browser clone: drop the redundant X-API-Key header (the servers CORS-allow x-sgraph-access-token but not x-api-key, and one disallowed header fails the whole preflight, diagnosed live from the first user clone attempt); CORS/network failures now surface as readable HTTP 599 errors instead of a Pyodide SystemError.
v0.1.10 2026-08-11 obj-cas-imm-deac6363bff9	In-browser terminal on /try: the real sgit CLI in-process (init, commit, status, history, and network commands via a browser XHR transport: clone/push/pull straight to the SG/Send servers), plus a busybox of file commands over the in-memory filesystem. Key hygiene: every example key on the site is now an obviously-invalid placeholder (format-valid example keys are squattable namespaces), enforced by a new validator rule.
v0.1.9 2026-08-11 obj-cas-imm-83b8c23a1baa	"Try sgit in your browser" page: the real sgit-ai wheel running client-side under Pyodide (verified in headless Chromium first), key derivation, encrypt/decrypt, an in-memory vault round trip, and a Python REPL. Plus: bootstrap fast-path for static hosting (no 2.5s bridge wait on GitHub Pages), CNAME for sgit.ai, and GitHub Pages deployment via Actions in the SGit-AI__Website repo.
v0.1.8 2026-08-11 obj-cas-imm-775783f31110	Skills promoted to a top-level nav item with a new /skills page and the three agent skills shipped in the vault (latest versions, verbatim); llms.txt added at the vault root, encrypted for key-holders today, a standard public llms.txt when the site deploys to GitHub Pages; Home nav link retired (the brand mark covers it).
v0.1.7 2026-08-11 obj-cas-imm-c226a3aff160	SG/Vault section rebuilt from the official docs bundle: corrected security-page structure-key claim to current reality, git page aligned with the publishing guide (three-rule boundary, leak audit, GitHub round trip, restore drill), new pages for static hosting on GitHub Pages, sub-vaults, and no-code content authoring; .gitignore extended with work/ and *.pem rules.
v0.1.6 2026-08-11 obj-cas-imm-f62d9bd2d0d4	Corrected git integration to the side-by-side design: git now tracks the encrypted .sg_vault store (only the plaintext local/ folder is excluded), so a git remote doubles as a zero-knowledge mirror of the vault. Pattern documented on the git-and-vaults page.
v0.1.5 2026-08-11 obj-cas-imm-353038cc3e56	Git integration: .gitignore (keeps .sg_vault/, above all local/ keys and token, plus git metadata and build noise out of git and out of vault snapshots) and .gitattributes (raw sgit store files marked binary/-diff/-merge; generated *.html marked linguist-generated).
v0.1.4 2026-08-11 obj-cas-imm-90254d9591ff	New SG/Vault section, for now the official sgraph platform documentation: SG/Vault & the platform, building vault apps, the window.sg bridge & host capabilities, and "git repos inside vaults" (engineering preview of the pure-Python git reader, verified against a real 906-commit repo).
v0.1.3 2026-08-11 obj-cas-imm-46a8b14d4fca	Beta status (in production use), light theme, admin & engineering section, per-push version badge on every page, SG/Vault & SG/Send now link to sgraph.ai, design-improvements brief for Claude Code.
v0.1.2 2026-08-11 obj-cas-imm-c3084abbba8c	Replaced the proposal app with the sgit.ai MVP site: 12 individually-navigable pages, shared CSS/JS loaded through the SG bridge, full-strength keys in all examples.
v0.1.1 2026-08-11 obj-cas-imm-7f1fbacf0485	Initial vault app: the positioning & messaging proposal microsite with an embedded landing-page prototype.