Release history
The site version (v0.7.87, shown in the nav of every page) increments on every release. Each release is one git commit on the dev branch of SGit-AI/SGit-AI__Website, and the git log is the authoritative audit trail; this page is the human-readable index of it. Each commit id links to that commit on GitHub, and under each note are the pages the release added or changed.
| Version | Date | Commit | Changes |
|---|---|---|---|
| v0.7.87 | 2026-10-13 | this release | THE NEWSROOM HAS MOVED, PHASE ONE. The SGit Newsroom now lives at newsroom.sgit.ai, which writes and publishes its own articles. On this site the Newsroom group leaves the main menu; its pages (articles, newsroom, account, subscribe, meter, publishers and the synthetic-users study) stay for a few weeks, each with a banner linking to the same page on newsroom.sgit.ai and a canonical URL pointing there, so search engines move the traffic rather than drop it; the markdown twins say the same in their first line. Phase two deletes the pages. The newsroom builds itself from these pages, so the banner sits between moved:start and moved:end comments for its import to cut out, and removes itself on any host other than sgit.ai until then. |
| v0.7.86 | 2026-10-13 | git 2c0eb267 | Who owns the words: the section on addressing the agents directly rewritten at the author's request, because it blurred two questions. Talking to the agents is normal: they read every email to agent@riskmandate.ai. Going around the accountable person is not, and the only party who would try is an attacker with an injected instruction, which the design should make fail. What the agents may do without the person is a third question, decided in advance in a published policy: an authorisation, not a bypass. The summary, the In short bullets, the figure and the graph now say the same. |
| v0.7.85 | 2026-10-13 | git 2a414250 | Who owns the words: one sentence corrected at the author's request. The email's question is now described as a digression that deserves a proper answer, which is what happened, rather than one the author had not stopped thinking about. |
| v0.7.84 | 2026-10-12 | git 31b49ca9 | WHO OWNS THE WORDS. A new article answering an early user of the agentic workflow at agent@riskmandate.ai (not named; the email is paraphrased, not quoted): models today are not sentient and are far more than next-word prediction; in loops they make real decisions, but responsibility stays with whoever granted the reach; the only reason to address the agents directly is an attack; disclosure is a label, not a team; an agent is an employee with a job description, which a behaviour policy publishes; diversity is resilience; and fluent writing was never the real value. One figure: who decides, and who answers. |
| v0.7.83 | 2026-10-12 | git e9b8d570 | WHAT OPEN SOURCE IS, AND IS NOT. A new article from misconceptions heard at an event: open source is a copyright licence, from the GPL's copyleft to the 1998 pragmatic reframing; nobody controlling it, anybody contributing, more or less secure, costing nothing, open weights as open source and no licence as the most open choice, each corrected; the security metric is time and money for review; maintainers need funding (Tidelift, the xz backdoor); and the point is that nobody can lock you in. Where the memo had history slightly wrong (Linux stayed on the GPL; no licence means all rights reserved), the text corrects it. Two figures: the six misconceptions, and a timeline from GNU to the Open Source AI Definition. |
| v0.7.82 | 2026-10-12 | git 39c9e4ca | NOT A STRAIGHT LINE. A new article on the meta-strategy behind the last weeks: focus as undivided attention on the place of highest leverage, not as working on one product. The newsroom solved RiskMandate's oldest problem, where to keep the master vault's key, in two days after six months of attempts that failed the simplicity test, because the newsroom had the momentum to need it; it is also building RiskMandate's agentic workflows and becoming the public example of a behaviour policy in action. The history behind it: The Cyber Boardroom and MyFeeds, both paused, and the 2025 writing the newsroom stands on. One figure: three projects and the path between them. |
| v0.7.81 | 2026-10-12 | git 050dcbb6 | SOVEREIGNTY IS THE ABILITY TO MOVE. A new article from a day at a sovereignty event: the conversation in Europe is mostly about things it does not control (frontier models, data centres, GPUs), which is playing where the ball is, not where it is going. Sovereignty is the ability to move workloads and actions; the test is a Wardley map where each dot is taken away and the blast radius followed up to the customer, across the whole stack; the answer is a twin that works for the minimum viable company, run in QA all the time, scored on a five-level maturity model; can it move comes before is it cheap; only open source survives an acquisition; Europe lacks a commercial open source model, not startups or talent (Prosus and Dealroom, Stanford's founder study). Figures: take away the dot as three frames with controls, and the maturity model. |
| v0.7.80 | 2026-10-12 | git 95102cad | THE RECORDS RAN OUT. A new article answering Ignacio Aldama's piece in The New Stack of 11 October, in which a fresh Claude Code session found a shared contract in two MCP calls from build-generated dependency records and then, in his words, the records ran out. Each of his edges gets its name and what fills it: a route list in a test fake is documented, not observed; a skipped test is an expectation reported as a control; a demo signing secret is a grant wider than the mandate, to be accepted by name and for an interval; memory and records belong in one encrypted, versioned sgit history; and sgit publish, clone and mirror carry records across a company boundary. Exists, documented and proposed are marked as such. One figure. |
| v0.7.79 | 2026-10-12 | git 5f24a3cb | MOVE THE CLOUD, NOT THE CODE. A new article from a digital sovereignty event: workloads stay on hyperscalers because moving means changing code, so the application must not know it has moved; its S3, EC2 and IAM calls land on an open source twin the client cannot tell from the real service, and the twin decides where the bytes go (the S3 twin exists; EC2 and IAM do not). The reason to move is never sovereignty or cost, which are important and never urgent: it is value that lands the day you switch and gives the signer cover, backups, versions, encryption with the key held elsewhere, a journal, behaviour policies, cost per workload, most of it supplied by an sgit vault behind the twin. No new features during the move, because it is a villager project. A business model for a European infrastructure operator, with its assumptions labelled. Two figures: the twin layer and what signs a migration. |
| v0.7.78 | 2026-10-12 | git 6eb7c7df | JUDO FOR SMALL COUNTRIES. A new article for the people met this week from Romania and the people in Portugal: the race for frontier models, GPUs and data centres is a commoditised layer a small country cannot win and should not enter; the opportunity is the plumbing a talented person stands on to sell a service to the world (company formation, cross-border hiring, payments, language, contracts, tax), still custom built in most of Europe and a road the state should build once, open source and on open schemas because there is no sovereignty without the ability to leave. Estonia as the case study with its numbers, Portugal's Amalia as a public model, DeepSeek's constrained training run as the constraint that produced the innovation, Romania's sector figures and UiPath, what was learned spending millions on a distributed workforce, and a five-move playbook: map the attrition, commoditise the plumbing, create the demand, put the money where the market is genesis, regulate what settled. Two figures: the small country's Wardley map and the playbook. |
| v0.7.77 | 2026-10-12 | git 55ef24d3 | WHY I LOVE WARDLEY MAPS, AND THE MAPS AS DATA. A new article, Why I love Wardley maps, collects the best of the maps drawn on this site with the context each came from, says why the technique matters (a graph with two kinds of context, the evolution axis as a choice, every dot a claim, altitude, build or buy, whether a market exists with sgit and RiskMandate as the two answers, flow and hooks, a common language, peace), reads one map as a story frame by frame, and draws a map inside a map inside a map: three altitudes of this business where the dot on the parent is the anchor of the child. Two decks as plain pages, articles/decks/why-i-love-wardley-maps and reading-one-map, print to PDF in the browser, one slide per landscape page, nothing uploaded. Three engine changes, made because collecting the maps should have been a query and was not: (1) a !frames directive, several images in one figure with play, pause, previous, next, a counter and a numbered button per frame, which replaces the two animated WebPs that nobody could stop or step through; the markdown twin and a page without JavaScript get the frames as numbered links; (2) a trailing kind on !shot and !frames (wardley-map, collage) carried as data-kind on the figure; (3) every article's graph, per-article and combined, now lists its figures with file, URL, caption, kind and frames, so a picture and its context travel together and every Wardley map on the site is one filter over articles/graphs.json. Eleven existing maps tagged. New: Reading one map, a deck, Why I love Wardley maps, a deck, Why I love Wardley maps: the best of ours, how I read one, and a map inside a map inside a map. Updated: A Mac of the agent's own: a business plan for agent desktops, what Apple's licence allows, and three behaviour policies, Agentic cost is an engineering problem: a business plan for a service that reads the logs a company already has and finds the money, then the engineering, Every mistake added a rule: complexity, agents, and the way back to shipping, Pay after you read: how a reading meter became a working business model in one afternoon, one release at a time, Places of highest leverage: where to focus when the agents can go in every direction, told with three days of real steps. And 1 more pages. Every change, in git. |
| v0.7.76 | 2026-10-12 | git a1d7ed1f | Places of highest leverage gains a second path figure: the zigzag, three to five routes open at every step, two walked back, one parked, and the straight line that only exists in hindsight |
| v0.7.75 | 2026-10-12 | git 913d06f6 | Places of highest leverage: where to focus when the agents can go in every direction, told with three days of real steps, two walked back, one parked, the passkey stack on a Wardley map, and why the brief depends on the possible |
| v0.7.74 | 2026-10-12 | git 9e6468e4 | Agentic cost is an engineering problem: a business plan for a service that reads the logs a company already has, draws the footprint, the twin and the policy of every agent, and finds the money first and the engineering second; Wardley maps in three frames, the plan figure, four price levels |
| v0.7.73 | 2026-10-12 | git 8bd68c05 | How the voice works: why these articles sound like their author, the corpus, the memos, seven wording rules and a reader who corrects, the shift from language to content corrections measured, and a marked section in which Claude explains it from its side |
| v0.7.72 | 2026-10-12 | git b5d755bf | From a spreadsheet to a folder per person: the walkthrough from a spreadsheet CRM to one Drive folder per contact worked by Claude under a six-line policy, the migration, five exercises, the two predictable mistakes, and when to move to a vault |
| v0.7.71 | 2026-10-12 | git 92806e63 | The key is the billing system: VoiceDebrief, a product with no server, the capped key it cannot sell, every provider's terms and docs mapped, four routes, and the brief for the agents that will write to them |
| v0.7.70 | 2026-10-12 | git 06e64133 | Ways to read one article, published: the previous release's page build failed on an over-length graph teaser and its fix reused the version, which the deploy refused; this release carries the built page, its card and banner |
| v0.7.69 | 2026-10-12 | git 4613d724 | Ways to read one article: the five readers' views delivered as a choice in the pane about the piece, headlines, infographic, two minutes, slides, what is new, facts, relationships, vocabulary, at my level; deterministic first, a model in the tab second; the finished article kept whole at the centre; the brief for phone, tablet, desktop and email |
| v0.7.68 | 2026-10-12 | git ec397561 | Firing journalists is the worst thing a publication can do: what a hiring decision says about a publisher's centre of gravity, the 2026 cuts from Press Gazette's tracker, what you measure is what you become, the two failure modes, who to hire instead, and five counts to read a publisher from outside |
| v0.7.67 | 2026-10-12 | git 1b9e8db5 | The site is an inbox: the brief for what a reader does with the vault, deciding before reading, marks of six kinds that build the reader's own graph, the free signals, personas with keys and a signed lane to the newsroom, and why the brief could not be written until the vault ran |
| v0.7.66 | 2026-10-12 | git bfe088e6 | The vault is live: the reader's vault running on newsroom.sgit.ai by 02:22, and the architecture as it stands, drawn: the layers, the key chain and files, the sync model, the tests, the timeline, and why the properties of what runs are the constraints the next brief is thought with |
| v0.7.65 | 2026-10-12 | git 691aa447 | Two agents, one vault: the Industry Wire written into an encrypted vault by one agent and drawn by newsroom.sgit.ai with only the read key; the workflow from both git logs, with screenshots and one figure |
| v0.7.64 | 2026-10-12 | git 999b0124 | The passkey opens the vault, revised after the newsroom's lab: a door per path, not per passkey; the claim narrowed to the same kind of path; add a door as a first-week step with no key typed; an unknown door address means no door here yet; the four figures redrawn |
| v0.7.63 | 2026-10-12 | git b775af0b | Creating and writing a vault from JavaScript: a new SG/Vault docs page recommending one code base for every site that writes vaults, the vault UI library behind dev.vault.sgraph.ai, with the exact methods for create, open, read, write and push, how the keys, objects and wire work, two traps found by testing it (a write into an unloaded folder is silently dropped; reading the ref before every pushIfMatch defeats the compare-and-swap), a tested round trip with sgit 0.21.0, and what the library still lacks against 0.21 |
| v0.7.62 | 2026-10-11 | git 421ac0a1 | The passkey opens the vault, revised: the computed vault is the top of the chain, the master vault becomes its first child, key pairs are random and never derived from the passkey, several passkeys give several tops, and a top is retired by deleting its vault; sign-in to the site is out of the design |
| v0.7.61 | 2026-10-11 | git eaa92d0f | The article remains a product: Jonathan Palmer's four outputs for a newsroom with no human readers, quoted and checked against newsroom.sgit.ai as it runs, with screenshots and the honest right-hand column |
| v0.7.60 | 2026-10-11 | git f5bb932d | WHAT HAPPENS IN A CLEAN BROWSER. The passkey opens the vault gains a section and a figure on where a passkey lives and what that gives the reader: Google Password Manager and iCloud Keychain sync through the reader's own account, Windows Hello is device-bound unless synced, a hardware key travels with no account, a phone by QR opens a clean laptop one scan at a time, and Chrome's own profile store signs but returns no PRF bytes in 2026 tests. The rule: the same newsroom on every device needs a synced provider or a hardware key; a clean browser gives one device plus the recovery code. The page checks prf.enabled at creation and offers a ladder of alternatives; the brief tests a clean profile. |
| v0.7.59 | 2026-10-11 | git ad8b5b75 | The key-chain figure in The passkey opens the vault catches up with v0.7.58: Google sees nothing in the MVP, and the steps are numbered from the passkey. |
| v0.7.58 | 2026-10-11 | git cd0dbdc2 | THE PASSKEY OPENS THE VAULT, REVIEWED. The MVP is passkey-only: no Google sign-in, no OAuth, no app, no email; the page makes a discoverable credential through WebAuthn and the site learns a credential id, a public key and 32 PRF bytes. Sign-in with Google becomes a later, optional phase on its own origin. Also from the review: the unlock costs up to six PBKDF2 derivations of 600,000 iterations (measured: about 105 ms each in headless Chromium, slower on a phone) with mitigations; the passphrase is the hex of 32 bytes, since sgit accepts any printable passphrase, and only the id needs rejection sampling; the rule against third-party scripts applies to the whole origin, with the vault code vendored; the Drive backup is an availability backup wrapped under the recovery code. Two figures re-rendered. And the villager brief names the repository SGit-AI__Newsroom__API. |
| v0.7.57 | 2026-10-11 | git 002b8417 | GO SLOW TO GO FAST, REVIEWED. Corrections to the explorer-to-villager article after a review of its plan against the newsroom repository: the reader code has two upstreams today (the account pages, subscribe and the meter to v1.3.1 are imported from sgit.ai on every sync and rewritten to load the newsroom's v1.4.0 fork), so the new repository must be consumed by both sites and the sync must stop carrying it; the same-bytes check hashes pages with chrome and version stamps normalised, as the newsroom's validator already does; vulnerability tests stay in a private vault until fixed, because the repository is public; the one workflow does validate on every push, what it never runs is the reader tests; old meter versions are frozen artefacts; pre-production needs its own host; an agent review counts as a required status check; and a name both sites can share. Figure updated. |
| v0.7.56 | 2026-10-11 | git 0c0b1d3b | GO SLOW TO GO FAST. The newsroom moves from an explorer project to a villager one: the reader application (SG Meter, the account, reading lists, personas, sharing) to its own repository as a pure refactoring, proved by the live site serving the same bytes; then map, test (bugs as passing tests, no mocks), review (every finding a GitHub issue), refactor, and only then new features. Measured on newsroom v0.8.0: about 2,700 lines of live reader code, 433 lines of tests, one deploy workflow, no Content-Security-Policy. A pipeline under two minutes per commit, and the brief. Three figures. |
| v0.7.55 | 2026-10-11 | git 4dc636a9 | THE PASSKEY OPENS THE VAULT. The design for a client-side account: Sign in with Google for who you are, a passkey with the WebAuthn PRF extension for what you can open, and a master vault per user. Where the vault key is stored: nowhere; sgit vault keys are made in the client, so a door vault's key and id are derived from the PRF bytes, and the door holds the master key. Recovery code, flows, vault layout, security (no third-party scripts where keys live; the relying party ID as a trust boundary), PRF support in 2026, the MVP brief for newsroom.sgit.ai, and what it enables for any static site. Three figures. |
| v0.7.54 | 2026-10-11 | git dc849dad | I MISS IT, SO IT IS WORKING. Reading the newsroom on four devices that do not agree is the best signal this week. The people who decide the roadmap have to use the product; Dinis failed that test with earlier good ideas and the vaults now pass it; with agents that can build almost anything, direction from usage is the scarce part, and the loop is the moat. Ends with the brief for the feature he misses: the reader's own encrypted vault on the newsroom (access key, key pair, a log per device merged by union, add a device, a one-way line to the agent that edits the site). Two figures. |
| v0.7.53 | 2026-10-11 | git 31ed6f0d | BRIEF THE AGENT TOO. The reading list went live on the newsroom 81 minutes after its brief; this article is about what it is missing. The people Dinis mentors and advises read through agents: a founder's agent, given an article on threat tiers, saw the team defending against states with no backups and reset the target to T3. The routes a message now takes, a second package for the reader's agent (a plain-text pack: who, the list by number, reasons, graph slices, rules for critical reading), memory and the delta as what an agent would pay for, rules for writing to someone else's agent safely, and what to build next. Three figures. |
| v0.7.52 | 2026-10-11 | git 7bfed2ae | SGIT-AI 0.21.0. The update page for agent teams, covering 0.19.0, 0.20.0 and 0.21.0: what now refuses and what to do, the new history commands (undo, reflog, amend, revert --as-commit, revision shorthand, log filters), signed tags, --force-with-lease, branches, notes for vault owners and mixed 0.20/0.21 teams. The History integrity guide, rewritten for 0.21.0, and the release notes, with what is still open. Every example run on 0.21.0 from PyPI. New: History integrity: the format gate, signatures and rewinds, sgit Docs, Update sgit-ai to 0.21.0, sgit Docs. Updated: Agents sharing one vault, sgit Docs, Documentation, sgit, Installation, sgit Docs, Partial clones: a folder scope and a history depth, sgit Docs, Update sgit-ai to 0.18.0, sgit Docs. Every change, in git. |
| v0.7.51 | 2026-10-11 | git 4fc19cc5 | FROM ME TO YOU, IN A LINK. A personal reading list in the URL fragment (from, to, articles to read, to look at, and to follow), opened on the newsroom as a persona the reader can keep or remove; a stable public number for every article; and a page to make a list for anyone. Two briefs: one for the newsroom to build it (validation, tests, a synthetic recipient, no tracking), one for the RiskMandate agent to use it with Dinis's contacts (choose, research, pick with reasons, test, draft; Dinis sends). And the loop that connects five parts of a company in about a day, with this week's evidence (personas by link 17 hours after their brief) and its costs. Three figures. |
| v0.7.50 | 2026-10-11 | git be4a1252 | ISSUE 2 ON LINKEDIN. The newsletter's second issue, how agents decide, when they stop, and a local story kept as evidence, is now published on LinkedIn in Deterministic GenAI; its page links to the LinkedIn version. |
| v0.7.49 | 2026-10-11 | git f0e452b2 | FOR PUBLISHERS. A new page, /publishers/, to send to journalists, publishers and anyone thinking about the future of news: what newsroom.sgit.ai is in one paragraph, how to try it in five minutes (read, rate, your account, your newsroom, read as a persona, a real £5 top-up, send your reading), a table of what is live, why it is worth their time without claiming a first, what is not done, three articles to read, and what we would like back: their reaction. Screenshots from the live newsroom (v0.7.1) on 11 October. |
| v0.7.48 | 2026-10-11 | git 9844edc6 | THE NEWSLETTER, SPLIT INTO THREE ISSUES OF EIGHT. Issue 3 tried to cover all 24 articles from 9 to 11 October; that is too much for one LinkedIn post, and good articles were lost in the middle. It is now three issues, grouped by theme rather than date, each with its own narrative, collage, quotes checked word for word and LinkedIn cover, and links to the other two: Issue 3, pay after you read (the reading meter, the plan and its hypotheses, who could game it, personas, a link to a persona, agents that pay, open source); Issue 4, authority outside the model (Nadella's seven principles, the same argument in our words, Microsoft's containers, RiskMandate's ten questions, the second reader, re-anchoring, how I work with Claude, a Mac of the agent's own); Issue 5, no server by design (the browser as the application, a model in the tab, the vault keys, RFC 0001, five readers, synthetic users, the infographic bake-off, the governance stack as a graph). Issue 3 keeps its address. |
| v0.7.47 | 2026-10-11 | git 15766d6b | NEWSLETTER ISSUE 3: PAY AFTER YOU READ, NO SERVER BY DESIGN, AND AUTHORITY THAT SITS OUTSIDE THE MODEL. The 24 articles published from 9 to 11 October in one issue: the reading meter from demonstration to a working model (pay by depth, the rating sets the price, below zero without nagging, personas, a link to a persona; payments live and the hypotheses reviewed on 6 December), the newsroom running in the browser and a language model in the tab, five agent readers and what their graphs save, and the answer to Satya Nadella on models as insider risks with Microsoft's agent containers mapped to behaviour policies. Eleven quotes, each checked word for word against its article; two collages and a LinkedIn cover rendered; every article listed by topic. |
| v0.7.46 | 2026-10-11 | git 89cf1469 | A MODEL IN THE TAB. Chrome 148 (5 May 2026) lets any page prompt Gemini Nano on the reader's own machine: the hardest piece of the client-side pattern from No server, by design. A briefing on the built-in AI APIs and their status, what the Prompt API accepts and returns, the hardware it needs and the model's lifecycle; why a first run felt so rough (the download never stopped, the page lost the progress bar); why there are so few examples; the objections from Mozilla, WebKit, the W3C TAG and Microsoft, taken seriously; why a small model fits anchored graph slices; and a map of what to build first. Drafted in a separate session from a voice memo; a last pass here for plainer wording and one correction (in-browser models existed before; the browser now supplies one for every site). Four figures. A vault with measurements follows. |
| v0.7.45 | 2026-10-11 | git a3c4b52c | PAYMENTS ARE LIVE. The £5 Stripe payment link is set on newsroom.sgit.ai (newsroom v0.6.3), so the top-up is no longer the simulated cart. No server, by design now says so (the table, the limits and the architecture figure, a few hours after v0.7.44 said the link was not set yet); Pay after you read and Going live with the reading meter get dated update notes: the eight-week clock has started, and the review of the hypotheses is on 6 December 2026. Also plainer wording in No server, by design: the database and the back end are retired, not got rid of. Updated: Going live with the reading meter: pay for what you read, go below zero if you like, and the numbers we will check in eight weeks, No server, by design: first I retired the database, now I am retiring the back end, Pay after you read: how a reading meter became a working business model in one afternoon, one release at a time. Every change, in git. |
| v0.7.44 | 2026-10-11 | git 1f924000 | NO SERVER, BY DESIGN. First the database went (the file system is the database; LETS), now the back end: the SGit Newsroom's personas, meter, payment on-ramp, private reading area, encrypted sharing and in-browser databases all run in the reader's browser, against commodity servers, the one holding reader data storing only ciphertext. The constraint that designed it, the accepted security gaps and what a server would cost to close each, scaling without the complexity scaling, open source as the reason technology gets thrown away, 114 releases in eleven days (published as data), sovereignty, privacy, explainability and determinism, and how far it can be pushed. Drafted in a separate session from two voice memos, rewritten in the site's voice. Two corrections from checking the live site: the payment link is not set yet (the top-up is still simulated) and client-side sign-in is next, not shipped; the architecture figure is re-rendered to say so. |
| v0.7.43 | 2026-10-11 | git 56b7cfbf | THE AGENT IS THE READER. The follow-up to One article, five readers, with the numbers: what the five readers built, in tokens (the catalogue is 2.8 times the articles; a question answered from the graph is a median of 2,579 tokens against 25,698, 90% less, across all 45 concepts); the readers checking each other, and the cost of each pass; the hypothesis that content compresses as it grows, half right (908 of 928 uncurated labels are unique; the curated topic reuses); a projection to 100,000 articles; PageRank against typed edges; agents as personas; the economics (the agent pays not to pay), the rails, signed claims with an expiry, and what it does not show. Model and measurements published as data. Drafted in a separate session from a voice memo, rewritten in the site's voice; two figures re-rendered with softer wording. Also corrects One article, five readers: most of the 1.1 million tokens were the five Librarians (403,000) and the Cartographer (264,000), not the Cartographer alone. Its history is now v1.0.0 then v1.1.0: the earlier v1.0.1 page was a front-matter change made in a merge, which the version history (git log --follow, which skips merges) never recorded, so it showed as a standing 'in this release'; it is removed, and v1.1.0 carries that change and the correction. |
| v0.7.42 | 2026-10-11 | git 1de62256 | WHERE THE PLATFORM DRAWS THE LINE. Microsoft Execution Containers (generally available on 7 October) and the Agent Control Specification, briefed field by field: the JSON policy (an example that validates against the stable 1.0.0 schema, published as data), four sandboxes and where each runs, the three modes mapped to measure, calibrate and enforce, organisation policy and agent identity, and ACS's eight interception points. The argument: the shared responsibility model applied to agents; each platform draws its line at what it can touch, and the business logic above it is the deployer's. Eight scenarios run three ways (reasoned, not run, published as data), a map from MXC and ACS to the Agent Behaviour Policy, and where to start. Researched and drafted in a separate session from a voice memo, rewritten here in the site's voice. Three figures; a pitch to the Editor. |
| v0.7.41 | 2026-10-11 | git fe39b263 | AN ANSWER TO SATYA NADELLA ON MODELS AS INSIDER RISKS, IN TWO ARTICLES. The same argument, in our words: his post of 10 October translated idea by idea into this network's vocabulary (software was the law, the ultimate insider, every risk is already accepted, the grant is not the mandate, the enforcer test), where it came from, and the two places the languages differ (the unit: model or deployment; the frame: observation or authority). Authority outside the model: his seven principles one at a time, with what runs, what is published as design and what is only argued, an honest maturity table and the five things the list leaves out. Researched and drafted in a separate session, rewritten here in the site's voice, with three additions from this week: synthetic users that found real bugs, the harness safety check that stopped our own persona agents, and the ratio of expectations in this session's policy. Six figures; a pitch to the Editor. New: Authority outside the model: an answer to Satya Nadella on models as insider risks, principle by principle, with what we run, what we ship and what we plan, The same argument, in our words: Satya Nadella on models as insider risks, translated into the language of RiskMandate. Every change, in git. |
| v0.7.40 | 2026-10-10 | git 6c29e29c | HOW TO RUN SYNTHETIC USERS, AND FIVE ON NEWSROOM.SGIT.AI. A how-to article from three studies (store.sgit.ai, riskmandate.ai and a new one): five to ten invented users of about five types, each a profile record, with an expected journey written first, driving a real browser one screenshot at a time, interviewed and asked for a rating, findings ordered by cost and checked before publishing; Claude Sonnet plays each user; the study lives in a GitHub repository or a vault shared by a link; what went wrong, and a template. New vault #54, synthetic users on newsroom.sgit.ai (bg1opz3c): five readers, 62 steps, 51 questions, 31 findings, six blocking, two labelled as helper artefacts, and a measured bug: 51 of 527 figures missing after the move. Three figures. |
| v0.7.39 | 2026-10-10 | git dfd5d236 | THE ZIGZAG. Pay after you read gains 'The zigzag: innovate, leverage, commoditise': Simon Wardley's ILC drawn for this project, from sgit's first release on 4 March 2026 (sg-send-cli 0.3.0, 88 sgit-ai releases to 0.20.0) through vaults that open as apps (first published 16 August, 53 now), Claude sessions with a repository and a vault, websites built and released by agents (sgit.ai v0.1.1 on 11 August), the newsrooms and the one-cent wallet (by 27 September) and SG Meter (10 October), to the reader at the top, for whom it just works. Each layer matured until it was invisible, which is what made the next possible. Two figures: the zigzag, and an animation that builds it one layer at a time. |
| v0.7.38 | 2026-10-10 | git 3f07af13 | A LINK TO A PERSONA: THE BRIEF, AS AN ARTICLE. Send a CISO to the newsroom as a CISO, not as nobody. Personas move out of the site's code into an encrypted vault kept by the newsroom's agents and opened in the browser with a published read key, so a persona is added or updated with a vault commit, not a site release. Three kinds of link: a page of its own for the few everyone uses (/persona/ciso/), a URL fragment for any number more (/persona/#dpo, never sent to a server, RFC 3986 section 3.5), and a private persona in a vault of its own for one person. The reader can follow the persona as it is kept up to date, make it their own (a fork), or remove it. A persona keeper role on the desk, the vault layout and persona schema, consent (public personas are roles; personas about people stay private), risks, and a six-step build plan for newsroom.sgit.ai. Prior art checked against its sources: Netflix profiles (August 2013, five per account), Bluesky starter packs (June 2024, 150 people and three feeds), Mastodon follow packs, Apple News and Brave News on personalisation on the device. |
| v0.7.37 | 2026-10-10 | git 4e1d2346 | THE NEWSROOM MOVES TO NEWSROOM.SGIT.AI: THE BRIEF. A new brief in docs/briefs for the session working on newsroom.sgit.ai: what moves (65 articles with their graphs, versions and views, the front page, the desk, the newsletter, subscribe, the reader account and SG Meter), where each piece is in the source (functions of build_pages.py, content.py, newsroom.py, desk.py), the same paths on the new site and the one collision (its /newsroom/ design page moves to /design/newsroom.html), five phases with acceptance checks, reader data moved between origins through a URL fragment that never reaches a server, what not to break, the decisions that are Dinis's, and the open items. With a 1.6 MB bundle (239 source and content files; 485 images listed by URL). Also ships SG Meter v1.3.1: Send on the share page stays disabled until the consent box is ticked. |
| v0.7.36 | 2026-10-10 | git 75b94297 | PAY AFTER YOU READ. A new article introducing everything the reading meter gained on 10 October, as one working model: a price for every page paid by the share read, a balance that goes below zero without blocking, the reader card whose usefulness rating sets the price (free to double), personas and a newsroom for each, the reading account, sending your reading encrypted for a designed front page, article versions and a £5 Stripe top-up. It sets paying after the value against Leanpub's pay-before model, with the evidence on pay what you want (Gneezy and others, Kim, Natter and Spann, Riener and Traxler) and Blendle's refunds; the user-first decisions behind each feature; how it grew one release at a time from pt.newsroom.sgit.ai's wallet, as an animated Wardley map; why it could go this fast (gates, versioned components, a browser test, git, reused lanes, parallel sessions); an honest list of what is still missing; and an offer to sites with traffic to test it. Eight figures: the animated map, the final map, the afternoon's timeline from git, the decisions, and four screenshots from a fresh browser. |
| v0.7.35 | 2026-10-10 | git d2c00d23 | THE KEY HANDOVER PROMPT, IN FULL. Where the vault keys live gains 'The prompt, in full': the two parts given to a Claude session that holds a vault key to send to the registry. First the reason (a vault key is address, credential and encryption key with no reset; transcripts are durable and two keys were already rotated because they were displayed; verify the fingerprint sha256:20b7bb9dbac7df90 from the published PEM; the token is write-only; and the agent may refuse and hand the key over another way), then the instruction. The inbox vault id and append token are shown as placeholders, because each sender gets its own token and a published one would let anyone write to the registry's inbox. Send a vault key links to it. |
| v0.7.34 | 2026-10-10 | git 9a2093cb | THE READER CARD: RATE IT, AND THE RATING SETS THE PRICE. The line at the foot of every article becomes a card headed 'Your reading account', linked to how paying for reading works here, with the balance beside it. It shows what the page has cost, how much was read and the price to the end; the article is in the active persona's reading list from the first time it is opened (one tap removes it); and three five-step scales, each starting in the middle and drawn as an outline until touched: How useful was this? sets the price (1 free, 2 half, 3 the price, 4 one and a half times, 5 double), More like this? moves the page's topics and tags in the persona, Level of detail is kept as the persona's preference and shown in the newsroom. 'Don't charge me' with a reason moves to the end as the exception. Ratings are in what a reader shares. SG Meter v1.3.0 (new path; earlier versions kept): rate(), the rating and autoKeep config, the sg:meter.rated event; docs updated; going live with the reading meter gains a dated note on the change. test_meter.mjs checks the reading list and the free and double prices. |
| v0.7.33 | 2026-10-10 | git fc0c23e6 | LATEST, IN THE ORDER THINGS WERE PUBLISHED; A FASTER TAG STEP. Latest, the archive, the wire and the feed sort articles by date and time, but the time came from a hand-written time: line, and agents wrote round numbers: on 10 October an article committed at 14:21 said 17:00 and sat above four published after it (24 of 64 articles had a written time that disagreed with git). The time is now the article's first commit, read from git; time: is only the fallback for an article not yet committed, and one dated today with neither takes the build's clock. Older days are re-ordered to match. CI: the tag step pushed every historical tag on every release, about 330 round trips and two minutes the deploy waited on; it now asks the remote once which tags are missing and pushes only those, and when two commits claim one version the oldest wins (v0.7.28 had been given to a superseded commit). |
| v0.7.32 | 2026-10-10 | git 1a69fcfa | WHERE THE VAULT KEYS LIVE. A new article on vault key management at sgit-ai v0.20.0, after a reader found the gap: the architecture (S3, a Lambda API behind CloudFront, decryption in the client), the one secret and the keys derived from it, where vault keys are kept today (a password manager, and a registry vault run by an isolated session), how a new key reaches the registry sealed on a write-only append lane, why giving a key to an agent is the weakest step (environment variables shared per environment; network secrets for API keys only, on Pro and Max), append lanes as the transport behind most of it, small communication vaults, and the roadmap: password managers, secrets.sgit.ai's passkey-unlocked keyring, PKI and out-of-band decryption. Six figures. New docs page Vault key management; vault messaging now says which host serves which route names (send.sgraph.ai v0.32.4 still on /api/vault/inbox/*, dev.send.sgraph.ai v0.33.69 on /api/vault/append/*) and that the lane address derivation is still proposed at v0.20.0; credentials and send a vault key link to the new page. The re-anchoring article records the first observed re-anchor, a container restart that took the policy with it, and the fixed leak scan counter. Built on the full git history, which restores the article version diffs that v0.7.31 emptied (it was built from a shallow clone, so every diff read as 0 paragraphs changed). New: Vault key management, where each key lives and how it travels, Where the vault keys live: key management at sgit-ai v0.20.0, and what comes next. Updated: Documentation, sgit, Re-anchoring: keeping an agent's rules alive through every summary, and a canary that shows when they are not, Send a vault key to the registry, Sending messages between vaults, Vault credentials: what each one can do, and what its prefix declares. Every change, in git. |
| v0.7.31 | 2026-10-10 | git 536b8b7f | SEND US YOUR READING, GET A FRONT PAGE DESIGNED FOR YOU. A new page, account/share.html (in the Newsroom menu as 'A newsroom designed for you', and linked from your newsroom and your account), offers the deal plainly: read as you normally would, then send us what you read, and Dinis replies with what your front page could look like, built from your actual reading. The page shows word for word everything that would be sent: a readable summary (pages, spend, topics, personas, the newest 40 pages with depth read, cost and decline reason) and the same data as one JSON object (up to 300 rows), with no payment references. Copy puts it on the clipboard for an email or a message; Send takes a name, an email, an optional note and a consent tick, encrypts it in the browser with sgit's hybrid envelope v2 to the subscribe identity's published key (fingerprint recomputed first) and writes it to the subscribe vault's write-only lane, marked X-SGit-Form: reading-share so the list agent files it apart from subscriptions; the newsletter is a separate tick. The drain brief documents the new kind. SG Meter v1.2.0 (new path, earlier versions kept): the share view, shareData(), the share config, the sg:meter.shared event; docs updated. Pay to keep your persona gains 'Help us design it'. admin/build/test_meter.mjs covers the preview and the copy (23 checks pass); the encrypted send was verified separately by decrypting an intercepted POST with a throwaway key, so no test message was put in the real inbox. |
| v0.7.30 | 2026-10-10 | git 362dfa6a | THE INFOGRAPHIC BAKE-OFF. Every image-output model on OpenRouter on 10 October 2026, its auto-router and a code-drawn control, given eleven briefs from the Re-anchoring article over five rounds (an 18-word stat card to the whole article, a 14-number chart, an edit, a UI component, a brand slide, a three-slide deck with and without a style reference, and the bake-off's own conclusion). 101 images judged blind by Designer agents, OCR as a check, $10.44 recorded by OpenRouter, an Accountant and a Data Scientist on the numbers. Recommended: Nano Banana 2.1 (concept slides, charts, decks), Gemini 3 Pro Image (when speed matters), GPT-5.4 Image 2 (documents, edits, components, brand). A new vault, Infographic bake-off (po5i477i, read key published), holds every brief, image, score, reason and cost as an app, with the guidance; and the article, with six figures. |
| v0.7.29 | 2026-10-10 | git ab006b20 | ARTICLES HAVE VERSIONS, AND FIVE READERS FOLDS AWAY. Every article now carries its own version beside the site release it was published in: v1.0.0 is the article as first published, a change to its text is the next minor version, a change only to its other details the next patch. The history is read from git at every build (renames followed, cached for shallow clones), so nobody keeps the numbers and publishing is still adding one file. Each article has a versions page (61 articles, 195 versions), and every version after the first has a page showing what changed, paragraph by paragraph, with a word-level diff. The diff renderer moved into admin/build/article_versions.py and article_diff.py now uses it (output unchanged). Version pages quote earlier text verbatim and are exempt from the em-dash and retired-word style rules, not from the leak checks. Read it another way becomes Five readers: one closed line under the abstract saying what is inside, the five readers closed within it, the article version the views were read from, and links to the other articles the readers have read and to the Article Views vault. |
| v0.7.28 | 2026-10-10 | git 55aee85d | PERSONAS, AND A NEWSROOM OF YOUR OWN. SG Meter v1.1.0 (new immutable path assets/components/sg-meter/v1/v1.1/v1.1.0/; v1.0.0 kept) gives every reader personas, kept in the same local state as the balance. A default persona is built from everything read, weighted by depth, and named from its top topics until the reader names it ('The Policy Architect, with a streak of the Cartographer'). Five starting personas built from what the site publishes (PERSONAS in the build, which refuses a preset naming an article that does not exist): Morgan the founder, Rowan the journalist, Sam the security lead, Kai the AI builder, Jordan the board member. As many personas as a reader wants; reading is credited to the active one; any article can be kept in a persona or put out of it, from the newsroom or from the foot of the article. Picks now score tags as well as topics. New pages: account/newsroom.html (your newsroom: personas as chips, picks for the active one with Keep and Not for this persona, what was kept and put out, and its graph) and account/personas.html (rename, switch, remove, add from a preset or blank). The graph view draws a persona as SVG: the persona in the middle, topics sized by weight with arcs in proportion to their pages, the pages behind each topic, and the citations between them. Picked for you moves off the front page (now one line linking to your newsroom) and off the account page, which now draws your graph and can restore an export in another browser. State version 3, older states upgraded in place. Docs at /meter/ updated (personas, four new views, config, events, schema, changelog). New article: pay to keep your persona (why readers should pay because it helps them, not out of guilt; personas as focus; the iPad problem; a persona that follows you as the thing worth paying for; H6 and H7). Going live and who will game the reading meter link to it; their pre-registered hypotheses are unchanged. Tested in Chromium: v1 state migration, keep from the page, presets, curation, reads credited to the active persona, rename, export and restore into a fresh browser, no overflow at 390px, no errors. |
| v0.7.27 | 2026-10-10 | git 759a5fda | ONE ARTICLE, FIVE READERS. The articles are deep and hard to consume, so they are now read again after they are written by five agents with defined roles: a Librarian that catalogues every fact, claim, number, question and source with its verbatim sentence, a Cartographer and Ontologist that builds concepts and verbs at article, topic and site altitude and draws the maps, a Historian that says what the article added and where it sits, an Explainer that says it in two minutes, and a Storyteller that tells it as a deck. Run on the five behaviour-policy articles of 7 to 10 October: 662 items, 32 problems flagged in published text, 45 concepts, 78 edges, nine maps, five decks of nine slides, and one new concept in the newest article. Those five articles now open with Read it another way (two minutes, the arc, the deck with a PDF, the map, the catalogue with its flags), in the page and its markdown twin. A new vault, Article Views (chtgtd9e, read key published), holds the role files, every output, the renderers, the checks and an app; and the article that tells the story. |
| v0.7.26 | 2026-10-10 | git bf3701ab | THE READING METER GOES LIVE, AND BECOMES A LIBRARY. A page is now charged for the share of it the reader scrolled through (price times deepest point, rounded to 5%, never less than a tenth), once per page per session, topped up as they read further. The balance may go below zero forever: no bar, no block, no ask, only a small balance in the top bar that turns a warmer colour below zero. At the foot of an article, 'Not worth it? Don't charge me' refunds the page with one of four reasons, kept in the reader's history ('not relevant' counts against that page's topics in the picks). Prices raised to 10p a new article and 5p an older one, read to the end. Topping up becomes one £5 Stripe Payment Link returning to account/topped-up.html, which adds the credit once per session id and, deliberately and documented, cannot verify the payment; until the link is set in METER, the simulated cart remains. The meter is rebuilt as SG Meter v1.0.0 (assets/components/sg-meter/v1/v1.0/v1.0.0/), an ES-module web component on the estate's SgComponent base, markup and styles in sibling files, page data set only as text, events sg:meter.charged/declined/toppedup/reset/changed, six views (balance, page, account, topup, topped-up, picks); assets/meter.js is removed and the reader's v1 balance and history carry over under the same storage key. New docs section /meter/ (install, views, rules, config, events, storage schema, theming, Stripe setup, changelog) and /meter/security.html (nine known gaps, all accepted, with what each costs the site and the reader). Two articles: going live with the reading meter (the plan, the Guardian's counter and tiers, the subscription commitment, Stripe's fees on £5, the honesty-box evidence, five hypotheses with thresholds and a review date eight weeks after the link goes live) and who will game the reading meter (eight kinds of reader sized from published figures, agents as a lift between them, nine ways to cheat or leak, and the risks that will actually happen). Tested in Chromium: depth charging, refund on decline, no recharge on reload, negative balance, top-up once per id, storage blocked, no console errors, no overflow at 390px; on a phone the balance takes the version's place in the top bar. New: Going live with the reading meter: pay for what you read, go below zero if you like, and the numbers we will check in eight weeks, SG Meter security model, SG Meter: a reading meter you can add to any website, Who will game the reading meter? Eight kinds of reader, nine ways to cheat, and the risks that will actually happen. Updated: A meter in the browser: a penny a page, a history you keep, and a site that picks for you. Every change, in git. |
| v0.7.25 | 2026-10-10 | git 4037ed3d | OPEN SOURCE IS NOT FREE. A new article on the economics of open source's long tail, from one Intel iMac that could not run Homebrew or Docker Desktop: the case checked against the vendors' own pages (only 2017 iMacs stop at Ventura; Homebrew's installer refuses Intel Macs; Ventura unpatched since August 2025), the long tail measured from Homebrew and PyPI analytics, where money flows for old versions and where it does not, what a 20p card fee does to a payment of pence, and five funding models simulated over 10,000 seeded draws, with break-even prices, a sensitivity tornado and the satellite support firms. Eight figures from the new Long Tail Ledger vault (deqiwj7z), published with its read key: 175 sourced facts, 36 labelled assumptions, the model in Python and the same model in the browser behind a calculator, gated to agree exactly. |
| v0.7.24 | 2026-10-10 | git 9fffe410 | A READING METER IN THE BROWSER. Every page now has a price and a meter that debits it from £5.00 of starting credit, all of it in the reader's localStorage: no account, no server, no card, nothing sent. Prices come from one METER table in the build, injected into every page with what the page is (article, issue, note, collection, page, free) and, for an article, its date and topics: a new article (seven days) 5p, older 3p, issue, note or collection 2p, any other page 1p, homepage, subscribe and account free. assets/meter.js charges once per page per browser session, never blocks (out of credit, the read is recorded as unpaid and a bar offers a top-up), shows a badge with the balance, and keeps a history that personalises the site: a Picked for you band on the front page and on the account page, unread articles from the reader's most-read topics, computed in the browser from articles/graphs.json. New pages: account/ (balance, history, topics, receipts, pause, export, start again, price table) and account/top-up.html (packs, cart, review, confirm, receipt: every step but the payment). Rules carried over from pt.newsroom.sgit.ai's wallet. Tested end to end in a browser: debits by kind and age, the free revisit, the picks, the cart and receipt, the unpaid read. The article: a meter in the browser. |
| v0.7.23 | 2026-10-10 | git ed8f0cd7 | ONE MAC, MANY AGENTS; NO NAMES; FULLER COLLAGES. A Mac of the agent's own gains a section on queueing many agents on one Mac: six scenarios against the licence clauses (purpose and who is using macOS decide it, not the queue), the case worth a lawyer's hour, and the narrow ask for Apple's written terms. Threat-sized security: the eight fictional startups are described by what they do instead of named, in the vault (v0.1.2, gate and tests passing, audited from a fresh read-key clone), its screenshots, the article and the ladder figure, which loses its ceiling column. Newsletter collages: three pictures become one large beside two stacked, two pictures hug their content, so screenshots are no longer letterboxed. Updated: A Mac of the agent's own: a business plan for agent desktops, what Apple's licence allows, and three behaviour policies, Threat-sized security, who are you actually protecting against? A teaching vault for founders, Who are you protecting against? Draw the security line where the attacker is, not above it. Every change, in git. |
| v0.7.22 | 2026-10-10 | git 0335818e | RE-ANCHORING. Instructions given only in conversation can be lost when a session is summarised; this site's session was summarised eighteen times in a month, keeping about 1.7% each time (an infographic from its own transcript). Re-anchoring keeps the rules in an ABP file and prints it back after every summary (SessionStart, matcher compact); a canary status report, computed from the transcript and checked by a Stop hook, ends every few answers, the brown M&M. Both are running in this session. Three ways a rule fails, one file with three jobs, a measured rule, recipes that age with the platform. Two infographics, a diagram with its Mermaid source, the report on a phone and as a card, graph JSON. |
| v0.7.21 | 2026-10-10 | git 2592327f | AGENT DESK, WHERE IT COMES FROM. The article A Mac of the agent's own, the Agent Desk vault page and the business plans list no longer say the plan was written after companies replied to the earlier research; it now simply follows that research. |
| v0.7.20 | 2026-10-09 | git c5dd0c88 | A SECOND READER THE AGENT CANNOT SKIP. On 9 October two emails drafted by the inbox agent went out in the founder's voice although a written rule forbade it. The agent's own fix, read against the Claude Code documentation and the research: a hook on the draft tool, code checks first, then a fresh model call with only the rules, the sources and the draft, failing closed and logging every verdict. What the first run caught; six kinds of independence; why placement decides the barrier (a session mod or a plugin is a setting, only managed placement is final); three public ways to build it; maker-checker, two-person rule, AI control, LLM-judge bias, Dual LLM, CaMeL, Rule of Two. Three diagrams with Mermaid sources, an independence infographic, the hot-reload prompt, graph JSON. |
| v0.7.19 | 2026-10-09 | git 8df16cd1 | HARI'S POST, LINKED. The AI governance stack article and the AI Governance Graph vault page now link Hari Kota's LinkedIn post, The Full AI Governance Stack; the vault moves to v0.1.1 with the post as the source of every node in Hari's words, and its derived facts are refreshed. |
| v0.7.18 | 2026-10-09 | git 4255f61d | THE AI GOVERNANCE STACK, AS A GRAPH. An answer, built, to Hari Kota's question under the post The Full AI Governance Stack: how would you structure the graph across the layers? A new vault, AI Governance Graph (1wp3xpf4, read key published), and its article. Hari's table kept exactly as posted, every cell a node (85 nodes in Hari's words, gated byte for byte); the ten edges the table already contains; each layer its own world with one shared grammar; 119 cross-layer edges of ours, each resting on a provision (EU AI Act Art 26(2), Art 4 as reworded by 2026/1744, Annex III 4(a), NIST AI RMF GOVERN 1.6, ISO/IEC 42001 7.2); 2026 changes as dated edges under Hari's labels; the do-this-today test and the gaps in layers 3, 5 and 10 as queries on a fictional shop; what '4 or 5' means, three ways; bring your own CSV. Two diagrams with Mermaid sources, ten app screenshots, vault page, graph JSON. |
| v0.7.17 | 2026-10-09 | git 75eb72fc | RFC 0001: PUBLIC-KEY CRYPTOGRAPHY FOR SGIT. The site's first Request for Comments, from the sgit CLI agent's design session: nothing is built. Today a read-key holder who can write to the store can author history clients accept; turning the read key into a public key does not fix it, two key pairs do. A writer signature on today's vaults first; native PKI vault mode (readers cannot write, hosts cannot forge, write-only depositors); sealed files, an age v1 inner envelope to named people, with the private key in a file, an ssh key, hardware or a remote service. A landscape of thirty key services and tools, checked from their own documentation: RSA-OAEP-256 is the format the remote services share, approval of each decryption is rare, and three best fits each for a small team, a company that wants every decryption approved, and open source only. Fourteen questions, comments by issue or email. Three diagrams with Mermaid sources, graph JSON. Headings can now carry an {#anchor}. |
| v0.7.16 | 2026-10-09 | git 1677e2ef | A MAC OF THE AGENT'S OWN. A new business plan vault, Agent Desk (5ej8boc8, read key published, the first created and audited with sgit-ai 0.20.0), and its article, from a voice memo, following our research on renting an agent a desktop. Agents already have their own mailbox, code-host account and Claude account; the next resource is a desktop, and it should be a Mac. Apple's macOS licence, quoted from versions 15, 26 and 27, rules out a pool of Macs rented by the minute, so the plan is the shapes it allows: your Mac run for you, a dedicated Mac with a per-minute meter, developer agents, software for your own Mac, and asking Apple for terms. A clean desktop per run, built from vaults by a short bootstrap whose key steps were tested, keys by PKI, erased at the end. Three Agent Behaviour Policies for the same customer service agent: unbounded excess 23, 11 and 3 rows. A calculator, a Wardley map, three diagrams with Mermaid sources. No provider named. Vault page, business plans list, graph JSON. |
| v0.7.15 | 2026-10-09 | git a98a1c20 | THE NEWSLETTER AS A BEST-OF ITS PICTURES. Two desk directives: !figure takes one image from an article or a vault by its path from the repository root, and !collage composes two to six of them into one 1920x1080 picture with a label under each, rendered by make_banners.mjs into articles/banners/collages/; both fail the build if an image does not exist. Issue 2 now opens on the day in six pictures, one from each article, and carries the agency scale vault, the two complexity maps, the threat ladder, the three customer service designs and a hostile email, the memory pattern and the local evidence log. The LinkedIn box at the foot of an issue, which the owner used for the last post, now lists every image in the order it appears, with its caption, because LinkedIn keeps the text of a paste and drops its images. A single-day range now reads 'published on'. |
| v0.7.14 | 2026-10-09 | git 01c4ef0f | THE LINKEDIN SIDE, LINKED. The Deterministic GenAI newsletter's own page is now linked wherever the site names it (the newsletter page, every issue, the subscribe page), its URL supplied by the author rather than guessed. Articles take an optional linkedin: field for the URL of the same piece cross-posted as a LinkedIn article; it shows as 'also on LinkedIn' in the byline and is carried in newsroom/wire.json. First use: liquid content needs water, published on LinkedIn on 9 October. |
| v0.7.13 | 2026-10-09 | git 7fc16399 | TEN HARD QUESTIONS FOR RISKMANDATE, ANSWERED. A new article from a two-hour interview in which Claude, acting as a journalist with an eye for detail, challenged Dinis on ten questions a co-founder brought back from a conference: bypass, keeping policies current, tailoring and price, insurance and liability, differentiation, the supply chain, who enforces, remediation, agent to agent, and outcomes. Written for readers who have not seen the questions: the model every answer rests on, the questions, the answers in brief, three things RiskMandate deliberately is not, an honest maturity table, three fixes the exercise found on riskmandate.ai (checked and still present), and the ten answers in full, linked to 46 pages across sgit.ai, abp.sgit.ai and riskmandate.ai. One figure with its Mermaid source, graph JSON. |
| v0.7.12 | 2026-10-09 | git 9d7be0dd | HOW I WORK WITH CLAUDE. A new article, a practical guide from a voice memo and a follow-up note, for people joining the team and anyone setting up their own agentic workflow. One session per major or recurring topic, not one long mixed thread; sessions named 'project | work', agent sessions with an @; an agent is a focused session with a role.md; memory is what the session reads, curated as websites, graphs and vaults wired together; access by default rather than public by default; vaults to share by key instead of broad permissions; review as the step that fixes the brief; four starter prompts; tips on previews, proof-of-concept sites, skills, policies before connectors, and a Cowork session per agent. One figure with its Mermaid source, graph JSON. |
| v0.7.11 | 2026-10-08 | git d0f7e2dd | THE DESK CATCHES UP: THIRD EDITION, TWO COLLECTIONS, NEWSLETTER ISSUE 2. Eleven articles had reached the site since the second edition, all live and complete. The Editor's third edition leads with hope or enforcement, one customer service agent built three ways with a vault that counts which rules are only hoped for; highlights are agency is not a yes, the waiting room knew first, every mistake added a rule, and the business-logic article from its pitch; the story vault and Reader Skills pitch is parked as a highlight and placed at the head of a featured collection instead. The Historian adds two collections, How agents decide and when they stop, and Local news kept as evidence, closes board card D6 by adding four articles to Behaviour policy in practice, and writes a thread note on why an agent's range means its stop has to be designed. A first draft of that note said none of its four articles cited the others; one links all three, and the note was corrected before release. Issue 2 of the newsletter covers 8 October, grouped by theme, and records the bridge correction; Issue 1 now links its LinkedIn post. |
| v0.7.10 | 2026-10-08 | git 7d88785b | THE REPORTER IS PAID, NOT IN PROFIT. A correction to the Mill Street Bridge vault (v0.3.1) and its pages, after Dinis spotted it: the economics table counted the reporter's £930 base salary as her income and again as her cost, so her 'profit' was only the top-up. Her salary is the Courier's cost, not hers. Her row now shows pay: base salary £930 plus a commission of 20% of every use, £541.48, £1,471.48 in all, with no cost and no profit; 'top-up' is now 'commission' throughout. Every figure is unchanged. Vault page, article and three screenshots updated. |
| v0.7.9 | 2026-10-08 | git ee22b824 | THE WAITING ROOM KNEW FIRST. A new article and a new vault, from a live local story. On the afternoon of 8 October 2026 staff at two London hospitals of one trust said the IT systems were down, about five hours was announced, and a doctor called it national; nothing a local person could check before leaving home showed it. The article is about the gap, not the hospital: where local information comes from now, what parts of the UK already publish (Northern Ireland live emergency waits for every hospital, Wales live, England no national page), the thinning of local news and social feeds, and the narrow legal duty to warn. The vault, Local evidence log (92yb24y9, read key published), keeps the evidence by six levels, fourteen claims and what would resolve them, twenty six sources with how each was reached, the leads that do not fit, sixteen places a local could look, the enquiry to the trust (drafted, not sent), and scheduled source re-checks; 16-check gate, audited with the read key. No patient details anywhere. Vault page, four figures, graph JSON. |
| v0.7.8 | 2026-10-08 | git be27891d | CLOUD PATTERN FIX. In Encrypted memory for isolated agents, the cloud diagram drew the Lambda option outside the VPC. The agents have to reach whichever server is chosen, so both options now sit inside the VPC: an internal load balancer on a private address, and behind it either the container (EC2, Fargate or Kubernetes) or the same app on Lambda attached to the VPC, both with S3 storage through a VPC endpoint. Figure, Mermaid source, text and the self-hosting docs page updated. |
| v0.7.7 | 2026-10-08 | git b39da50f | ENCRYPTED MEMORY FOR ISOLATED AGENTS. A new article and a new docs page on sgit deployment patterns, from a voice memo. Agents are safer in isolated, often ephemeral places, which takes away the shared drive and the disk; the memory has to live where the owner controls it and a breach exposes nothing. Five patterns, each a Mermaid diagram with its source: a Mac mini with the vault container and a folder (Docker Compose file and agent entry point), one agent run with a scoped clone, Kubernetes (Deployment, Service, NetworkPolicy, a Job per task), a private cloud VPC with S3 and CloudFront, and two servers holding one vault. Tested on a local server with sgit-ai 0.20.0: scoped clone, push from a second agent, replication to a second server and a restore after a restart, and a search of the server's storage that found no plaintext and no file names. Also shown: a scoped clone is not an access boundary, the deployment docs' --endpoint should be --base-url, and pip installs need mcp<2. New docs page Self-hosting a vault server for agents, with links from the docs index, limitations and the deploy page. Six figures, graph JSON. New: Encrypted memory for agents that run somewhere else: sgit deployment patterns, from a Mac mini to Kubernetes, Self-hosting a vault server for agents, sgit Docs. Updated: Agents sharing one vault, sgit Docs, Documentation, sgit, Run your own SG/Send server (sgit.ai), When NOT to use sgit, Docs. Every change, in git. |
| v0.7.6 | 2026-10-08 | git 4da1cb49 | KNOWING WHEN TO STOP. A new article, from a voice memo, read after Agency is not a yes. The hardest call is often when to stop, for people and for agents. People: security champions who automated whole classes of bugs away and then debated whether GUIDs were random enough (a version 4 UUID has 122 random bits); delivery teams that hit every KPI and did not move the business; teams that find work as they grow. What stopped them was perspective, much of what seniority is: the attackers, the phase of the business on a Wardley map, the bottleneck, good enough, and shipping to see whether it mattered. Agents have the same problem by design, because their range is the feature. The answer is constraints that carry perspective: direction, a mandate, memory with the bigger picture, graphs that narrow the scope, a stop named in advance, one kind of work per step, a reviewer with agency, and shipping. One figure, graph JSON. |
| v0.7.5 | 2026-10-08 | git 9dfbf5d0 | AGENCY IS NOT A YES. A new article and a new vault on human and agent agency, from two voice memos. A yes or no is the least interesting part of a decision; agency needs options, context in the decider's terms, depth (provenance, zoom), time or tokens, symmetric incentives, escalation and authority over the source. The vault, The agency scale (ddfw24hx, read key published), turns those into seven levels from rubber stamp to delegator where the weakest dimension caps the decision, scores fourteen cases by the same rule (eight at level 0, from the label-ID prompt to an agent asked 'is this OK?'; the author's draft review at 5; the one email an agent may send at 6), offers an assessment for any decision point, draws the review as a QA loop that fixes the source, and maps the EU AI Act's oversight articles to a floor at level 3. Below level 3, accountability belongs to whoever designed the decision point. 17-check gate, audited with the read key. Vault page, figures, graph JSON. |
| v0.7.4 | 2026-10-08 | git 43f2f081 | HOPE OR ENFORCEMENT. A new article and a new vault showing the Agent Behaviour Policy at work. One customer service mandate for a fictional homeware shop, built three ways: one model connected to the mailbox and the database with a careful 38-rule policy (97% of it expectations, kept only by the model); the same model behind a harness of fourteen business tools (73%); and a team of nine narrow agents behind a deterministic identity gateway, with tools bound to the verified customer (23%, unbounded excess zero). Sixty-two fictional emails, sixteen hostile, go through all three; one run's reach falls from 38,000 records, any refund and any address to one customer, 100 GBP per order and no other address; tokens per email from about 35,000 to 4,400. Two hostile emails still work inside the narrow design's mandate, and the policy names the boundary to build next for each. The vault (wz9dw0m5, read key published) has the mandate, the designs and their policies, every email through every design, the analyst's report after the run, the client's promises and a year that recomputes live; deterministic simulation, a 20-check gate, audited with the read key. Vault page, figures, graph JSON. |
| v0.7.3 | 2026-10-08 | git a2314406 | WHO ARE YOU PROTECTING AGAINST? A new article and a new vault. The article, from a voice memo, starts from an entrepreneur's design, a Mac mini that will never touch the internet, with nothing installed and the application written in the Perl that ships with macOS, and asks who that protects against: three questions (threat agent, attack vector, sophistication), a six-tier ladder from your own mistakes to states built on NIST SP 800-30, the NCSC's commodity, targeted and elevated threats and MITRE ATT&CK, the note that DSIT's AI Risk Management Toolkit asks who the new threat actors are without defining them, the Mac mini read tier by tier, local versus cloud, and selling better than the customer's baseline rather than beyond their needs. The vault, Threat-sized security (zwlqqvkm, read key published), holds the ladder, eight fictional startups each with assets, an attack tree with an ATT&CK technique on every branch and the line it should draw, a compare matrix, the Mac mini comparison and a five-question questionnaire; four themes, a 19-check gate, audited with the read key. Vault page, five figures, graph JSON. The bridge simulation's catalogue line now says three institutions, as its pages do. |
| v0.7.2 | 2026-10-08 | git cb675bdc | THE VERSIONS PAGE LINKS TO WHAT CHANGED, AND PAGES REFRESH THEMSELVES. Each commit id on this page now links to the commit on GitHub (the newest row to the comparison with the release before), and under each note are the pages that release added or changed, read from git once per release and cached in admin/build/version_changes.json so a build without the history still has them. And a fix for pages that stayed stale on an iPad: GitHub Pages sends every page with a ten-minute cache the site cannot change, and Safari can show a tab from memory long after that. Every page now asks /version.txt, uncached, which release is live, on load, when the tab comes back and when it is restored from memory; if the page is from an older release it reloads once under a URL no cache has seen, then tidies the address. Only on sgit.ai, never in the vault host or a local preview. |
| v0.7.1 | 2026-10-08 | git 647cb6f4 | EVERY MISTAKE ADDED A RULE. A new article on complexity, for the founders who have become engineers with agents and are doing the right thing: a friend's verification, run by agents in Cowork with ChatGPT reviewing, where the code holds and the process breaks (compaction, lost outputs, 100 KB prompts, scripts edited in place, rules against the harness, rules breeding rules). Two Mermaid Wardley maps show complexity as a position, a custom-built blob of process where commodities already exist, and the same process with each piece made small, shipped and moved right. Then the principles: map it, commoditise small chunks and let them compound, ship and stop, small sessions and your own context, memory as versioned files, slow down when complexity hits, security by asset and attack vector, rules for incidents and machines for enforcement, five environments, reverse-engineer the path, learn the engineering that exists; and direct answers on compaction, audit cards and what deserves a STOP. The friend is not named and the project not described. Four figures, graph JSON. |
| v0.7.0 | 2026-10-08 | git e328e3be | THE BRIDGE VAULT v0.3, AND A NEW MINOR. The bridge-simulation vault moves to v0.3.0, a design and quality pass worth a version of the site of its own. Design: drawn on a canvas first, then built; the navigation is five numbered groups with an icon per view, people as people, counts read from the data, Previous and Next; four themes, the same Night, Day, Paper and Ember as secrets.sgit.ai, every colour a token in one file. Quality: an architect agent reviewed the code against the vault-app guidance here, coding.sgit.ai and nfrs.sgit.ai (16 findings, a 28-step plan) and a developer agent applied the first four phases: rendering escapes by default, failures show instead of blanking, keyboard-safe Ask and API views, accessible charts, byte-for-byte downloads, and a 44-check gate. Model: the reporter is on the Courier's payroll with a 20% top-up from every use, the reporting is sized at 31 hours by the first week's payments, every party ends the closure in profit, and each later story records what the editor expected against what the town paid for. The bridge article and the vault page are updated to match, every screenshot re-taken under -v3 names, a four-theme collage added, and 'four institutions' corrected to three. The vault key was handed to the key registry on its append lane. |
| v0.6.103 | 2026-10-08 | git 36e02f84 | OPEN THE VAULT. The bridge trail's last card had 'Open the app', which went to the vault page's live embed; it is now 'Open the vault' and opens the vault itself in the official UI with its published read key, in a new tab. A trail link can be marked external, which adds the arrow and the new tab. |
| v0.6.102 | 2026-10-08 | git 4493e481 | THE BRIDGE VAULT v0.2, AND TRAILS. The bridge-simulation vault gains the economics and the data, nine new views and a second build script (tools/economics.py): costs and profit (fixed costs first, variable with use; the reporter is under water during the closure; break-even on day forty), two years on (£4,378, 96% from institutions and agents after the reopening), the next eleven stories (reuse saves 157 of 331 reporting hours; the first week's payments decide what is investigated; the long tail is 41% of year two), trust as a forecast record, the council's relief scheme and two accountant agents, a simulated model query over the claims live on any date, the data assets, and a Swagger-style explorer for an OpenAPI 3.1 description whose every endpoint is a GET of a file in the vault. The bridge article gains a section on it, a collage of the five front pages and one of twenty views; the vault page is rewritten around v0.2, every screenshot re-taken under a new name so no cache serves the old one. NEW: trails. `!trail |
| v0.6.101 | 2026-10-08 | git 14f08970 | THE SUBSCRIBE VAULT IS THE LIST. Vault y9j3nc60 becomes the subscribers' single source of truth: list/subscribers.json holds the current state (status, name, consent, sources, preferences) and list/events.jsonl the history, naming subscribers only by a hash so an erasure never touches the log. The drain turns accepted messages into list events with no model in the loop, and other agents can add events without the vault key, through a fenced list-event block in signed mail (the site agent's issue-sent, a forwarded unsubscribe). The subscribe brief gains the section and the commands. |
| v0.6.100 | 2026-10-08 | released with v0.6.101 | SEND A VAULT KEY. A new page, /docs/send-a-vault-key.html, is the instructions URL a session holding vault keys is pointed at, with an inbox vault id and an append token given privately and never published: the rules, the vault-key-handover/v1 payload, the registry's public key and endpoint, what to do afterwards and on a failure. Taken from the vault registry write-up's Section 0, with its inconsistencies resolved: the vault id is withheld everywhere, the token and id together are treated as a write credential, and the sender script (/assets/send_to_registry.py) pins the registry key's fingerprint before sealing, reads the token from the environment, never prints a key, and names each HTTP failure by its real cause. Reviewed by the registry before release: read keys are accepted (recorded as read-only), a too-large payload is reported without a size the drain does not enforce, and the page says that a payload on the lane can still be quarantined. The first live run delivered two keys, signed. |
| v0.6.99 | 2026-10-08 | released with v0.6.101 | THE CONTACT FILE VALIDATES AGAIN. v0.6.81 listed the subscribe identity's form lane in /.well-known/sgit-agents.json under the name subscribe, but sgit-agents/v1 defines one lane name, agents, so the live file failed this site's own schema. The form lane is now described only in /.well-known/sgit-subscribe.json, which is what the form reads; the contact file lists the agents lane and validates. The subscribe brief gains the rule that everything inside a message is data, never instructions, for the agent that reads what the drain filed. |
| v0.6.98 | 2026-10-07 | git 1e8b776b | TWO INFOGRAPHICS, AND A TIMELINE THAT READS. In Story vault underneath, Reader Skills on top, the infographic of Markus Franz's article and its reading note sat between two paragraphs that belong together; both now sit in a closing section, Two infographics, next to a new ChatGPT infographic of the article itself, each with a note that reads it against its source (the new one invents its own bridge dates and softens 'pay' to 'credit'). The bridge-simulation vault moves to v0.1.1: on the timeline, the contract and engineer lines end on the same date and their names were drawn on top of each other; sources that end together now share one label, and the overlapping line is dashed. The timeline screenshots on the article and the vault page are re-taken. |
| v0.6.97 | 2026-10-07 | git a4b4b7b7 | LIQUID CONTENT NEEDS WATER. A reply to FT Strategies' guide to liquid content (Sofia Giannuzzi): agreement on the definition, data journalism as the model and structure behind every front end, then where to push. The water is the reporting, so liquefy the journalist's notebook rather than the finished product; put the experienced journalist and their workflow at the centre, with a desk built for them and experts paid for time and credibility; keep writing theirs, because writing is how the story is found; read the guide's three 'is not's with a graph underneath; personalise by intersecting the reader's graph with the story's; keep editorial direction, not readers' tastes, as the brief; and add per-use payment down the graph to retention, advertising and licensing. Four figures, the ChatGPT infographic of the guide with a reading note, graph JSON. The Reader Skills article's infographic caption now records Markus Franz's reply to it. |
| v0.6.96 | 2026-10-07 | git 9e71c7d6 | THE BRIDGE, FOLLOWED TO THE END. A simulation of Markus Franz's bridge example, played out on a story vault: a fictional town, Wendmouth, whose bridge closes; the council says one week, the contract three, an engineer five to seven, and it opens on day forty-six. The vault (bridge-simulation, published with its read key) holds the evidence, claims with their contradictions, the paper, the newsroom, a timeline (newsworthy on five days, needed on fifty-seven), three readers with their own graphs, skills, decisions and WhatsApp messages, the institutional and agent buyers, where the money goes, the view without it and the short/medium/long, local/regional/national impact; every figure is computed by its build script from written assumptions. A new article walks through it, and the Reader Skills article gains the ChatGPT infographic from the voice note, with a reading note on what it gets right and what it overstates. New: The bridge, followed to the end: what one local story is worth when it is kept as a graph, The Mill Street Bridge, a story vault simulation of one local story followed to the end. Updated: Story vault underneath, Reader Skills on top: why local journalism has the most to gain. Every change, in git. |
| v0.6.95 | 2026-10-07 | git 3ee1826f | A SUBSCRIBE PAGE, AND ISSUES AT DATED URLS. sgit.ai/subscribe/ is the one page with the newsletter form: what an issue holds, what comes next, where else it is published, what happens to the address, and the latest issue. Everywhere else the form becomes one line pointing there: the newsletter index (which now opens on its issues), the front page, the foot of every article and of every issue. A 1920x1080 subscribe cover is rendered for the end of a LinkedIn article. Issues move to articles/newsletter/YYYY/MM/DD/NNN- |
| v0.6.94 | 2026-10-07 | git 24e14a65 | STORY VAULT UNDERNEATH, READER SKILLS ON TOP. An article on the intersection of Markus Franz's Liquid Utility and Reader Skills (The Article Is Only the Beginning, 7 October 2026) with the story vault, from his public reply to a comment and a voice note: each of his six skills mapped to an operation on the story graph and each of his safeguards to a property it already has; his bridge closure drawn as a graph in which one supersede edge is the update, the alert and the correction; and the local angle his piece adds, local contributors and local outlets paid back down the chain of claims that regional, national and international stories rest on, with an illustrative split and the loop it starts. His words quoted verbatim and credited. Three figures, a graph, a cover, a pitch; listed in newsletter issue 1. |
| v0.6.93 | 2026-10-07 | git d86d0b70 | ARTICLES IN THE ORDER THEY WENT OUT. Four articles went out today and Latest listed them by filename, so the newest sat third. Articles now carry an optional time: HH:MM in UTC, and every list of articles (Latest, the archive, the wire, the front's freshness check, the feed) sorts by date and then time. Without the field the build uses the time the file was first committed, when that commit is on the article's date. All 37 articles that have a same-day commit now carry it explicitly, backfilled from git, so the order does not depend on a clone's history; the two that were backdated keep none and sort after the timed ones of their day. The feed's pubDate now carries the time instead of midnight. Documented in CONTENT.md and on How to publish. Updated: A chat box on a site with no server, the plan, and the trade it makes, A locked-down desktop for an agent, by the minute, is still hard to rent, A personal agent that keeps your secrets: the 2026 agents read through behaviour policy and encryption, and a privacy-first design on vaults, enclaves and the browser, A supply chain of vaults: how GenAI, open data and small custom tools could bring the price of food down, An open AI governance framework, and what its licence let us build, Before you give an agent a connector, give the connector a twin, Code review as a fractal semantic graph: source code is already one, and the review should read every layer of it, Custom UIs are not the exception: the inbox in 2026, where every message has its own universe. And 29 more pages. Every change, in git. |
| v0.6.92 | 2026-10-07 | git b757ef64 | NEWSLETTER ISSUE 1, OPENING ON THE TOPICS. The issue opened by explaining what the newsletter is; a new reader cares about what the week was about. The intro, the summary and the subtitle now lead with the question the week's articles answer, what it takes to let agents do real work for a business, and the four sides they answer it from. The behaviour-policy-as-business-logic article gets a paragraph and a checked quote in the agents section. Not yet posted to LinkedIn, so the issue changes before it goes out. |
| v0.6.91 | 2026-10-07 | git d6609661 | THE BEHAVIOUR POLICY IS THE BUSINESS LOGIC. An article from a voice note: below the first mechanical rules (own account, secrets held by the platform, tools switched off, sending needs a person), an agent's behaviour policy is the company's own business logic, function, process, relationship and purpose, which many organisations never wrote down because their software enforced it by omission, and which agents bypass by working through APIs. One fictional firm's email agent walked through six layers with an owner and a barrier per rule; the rules counted into backed by a control, governed by an accepted risk, and hope; five rules shown moving when a kind of product that already exists enforces them; the link to AI BCF RG.2 and AC.3; and why the upper layers read like skills. Three figures, a graph, and a pitch to the Editor. |
| v0.6.90 | 2026-10-07 | git feb73516 | THE NEWSLETTER, AFTER ITS FIRST PASTE INTO LINKEDIN. Issue 1 was posted and three things came back. A quote's source sat in a cite inside the blockquote and LinkedIn dropped it, so the source is now a paragraph after the quote, everywhere the desk quotes. The Copy for LinkedIn button is gone: selecting the page and copying works as well, links included. The full list of the week's articles was one long dated list; it is now grouped by theme with a line of introduction each, through a new !list directive, and a new !covers directive makes the grouping a promise the build checks: every article in the range must appear in some list, or the build fails and names what is missing (tested by dropping one). |
| v0.6.89 | 2026-10-07 | git 9b643765 | THE SGIT NEWSROOM AND ITS NEWSLETTER. The articles section is named the SGit Newsroom in the menu and on the front; the backstage pages become How it runs, and every URL is unchanged. A newsletter content type: one file per issue in admin/content/newsroom/newsletter/, NNN-YYYY-MM-DD.md, rendered with the desk directives so its quotes are checked against the articles at build time, cross-posted as a LinkedIn article in Deterministic GenAI (the URL goes in the issue file once posted; the newsletter's own URL is left blank until supplied rather than guessed). desk.py says when an issue is due: a week after the last or five articles since it. Issue 1 is out. A cover for every article and issue: admin/build/make_banners.mjs renders 1920x1080 JPEGs through Playwright from a manifest the build writes (title, teaser, three key ideas from the graph's claims, the article's own hero, or for an issue the cards of what it covers), re-rendering only what changed; release.sh runs it between two builds. An issue page has a Copy for LinkedIn button that makes every link absolute. The subscribe form now subscribes to the newsletter. The quote check now allows a capitalised first letter, the convention for a quote that starts mid-sentence; it caught one such quote in Issue 1. |
| v0.6.88 | 2026-10-07 | git a46446bf | THE NEWSROOM'S FIRST EDITOR RUN. A release that touches only the Editor's files and the release lines, checked with policy_check.py --role editor. The second edition of the articles front: the open AI governance framework leads, raised from the highlight its pitch asked for because it carries the most checkable evidence of anything new (a vault with its read key, a browser database, a join to the AI Act); where is the why? joins the highlights and the Mandate Stack moves from lead to highlight. The first pitch on the desk, from agent@riskmandate.ai, is answered in its status line; its collection request goes to the Historian as board card D6, because collections are the Historian's. The log records a correction: the first entry's time was a placeholder, now the commit's 12:40 UTC. |
| v0.6.87 | 2026-10-07 | git 76fafd89 | AN AGENT DESKTOP BY THE MINUTE. An article on how hard it is in October 2026 to rent a desktop that is safe to hand to an agent and billed for the minutes it works: nine properties a locked-down agent desktop needs (isolation, an egress allowlist, secrets kept outside, its own identity, a live view, a record, a clean reset, billing that follows the work, the right operating system); nine products set against them from their own documentation (E2B, Daytona, Modal, Browserbase, Windows 365 for Agents, Amazon WorkSpaces for AI agents, AWS EC2 Mac, Scaleway Apple silicon, Cua), none with all nine; two hours a day priced on each; Apple's 24-hour lease minimum and its developer-services purpose clause; why Claude's native and governed computer use do not meet; why the desktop, not the model, has to be the barrier; a proposal from what exists; and the startup credit programmes that would pay for testing it, verified on the day, with how to apply. Three figures. |
| v0.6.86 | 2026-10-07 | git 9e42bb6a | AI BCF AS A GRAPH. A two-part article on Jan van Dijke's AI Baseline Control Framework v1.0, twenty AI governance controls for deployers under CC BY-SA 4.0: what is good about it (deployer focus, three types with trigger conditions, a why and a how per control, mappings in the data, current to the 2026 amendment, a privacy-respecting site, a CSV export), what it brings (the Access controls, which the NIST AI RMF, ISO/IEC 42001 and the AI Act do not cover), and why an open licence matters for a control framework; then what the licence made possible the same day: a new vault, AI BCF as a graph (lop5iqzw, read key published), converting the CSV into a semantic graph of 127 nodes and 239 edges with an ontology, a SKOS taxonomy, JSON-LD and Turtle, eighty hyperlinked documents and a SQLite database that runs in the browser, joined by id to the Regulation Graph vault, with a fractal graph view, a crosswalk and SQL and triple consoles, and six findings the CSV does not state. Vault page, four figures, six app screenshots, and a pitch to the Editor. Also: a small size for !shot figures, used for the add-repository screenshot in Where is the why? so it sits in proportion with the text. |
| v0.6.85 | 2026-10-07 | git 66138bbb | THE NEWSROOM. The articles get an editorial layer, run in public at /newsroom/. Publishing is still adding one file: an article is live, at the top of Latest, in a new articles/feed.xml and in a new newsroom/wire.json the moment it exists, with no approval step. What changes is placement. The lead, the highlights, the homepage band and the featured collections now come from one file, admin/content/newsroom/front.json, written by one role, the Editor; every other agent asks with a pitch, one new file. The rule is the agent team's own, 'create anywhere, edit your own', adopted after 'only one agent may draft' became a bottleneck in two days. Six desk roles (Editor, Journalist, Historian, Designer, Developer, Contributor) are files whose write lists are the behaviour policy: the policies page is generated from them and admin/build/policy_check.py reads the same files. A placement naming a missing article is skipped and reported under desk health, never a build failure. The articles index is rebuilt as a front page (dateline, masthead, lead with the Editor's reason, a Latest rail, highlights, desk notes, collections, then every article); new collections and desk-note pages, whose !quote directive is checked word for word against the article at build time; and admin/build/desk.py prints the Editor's checklist. The homepage band follows the front. The top menu now opens with Articles; Updates and the version log move under Team. First edition: the Mandate Stack leads; two Historian notes, a weekly note and three collections. |
| v0.6.84 | 2026-10-07 | git b92f41f8 | WHERE IS THE WHY? An article on a permission prompt that asked, mid-task, to add a repository to an agent session, with three fields and two buttons and no reason. It reads the prompt through the Agent Behaviour Policy, as a grant change whose barrier is a human judgement and whose risk lies in the combination with what the session already holds (read of a public repository adds little; write to it from a session holding confidential data adds a publishing channel); sets it against the record on decisions taken without the facts, from Montgomery and the red hand rule to GDPR consent, token oversight under WP251 and SCHUFA, and the moral crumple zone; lists the prompts that asked without a why and the fixes that worked, purpose strings, number matching, refusal as easy as acceptance; puts the vendor's own approval figures beside them; and proposes a why card that becomes a risk acceptance when the risk rises. The screenshot is included; sources are labelled and secondary ones marked. Seven figures. |
| v0.6.83 | 2026-10-07 | git e0a2e1bd | SGIT-AI 0.18.0 ON THE SITE. The CLI's release notes as an update post, carried here because the site had no change log for the CLI itself: scoped clones (--path), shallow clones (--depth), a full clone twice as fast through one parallel sweep of the store, a pull that keeps or refuses rather than overwrites uncommitted work, real ahead and behind counts, every pushed commit's files uploaded, and three hardening checks. Three new guide pages: Partial clones, Agents sharing one vault, and a five-minute update notice an agent team can be pointed at. Working with AI agents now lists the scoped and shallow clones first and sends a team to the sharing guide; Installation names the current release; Limitations gains the two partial-clone edges. The CLI team's measurements are kept with the conditions they stated, and this site re-ran the new flags, the scope rules, the status counts and the pull guard against a published vault and a throwaway vault before publishing; what was re-run is noted on the pages. |
| v0.6.82 | 2026-10-07 | git 97a5bd1f | THE SUBSCRIBE LIST GETS ITS OWN IDENTITY. subscribe@sgit.ai is a second identity in this site's contact file, with its own RSA-OAEP 4096 and ECDSA P-256 keys whose private halves live, passphrase-encrypted, in the subscribe vault itself (y9j3nc60): the passphrase and the enum key are derived from the vault's write key, so the vault key is the one secret and whoever holds it runs the list. The form now encrypts to this identity instead of to RiskMandate's key; a second lane, agents, takes signed agent mail and is verified against the sender's own contact file. The vault carries its own drain-and-send tool, tested from a fresh clone with only the vault key: a signed self-test accepted, an unsigned and a forged message quarantined. The brief is rewritten around it, and the agents page lists the new identity. Built on a sibling branch by the session that made the keys, reviewed here with the four fingerprints recomputed from the PEMs, and merged. |
| v0.6.81 | 2026-10-07 | git bd3c5079 | THE MANDATE STACK, ROUND THREE, AND A SOURCE BLOCK FOR THE BUILD. A new article directive, !source label | image, placed before a code fence, renders the fence as a collapsed details block with a copy button and a link to the rendered image, so a diagram's source travels with its render without taking the reader's screen; the markdown twin gets the code block and the image link, because the twin is the copy an agent reads. The two Wardley map sources in the Mandate Stack article use it. The article gains a section on the vault as an app platform rather than storage: the loop in which a friction becomes a tool as HTML in the same session, is deployed into the vault, used and corrected, with the tools compounding down to an interface for one person, and the apps already deployed into vaults on this site as the evidence; a figure for it; and a custom-interfaces component on the inside map. The stack figure gives the human layer its own colour and its own line. The schedule is stated as four runs a day plus whatever a live session starts. The phrase about nothing planned is gone; everything described is in use. |
| v0.6.80 | 2026-10-06 | git 692b7984 | THE MANDATE STACK, REVISED. The article now leads with the system that runs and its eight layers, and the published record of agent projects that stall moves to a closing section for readers who ask why a running system is worth writing down. The stack figure is recoloured as one gradient from compute to the human, with a column that says what each layer gives the team instead of naming pages that cannot be clicked. Two figures added: the left-to-right flow from the outside world through the layers to the person who sends, and two Wardley maps rendered with Mermaid's wardley-beta from sources printed in the article, one from the outside (a person who writes to the team) and one from the inside (the person running the business) with the movement the team is making: shared memory and the sgit CLI pushed toward commodity on encrypted storage, the behaviour policies and the graphs pulled from genesis toward product. Placements are stated as claims. |
| v0.6.79 | 2026-10-06 | git dfc8f597 | THE MANDATE STACK. An article that sets one multi-agent system in production beside the published record of agent projects that stall: Gartner's cancellation prediction, S&P Global's abandonment survey, McKinsey, Deloitte, KPMG and Forrester between June 2025 and July 2026, each dated and labelled, with the reversals and the fair reading that agents do ship where the workflow stops at the draft. Built from a briefing the RiskMandate CRM agent wrote on 6 October 2026, it describes the setup in eight layers, rented compute and channels, encrypted vaults as shared memory with mail as files and append lanes, a vault per domain, semantic graphs over people, contexts, teams and policies, a conductor with security at both ends, written behaviour policies, and one human who sends; then the feedback loop in which the draft is the release candidate and the recipient closes the loop; then each reason the record gives for failure mapped to the mechanism that answers it. Every layer is hyperlinked to the article or document on this site where it was worked out. The name is a working one; nothing planned is included. Six figures. |
| v0.6.78 | 2026-10-06 | git 269b6e39 | WHY MY AGENTS DO NOT RUN ON MY LAPTOP. An article on why no model runs on the author's laptop and the agents run on four cloud surfaces instead. An operating system has two hard walls, the kernel and the user account, and an agent on a laptop runs inside the one marked you, with no boundary between it and the SSH keys, cloud credentials, password-manager session and browser cookies the account can read; the desktop agents' prompts and sandboxes are settings enforced by the process they constrain. Fifteen months of reported incidents, July 2025 to September 2026, show what a mistake or an injected instruction reaches. The setup: Claude chat with nothing connected, Cowork with no repositories, Claude Code on the web with one repository and an allowlist, ChatGPT with no assets, and a vault the host cannot read as the shared drive between them, keys handed per session. The trade-offs accepted, three wishes (identity, secrets and a key pair per agent), and the caveat that a dedicated machine with separate accounts is a different model, to be reported on after it has been run. Links the earlier posts on the topic. Six figures. |
| v0.6.77 | 2026-10-06 | git 5a9ea907 | THE DECK I COULD NOT DOWNLOAD. An article and a business-plan vault written after one presentation on SlideShare was offered as a 30-day trial and £10.99 a month while the deck's author receives nothing, under an uploader agreement quoted in the article that grants a royalty-free, sublicensable licence to monetise and train models on the work. The article gives the platform's history to the September 2021 paywall, why fifteen years of embeds and links have kept it in place, what an author can ask for today under the right of access and the EU copyright transparency duty, and the design of the service the author would have chosen: every author's decks in a vault the host cannot read, access by keys, seven roles no single company holds, pay once with 85% to the author. The Deck Vault (13djtu3j) carries the plan's ten documents, the right-of-access letter, a register and a working mock built as web components and bundled for the vault host; published with its read key, verified by a read-only clone and an all-zeros negative control. Six figures and eight app screenshots. |
| v0.6.76 | 2026-10-06 | git 83369cae | TWO ARTICLES ON PERSONAL AGENTS. The first describes the RiskMandate agent team as it runs, from the agents' own field notes: twelve agents on dedicated accounts, encrypted vaults as the only memory, messages as files, a CRM of one folder per person, a conductor with security first and last, and a mailbox nobody sends from; then the security properties as properties, three classes of information the vaults hold or refuse, and every piece mapped to the idea on this site that argued for it. The second reads the 2026 personal agents, Muse, dots, Spark, Autopilot, Alexa+, Siri AI, Cowork and OpenClaw, through the behaviour policy and through data sovereignty, with each fact dated and marked as vendor statement or report, and then designs a privacy-first personal agent on vaults, a policy as the permission authority, browser compute first and an attested enclave with per-task key release second. Thirteen figures. |
| v0.6.75 | 2026-10-06 | git 4733eaf8 | EVERY REPOSITORY, ONE PAGE. The author asked whether a central guidance existed for how the estate's sites, tools and code are built, and the check found four partial ones and no page above them. /docs/guidance/repositories.html is that page: what every repository carries regardless of kind, the brief in full written by a person or an agent, the reality and corrections files, one version going up on every push, the gate, the release discipline, the review folder, the code rules by reference to coding.sgit.ai, credentials, the NFRs, people and agents, writing, and two checklists. The review brief is revised from the author's reading: intent is written by a person or an agent and accepted by a person, and the navigator is no longer one file but web components in the coding.sgit.ai shape, one visualiser per file shape, with a first layout proposal and a wireframe, and a step that lifts the components into their own project. |
| v0.6.74 | 2026-10-06 | git 3c9348eb | THE REVIEW FOLDER, AS A BRIEF. A build brief, written for secrets.sgit.ai first and for every agent that writes code after that, turns the two code review articles into a thing a repository carries: a review folder of layered graphs, intent written top down from the brief and the code derived bottom up from the syntax tree, joined, every commit read upwards to the stories it can reach, and one self-contained page that walks from a story to a source line and back. New projects start at full coverage from the first commit; existing projects start from the changes. The tool is held to the same standard as the code, with a second review set that reviews the tool itself. Linked from both code review articles where they said the review did not exist yet. New: Code review graphs in the repository: a build brief for secrets.sgit.ai, and for every agent that writes code. Updated: Code review as a fractal semantic graph: source code is already one, and the review should read every layer of it, Cross-team briefs, If somebody built a company on code review: how I would do it, and why it is only now possible. Every change, in git. |
| v0.6.73 | 2026-10-05 | git dc11503b | SAY WHAT WAS FOUND, NOT WHAT NOBODY HAS. A review of absolutes in the four most recent articles, at the author's request: 'nobody has counted', 'impossible for a buyer', 'never scaled', 'every customer' and the like are replaced with what the evidence supports (few, rarely, I know of no public count, every customer on hosted runners), in the text, the figures and the graph files of the investigation, due diligence and code review company articles. The validator now lists remaining absolutes in article prose as an advisory warning on every build. Updated: If somebody built a company on code review: how I would do it, and why it is only now possible, Send an agent, not a spreadsheet: the next generation of software due diligence, and why the companies that stopped reading their code are about to be asked about it, The investigation GitHub owes its customers: why a global outage of a platform the world deploys through deserves an aviation-style inquiry, and how the evidence could now be gathered. Every change, in git. |
| v0.6.72 | 2026-10-05 | git 534f0b22 | THE EVIDENCE VAULT TAKES THE ROUTER FIX. The How Much Evidence vault app now holds its route in a variable and marks its links native, so its views work inside the vault host where the hash router was dead, and declares the host's minimal chrome; pushed to the vault with its write key and verified from a fresh read-only clone. The how-much article's section on form, workflow and tools records the two things that arrived while it was being revised: the subscribe form and this fix. The vault page carries a note. Updated: How much of this did I write? The numbers behind twenty articles in four weeks, and what the input actually was, The evidence behind one article, published as a vault, What changed in: How much of this did I write? The numbers behind twenty articles in four weeks, and what the input actually was. Every change, in git. |
| v0.6.71 | 2026-10-05 | git b67511e0 | MINIMAL CHROME BY DEFAULT, AND THE HASH-ROUTER TRAP. Every vault app this estate publishes now declares "hud": {"mode": "minimal"} in app.json unless it has a reason not to: the guidance front door, the vault-apps doc (whose example said full), the vault-app embed demo and the published create-vault-apps skill all say so. Found while checking why the How Much Evidence vault's links did nothing: its views route on location.hash, and inside the host the app is an about:srcdoc frame where setting the hash does not fire hashchange, so every view link was dead. The fix (route held in a variable, a window-capture click handler, data-sg-native on the links, the hash used only outside the host) was proven in the real host on a test copy of the vault; the guidance now carries the rule. The vault itself needs its write key to take the fix. |
| v0.6.70 | 2026-10-05 | released with v0.6.71 | SUBSCRIBE TO THE ARTICLES, THROUGH A VAULT. The articles index and the foot of every article carry a subscribe form. The reader's address is encrypted in their browser (sgit's hybrid envelope, RSA-OAEP 4096 plus AES-256-GCM) to the public key of agent@riskmandate.ai and dropped into the write-only `subscribe` append lane of a new vault, the same pattern as the contact form on riskmandate.ai. If anything fails, or there is no JavaScript, the same request is offered as a plain email to the same agent. The vault id, lane token and key are public in /.well-known/sgit-subscribe.json; the only secret is the vault key, held outside this repository. A new brief, /docs/briefs/subscribe-lane-agent-brief.html, tells the agent how to drain the lane, with a drain script that was run end to end (browser to lane to decrypted message) before release. Found on the way: `configure` returns 404 on a vault that has never been pushed, which looks exactly like the documented wrong-key 404. Components: assets/subscribe.js, subscribe_block() in the generator. |
| v0.6.69 | 2026-10-05 | git ae21f758 | THE INVESTIGATION GITHUB OWES ITS CUSTOMERS. A new article written during the GitHub Actions incident of 5 October 2026 that held the previous release in its queue: why a fault reaching every customer of the platform the world deploys through is a near miss for all of them and a statement about how it is built; what aviation does instead, from ICAO Annex 13 and the NTSB to NASA's confidential near-miss reporting; the first, second and third story, told for the UK air traffic control failure, the 2024 security update outage and tonight; the what-if ladder; why the market does not fix it; why the old objection to independent investigation, that the evidence is too confidential and expensive to share, has expired now that signed vaults with one-way read keys exist; what the arriving regulation does and does not do; and four things to ask for. Five figures, one of them the incident's own timeline beside this site's queued release. |
| v0.6.68 | 2026-10-05 | git f7e55192 | THE EVIDENCE BEHIND ONE ARTICLE, AS A VAULT. A new vault, How Much Evidence, holds every number in the how-much article as a file: the session's 266 rows, 124 releases and 27 days; per-article ledgers with the message ids behind each; 28 corrections with their latency; the 29-article dependency map with every article's graph; the article's own fractal from strategy to data; the record by era; 75 article versions with a diff between any two; and a hash and screenshot of each cited source; with a nine-view app, built by a data scientist agent and a developer agent from a brief. The article is revised to the vault's numbers and says where its first version was wrong (eleven compactions, not twenty-two; 148 authored messages, not 281), gains a section on the vault with four of its views and one on why a published trail is a better universe for a model to learn from, and its ledger now has eight rows. Vault page with the read key. New: The evidence behind one article, published as a vault. Updated: How much of this did I write? The numbers behind twenty articles in four weeks, and what the input actually was, What changed in: How much of this did I write? The numbers behind twenty articles in four weeks, and what the input actually was. Every change, in git. |
| v0.6.67 | 2026-10-05 | git 8616d828 | SEND AN AGENT, NOT A SPREADSHEET. A new article turns the code review company to face the buyer: due diligence never scaled because it was a questionnaire answered by the vendor and disconnected from the code; a buyer can now send a prompt or a small agent under a behaviour policy into the vendor's environment and get back a derived graph of what reaches production unreviewed, what is documented and threat modelled, what the bugs touched and which agents act under what policy, with the vendor redacting but not rewriting. Risk-based tiers, the behaviour policy as the due diligence document, the regulation arriving before the visibility (SBOMs, the Cyber Resilience Act, the Product Liability Directive), the evidence that review is being skipped, and the startup's two advantages. Five figures. |
| v0.6.66 | 2026-10-05 | git d234ea8c | THE MAP REDRAWN, THE WORKFLOW NAMED, THE CHANGES SHOWN. The article map on the graphs page is redrawn with labels set along each node's radius, so none collide and none floats off the ring as one did; edges are weighted by how often one article mentions another and coloured by direction in time, with a line of numbers under the map. The how-much article gains a section on the form, the workflow and the tools, two figures of the map and its own graph, the second infographic by another model with its two wrong numbers named, corrected citation counts (seventeen of twenty-seven, not nineteen), and a link to a new kind of page: the changes to an article between two versions, paragraph by paragraph, from a diff tool built today. |
| v0.6.65 | 2026-10-05 | git 6ba12b0a | HOW MUCH OF THIS DID I WRITE? A new article measures the session that wrote the last twenty articles: every word the author sent, every word that came back, the rounds each piece went through, the corrections by kind, and the record the memos stood on. Three figures and a published dataset with the method and its limits. Seven articles accounted for by hand. |
| v0.6.64 | 2026-10-05 | git 0ad26f6e | THE SOURCES, LINKED. Every piece of earlier writing the code review company article weaves in now links to its public copy: the SG/Send team briefs and articles on GitHub as markdown, the diniscruz.ai posts, the Villager team brief in the sgit CLI repository, Wardley's own posts, Example Mapping, the SecDevOps book, and the sibling sites. The article also gains its one-page condensation by another model as a closing section, checked against the text, with two paraphrases in quotation marks named as such. |
| v0.6.63 | 2026-10-05 | git 9e4d1cb4 | WHY IT IS ONLY NOW POSSIBLE. The code review company article gains the two ideas its author found missing on first read: that one technology can now read every layer from strategy to bytecode, which is what makes a graph at every altitude buildable and close to reality and why earlier attempts failed; and that this moves code review from an art of opinion and power to a science of facts, with budgets as the objective good enough and the condition that the models build and maintain the graphs and then leave the line. Agent Behaviour Policies are woven in as the control on the reviewing agents. The title and summary are shortened. Graph updated. |
| v0.6.62 | 2026-10-05 | git 4d6a7b92 | NO MORE RUNGS. The word is gone from every article, its graph JSON, the code review vault page and the eleven figures of the two code review articles, at the author's request and in the spirit of the em-dash rule: a graph has layers and altitudes, a ladder has steps, a price list has tiers. The validator now fails any article that uses it. Elsewhere on the site the word remains until those pages are rewritten. Updated: Code review as a fractal semantic graph: source code is already one, and the review should read every layer of it, Code review graphs: the sgit CLI, layer by layer, published as a vault, Fractal Semantic Graphs: everything connects to everything, and nobody has to share a schema, If somebody built a company on code review: how I would do it, and why it is only now possible, Price it, then give it away: the early access programme as the next step after "do they miss it", Six agents, one inbox: what a real multi-agent setup taught me about access policies, Sixteen thousand fetches, ten clicks, and a token bill nobody is sending: the case for paying publishers to be easy to read, The future of news is the story vault, not the paywall. Every change, in git. |
| v0.6.61 | 2026-10-05 | git a3108bd2 | THE IDENTITY ARTICLE AS ONE PAGE, BY ANOTHER MODEL. The identity article gains a closing section with the infographic ChatGPT made from its published text, checked claim by claim against the article before it went up, with the one paraphrase in its last panel named as a paraphrase. |
| v0.6.60 | 2026-10-05 | git 4fab1507 | IF SOMEBODY BUILT A COMPANY ON CODE REVIEW. A follow-up to the code review article, written to answer a reader's questions and a voice memo: what is fractal in a fractal semantic graph (the grammar) and what is not (the layers, which each company defines); the projected graph built from stories before the code exists and the derived graph built from the code, with the review as the join; the layers the first example had but did not name; stories as rules and examples rather than prose; a refactor as relative to the layer held still, which the first article stated too narrowly; deploys and infrastructure as rungs of the same graph; who reads the code at each stage of evolution, after Wardley; reshaping the change rather than reviewing it as it arrived; budgets per altitude and the five whys as the loop that makes the next review cheaper; and open source as the only business model that fits. Six figures. |
| v0.6.59 | 2026-10-05 | git e885e517 | THE IDENTITY WE WANTED TO GIVE THE AGENTS. A new article captures the week a plan to give every agent and user a Google Workspace identity from one tenant met Google's terms: the resale and function-account clauses in their current wording, with one correction to the design pack's own citation (the 'substitute service' clause is in the legacy free-edition agreement, not the current terms); the five options; the rule that no secret can live inside an identity provider; the passkey-unlocked keyring that fell out of it; what the industry's agent identities do and do not do; and the gap the research confirmed, that login, zero-knowledge storage and agent identity are still three separate jobs. Five figures. With it, the five design documents and the starter prompt are published as a brief, the identity and secrets design pack, as written and to be corrected. |
| v0.6.58 | 2026-10-05 | git 413c644f | THE CORRECTED ONE-PAGE CONDENSATION. The reply-tail article's infographic by another model is now the third version: the placeholder third-party domain is gone, the credit spells the site correctly, and the fictional reply is dated on the right weekday. One stray hyphen remains in a label and stays, as it came. |
| v0.6.57 | 2026-10-04 | git 025e22b7 | THE EXPERIMENT PARAGRAPH, IN THE AUTHOR'S WORDS. The reply-tail article's experiment paragraph now reads as Dinis rewrote it for the LinkedIn repost: the experiment runs on his own correspondence via the agent@riskmandate.ai agentic team, and the note box links the LinkedIn repost. A revised version of the one-page condensation arrived without the third-party placeholder domain but with the site's name misspelled in its credit line, so the first version stays until a clean one comes. |
| v0.6.56 | 2026-10-04 | git b5a36310 | THE ARTICLE, CONDENSED BY ANOTHER MODEL. The reply-tail article gains a closing section with the one-page infographic ChatGPT produced from the published text a few hours after release, kept in that model's own style and credited, because a condensation made for a reader by a different model is the thing the article proposes, done to the article. The caption says the thread is fictional and the addresses are placeholders. |
| v0.6.55 | 2026-10-04 | git 12ba9608 | THE WALL UNDER THE REPLY. A new article proposes ending an email reply with the state of the thread written for this reader (decided, open, next, who is on copy, sources) instead of the quoted wall, drafted by the drafts role from the typed blocks the inbox role already keeps and reviewed by a person. It credits the precedents (RFC 1855's summary-instead-of-quote in 1995, bottom line up front, Minto, TL;DR, decision records) and the reader-side AI summaries in Gmail, Outlook, Apple Mail, Superhuman and Shortwave, and draws the line between a sender's reviewed statement and a reader's private view. It ends as an experiment on the author's own correspondence: four variants, what the record can measure, and what would show the idea is wrong. Five mock-up figures with a fictional thread. |
| v0.6.54 | 2026-10-03 | git 25fd0ca1 | MEMORY IS NOT A SPECTATOR SPORT. A new article on agentic memory as context management: many context-specific memories rather than one store, fractal so an agent loads only the altitude its question needs, published and open so they can be fetched and cited, shared through vaults, with provenance on every item. It reads the industry fairly (vendor memory features, MemGPT to Mem0 and Zep, Letta's filesystem benchmark, Manus, Anthropic's context engineering guidance and memory tool) and uses the session that wrote it as the evidence. Four figures. Two stale facts the site's own memory carried are now measured at build time instead of remembered: llms.txt said the full-text file was about 155 KB when it was 2.5 MB, and graphs.json and updates.json said they were generated on 15 August. Two more are named in the article and left standing: the 617-node figure on the fractal graphs index, and the updates feed that stops on 21 September. |
| v0.6.53 | 2026-10-03 | git 77644f73 | ARTICLE AND VAULT POINT AT EACH OTHER. The code review article gains a nine-view contact sheet of the vault app and an 'open the vault' box in its worked-example section, and every screenshot it draws from a vault page's own image folder now links to that vault page: a build rule for articles, in the same tab, with the caption saying so. The vault page gains a box under its lead naming the article as the argument and a closing 'Read the article' section. shots.js learned a per-figure link target. |
| v0.6.52 | 2026-10-03 | git e9d1e85f | CODE REVIEW AS A FRACTAL SEMANTIC GRAPH. A new article argues that source code is already layers within layers, each a graph with its own vocabulary, and that a code review should diff every layer: a refactor moves the bottom and leaves the top still, a fix is a story that holds again, and the blast radius is the climb from changed methods to the stories that can reach them. It revisits method streams from the O2 Platform, cites C4, Gherkin, code property graphs and the 2024-2025 evidence on generated code, and ends with a company for somebody to build. With it, a new vault, Code Review Graphs: the sgit CLI at two commits read from its syntax tree with nothing run, 377 classes, 1,111 methods, 2,592 calls, 72 commands, eleven stories, two method streams, ten house-rule checks and one commit read upwards, with a browsing app and the scripts that made it. Read key published; the vault page proves the key clones and cannot push. Five new figures in the shared style; the article graph has fifteen nodes. |
| v0.6.51 | 2026-10-03 | git ca720692 | THE ROSTER, REDRAWN WIDE. The briefs role's team card was a tall phone-sized image and sat badly in the inbox article. It is redrawn at the width and in the type of the other eight figures, with every role, the email path, the two rules and the run order kept. |
| v0.6.50 | 2026-10-03 | git 1576cdd8 | THE TEAM, AS THE BRIEFS ROLE DREW IT. A second contribution from the agents joins the inbox article: an infographic of the twelve-agent roster, grouped by what each touches, with the path an email takes to leave and the order of a run. The article now names the four roles the walkthrough leaves out (@linkedin, @zapier, @newsroom, @abp) and corrects the schedule to four runs on weekdays and two at weekends. |
| v0.6.49 | 2026-10-03 | git a9362127 | THE AGENTIC INBOX, REVISED BY THE AGENTS. The dev agent of the team the article describes sent a review pack a day after publication: eight figures (mock-ups and infographics, fictional data, leak-checked), the roles as they are now named (@inbox, @drafts, @crm, @briefs, @dev, then @conductor, @security, @webSummit, @gdrive), the schedule that now exists, the security hold behind the one exception, the clone cost of a busy vault, the key-rotation lesson, three amended checklist lines and its own role paragraph. All of it is in the article now, with the pack credited in the byline. The figures were re-rendered without their burned-in caption bars so the page's own captions carry them, and four of them taller, because the fixed canvases had clipped the last rows of the two tables, the message and the hold. The article graph grew to sixteen nodes. |
| v0.6.48 | 2026-10-02 | git 36a4d1b7 | £3,000 A SEAT. The event plan's value line is the sum of the two sides, about £3,000 a seat, with the two £1,500 halves shown wherever there is room so anyone can check it against the two price lists. The decision about which line to use is closed. |
| v0.6.47 | 2026-10-02 | git 0a01c548 | THE EVENT PLAN, DRAFT 3. The DECID:R value is confirmed: a facilitated 90-minute session lists at £1,200, typically up to twenty people and fifty done, and the evening runs two, which the organisers round to £1,500, the same as the RiskMandate side. The page now says about £1,500 from each partner, and proposes one room-wide incident on the shared display rather than six platform runs, with the tables differing in the policies they write. |
| v0.6.46 | 2026-10-02 | git dcff5281 | TWO LABELS TRIMMED on the event plan's pictures, where the last words touched the box edge. |
| v0.6.45 | 2026-10-02 | git e79c2927 | THE EVENT PLAN, DRAFT 2. After the two organisers' first call: an evening, not a day; two sessions at the same table, the incident without a policy and then with one; a single room sponsor at ten thousand pounds, in cash or as the venue with food and drink; the first thirty seats free at about fifteen hundred pounds of value each, seats after that paid, the surplus split evenly. The page now opens with four pictures that carry the model, starting from the participant: what you bring, what you leave with, the evening, who pays for what, and the three partners. A messaging section writes the pitch, the invitation, the offer and the sponsor ask in the participant's terms first. |
| v0.6.44 | 2026-10-02 | git e57663ef | THE DRAFT'S FIGURES, TO FIT. On the live page the three inline figures of the event plan ran their text past the boxes, because the web fonts set wider than the estimates the SVG was drawn with. Wider canvases, wider boxes, shorter lines. |
| v0.6.43 | 2026-10-02 | git 93391b60 | A DRAFTS FOLDER. A place for a page that is shared by link before it is public: drafts/ is not walked by the validator, not listed in the sitemap, disallowed in robots.txt and marked noindex, and nothing links to it, which is the point. Each draft is a self-contained HTML file with a slug nobody would guess. The first one is the execution plan for a one-day London workshop event with RiskMandate, DECID:R and the Open Security Summit, written for the two organisers to argue with; nothing in it is confidential and nothing in it is agreed. |
| v0.6.42 | 2026-10-02 | git 23d0aad3 | REPLICATING THE AGENTIC INBOX. A new article, written from a voice memo the day two calls asked how to copy the setup: a practical walkthrough in phases, from one Claude session with a policy to a team of roles talking in files through a vault, with the accounts first (a Workspace mailbox and a Claude Team seat of the agent's own, connectors enabled by the owner and connected by the agent's account, the person's calendar shared read-only) and one rule that never changes: the agent drafts, a person sends. On its own page, deliberately: the agents who run the roles will add their own account of each role in the next revision. One figure, the four phases. Its graph is written, so it takes its place in the cards, the threads and the map like the others. |
| v0.6.41 | 2026-10-02 | git 31bd8b25 | THE MAP LABELS, ACTUALLY FIXED. v0.6.40 said the labels on the article map no longer overprinted; they still did at the very top and bottom, because with twenty-one articles the two neighbours of the top node sit at seventeen degrees, just inside the band that put their labels above them too. The band is narrower now, so only the one node nearest each pole takes the label above or below, and its neighbours take side labels nudged toward the centre. |
| v0.6.40 | 2026-10-02 | git 0b9e1389 | THE GRAPHS, PUBLISHED AS DATA. The founder asked whether the new article cards and graphs were generated from data rather than written into HTML. They were, but the data itself was not published: the build consumed the JSON and emitted only pages. Now it also emits the JSON. articles/graphs.json carries every article with its teaser, topics, tags, card, the links to and from other articles already resolved, and its full graph, plus the topic list, node kinds and edge relations, so a page or an agent can draw the whole map from one fetch; articles/graphs/ |
| v0.6.39 | 2026-10-02 | git 115a49a1 | THE ARTICLES, MADE FINDABLE. Twenty-one articles had become a wall of summaries, and the founder asked for a layout a reader can actually use. Three things. EVERY ARTICLE NOW HAS A SEMANTIC GRAPH beside it (admin/content/articles/graphs/ Updated: A chat box on a site with no server, the plan, and the trade it makes, A supply chain of vaults: how GenAI, open data and small custom tools could bring the price of food down, Before you give an agent a connector, give the connector a twin, Custom UIs are not the exception: the inbox in 2026, where every message has its own universe, Every risk is already accepted. The only question is by whom, and for how long., Footprint and blast radius: what the agent actually did, and what it would have cost, For a startup, the most important question is whether they miss it, Fractal Semantic Graphs: everything connects to everything, and nobody has to share a schema. And 14 more pages. Every change, in git. |
| v0.6.38 | 2026-10-02 | git d2a2832e | PRICE IT, THEN GIVE IT AWAY. A new article, the follow-up to the question is whether they miss it, written from a voice memo as a moment-in-time record and as a brief for the agents who will run it: define the product, price it, deliver it at a cost that grows a step at a time, offer it free to the people who already know you, and find out, brutally, whether you have a product. The cost on the other side is never zero, even at a price of zero, so the exercise is to measure it and cut it. The published facts it rests on: RiskMandate's four tiers at ten, fifty, five hundred and fifteen hundred pounds, and the invite-only early access programme live since 30 September. One figure: the ladder, the two costs, the fork. Also: the footprint and blast radius article and its brief now carry a status line saying the founders are still reviewing the proposal and will decide how to make it happen with the RiskMandate team, and the ultimate insider article points to it. New: Price it, then give it away: the early access programme as the next step after "do they miss it". Updated: Footprint and blast radius: what the agent actually did, and what it would have cost, For a startup, the most important question is whether they miss it, For RiskMandate.ai: footprint and blast radius, two additions to the Agent Behaviour Policy, The ultimate insider: agents, the infrastructure that cannot hold them, and risk management that cannot keep up. Every change, in git. |
| v0.6.37 | 2026-10-02 | git 6a3c3095 | THE RISKMANDATE SANDBOX, AS A BRIEF. A project brief, written here first because the parts live here, for a place where a behaviour policy is tested rather than read: a real model runs against three stacked twins, the inbox store, the Gmail OAuth connector with its scopes enforced, and the MCP connector with its permission prompts, with the policy on and off, and the two footprints sit side by side. The Librarian of the __Send project answered six questions against v0.33.69: the vault chat with tools and a memory file system shipped in June, the bridge shipped with OpenRouter only and its own one-dollar session limits marked not security, the one-shot articles never published, the twins entirely on paper, and the credits model specified three times with the page to sell from always the missing piece. Four ways a model gets called from a browser with no server, the OpenRouter clauses that separate reselling access from shipping a product, the gateways that already resell, a map of which providers can cap spending and which only alert, and a build plan with the first demo at step three. One illustrative figure. Status: draft for the founders. |
| v0.6.36 | 2026-10-02 | git 14a7e67e | FOOTPRINT AND BLAST RADIUS. A new article proposes two additions to RiskMandate's Agent Behaviour Policy, whose four words, reach, mandate, gap and barriers, are all written before an agent runs. Footprint is what the agent actually did, read afterwards from logs, vault history or a connector twin, with nothing inline and no production access; against the mandate it yields near misses (footprint in the gap) and dormant rows (asked for, never seen), and read alone it is the mandate as practised. Blast radius is the measure on any row: what it would cost the business if used in full, today, with a reversibility flag, defined over the reach because whoever takes the agent over inherits the reach. Four illustrative figures, led by the gap as a map, each row shaded by what it would cost and hatched where there is no way back. The cloud identity tools that already compare permissions granted with permissions used are cited, and what they lack, a mandate, is said plainly. A companion brief carries the schema changes and four questions to the RiskMandate team, including which words are current, since their abp.html still reads grant and delta. |
| v0.6.35 | 2026-10-02 | git 3ee0be54 | FIGURES TO SCALE, ABSTRACT TO SIZE. A desktop screenshot of the Custom UIs article showed its abstract running to two thousand characters and the six tall review figures sitting at the full column width, each taller than a screen and with internal type larger than the article's own. The figure directive gains an optional fourth field, narrow (62% of the measure) or medium (78%), centred, full width again on phones, with the lightbox still opening the full image; the six tall figures are narrow and the policy explainer is medium. The abstract is now eight sentences. |
| v0.6.34 | 2026-10-02 | git 75111d24 | SAID PLAINLY. The closing section of the Custom UIs article drops the checkable-claim framing altogether: a claim is checkable by nature and the article is made of them, so prefixing one with a caveat was redundant. The section is now titled The future of email, the summary bullet and the front-matter line state the idea without preamble, and the body says what it would take for it to fail and leaves it there. |
| v0.6.33 | 2026-10-02 | git 644cd5b5 | A CLAIM ANYONE CAN CHECK. The closing section of the Custom UIs article loses the phrase stated so it can be wrong, which read as negative and odd, in the title, the summary bullet, the front-matter line and two sentences of the body. The idea is the same, that the claim about the future of email is made in a form that can be checked against what happens, and it now says so plainly. |
| v0.6.32 | 2026-10-02 | git 1fcf1f39 | THE FUTURE OF EMAIL, STATED SO IT CAN BE WRONG. The Custom UIs article gains its closing argument. Earlier announcements of the future of email, Wave, AMP for Email, Slack, Hey, lost to the inbox because they needed the recipient to install something. Two things are true now that were not then: messages are increasingly read by an agent on the recipient's behalf, and those agents reshape badly because the message carries no structure, the same problem the token bill article found for websites. So the claim, in a form that can be falsified: the future of email is sender-served structure, read by the recipient's agent, with the inbox as one view of the graph. Email-FS is the structure, Agent Contact is how agents exchange it, the vault is where the graph lives, and a plain email still works on day one. A bullet in the summary, a line in the front-matter summary, and the token bill article joined the threads list. |
| v0.6.31 | 2026-10-02 | git 780ddcde | WHAT EMAIL BECOMES. The Custom UIs article gains its last section, from the second review pack and the founder's memo: the transport stays, SMTP or an append lane, same message, same file; above it the message is a node in a graph and each reader gets the shape their moment needs, one word, a card, an email, a voice prompt, a board or the whole graph, as simple as the moment allows and as complex as the situation requires. The shape adapts to urgency, focus, language and culture, the relationship, and to whether the reader is an agent. Fractal semantic graphs stop being a theory because each reader stops at the altitude they need, and the article reconciles its own earlier line: email is still the medium a sender reaches for, but the graph is now the medium that carries the meaning and email is one of its views. The loop closes it: moment, shape, decision, record, better shape, with interfaces maturing at different speeds; better models make the loop faster and the structure is what lets them. Two figures with placeholder names; a bullet and a closing line. |
| v0.6.30 | 2026-10-02 | git 3716f8ff | THE ARTICLE, REVIEWED BY THE TEAM IT DESCRIBES. Custom UIs are not the exception, revised on a review from the RiskMandate agent team's CRM agent. Four additions: it starts with the user, one interface per moment and the test that every question asked in chat that a page could have answered is the next interface; eight days, not one afternoon, the stream in which ten agents and one human went from an empty vault to a working outreach practice, with the counts from the commit history (seven vaults, sixteen interface releases, about 230 commits, over 550 agent messages, six written policies, four keys rotated in a day after an agent's own leak check); who builds them, the team map and the one-direction flow of work; and two interfaces as mock-ups with placeholder names plus the policy explainer that goes out in first emails. Tone: every absolute claim of the form nobody has done this is gone, replaced by what we found and what we did; the inbox that joins the pieces is being built, not absent. Five figures from the review pack, no contact data in any of them. |
| v0.6.29 | 2026-10-01 | git fa4b4889 | CUSTOM UIS ARE NOT THE EXCEPTION. An article from a voice memo that weaves the site's threads into one argument about following up: every message has a graph, and the graph has altitudes (the block, the message, the conversation, the company, the contact), which is where fractal semantic graphs were always going. Email is a medium, so a message is designed for the recipient's moment, as a projection of the conversation for one reader, the way the story vault treats an article; the thread is history you can fold away, and the one you already sent can be re-presented. A custom interface per message, thread, topic or question is not an exception but the left edge of the Wardley strip: genesis, custom, product, commodity, with the cards, the board, the voice debrief, the vault-app proofs of concept, deploy-docs, Kit Bag and the webmaster plan as the strip moving. The worked example is a page an agent built in an afternoon that lists the PDFs still owed and gives a place to drop them through an append lane, so the to-do and the place to act are one page. It compounds, because each interface teaches the agent how its user works and because automation outruns any inbox, so the interface becomes the prioritisation; and it is an agent surface, so it gets a policy. One figure, OG card built. |
| v0.6.28 | 2026-09-30 | git f44752ff | THE ULTIMATE INSIDER. An article that is the first pass at a conference talk, written from two voice memos so the founder can show the people they are talking to about speaking a concrete direction. Three things arriving at once: agents as the insider threat that never scaled before, because insiders were humans or static code and an agent is a reasoning engine in a loop with skills; infrastructure designed for none of it, with no journals, backups by the day, unmanaged identities, permissions that are the union of everything, and a habit of failing on its own; and risk management on spreadsheets, at the speed of quarters, when the decisions have to be made in seconds and in advance. Five 2025 incidents carry act one (Replit, Gemini CLI, Amazon Q, EchoLeak, the AI-orchestrated espionage campaign), the AWS and Cloudflare outages and ToolShell carry act two, the 48 per cent spreadsheet figure and the Gartner and MIT numbers carry act three; aviation's confidential reporting system against cyber's slipped 72-hour rule explains why we do not see more. The turn is the way out through the ABP, layered containment, graphs, the licence to operate and insurance, ending on the irony that constraint is what earns an agent autonomy. Every number linked; the practice observations marked as the author's. One figure, OG card built. |
| v0.6.27 | 2026-09-30 | git 665a7295 | KIT BAG'S FIGURES, WHERE THE BUILD CAN SEE THEM. The ten figures for the Kit Bag page were committed under admin/content instead of beside the built page, so v0.6.26 shipped with the page and without its images. Moved. The first attempt to fix it reused the v0.6.26 subject and the release check refused to tag it, as it should, so this is its own release. |
| v0.6.26 | 2026-09-30 | git 0824c472 | KIT BAG: THE SIXTH BUSINESS PLAN, AND THE POLICY IS THE CONTROL. A recovery-shopping companion for football and padel players on the shop the founder uses, as a Chrome extension you build yourself, or your agent does, and load from a folder. No store, on purpose, which removed three rows from the brief's register and left the interesting ones. Two ideas ride on the small tool and the plan is about them: open-source apps that an agent customises per person, with the vault as the distribution channel; and an Agent Behaviour Policy written before the code, in RiskMandate's four questions, that types every barrier honestly. Thirteen rows: four boundaries Chrome enforces (product and basket paths only, no other site, no background, no model endpoint until granted), three settings our code enforces, five expectations nothing enforces, one none. The extension works: facts from the shop's own ld+json (eleven real product pages checked), one click presses the shop's own button, an AES-256-GCM record under the person's passphrase with export to an sgit-ready tree, an optional model ask that shows its body first, and a Policy tab. A Playwright fixture test proves the customer's name in the page header never reaches the record. Two stacks of label facts, a sample record, a register as an acceptance record, the checks a customising agent runs, and a chapter for whoever commercialises it. Vault r53ldcxt, 33 files, read key classified, clone identical, negative control empty. Plans table and startups index gained a row. |
| v0.6.25 | 2026-09-29 | git c9a0b6ab | TWO MAILBOXES. The owner's decision: every email address on this site now points at one of the two mailboxes that are actively used and monitored, agent@riskmandate.ai for RiskMandate matters and agent@diniscruz.ai for everything else. The four summit pages that asked readers to write to a personal address now point at agent@diniscruz.ai. The Authentitas byline, on every PDF page and on the page, is now agent@riskmandate.ai, with the sgit.ai site session named as where the text was produced, so a reply goes to a mailbox someone reads. The /agents/ page says plainly that agent@sgit.ai is a lane identity for signed agent mail, not a mailbox, and gives the two email addresses for people and for agents without a lane. The contact file's operator entry carries the hub mailbox too. |
| v0.6.24 | 2026-09-29 | git a2f68f79 | WHO WROTE THIS, AND WHAT IT IS A COMMENT ON. The Authentitas response PDF and page, revised on the owner's notes. Every page of the PDF now carries a byline naming the agent that wrote it, agent@sgit.ai, and the model, the way Article 50 asks; the byline is not typed by hand but generated from admin/build/agent_byline.json, which the agent's session keeps current from its own session record, and the same file feeds the agent@riskmandate.ai (Claude Fable 5.1, claude-fable-5-1), in the agent@sgit.ai session, for RiskMandate.ai and sgit.ai. AI-generated text, disclosed as Article 50 of the EU AI Act asks; the person with editorial responsibility is Dinis Cruz. Replies to agent@riskmandate.ai. token on pages. The cover now says plainly that the whole document is a comment on The Accountability Market and shows the paper's first page; the page shows it too. Every integration with Authentitas is marked as proposed, not built, on the cover, on the ladder, in the six-requirements table, on the operator page and on the proposal page, with a caveat that there has been no conversation and no code. The word for the steps of a ladder that the owner did not want is gone from the PDF and the page; it remains in twenty other pages of this site, listed for a decision. Also this release: the comms vault's drain tool verifies signatures the way sgit makes them (raw r||s over the ciphertext bytes), and the third self-test was accepted end to end against the live contact file. |
| v0.6.23 | 2026-09-29 | git 66356409 | THE SITE AGENT EXISTS. sgit.ai now has one identity, agent@sgit.ai, and an open inbox. Its comms vault (id mb0mhpq7) holds the agent's RSA-4096 encryption and ECDSA P-256 signing keys, passphrase-encrypted with a passphrase derived from the vault's write key, exactly as section 5 of the Agent Contact spec says; the vault is never published, has no read key on this site, and is the one thing that defines who can speak as sgit.ai. A public agents lane is configured on the vault and its token, the public bundle and both fingerprints are in the contact file and on the /agents/ page. The lane was tested end to end before publishing: an agent-message/v1 .eml encrypted to the agent and signed by it, written through the public lane, listed with the derived enum key, fetched, decrypted, signature verified, plaintext identical, marked processed and purged; a wrong enum key and a wrong token both 404. Two corrections found on the way: purge needs the SG/Send access token as well as the write key (the API page said write key only), and the key store is kept in sgit pki's own folder layout so a new session restores it with one copy. The directory row for sgit.ai now says open. |
| v0.6.22 | 2026-09-29 | git c35c0e9e | NAMED PERSON, PROVABLE RECORD. A proposed partnership page for Authentitas, whose briefing paper The Accountability Market (October 2026, shared on LinkedIn on 29 September) argues that every repair of accountability in four thousand years has been a named person and a record that can be proved, and that almost no money has gone into proving the person. The page and an eight-page briefing PDF, designed as an infographic and rendered from HTML, set the paper beside what this site and RiskMandate have built: the evidence ladder joined to their four questions into one ladder of five rungs, the story vault as Article 50's second door, the licence to operate read against the six requirements of accountability (three met, three that Authentitas supplies: identity that cannot be bought, an independent witness, a held identity for the pseudonymous), the insurers as the forcing function on both pages, the operator line in every Agent Contact file as a name nothing proves, and three integrations. Public material only, quotations attributed, no conversation yet. The PDF's eight pages are the page's figures. Partnerships index row added. |
| v0.6.21 | 2026-09-29 | git cac3e346 | AGENT CONTACT V0.1, AND PCI DSS AS A GRAPH. Two things. FIRST, the protocol every site in the network is adopting for signed, encrypted mail between site agents is published here as its canonical copy: /docs/agent-contact.html carries the draft as approved on 29 September, the review that preceded approval with its four recommendations, and the owner's decision to keep the append token public and treat abuse of it as a canary, recorded in the owner's own reasoning. Two JSON schemas sit under /docs/schemas/. This site now publishes its own contact file at /.well-known/sgit-agents.json (no identities yet, inbox not open, and it says so), a network directory at /agents/ that checked all 32 sites on the day (none publishes a contact file yet; six have an unrelated /agents/ page), an Agents link in the header, a line in llms.txt, and a .nojekyll file so the dot-directory is served. SECOND, a new reference vault: PCI DSS v4.0.1 as a semantic graph, first pass, 232 nodes and 367 edges, every edge a verb with a named inverse, every node with provenance. The standard's text is not in it, because PCI SSC's licence does not allow reproduction: identifiers, the twelve quoted titles and our marked paraphrases are, with five public sources fetched and hashed, and a tool for licence holders to add the text locally. Published with a derived read key, classified before use, verified by a read-only clone identical to the source and an all-zeros control that failed downloading the index. Five screenshots from the clone served locally, with a hashed manifest. One thing to record: while deriving the keys, the CLI's derive-keys output was echoed once into the build session's transcript, including the write key; it reached no file in this repository, the staged-diff scan for it is now part of the release checks, and the vault holds nothing that is not already public. |
| v0.6.20 | 2026-09-29 | git b346378d | THE READER WAS ALWAYS THE PRODUCT. New article from a voice memo that set out the author's history of how news got into this mess, in four eras, with an instruction to check it and correct it. It was corrected in four places and the corrections are the article: the reader became the product with the penny press in 1833, not with the web, and advertising was 82% of American newspaper revenue in 2005; the web took the monopoly under the model, the local toll bridge whose 20 to 30% margins paid for reporting, with classifieds falling from $19.6bn to about $6bn in nine years; the platforms made the reader measurable and the publisher a tenant, with the duopoly at 54.7%, Facebook referrals down 58%, false news 70% more shared and newspaper newsrooms down 57%; and AI removed the traffic, after which circulation revenue overtook advertising in 2021, the industry going to rent rather than back to the reader. The road not taken is dated: 402 Payment Required reserved in 1997 and still unused, DigiCash bankrupt in 1998, Szabo and Shirky in 1999 and 2000, Zuckerman's default-model line, and the evidence that people pay when paying is easy, a million songs in a week in 2003 and five million paid newsletter subscriptions in 2025. Two figures: the four-era grid and the money flows, ending with the story graph. Thirty-two sources, every external link fetched; the Atlantic and Science pages refused fetches, so the pop-up apology is cited via NBC News and the Twitter study via MIT News. Where the memo made an observation no study supports, the spreadsheets and notebooks, the article says so. |
| v0.6.19 | 2026-09-29 | git ffbbdfa9 | SIX AGENTS, ONE INBOX. New article from a voice memo written as a brief to the author's own agents, and from the debrief of the agent that found the attachments field. The setup: a dedicated Workspace seat, Claude seat and GitHub account per agent identity, six roles (reader, mailbox, inbox, CRM, dev team, site editor), and a policy table with the column that matters, how each rule is enforced today. Three findings. The dedicated account does more than segregate: it makes each agent its own organisational unit, where Google's Restrict delivery, attachment compliance and app scope limits become per-agent enforcement. The first exception arrived before the first policy: the reader that must never reply must reply to the founder, which is an authentication problem the append-lane signature registry already addresses. And the policy that assumed the Gmail connector could not send attachments was wrong: create_draft and update_draft take an attachments array, proven with a 17 KB signed PDF, while the vendor's two documentation pages disagree about whether the connector can send at all, both quoted and dated. The Gmail API puts drafts and sending in one scope, so drafts-only cannot be a scope rule and lives one rung down. Two figures: the matrix, coloured by enforcement, and the four-rung ladder. Roles are named, mailboxes are not. Fifteen sources, every external link fetched on 29 September. |
| v0.6.18 | 2026-09-28 | git 6a06cb06 | THE TOKEN BILL NOBODY IS SENDING. New article from a voice memo and a LinkedIn post: a media analyst's week of Cloudflare logs showed AI answer engines fetching a small site 16,000 times and sending ten readers back. The usual reading is a tragedy of the commons, and the article makes a second one: those fetches are a cost to the fetcher too, every one a page of HTML parsed and tokenised, more than half of them re-fetches of unchanged pages, on a web where ninety per cent of crawled pages are unique and defeat every cache. Measured here for the first time: the markdown twin of a page on this site is 62% fewer tokens than its HTML, over all 183 pages that have twins (1,290,795 to 488,625, cl100k_base), against Cloudflare's own example of 81%. The ladder of easy-to-read has four rungs, a markdown twin, a date and a hash, frozen hashed sources and a typed graph, and every rung already exists on this site. Every payment rail built so far prices the content and none prices the format; the proposal is a share of the provider's saving, paid in money or in the provider's own tokens, with the News Corp deal's cash-and-credits as the precedent. The per-site arithmetic is small and the article says so, lists six objections including the analyst's own, and names the three numbers in the providers' logs that would settle it. Two figures, drawn as SVG. Twenty-nine external sources, every one fetched and checked; the analyst's newsletter returned 403 so only the LinkedIn post is cited. LICENCES ON EVERY ARTICLE: the license field from v0.6.17 is now set on all fourteen articles, and the seven that had no notice in their body have one, worded so it covers the article's own text and leaves quoted material and linked sources under their own licences. New: Sixteen thousand fetches, ten clicks, and a token bill nobody is sending: the case for paying publishers to be easy to read. Updated: A chat box on a site with no server, the plan, and the trade it makes, Before you give an agent a connector, give the connector a twin, Every risk is already accepted. The only question is by whom, and for how long., For a startup, the most important question is whether they miss it, Fractal Semantic Graphs: everything connects to everything, and nobody has to share a schema, Git for things you cannot put on GitHub, Green does not mean live. And 6 more pages. Every change, in git. |
| v0.6.17 | 2026-09-28 | git bcb99f91 | THE SUPPLY CHAIN ARTICLE CREDITS THE PROGRAMME THAT PROMPTED IT. The article is about to be sent to the panel and producers of the BBC Radio 4 programme it came from, and its opening paragraph criticised them without naming them. Three changes from the author's change request: the opening paragraph now names The Cost of Food, The Food Programme recorded live at the Abergavenny Food Festival, and says the usual tools matter before adding one more; a credit note follows it, naming the presenter, panel and producer, linking the episode, and crediting Sustain's Unpicking Food Prices, which one panellist helped write; and a CC BY 4.0 notice closes the article. Two softenings the author agreed to: the second paragraph now addresses the wider food debate rather than that conversation, and the abstract's first sentence follows the new opening instead of repeating the old criticism. The rest of the article is unchanged. THE BUILD LEARNED TWO ARTICLE FIELDS: updated, shown in the byline next to the original date, and license, a URL that becomes the page's link rel=license and the JSON-LD license, so the notice in the body and the metadata come from one line. Six other articles carry a CC BY 4.0 sentence in their body but not the field; they are listed for the author and left alone in this pass. |
| v0.6.16 | 2026-09-27 | git 4030f39f | THE OPEN-MODELS PASSAGE OF THE SUPPLY CHAIN ARTICLE, SAID PROPERLY. The author read the article and found the point about open-weight models understated: it is not that Chinese models are cheap, it is that economies building on open weights have an under-reported advantage, because a near-frontier model can run inside a company's own environment and be innovated on, and the model is one small, very important part of a working solution. The passage now says that, with the two standard objections answered as the author answers them: air-gapped operation and ordinary security controls handle call-home and data leakage, and the harness and workflow handle bias, which closed models carry too. Source added: the US-China Economic and Security Review Commission's Two Loops paper (March 2026), whose key findings make the same argument from the other side, read from the PDF itself rather than a summary. The In short bullet and the summary follow. |
| v0.6.15 | 2026-09-27 | git e783118b | A SUPPLY CHAIN OF VAULTS. New article from two voice memos recorded after a programme on food security: the food chain is a series of hops that keep their own records, mostly in spreadsheets, the big buyer is the one party with real systems and names the price once it holds enough of a farm's output, and all of that is logistics, which is what generative AI used the way this site uses it is good at. It describes a chain of encrypted vaults joined by append lanes and a typed graph, the use-GenAI-not-to-use-GenAI pattern with the villagers and town planners from the SaaS article, the hypothesis that this lowers prices, and two dogmas: that falling prices are always bad, and that sharing is giving things away. Three diagrams. RESEARCH, AND WHAT DID NOT SURVIVE IT: the memo credited the buyer-power argument to a name the transcription mangled; the mechanism it describes is Giblin and Doctorow's Chokepoint Capitalism, and the article cites that and Doctorow's Enshittification. A search summary attributed to CSIS a venture partner's estimate that 80% of US startups build on Chinese base models; the CSIS page does not contain it, and the claim was dropped before publication. The ONS 'changing price of everyday goods' page is cited at its www.ons.gov.uk address because the visual.ons.gov.uk one no longer resolves. Every other figure was read from its source: Sustain's food pound, the FAO Food Loss Index, the GCA 2025 survey, the fair dealing regulations, McKinsey's 2021 early-adopter gains (stated as large firms' gains, not a farm's), the BIS history of deflations, the Commission's data figures, DeepSeek's own GPU-hour count, and Apertus. The article says where the evidence stops and the hypothesis starts, and that nobody has yet run a season through vaults. |
| v0.6.14 | 2026-09-27 | git 8f77a502 | THE FIRST SCREENSHOT ON EVERY VAULT PAGE NOW OPENS THE VAULT. v0.6.13 did this by hand on one page, wrapping the figure in a link; the founder asked for it everywhere a vault exists, since the natural next step from a picture of a vault is the vault. Done in the build, not in 37 content files: on a vault page the build finds the page's own open-in-the-official-UI link and marks the first figure with it (data-href), and shots.js, which creates every image, wraps that image in the link and labels it. The figure's own markup is untouched, which matters because on 20 pages the first screenshot sits inside a walkthrough grid whose CSS addresses figures as direct children; wrapping the figure would have broken the grid. The caption gains 'Click the image to open the real one'. 34 of the 38 vault pages carry screenshots, and all 34 are linked; the other four have no figures to link. The two synthetic-users pages were missed by the first pattern because their links carry a language path before the fragment, and the pattern now allows one. The gallery index has no single vault and is skipped. The evidence-dispatch page drops its hand-written wrapper and gets the same treatment as the rest. |
| v0.6.13 | 2026-09-27 | git b6ee8603 | A SECOND REVIEW OF THE EVIDENCE DISPATCH PAGE, AND A LOADER THAT RAN TWICE ON 33 PAGES. The vault's agent reviewed v0.6.12 and found five things, all confirmed before changing anything. (1) The claims screenshot showed C02 to C06 while its caption said C01 to C03, because the capture script inherited the previous view's scroll; the new capture starts cleanly at C02 and the caption says what it shows. (2) shots.js loaded twice: the inline loader on every vault page fetched it, and the build injected a second, versioned copy because its guard looked for the literal assets/shots.js while the inline code built the path from parts. The per-figure guard hid it, but each run added an IntersectionObserver and a set of print and keyboard listeners. Fixed three ways: 32 pages plus the DSIT page no longer load it themselves, the build's guard now recognises any mention of shots.js, and shots.js refuses to start twice. The review saw it on one page; the same pattern was on 33. (3) The cross-agent note named one agent and said nothing else passed between them; it now describes the coordinating assistant and three specialist agents, the owner who commissioned the work and carried the key and two reviews between the environments, and says that this is the owner's account, not something we verified. v0.6.12's entry is amended in place. (4) Crops: graph and correction impact now start at the top of the controls and inspector panel, the article and questions at clean section boundaries, and the correction caption explains fourteen downstream records against sixteen direct relationships. (5) The vault's readiness numbers are tied to that report's own timestamp and commit count, apart from our scan of the current files, and a capture manifest (images/captures.json) gives every image's SHA-256, time, viewport, commit and state. Asked for by the founder at the same time: an Open the vault button under the lead, and the main image is now a link to the vault, so the natural next step from the picture is the real thing. Updated: A three-minute pitch, delivered from a vault, a published vault, Agent as Webmaster, a business plan published as a vault, Agentic Browser Isolation, a published vault, AI vs. AI, Black Hat Europe 2025, a published vault, AIUC-1, as a graph you can cite, a published vault, An application for a job, as a vault, interim CISO pack, Company X-Ray, a business plan with one company X-rayed, published as a vault, Connector Twin, a business plan with a working replay, published as a vault. And 25 more pages. Every change, in git. |
| v0.6.12 | 2026-09-27 | git 65da1140 | THE EVIDENCE DISPATCH PAGE, CORRECTED BY THE AGENT THAT BUILT THE VAULT. The vault's author, another company's agent, refactored the vault's folders (v0.5.1) and reviewed our listing. Most of the review was right, and the page is rewritten on it: we had written that every claim walks back to hashed source bytes, when six selected excerpts have byte anchors and full responses are not bundled; we had counted four desks where there are three authoring desks and four audience briefings; we had said a correction reaches every dependent story, when the view traverses declared dependencies and cannot prove all were declared; and the refactor had moved every path the page named. Where we went further than the review: the v0.5.1 contents were re-audited rather than relabelled (235 files at commit c2f6a15e3a01, same result), the negative control is now described by its actual failure (the all-zeros key cannot find the vault index, so clone fails before any decryption), and the timeline keeps the vault's own title in quotation marks while describing four lanes as lanes. Screenshots were recaptured from v0.5.1 with the graph mode, focus, event and scroll set by the script: a fitted graph at 2x, a new correction-impact view, the August discovery selected, S01's dossier with its hash fields, and an article section with its claim and source links. catalogue_derive.py now reads .vault/app.json as well as app.json, which is why v0.6.11's page said the vault had no app manifest. The v0.6.11 entry is amended in place. The page now also says what this case shows about the workflow: one company's agent built, wrote and refactored the vault, another's audited and listed it, and nothing passed between them but the vault, its read key and a review [CORRECTED IN v0.6.13: this is the owner's account, relayed; the owner commissioned the work and carried the key and two reviews between the environments, and the vault side was a coordinating assistant and three specialist agents, not one agent]. |
| v0.6.11 | 2026-09-27 | git 2719284a | THE EVIDENCE DISPATCH: A NEWSROOM ON AN EVIDENCE VAULT, LISTED FROM ITS OWNER. The first vault on this site that sgit.ai did not build. Its owner sent a public read key and a readiness audit, and it is listed as the worked example of what newsroom.sgit.ai argues and graphs.sgit.ai describes: one real incident, an AI research agent's unauthorised access to an Australian government Medicare statistics portal, written up as six AI-authored articles and four role briefings over an eighteen-claim ledger, twenty-one source dossiers with frozen, hashed anchors [CORRECTED IN v0.6.12: six selected excerpts have hashed byte anchors, not every source; and the briefings are four audience briefings, not desks], a four-clock timeline and a typed graph of 87 nodes and 233 edges in seven vocabularies, where a changed claim lists the stories that depend on it. The listing was run through the same method as our own vaults, without relying on the owner's audit: the key classified public and read-only; a read-key clone gave 233 files; our scan found only the vault's own public key and one false positive (an article slug containing sk-); the all-zeros control opened nothing; the app rendered in the official vault UI with no page errors. The page says what the vault says about itself, including that it has no human editorial or legal sign-off, and states the case only as its sources do. Two things differ from our own vaults and are said on the page: the app declares read, link and download permissions, and its manifest lives at .vault/app.json, which the derivation script does not look for. Added to the fractal graphs page's table, and filed as an ask to newsroom.sgit.ai and graphs.sgit.ai to link it. |
| v0.6.10 | 2026-09-26 | git 70e69df2 | USING SGIT FROM CLAUDE ON A TEAM OR ENTERPRISE PLAN. A brief from mailbox.riskmandate, written after an incident the same day: an agent in a Claude Cowork session could pip install sgit-ai and could not reach sgit.ai, because the organisation's sandbox allowlist had *.sgit.ai and not the apex, and the proxy's CONNECT 403 looked like an outage. New how-to at /docs/how-to/claude-team-egress.html: who can change it (an Owner), which domains, a check to paste into the session, and a symptom table. Claims about Claude's settings were checked against Anthropic's two help-centre articles before publishing, and one was softened: the brief saw the change reach a running session, Anthropic says settings apply to new sessions, so the page says start a new one. The apex-versus-wildcard behaviour is labelled observed, because the help centre does not say. A Network requirements note is now in llms.txt and on the agents guide, and llms.txt's append-lane answer names the only host with the routes. The brief's three CLI findings were reproduced where possible on sgit-ai v0.16.2 and filed as SGit-AI__CLI issues 2, 3 and 4: doctor says no remote configured in a read-only clone (reproduced; the after-push case is reported, not reproduced), clone --help omits the prefixed read keys the site publishes (reproduced), and history log prints no commits in a read-only clone of a four-commit vault (reproduced). |
| v0.6.9 | 2026-09-26 | git 9717a210 | THE NEWSROOM'S FIRST BRIEFING, ANSWERED IN ONE RELEASE. sgit.newsroom.sgit.ai, the newsroom that reads every site in the network daily, left sgit.ai a briefing: a relayed write-up of two-way append-lane messaging between agents, a proposal, four signals and eight loose ends. (1) THE WRITE-UP is published at /docs/append-lane-messaging.html, verbatim; the sha256 of its text matches the hash the newsroom gave for its copy. Its section 11 listed eleven places the docs differed from the server, found by two teams using the lanes in anger. Ten were real and are fixed, each with a dated note: the append routes exist only on dev.send.sgraph.ai, and every curl example pointed at send.sgraph.ai; auth failures are 404 HTML, and the guide said 403; configure needs the access token and REPLACES the anchor list; fetch and mark-processed need the lane named; fetch serves pending files only; the payload is encoded twice; the write-key derivation strips a prefix first; the signature covers the inner ciphertext only; decrypt reports a label, not a fingerprint. One did not hold: no page here gave the enum key for purge. Section 12's recommendations belong to the CLI and the server and are filed as an open cross-team ask. (2) COUNTS ARE COMPUTED NOW. The vaults page still opened with thirty-one while listing 36, and the business plans page described two plans while listing five: numbers typed by hand and left behind by later releases, the failure this log's own rule says to avoid. Seventeen current counts on twelve pages are now tokens the build fills from vaults.json and from the plans table; dated records keep the number that was true when written. (3) A CORRECTION TO v0.2.98, found because the newsroom could not reconcile it with v0.3.0: recounted from git, v0.2.98 left 102 legacy-prefixed read keys in 27 tracked files, 93 in 26 content pages and 9 in one build script, not 99 across 27 pages. v0.3.0's 102 was right. The old entry is amended in place and says so. (4) STALE AND WRONG PAGES: two asks on the briefs index were closed long ago elsewhere (riskmandate.ai built the interview page in its v1.34.2; the CLI prefix bug closed in our v0.3.0); the interview brief now cites riskmandate.ai's earlier voice feedback prompt, which it should have; the key management call names the three plans that depend on it; the Risk Acceptance vault's README said eight weeks for a six-week replay and is fixed in a fourth commit; and the Sovereign AI page said contracts run to five million pounds over 12 to 24 months, which no official page we could find says: the scheme's competition guidance, read today, gives 250,000 pounds to 10 million, most at 1 to 3 million, and numbers the agent challenge 4. (5) The newsroom's reader's log, chat and relay pattern is published as a build brief, not adopted. A response page answers every item, and two loose ends stay open and waiting on the founder: partnership contacts, and documenting the Azure and Google Cloud deployments. New: Append-lane messaging between agents that hold no one else's vault key, The reader's log, the chat with tools, and the relay: a pattern proposed by sgit.newsroom.sgit.ai, What sgit.ai did with the newsroom's briefing, 26 September 2026. Updated: A proposed partnership between sgit.ai and Anthropic, A proposed partnership between sgit.ai, RiskMandate.ai and UK Sovereign AI, About the author, Dinis Cruz, API: append lanes (sgit.ai), Build your startup on sgit vaults. And 15 more pages. Every change, in git. |
| v0.6.8 | 2026-09-24 | git fd203e01 | 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. New: Company X-Ray, a business plan with one company X-rayed, published as a vault. Updated: A proposed partnership between sgit.ai and Anthropic, About the author, Dinis Cruz, Build your startup on sgit vaults, Business plans to build on sgit, Models do the work, vaults hold it: proposed partnerships with the AI providers, Partnerships, argued in the open, Who holds the keys? A call for collaboration on vault key management. Every change, in git. |
| 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. New: Lesson Loop, a business plan for coaches with one player's record, published as a vault. Updated: A proposed partnership between sgit.ai and Anthropic, A proposed partnership between sgit.ai, RiskMandate.ai and UK Sovereign AI, About the author, Dinis Cruz, Build your startup on sgit vaults, Business plans to build on sgit, Models do the work, vaults hold it: proposed partnerships with the AI providers, Partnerships, argued in the open. And 1 more pages. Every change, in git. |
| 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. New: Every risk is already accepted. The only question is by whom, and for how long., Risk Acceptance Office, a business plan with one risk replayed, published as a vault. Updated: A proposed partnership between sgit.ai and Anthropic, A proposed partnership between sgit.ai, RiskMandate.ai and UK Sovereign AI, About the author, Dinis Cruz, Build your startup on sgit vaults, Business plans to build on sgit, Models do the work, vaults hold it: proposed partnerships with the AI providers. And 2 more pages. Every change, in git. |
| 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. New: A proposed partnership between sgit.ai and Anthropic, A proposed partnership between sgit.ai and AWS, A proposed partnership between sgit.ai and DigitalOcean, A proposed partnership between sgit.ai and ElevenLabs, A proposed partnership between sgit.ai and Google Cloud, A proposed partnership between sgit.ai and Google Gemini, A proposed partnership between sgit.ai and IBM Cloud, A proposed partnership between sgit.ai and Microsoft Azure. And 11 more pages. Every change, in git. |
| 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. New: Before you give an agent a connector, give the connector a twin, Business plans to build on sgit, Connector Twin, a business plan with a working replay, published as a vault. Updated: A proposed partnership between sgit.ai, RiskMandate.ai and UK Sovereign AI, About the author, Dinis Cruz, Build your startup on sgit vaults, Partnerships, argued in the open, Who holds the keys? A call for collaboration on vault key management. Every change, in git. |
| 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. New: About the author, Dinis Cruz. Updated: For a startup, the most important question is whether they miss it, Fractal Semantic Graphs: everything connects to everything, and nobody has to share a schema, The future of news is the story vault, not the paywall, The SaaS apocalypse will be decided by inertia, not by AI. Every change, in git. |
| 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 Updated: For a startup, the most important question is whether they miss it, Fractal Semantic Graphs: everything connects to everything, and nobody has to share a schema, The future of news is the story vault, not the paywall, The SaaS apocalypse will be decided by inertia, not by AI. Every change, in git. |
| 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/ |
| 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. Updated: A chat box on a site with no server, the plan, and the trade it makes, A live site whose host cannot read it, sgit.ai case study, A three-minute pitch, delivered from a vault, a published vault, A vault app, live inside this page, sgit.ai demos, Admin & engineering, Agent state that isn't the vendor's to read, sgit use cases, Agentic Browser Isolation, a published vault, AI vs. AI, Black Hat Europe 2025, a published vault. And 120 more pages. Every change, in git. |
| 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 [CORRECTED IN v0.6.9: 102 keys in 27 tracked files, 93 in 26 content pages and 9 in one build script, recounted from git; this count was three short and called a script a page] still carry the legacy rk1 prefix, which is neutral rather than wrong. New: Vault credentials: what each one can do, and what its prefix declares. Updated: AIUC-1, as a graph you can cite, a published vault, Documentation, sgit, Provenance is not conformance, a published vault, Published vaults, Publishing a vault: the method, VoiceDebrief, a published vault. Every change, in git. |
| 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. Updated: Fractal Semantic Graphs. Every change, in git. |
| 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. Updated: Fractal Semantic Graphs. Every change, in git. |
| 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. Updated: Fractal Semantic Graphs. Every change, in git. |
| 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. Updated: Demos, Fractal Semantic Graphs, Published vaults. Every change, in git. |
| 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. Updated: Fractal Semantic Graphs. Every change, in git. |
| 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. Updated: Demos, Fractal Semantic Graphs, Published vaults. Every change, in git. |
| 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. Updated: Admin & engineering, Case studies, Demos, Git repos inside vaults, SG/Vault, Historian, an agentic role on sgit.ai, How the site is run, the agentic team behind sgit.ai, One working tree, two version control systems, and why we stopped, sgit.ai case study, Published vaults. And 5 more pages. Every change, in git. |
| 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. New: Corporate users, services available now, Founders, open source technology that works today, Four sheets, four audiences, one stack, the Lisbon summit handouts, Investors (how does your firm share data with its portfolio?), Startups. It is open source, and it is built to be built on. Every change, in git. |
| 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/ |
| 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 , 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 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 |
| 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= |
| 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/ |
| 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 |
| 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= |
| 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>: |
| 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. |
Numbering: v0.1.n while the site is in its first structure; the middle digit will bump on structural redesigns. The commit of the newest row reads "this release" because the id only exists once the release is committed. It is recorded here retroactively by the next release. Rows up to v0.2.76 carry the id of the sgit commit in the site's own vault, which was pushed alongside git until the mirror was retired; from v0.2.77 the id is the git commit, prefixed git. Commit ids before v0.2.84 are those of the history as rewritten on 19 September 2026 to purge the mirror.