sgit.ai

sgit is git for encrypted vaults: clone, commit, branch and merge files that are encrypted client-side (AES-256-GCM) before they leave your machine. The server stores ciphertext under opaque IDs, it never sees filenames, contents, or commit messages. This site is the official documentation for sgit and the SGraph vault platform (SG/Vault, SG/Send).

Every page below is markdown, generated from the same source as the HTML page at the same path (swap .md for .html). Links inside the markdown point at markdown, so you can traverse the entire site without parsing HTML.

START HERE, BY WHAT YOU ARE DOING, the page list below is exhaustive and therefore flat, so these are the entry points that are worth more than their position in it suggests:

• About to build, publish or change a vault? /docs/guidance/index.md is the front door: the practices that get repeated most, and a route to the page that answers each question. Its agent-shaped twin is /docs/guidance/llms.txt, five rules, a reading order, the briefs, and reference implementations to go and check.
• Deciding WHERE your code should run? /docs/surfaces.md first. _page.json inside a vault, an HTML vault app, or a page on a *.sgit.ai site are three different answers to almost every question, and they have opposite trust directions.
• Writing a viewer, an app or a page against a vault? /docs/briefs/, build briefs written to be executed, each ending in a prompt to hand a builder agent.
• Looking for a worked example? /demos/vaults/llms.txt is the catalogue of every published vault with its read key, generated from the same file the human-readable table is, so the two cannot disagree.
• Fractal Semantic Graphs? /demos/fractal-graphs/index.md defines the term (every node opens into a semantic graph with its own ontology, down to the word; only the grammar is shared) and then walks one grammar from the text of a law to a threat in one method on one compute instance, across the vault where the idea was first worked and seven more, with the rungs that are still modelled rather than imported stated plainly.

SCOPED INDEXES, each covers one part of this site and is regenerated on every release: /llms.txt (this file, everything) · /docs/llms.txt · /docs/guidance/llms.txt · /docs/vault/llms.txt · /api/llms.txt · /demos/vaults/llms.txt

Notes for agents:

• sgit is in beta and powers production workflows. Honest edges: /docs/limitations.md
• Install: pip install sgit-ai (Python >= 3.11; entry points sgit and sgit-ai)
• Vault keys are full-strength generated keys (passphrase:vault_id). No password reset exists.
• Never write a vault key into a tracked file. See /case-studies/exposed-vault-key.md for what that costs, and /docs/guidance/index.md for the practice that prevents it.
• The agent-facing command is sgit write <path> --file <f> --message <m> --push --json; every read path has a --json flag.
• Cross-session state pattern: clone/pull at session start, commit + push at session end.
• Task-shaped recipes by industry live under /use-cases/; the guidance for working ON a vault moved to /docs/guidance/ and the build briefs to /docs/briefs/.

If your tooling cannot follow links out of this file, fetch /llms-full.txt, every page of this site concatenated into one document (~155 KB). One request gets the complete set.

Quick answers (so you do not need a second request for the common questions):

• Does sgit do the git operations you know? Yes for: init, create, clone, status, commit, push, pull, fetch, branch (new/list/switch/checkout), merge with conflict resolution, history log/diff/show/revert/reset, stash. No for: pull requests (a hosting-platform construct layered on merge, not a git primitive), a staging area or partial commits (a commit snapshots the whole folder), bisect, blame, rebase, cherry-pick, hooks, submodules and tags. Full mapping: /docs/sgit-for-git-users.md
• The three deliberate differences from git: no staging area; every clone gets its own private branch and publishing to a shared branch is explicit; the vault key is address, credential and encryption key in one string.
• What the server can see: the vault ID, the size of each encrypted object, and request timing. Never filenames, contents, or commit messages. /security/index.md
• Read access is a separate, one-way-derived key: publishable, cannot be turned into write access, works against any server holding the ciphertext. This site publishes one.
• Crypto: AES-256-GCM, PBKDF2-HMAC-SHA256 at 600k iterations, HKDF-SHA256. No custom primitives; output matches the browser Web Crypto API byte for byte.
• Can two vaults SEND MESSAGES to each other? Yes. The transport is an APPEND LANE: a write-only channel on the recipient's vault, gated by a hex append_token the sender holds. The sender POSTs to /api/vault/append/write/{vault_id} with NO account and NO access token; the response is blind ({"ok":true}, no id, no count). The recipient lists and fetches with x-sgraph-vault-enum-key and decrypts client-side. Encrypt with sgit pki encrypt --recipient (RSA-OAEP 4096 + AES-256-GCM). Full worked example: /docs/vault-messaging.md
• The intended lane address is append_token = H(recipient public key), so a sender can derive it from a published key. That derivation is PROPOSED, no shipped command emits it, so today you agree the token out of band. The server side is shipped. Do not code against the derivation.
• PKI exists. sgit pki keygen/list/export/import/contacts/sign/verify/encrypt/decrypt. The vault key is symmetric and roots the storage hierarchy; keypairs layer on top for identity and recipient-addressed encryption. /docs/pki.md · /security/index.md#pki
• The HTTP API is the whole surface, the CLI and the browser bridge are both clients. /api/index.md
• sgit is beta; it has no compliance certification of any kind.

Why this exists

• Why does this exist?↗: A direct answer to the sharpest criticism we received: no market, no value. The use cases, why existing tools do not cover them, where the criticism is right, and a FAQ of the follow-up questions.
• Four sheets↗: The September 2026 startup-summit handouts: the same capabilities framed for founders, startups, investors and corporate buyers, each as a page and as the PDF that was handed out, with a 'what exists today' column that is unflattering on purpose.
• Founders↗: Seven capabilities with an MVP or a live example behind each, and two ways to build a company on them: on your own, or with the author on one of three rungs, direct hire, revenue share, or a company.
• Startups. It is open source↗: Nine capabilities to reuse, each naming what it runs on and how far along it is, including the ones that are still a design and say so.
• Investors (how does your firm share data with its portfolio?)↗: Six capabilities for investor operations) vaults the host cannot read, a write-only link for founders, and a licence to operate for each agent a portfolio company runs before it becomes your risk.
• Corporate users↗: Eight services for governing the agents already running, each stating what it is, what it runs on, and how far along it is, some live products, some designs delivered as engagements.

About the author (Dinis Cruz: the record, the signed articles, writing elsewhere, and interests declared)

• About the author↗: The provenance behind the first-person articles: the record (sgit.ai, sgraph.ai, MyFeeds.ai, The Cyber Boardroom, RiskMandate.ai, VoiceDebrief.ai, OWASP), the signed articles on this site, where else the author writes, the interests a reader should know about, and how to reach or correct him.

Partnerships (the business case for specific partnerships, made from public material only: what the organisation is trying to do, what is published here that answers it, and a first concrete piece of work)

• Partnerships↗: The business case for specific partnerships between sgit.ai, RiskMandate.ai and organisations we would like to work with, made from public material only so the pages can be forwarded to anyone: what they are trying to do, what is published here that answers it, where the fit is partial, and a first concrete piece of work.
• A proposed partnership between sgit.ai↗: A proposal from our side, published in the open. UK Sovereign AI names trust, safety and assurance as one of five frontiers and the safe adoption of AI agents as a procurement challenge area. This page states their mission in their own words, maps each priority to vaults published here that can be opened now (Licence to Operate, Risk Mandate, AIUC-1 conformance, the DSIT AI Risk Toolkit, Regulation Graph), states the UK anchoring in the founder's own words (thirty years in the UK, a UK exit, The Cyber Boardroom Limited as the trading company), argues that sovereignty without open source is one acquisition deep, proposes three concrete partnership shapes sized to their instruments, and lists what the page cannot tell them.
• Who holds the keys? A call for collaboration on vault key management↗: An open call to password managers, identity providers and platform credential managers. sgit vaults are encrypted on the client and opened in a browser with one key, and keys now multiply faster than people can manage them by hand. We would rather use a key manager than build one. The page explains sgit for someone new to it, states what we are looking for (something that exists, a joint pilot, or an open specification), the requirements (browser first, key kinds kept apart, release only on approval, end-to-end sharing, names in plain words that are addresses and never keys, revocation, keys for agents), a sketch of the share flow, why the old word-based token was removed, and what we would bring.
• sgit runs on every cloud: proposed partnerships with the cloud platforms↗: What sgit needs from a cloud (mostly storage, a little compute), where it stands today on each (AWS templates in beta, Google Cloud planned, Azure deployed but undocumented, Docker everywhere), the two partnerships in one (vaults in the cloud's environment, and services on top of vaults), why it is good for a cloud, and one page per cloud: AWS, Azure, Google Cloud, IBM Cloud, the European clouds, DigitalOcean, Rackspace and Netlify.
• A proposed partnership between sgit.ai and AWS↗: We would like to work with AWS more closely, and we are already most of the way there. sgit's deployment templates were written for AWS first, the vault service behind the vaults published on this site answers from Amazon S3 behind CloudFront, and our startup credits are AWS credits. What is missing is the partnership: a reviewed reference architecture, a listing in AWS Marketplace, and a route to AWS customers who need encrypted handover or sovereign storage.
• A proposed partnership between sgit.ai and Microsoft Azure↗: sgit runs on Azure. We just have not written it down yet. The founder has deployed the vault server on Azure and it works, but the published documentation covers Docker, AWS, Google Cloud and static hosts, not Azure. We would like to close that gap with Microsoft: a documented, reviewed deployment on Azure services, a listing in Microsoft Marketplace, and a route to the many organisations whose data already lives in Azure and Microsoft 365.
• A proposed partnership between sgit.ai and Google Cloud↗: We would like to finish the Google Cloud path with Google. The vault server image is already Cloud Run-ready, the Cloud Run guide is written down as planned, and the founder has deployed it on Google Cloud. What is missing is native Cloud Storage support, a reviewed guide, and a listing in Google Cloud Marketplace, which accepts open-source container images and, now, AI agents.
• A proposed partnership between sgit.ai and IBM Cloud↗: We would like to work with IBM on sovereign, regulated data. IBM made digital sovereignty a product with IBM Sovereign Core, generally available since May 2026. sgit adds the piece that makes sovereignty hold at the data layer: encrypted vaults whose host, whoever runs it, only ever sees ciphertext. IBM Cloud has the storage and the serverless compute sgit needs, and IBM's customers have the regulated data that needs it.
• A proposed partnership between sgit.ai and the European clouds↗: For European clouds, vaults are the sovereignty argument made concrete. OVHcloud, Scaleway, Hetzner, IONOS and STACKIT are chosen by customers who want their data in Europe, under European law, with a European provider. sgit adds the guarantee that even the provider cannot read it: the host holds ciphertext, the keys stay with the customer, and the code is open, so nobody can be bought out from under them. Every one of these clouds offers S3-compatible object storage, which is most of what sgit needs.
• A proposed partnership between sgit.ai and DigitalOcean↗: DigitalOcean is the shortest path from "I want to try vaults" to a running server. Spaces is S3-compatible object storage with a built-in CDN, App Platform runs a container, and the DigitalOcean Marketplace explicitly invites open-source projects as 1-Click Apps. For the developers and small teams DigitalOcean serves, a one-click vault server is exactly the right size.
• A proposed partnership between sgit.ai and Rackspace Technology↗: Rackspace is the partner who would run vaults for customers, on whichever cloud they use. Rackspace Technology operates managed services across the major clouds and offers UK sovereign clouds for government, healthcare, police and commercial customers. sgit is open source and needs very little infrastructure, which makes it a good fit for a managed-service provider: the value is in running it well, not in the licence.
• A proposed partnership between sgit.ai and Netlify↗: Netlify already hosts the kind of thing a published vault is. A vault can be read from a plain static host behind a CDN: the browser fetches ciphertext and decrypts it locally, with no server at all. Netlify is named in our static hosting guide for exactly that. The partnership we would like is to make "an encrypted site, readable only with a key, updated with a push" a documented pattern on Netlify.
• Models do the work↗: Three places where a model provider meets a vault (agents read and write vaults through a connector, vault apps call models without holding a key, vaults carry the agent's work to a person), what we already do with these providers, what we ask of each, and one page per provider: OpenAI, Anthropic, Mistral AI, Google Gemini, OpenRouter and ElevenLabs.
• A proposed partnership between sgit.ai and OpenAI↗: We would like vaults to be where ChatGPT and Codex put work that has to be handed over. OpenAI's agents already produce reports, code and analyses that someone else has to receive, check and keep. A vault carries that result, its history and its app as one read key. OpenAI's platform now reaches remote MCP servers from the Responses API and lists MCP-based plugins in a directory shared by ChatGPT and Codex, which is exactly where a vault connector would live.
• A proposed partnership between sgit.ai and Anthropic↗: This site is already a Claude Code project, and vaults are how its sessions work together. sgit.ai, its briefs, its deployment docs and most of its thirty-three published vaults are built and published by Claude Code sessions that share state through a vault. We would like to turn that working practice into a partnership: a vault connector in Anthropic's Connectors Directory, skills that teach Claude to use vaults well, and a place in the Claude Partner Network.
• A proposed partnership between sgit.ai and Mistral AI↗: A European model, a European cloud, and vaults: a fully European AI stack in which no key leaves the customer. Mistral hosts data in the EU by default, supports MCP connectors in its Agents API and in Vibe (formerly Le Chat), and runs a partner programme with an integration tier. sgit provides the encrypted data layer, open source and runnable on any European cloud. Together they make a sovereignty story that holds at every layer.
• A proposed partnership between sgit.ai and Google Gemini↗: The quickest listing on this page is one we can do ourselves. Gemini CLI supports MCP servers, and Gemini CLI extensions are listed automatically when a public repository carries the right topic and manifest. For the enterprise side, partner agents listed on Google Cloud Marketplace appear in the Gemini Enterprise Agent Gallery. We would like to do both properly, with Google, so that agent work done with Gemini can land in a vault.
• A proposed partnership between sgit.ai and OpenRouter↗: OpenRouter is how the vault apps on this site reach models, and it has the credential the pattern needs. A vault app calls a model through the host, and the key never reaches the page. The safest credential for that is one that is bounded: a spend limit and a reset. The independent provider report on this site records OpenRouter as "the one provider in this family that can do pattern one". We would like to make that a documented, supported pattern together.
• A proposed partnership between sgit.ai and ElevenLabs↗: We already publish an independent report on ElevenLabs, and it ends with one clear ask. The narration on this site is rendered with ElevenLabs, and elevenlabs.providers.sgit.ai records what it cost on a named workload, what broke, and which credential patterns the product supports. What would let a vault app use ElevenLabs safely, with no key in the page, is a key with a spend limit, or a short-lived token for text to speech.

For startups (building a product on vaults: what you get on day one, the loop from first vault to first customer, and what you still have to bring)

• Build your startup on sgit vaults↗: For founders: a vault removes the four costs that usually stand between you and a first user (a database to run, hosting for your reader, an account, an install), so you can ship something usable, give it away briefly, take it away, and find out whether they missed it. What you get on day one, the ladder from first vault to first customer, what you still have to bring (billing, identity, server-side query), and the measured cost base.
• Business plans to build on sgit↗: Businesses we think should exist on top of sgit, each written up as a vault in enough detail for somebody else to start: Connector Twin (a journal and replay of every connector call an AI agent makes, sold per agent) and Agent as Webmaster (websites small businesses change by asking). How to take one, what every plan contains, and the offer to build them with partners.

Demos (live end-to-end examples with published read keys)

• Demos↗: Live end-to-end demonstrations: vaults actually created, pushed, and embedded in the pages that document them, each with a deliberately published read-only key.
• Fractal Semantic Graphs↗: What a Fractal Semantic Graph is: every node opens into a semantic graph with its own ontology, joined to the worlds above and below by named edges, down to the word; why that lets everything connect with everything without forcing anyone to share a schema; and the evidence: the vault where the idea was first worked plus seven more published vaults from the text of a law to a threat in one method on one compute instance, with screenshots, counts, and the rungs still modelled rather than imported.
• Performance↗: Measured answer to “performance of graph engineering versus fractal graph”: no live database, files in object storage, and the LETS cycle (Load, Extract, Transform, Save) with a disposable engine in the reader's tab. A 617-node graph opens in 94 KB and three requests, a question costs 7.8 s and 315 KB from cold against 65.4 s for a full clone, an ontology costs 4 KB, and the standing cost of thirty one published graphs is 295 MB of object storage with nothing running between questions. Plus the cost model line by line, the five places the same read key runs, fractal deployment, and six places it is slower. Key fact: NO LIVE DATABASE. A graph is encrypted files in object storage, read directly; the engine is built per question and thrown away (SQLite in WebAssembly in the tab, or a serverless function that lives one request). The cycle is LETS: Load bytes, Extract the slice plus its ontology, Transform in a disposable engine, Save the answer as NEW immutable files, never an overwrite, which is why every cache in the path is correct forever. MEASURED 21 Sep 2026 against live vaults: full clone of a 42-file 3.2MB vault 65.4s; sparse clone (every path, size and hash, no content) 7.3s and 256KB; one 59KB file 0.49s; the whole 617-node graph as one file 1.0MB in 1.21s; an already-fetched file 0.18s with no network. In-browser bytes per view: overview 94KB in 3 requests, guidance 295KB in 4, the 617-node graph 1.12MB in 5, data and queries 1.19MB in 6, against a 3.2MB vault that is never loaded whole. An ontology is 2-4KB, the entire price of crossing into another world. COST: zero instance hours, zero replicas, zero index memory, no separate backup line (every version is already kept); storage and egress only; query compute is paid by the reader device. The whole published estate is 2,662 files and 295MB. SLOWER AT: full clones, anything needing a server-side query, deep traversal over one huge single-schema graph (use a graph database), concurrent multi-writer. THE TRANSPORT: file ids are DERIVED by HMAC-SHA256 over the read key under named domains (sg-vault-v1:file-id:ref, :branch-ref, :branch-index), so a client COMPUTES an address instead of looking it up, and reading an encrypted file is ONE unauthenticated CORS GET (measured 2,364 B ciphertext in 0.86s, 59,324 B in 0.63s). One POST to /api/vault/batch/{vault_id} reads MANY: 5 objects 0.87s, 20 objects and 3.76MB in 2.79s, one round trip; 42 returned 502 (response-size limit, the CLI splits the chunk). Encryption adds a FLAT 28 bytes per object (12-byte nonce + 16-byte tag), not a percentage. Two addressing modes: pin the content-addressed obj-cas-imm id for one GET forever, or resolve HEAD to tree to blob for always-current. The 65s clone is a CLIENT-side cost (106 blobs including history, plus one 50-file batch degrading to 50 single fetches), not a transport limit. APPEND MODE: lanes live at bare/append/{token}/pending/ OUTSIDE the commit tree, so a write is one account-less POST with no read-modify-write, no commit, no tree rebuild and no lock, it never conflicts with a push and never contends with a read, and the response is deliberately blind. CACHING: the cached bytes are CIPHERTEXT so a cache is not a trust boundary, and an obj-cas-imm id is SHA-256 over the ciphertext so an entry can never be stale; refs are the exception and must not be cached. Live example: sgraph.ai/en-gb/library/ serves a whole knowledge base from two encrypted vaults behind a 270KB static shell. THE DESIGN IS THE BIGGEST FACTOR: start by asking WHAT DATA THIS QUESTION NEEDS, and compose three layers that are already fast (the file system with its page cache, a content-addressed hash store where a name is a hash, and the graph that tells you which bytes to ask for). A database is fast mainly because it keeps the working set in memory; same insight, but a buffer pool guesses the set in advance for all readers while we pick it per question and discard it. MEASURED on the 1.0MB graph file: cold network fetch 1,210ms, local disk read 2.5ms (418 MB/s), AES-256-GCM DECRYPT 0.351ms (2,978 MB/s), JSON parse 3.2ms. Decryption is 0.03% of the fetch and a TENTH of the JSON parse, so encryption is effectively free and the network is everything. BUDGET RULE: <100KB is an answer, ~1MB is a whole world, 10MB+ means you are loading a store not an answer, GB is a design error. SAVE COMPOUNDS: each pass leaves an artefact cut for the next question (the Article 9 slice makes re-asking cost 29KB not 1MB). SEMANTIC COMPRESSION LADDER, Regulation Graph: raw source 11,216,043 B, graph 1,073,915 B (10x), one article slice 29,638 B (36x), ontology 4,217 B (7x) = 2,660x top to bottom with NOTHING discarded, because each level keeps the edge to the one below. Therefore the store can be TB while a query stays in MB: adding data adds nodes you did not load. NOTE: the DSIT graph measured here has 1,051 nodes and 1,289 edges (its vault page says 617/694, the figure at publication before release 0.2.1). LATENCY IS A FIXED PER-REQUEST COST, NOT A BYTE COST: a GET returning 340 bytes took 0.331s and one returning 41KB took 0.309s, the same; at 1.0MB the total is 0.647s of which only 0.300s is transfer. That ~0.33s floor is the PER-INVOCATION COST OF THE SERVERLESS DEPLOYMENT, not a property of reading encrypted data, and SG/API also runs on EC2 with a warm process where it does not apply (not measured here). BATCHING AMORTISES IT: 1 object 0.590s, 2 in one batch 0.394s, 10 in 0.872s, 18 in 1.528s, fitting TIME = 0.25s FIXED + ~71ms PER OBJECT + transfer. 18 objects one at a time is ~6.3s versus 1.53s batched, 4x. The batch endpoint takes up to 100 operations, MIXED READS AND WRITES (read, write, write-if-match, delete) authorised per operation; write-if-match carries the SHA-256 of expected content and IF ANY MATCH FAILS THE WHOLE BATCH IS REJECTED, giving optimistic concurrency over many files in one round trip with no lock. Large blobs use presigned URLs. Known next optimisations: fetch batch objects concurrently server-side (the 71ms/object is near-linear, so it looks serial), and chunk by accumulated size rather than file count to stop the 502. THE API IS A CONVENIENCE OVER THE STORE, NOT A REQUIREMENT: readers can go straight to the bucket or a CDN with NO function in the path, and this is SAFE because every object is ciphertext and every name is a hash, so public GETs disclose only object size and request timing (the side channel the security model already names). MEASURED, same client, same vault, same 106 objects, only the path changed: full clone through the serverless API 65.4s, full clone over PLAIN GETS 2.63s, off a local folder 2.05s = 25x (the static host was localhost so the network was free; a real CDN adds edge latency). Already shipping as sgit clone --transport static <any GET host>, which sniffs one of two published layouts, fans out 8 parallel GETs, and records every URL touched so a test can assert no key material was ever sent. THE DIRECT PATH IS ALREADY IN PRODUCTION FOR LARGE FILES: anything over 4MB (safe margin under the ~4.7MB serverless base64 limit) is handed a presigned URL and fetched straight from storage, which is also the 502 fallback. Further ordinary options: CDN in front of the bucket, ranged/parallel GETs for 100-500MB objects, lower-latency classes such as S3 Express One Zone (not benchmarked here), or another provider entirely. FINDING AN OBJECT: usually the id is already pinned in the page; otherwise ref -> commit -> tree -> blob, a couple of requests, not a clone. Measured: one named file out of a sparse clone = 2 requests (one of them a skippable layout re-probe). Git cannot do this because its objects are packed and its transport negotiated. GAP: there is NO history-depth flag. --sparse skips content, --bare skips the working copy, but a full clone still takes 106 blobs where the current tree is 42 files; depth control would most improve clone time.
• A vault app↗: The complete walkthrough: create a vault app, push it, derive and publish the read key, and open the app live inside a sgit.ai page in a sandboxed iframe with a postMessage window.sg bridge.
• The Strategy in Seven Maps↗: The actual SG/Send strategy (eight Wardley Maps, published on LinkedIn in May 2026) served live from an encrypted vault with a published read key, plus the audit that found the original vault could NOT publish its key (its own write credential was inside its content) and the republish pattern that fixed it.
• sgit↗: Six Wardley Maps analysing sgit's positioning) starting with where git wins, drawn as inline SVG and served as a second app from the same encrypted vault as the SG/Send strategy essay: one vault, two entry points, one published read key.

Catalogue (the index of published vaults, read keys, shapes, evidence and write-key status)

• The vault catalogue↗: An index of published vaults rendered live from a vault that indexes vaults, including itself. Each entry: a deliberately published read key, shape, evidence status, copy-or-reference semantics, and write-key status (known-and-escrowed or lost, a frozen vault can never be corrected). Submitting a vault costs a read key and one line; the rest is derived.

Published vaults (one page per vault: description, features, live embed, and the read key that opens it)

• Published vaults↗: Thirty-one vaults you can open in your browser right now, every read key published on purpose. A read key is the whole credential: no account, nothing to install, no write capability in it. Each row opens a page with what the vault does and the vault running live inside it.
• Start with an AI decision↗: An independent, experimental journey through the UK DSIT AI Risk Management Toolkit, published as a vault: describe a use case, review the risk prompts that apply, record evidence and owners, propose controls and reassessment, and follow each step back to its source. An eight-slide walkthrough plays on the page from the encrypted vault, with the PDF as a download. Underneath: separate worlds with named bridges, every edge labelled curated or lexical, hashed source snapshots, 13 passing checks and 6 published gaps. Not an official DSIT service or certification.
• Publishing a vault: the method↗: The seven steps behind every vault published here, written for another agent to follow: classify the credential before it touches anything, derive rather than refuse, audit with the read key, derive the facts, capture evidence by driving the real product, write the page, and record what outlives it, plus the mistakes that produced each rule.
• The same pack↗: Sibling of vault #29 from the same generator: a fractional CISO pack that solves the publication problem by describing a type of company rather than withholding a real one. Five documents in four formats, a one-page infographic, an engagement document with a twelve-month map and a section on what two days a month is not, and the audit stated in full.
• An application for a job↗: A candidate pack delivered as an encrypted vault instead of a CV on an email: three routes for three readers, four documents each in PDF, Word, Markdown and JSON, a disclosed redaction, and a client named nowhere, with the pre-publication privacy audit stated in full.
• Synthetic users↗: The synthetic-user method applied to a second product one day later: 30 screenshots, 12 findings, two blocking a sale, and a headline finding that is measured rather than narrated, plus a JavaScript error on every page that had shipped and that every existing test had passed over.
• Synthetic users↗: Five invented buyers walked through store.sgit.ai one screenshot at a time, asked what they made of each screen and interviewed at the end: 43 screenshots, 15 questions the site did not answer, 10 confusions and 18 findings, three of them costing a sale, four already fixed and kept rather than deleted.
• The sgit.ai board↗: The site's own task board, moved into a vault: every card a markdown file, a five-column board app that requests no permissions, and a published read key, because every task, bug and need on it is public. The site renders a snapshot at each release; the vault is the truth between them.
• Field Notes↗: The minimum viable published vault: six studies with generative SVG art as a self-contained vault app, read over the sg.vfs bridge, opened by a single published read key.
• Strategy Maps (a published vault)↗: The SG/Send strategy in seven Wardley maps plus the sgit positioning analysis) two app entry points in one encrypted vault, published after the audit that made a republish necessary.
• Deploy Docs↗: The living deployment documentation for sgit.ai: markdown written by two Claude Code sessions, rendered live in the visitor’s browser, updated by an sgit push with no site deploy.
• The Vault Catalogue (a published vault)↗: The index of published vaults, itself a vault, listed in itself) a submission queue where an entry costs a read key and one line, with published to-do lists and first-class write-key status.
• Supplement Stack↗: A patient-held health record as a vault: a real supplement regimen, label photographs every extracted value is traceable to, deterministic totals against UK RNIs and EFSA upper limits, and an adherence log the app may write to and nothing else. Shared with a professional by handing over a read key.
• Risk Mandate↗: A working application built and delivered as a vault: 124 files, 98 commits, eight entry points, pinned releases, offline capable, and it calls an LLM without ever holding the API key, which is sealed under the vault key.
• Agentic Browser Isolation↗: A living risk graph for whether an AI agent browses with your logged-in sessions or an isolated identity: seventeen entry points, a page per stakeholder altitude, acceptance-gated escalation, cited evidence, and an app that requests no write capability at all.
• Risk Graph Explorer↗: A fact-to-risk graph explorer extracted into its own vault and designed to be public: its PUBLIC.md states three rules its build enforces, including no metered capability behind a published read key, and its app.json requests no permissions at all.
• The seven views↗: A deep walk through each view of the risk graph explorer) the estate, context, role risk map, risk chains, the register, acceptance and what happens next, with screenshots of the live vault and the mechanism behind each, grounded in the author’s own walkthroughs.
• The author’s walkthroughs↗: Three recorded walkthroughs of the risk graph explorer with full transcripts: the graph browser, risk chains, and the role risk map, the designer explaining why the tool is shaped as it is.
• Algarve · May 2026↗: A travel diary as a vault: twenty photographs in three sizes, an eight-chapter narrative and an auto-opening gallery app, 29 MB of ciphertext opened by one published read key, with its pre-publication audit finding stated on the page.
• Vault App Mode↗: Nine progressive proof-of-concepts and a four-page demo showing how to load CSS, JavaScript and data inside an encrypted vault, including a fifteen-test harness over the vault filesystem, and the audit that found the original could not be opened by a read key at all.
• Private Health Score↗: A complete clinical workflow as a vault: adaptive questionnaire, a versioned scoring framework loaded at runtime, explainability tracing every recommendation to an answer, and a clinician review, published as a sanitised republication after an audit found the original vault carried its own write credential.
• VoiceDebrief↗: Four apps in one encrypted vault: lifting meaning from fictional voice notes to Article 9(2) of the EU AI Act into typed semantic graphs, with read scoped to one folder, write nowhere, and the briefings it was built from shipped beside the work.
• Regulation Graph↗: The EU AI Act as a citable graph: Regulation (EU) 2024/1689 parsed from official Formex XML, hash-verified to source bytes, 1,523 nodes and 1,944 edges across eleven views. Published as a redacted republication after an audit found a plaintext vault key in the original.
• SG/Payments Brief Pack↗: A ten-document briefing pack for a payments and metering platform, published as a vault while every word of it is still PROPOSED. The status is stamped on the pack index, not buried in a footnote.
• Agent as Webmaster↗: A complete business plan for a company that gives small businesses a website they can change by asking, with an AI agent as the webmaster: architecture, workflow, packages and prices, a unit-economics calculator, go-to-market, the first ninety days, the investor case, the risks, four mock-up sites and the prototypes to run the first customer. Published with its read key, written for somebody else to run.
• Connector Twin↗: A business plan for a service that journals every request and response an AI agent makes through Gmail, Calendar or any connector, and replays it into the views the agent saw, with before and after and a revert plan for every change. Opens on a working replay of an invented seventeen-call session with a hash chain verified in the browser. Facts sourced from Google's documentation, the journal specification, revert rules, prototypes, packages priced per agent and a calculator.
• Risk Acceptance Office↗: A business plan for a company that runs the risk acceptance loop in the gaps of an organisation's GRC platform: every material risk established on facts, held by a named person, accepted for a stated interval, and at expiry accepted again, escalated, funded or fixed. Opens on ten principles and a six-week replay of one invented risk with a hash-chained decision record verified in the browser, then the operating model, services priced per material risk, a calculator, go-to-market, the risks and the open questions.
• Lesson Loop↗: A workflow and a business for padel coaches and any teacher with students: the coach records a voice memo at the end of the lesson, an agent turns it into a lesson note in the player's own vault, the player adds match notes, and the next coach starts from a two-minute briefing. One invented player's record across four lessons with three coaches, the themes each saw, phases, the two-vault architecture with write-only lanes for coaches, pay-on-demand credits, new coach income, a calculator, and the prompts for phase one.
• Company X-Ray↗: A business plan for a service that 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 the customer gets back their questions answered, a board pack, findings tied to the file and row they rest on, and a Claude setup to keep asking. No connectors or integrations. One invented company X-rayed end to end with fourteen findings and a script that re-runs every figure, four levels from £50 to £1,500 on the RiskMandate pattern, a calculator, the prompts and the plan.
• SG Commercialisation↗: A commercial operating model published in the open: nine tools to productise, eight agentic roles, the engagement procedure and every template, with the live engagement register deliberately empty.
• RiskMandate: File security↗: A risk-acceptance walk in eleven steps over one evolving register, where the browser becomes the database: versioned JSON in the vault is the source of truth, queried live through SQLite compiled to WebAssembly.
• Standards Atlas: GDPR↗: The General Data Protection Regulation as a navigable semantic graph, where CJEU rulings, regulator guidance and per-country variation are first-class nodes layered over the articles they bend, with a validation surface that writes corrections back into the vault.
• Content-Transformation Proxy↗: A three-part as-built engineering brief published as a documentation site inside a vault: ten authored slides, a diagram library and the source PDFs, all served from one read key.
• Penetration Test Report↗: A complete penetration test delivered as a vault instead of a PDF: eight audience-specific views over one engagement, evidence per finding, and a retest script that re-runs each check and exits 0 or 1. Entirely fictional, and it says so on its own front page.
• AI vs. AI↗: A conference keynote shipped as a vault: the deck as presented, six PDF exports, eight research papers and the full source history of the slide system that renders it, all behind one read key, with the slide content as data the app reads at load time.
• Scaling Threat Modeling with Semantic Knowledge Graphs↗: ThreatModCon 2025, Barcelona: eleven linked threat models from customer to compute instance, five interactive views and five Wardley map walkthroughs, running offline inside the vault, with two upstream-broken data files repaired and the repair proved as a pure block move.
• AIUC-1↗: An unofficial, derivative machine-readable catalog of the public AIUC-1 agent standard: 53 controls, 144 requirements, 1,126 crosswalks and 1,238 nodes, where every field names the page or commit it was read from with the SHA-256 of the retrieved bytes. Not approved or endorsed by AIUC. Forked, byte for byte, into the conformance layer vault.
• Provenance is not conformance↗: A fork of the AIUC-1 catalogue vault that keeps every byte of it and adds one directory: attested_by kept permanently apart from evidenced_by, 53 conformance rows for a named subject where unevidenced is the default, and insurability computed as a query that turns into 53 exclusions when the date moves. Unofficial and derivative; not approved or endorsed by AIUC.
• A three-minute pitch↗: The VoiceDebrief pitch to Founder Institute: a presenter app with timed slides, speaker notes and a countdown, shipped with the outline, script, research and exports it was built from, and the first vault here that asks for any permission at all.
• Two games about agent permissions (a published vault)↗: Two deterministic games about grants, permissions and mandates) and the first vault published here that phones home. Anonymous usage events go over a write-only append lane to a separate private vault, disclosed on every page with a pause switch. Built by another agent from the build brief on this site.
• Licence to Operate (an insurance policy for an agent↗: One agent, its grant of 12 capabilities, its mandate of 4, and the 8-capability delta no policy covers, with a simulated conversation where every reply carries its cost against a live policy. The vault holds the terms; your browser holds the run.
• Seven shorts on the licence to operate↗: Seven vertical videos walking through the Licence to Operate vault, collected in the order they are meant to be watched: the mechanism (grant against mandate, blocking, who accepts which risk), how to find and open the vault, and the insurance model behind it, each with what it covers and which part of the vault it demonstrates.
• The AIUC-1 conformance layer decks↗: 4 decks published inside vault 2wzct4k7, each on its own page, with the slides read live out of the vault using its published read key.
• What AIUC-1 is↗: The agent standard, read from its own pages: six domains, 53 controls, 144 requirements, 1,126 crosswalks, and what it does not say
• The vault: files↗: A walkthrough of what is here) the JSON the standard became, the graph you can walk, the conformance layer above it, and the chat that reads all of it
• How RiskMandate.ai's insurance model works with AIUC-1↗: Grant, mandate, delta; the policy in metered units; the licence as a derived fact, and the standard as the vocabulary of what the policy covers and excludes
• Zoom in: D003 (one control↗: One control followed from the bytes of the standard to a session measured against it, to the words the layer needed (granularity, vacuous, outside-only), to the grant per tool, to the policy it becomes, to a simulation that runs
• The Licence to Operate decks↗: 5 decks published inside vault posrhzp3, each on its own page, with the slides read live out of the vault using its published read key.
• The problem (Licence to Operate decks)↗: Opens where almost everybody is standing) agents already running, and no way to say what wrong means, and lands on the delta. Stops there.
• The map (Licence to Operate decks)↗: A companion rather than a step: the same ladder seen from our side) the dependency map whose every absence is a risk entry rather than a blocker, the four layers and their seams, and the rungs, with the one where insurance starts named honestly.
• Bounding it↗: Stop asking whether the agent may do a thing and start asking how much. The band, the limit, the refusal, and where the check sits, which decides what you are actually buying.
• Who says yes↗: The hardest one. A refusal is a question addressed to somebody: the draw, the acceptor, no deny button, whose name goes on it, and what is signed in advance so the ordinary day never stops.
• The insurance model↗: The endgame, whole: grant, mandate, policy, the check, the two modes, the money, risks and acceptance, with real screenshots of the running simulation.

Comparisons run as reproducible tests (the entry format, the privilege vocabulary, and the rows where vaults lose)

• Comparisons↗: What a task costs with vaults and without, published by a participant and built to be challenged: every entry states the steps, the date, the result and how to re-run it. Includes a privilege vocabulary, and one comparison vaults lose.

Use cases (task-shaped guidance: recipe, evidence status, agent brief)

• Use cases↗: Who has the problem sgit solves, with a working recipe and an honest evidence status for each: AI agents, professional services, security teams, health and regulated data, plus the underlying workflows.
• The serialised pull request↗: An agent contributes to a shared vault holding no credential at all: clone with a public read key, commit on a private branch, emit a diff; a person imports, reviews and merges. The ambient-authority problem it removes, the 5 Aug 2026 Black Hat grounding, and the honest shipped-vs-pattern table.
• Agent state that isn't the vendor's to read↗: Durable and shared memory for AI agents in a store that cannot read it: the session protocol, multi-agent branches, sparse clones, and the evidence (this website).
• Working documents with clients↗: Engagement vaults for legal, M&A, audit and assessment work: versioned working notes, review as branches, and read-only handover with a published read key.
• Findings about your own weaknesses↗: Pentest and vulnerability findings with history, diffs and multi-person workflow, in a store that cannot read them, plus the key-hygiene rule we learned the hard way.
• Data that changes what is permissible↗: What client-side encryption does and does not change for regulated data, stated precisely and without compliance claims. Key fact: No HIPAA, ISO 27001, SOC 2 or GDPR finding exists; client-side encryption does not by itself make processing lawful.

Case studies (worked accounts of what actually happened, with numbers)

• Case studies↗: Worked accounts of things that actually happened, including the ones that went wrong: a leaked vault key and its rekey, and the architecture of a live site whose host cannot read it.
• One working tree↗: How this site was developed for 76 releases in a single folder that was both an sgit vault and a git repository (the .gitignore boundary, why the encrypted ref always looked dirty to git (fresh AES-GCM IVs), the ordering rule) and why the vault mirror was retired and purged: no reader, no published read key, 91% of the repository, and seven releases shipped without it before anyone noticed.
• Deleting files from git history↗: How this repository dropped 15,933 files from every one of its 112 commits: the setup with two branches drawn out, why git rm is not deletion, what git filter-repo does to every commit id, why the push had to be forced and how the lease made it safe, why a forgotten merged branch kept the purged objects reachable and downloadable, what happens when it is deleted, and the order to do it in when the file is a secret.
• A live site whose host cannot read it↗: A case study in the mechanism: two Claude Code sessions, two encrypted vaults, one page, with architecture diagrams of the publishing pipeline and the in-browser read path.
• The day we leaked our own vault key (sgit.ai case study)↗: The runbook for a leaked vault key) rotate, verify, re-point, plus a worked case study of the time it happened to this website.

Lessons learned (the rules this site enforces, each with the incident that produced it)

• Lessons learned↗: Every rule this site enforces, with the event that produced it: classify a credential before it touches anything (a vault key once arrived labelled as a read key), read keys yes and vault keys never (we leaked our own), audit every vault before its key is published (three vaults shipped as republications), and write the method down rather than the outcome.

Docs

• Documentation↗: sgit documentation: quickstart, concepts, guides for humans and AI agents, and the honest limitations page.
• What is sgit↗: sgit is git for encrypted vaults: how it works, what makes it different from git, and the ecosystem around it.
• Installation↗: Install sgit with pip, verify with sgit doctor, upgrade with sgit update. Python 3.11+, two runtime dependencies. Key fact: pip install sgit-ai, Python >= 3.11, two runtime dependencies, entry points sgit and sgit-ai.
• Quickstart↗: From zero to a synced, encrypted, versioned vault in five minutes: create, commit, push, clone, pull. Key fact: sgit create <name> then commit/push; the vault key is printed once and there is no reset.
• sgit for git users↗: The Rosetta stone: every git command mapped to its sgit equivalent, plus the three deliberate differences. Key fact: The three differences: no staging area; private clone branch per machine or agent with explicit publishing; the vault key is address + credential + encryption key in one string.
• The two-branch model↗: sgit's central idea: private clone branches per machine or agent, shared named branches, and explicit publishing. Key fact: Every clone commits to its own private branch; pushing to a shared named branch is a separate, explicit act.
• Working with AI agents↗: The agent-facing surface: sgit write, --json everywhere, sparse clones, the session pattern, and multi-agent collaboration. Key fact: sgit write <path> --file <f> --message <m> --push --json is the one-shot agent command; every read path takes --json.
• When NOT to use sgit↗: The honest page: sgit's edges, stated plainly, plus the current roadmap gaps. Key fact: Not a secrets manager; no partial commits; no key recovery; the server cannot index or search; beta.
• Working on a vault: start here↗: The first page to read before building, publishing or changing a vault. The practices that get repeated most, pick the surface, do not rebuild what the platform has, publish read keys never vault keys, version everything and show the version, plus routes to the brief that answers each question, and out to coding.sgit.ai, nfrs.sgit.ai and graphs.sgit.ai.
• Three surfaces: which one are you building for?↗: _page.json inside a vault, an HTML vault app, or a page on a *.sgit.ai site: what each can do, which credential each uses, and the trust direction that inverts between them, plus the same job done on all three, and where each surface’s guidance lives.
• Sending messages between vaults↗: How two vaults exchange encrypted messages without sharing a vault key and without the sender holding an account: append lanes addressed by a token, composed with PKI. Worked example in CLI, curl and sg.append, with the one step that is not yet wired marked PROPOSED. Key fact: Two vaults exchange encrypted messages over an APPEND LANE: a write-only channel on the recipient vault. The sender holds an append_token (hex, ^[0-9a-f]{16,128}$) and POSTs to /api/vault/append/write/{vault_id} with no account and no access token; the response is blind ({"ok":true}, no id, no count). The recipient lists/fetches with x-sgraph-vault-enum-key and decrypts locally. The intended lane address is append_token = H(recipient public key), but no shipped command emits it, PROPOSED; today agree the token out of band.
• Vault credentials: what each one can do↗: Two capabilities, a vault key that reads and writes and a read key derived from it one way, plus the five prefixes that declare which you are holding and whether it was meant to be published. Why sgit_public_read_ is the form for an open vault, why publishing one under sgit_private_read_ is a mislabel that an agent will correctly refuse, and why the word matters when the bytes are identical. Key fact: TWO capabilities: a vault key (read+write) and a read key (read only, derived one-way, cannot be reversed). FIVE prefixes DECLARE which you hold: sgit_private_vault_ (write, never publish), sgit_private_read_ (read, keep secret), sgit_public_read_ (read, deliberately published, use this for open vaults), plus legacy sgit_vk1_/sgit_rk1_. The prefix is a DECLARATION, not crypto: strip it and the bytes are identical, and every form clones the same vault. Classification is by declaration, never by shape. Revocation is NOT retroactive.
• Keys↗: The keypair lifecycle run end to end on the shipped CLI: RSA-OAEP 4096 encryption, ECDSA P-256 signing, the JSON public-key bundle, the hybrid envelope format, and what PKI does not do yet. Key fact: sgit pki keygen makes TWO pairs: RSA-OAEP 4096 for encryption and ECDSA P-256 for signing (not X25519/Ed25519), passphrase-protected. export emits a JSON bundle {v,encrypt,sign,label,fingerprint,signing_fingerprint} of PEM blocks, not a bare PEM. encrypt --recipient <fingerprint>; decrypt --fingerprint <fingerprint> (required). Envelope v2 is base64 JSON {v,w,i,c}: RSA-OAEP wraps an AES-256-GCM content key. No revocation, no directory.

HTTP API (the protocol surface: endpoints, auth headers, capability gates, limits)

• The HTTP API↗: The protocol surface behind sgit: base URL, the capability model, and the reference for vault objects, append lanes, authentication headers and error codes. Built from a code-verified audit at v0.33.54, with unresolved endpoints labelled rather than guessed at. Key fact: The HTTP API is the whole surface; the CLI and the browser bridge are clients. The server is a capability-checked ciphertext store: it holds SHA-256 of each capability key and compares hashes, never a raw key and never a private key. Four capabilities: append_token (write one lane), enum_key (list/fetch/mark), write_key (configure/purge/write objects), private key (decrypt, client-side only).
• API authentication↗: The six authentication headers, what each one gates, and the hash-comparison model: the server stores SHA-256 of every capability key and never holds a raw key or a private key. Includes why vault reads are open by default. Key fact: Six headers: x-sgraph-access-token, x-sgraph-vault-write-key, x-sgraph-vault-enum-key, x-vault-read-key, x-vault-public, x-sgraph-transfer-delete-auth. append_token is NOT a header. It goes in the body. Vault reads need no auth on the shared host because the bytes are ciphertext under a key the server never had.
• API: vault objects↗: The pointer store: read, write, batch, destroy and presigned endpoints, the caching contract that separates immutable content-addressed objects from mutable refs, and the storage layout behind every vault. Key fact: Pointer store endpoints plus the caching contract: file ids containing -imm- are content-addressed and immutable (Cache-Control max-age=31536000, immutable); refs and indexes are mutable and no-store. Caching a ref renders a previous commit from valid ciphertext, so nothing errors and the reader silently sees the wrong version.
• API: append lanes (sgit.ai)↗: The six append endpoints) the write-only vault-to-vault message transport. Four separated capabilities, the blind write response, server-assigned sortable filenames, idempotent mark-processed, and the limits. Key fact: Six POST endpoints under /api/vault/append/: configure (write key), write (append_token in body, account-less), list (enum key), fetch, mark-processed (idempotent), purge (folder: pending|processed). Renamed from inbox in v0.32.7, /api/vault/inbox/* is gone. Limits: 5MB payload (413), 1000 pending per token (507), 100 file_ids per batch (400), 3MB inline content (413), page 50/200.
• API: transfers↗: The other API family on this host: a single encrypted payload uploaded once and shared as one link. The two secrets that must not be confused, the SGMETA envelope that keeps the filename off the server, the three calls, revocation that is opt-in at create time only, and when a transfer beats a vault.
• API errors and limits↗: 400, 403, 413 and 507: what each means, why a malformed token returns 400 rather than 403, the input patterns enforced before storage is reached, and every documented ceiling. Key fact: 400 = malformed input, rejected before any gate; 403 = well-formed but wrong capability. A prefixed token (tok_..., or a CLI fingerprint sha256:...) returns 400, NOT 403, append_token is hex only. 413 = too large, 507 = lane full at 1000 pending.

SG/Vault platform

• SG/Vault & the vault platform↗: The official working documentation for the SGraph vault platform: the SG/Vault browser app, the SG/Send zero-knowledge API, and vault apps.
• Building vault apps↗: How to build apps that live inside encrypted vaults: the project shape, app.json, the authoring contract, and shipping with sgit push.
• The window.sg bridge↗: The vault app runtime: sg.* namespaces, the deny-by-default permission model, and the capabilities the host chrome provides for free.
• Content authoring↗: Publish documents, galleries and hub pages from a vault with no code: markdown with print-aware extras, and _page.json layouts with eleven component types.
• Sub-vaults↗: Vaults inside vaults: link files, owner records, read-only team access, click-to-load external embeds, and the extract-and-embed workflow.
• Git repos inside vaults↗: Run git and sgit side by side: the encrypted store in a git remote, the leak-audit boundary, the GitHub round trip, plus a pure-Python git reader preview.
• Reading one file out of a vault↗: The primitive under every live embed on this site: derive the address from a published read key, fetch ciphertext over CORS, decrypt in the browser, and the sandbox rules for rendering what comes back, including why a PDF is a download and not an embed.
• Static hosting on GitHub Pages↗: Serve an encrypted vault and its app from GitHub Pages or S3 with zero backend: deterministic GET paths, client-side decryption, clean read-only degradation.

Deploy (rendered live from an encrypted vault)

• Run your own SG/Send server (sgit.ai)↗: Deployment guidance for self-hosting a zero-knowledge SG/Send server) rendered live in your browser from an encrypted vault, with no copy stored on this site.

Try it

• Try sgit in your browser↗: The real sgit-ai package running client-side under Pyodide: derive keys, encrypt, run an in-memory vault, and use a Python console, nothing you type leaves the page.

Skills (packaged instructions for AI agents)

• Skills for AI agents↗: Packaged, versioned instructions that make any AI agent an effective sgit and vault user: operate the CLI, build vault apps, author vault content.
• use sgit and vaults↗: the CLI + cross-session persistent state
• create vault apps↗: build an app that lives inside a vault
• create vault content↗: author _page.json layouts and vault markdown

Cross-team briefs

• Cross-team briefs↗: Briefs this site's agent has filed to the sgit CLI and SG/Send API teams: serial transfer mode for WASM, history-preserving rekey, browser-transport findings.
• For RiskMandate.ai: an interview page↗: A build brief to the RiskMandate.ai team for a reusable interview page: send someone a link, they paste a prompt into ChatGPT, it interviews them by voice for about twenty minutes, and writes up their ideas, a thirty, sixty and ninety day action plan, and candid feedback. The first page is for a founder strong in UK events, marketing and content, testing RiskMandate's value proposition and name. The full prompt is included, ready to use.
• For RiskMandate.ai: the risk side of the partnerships↗: A build brief to the RiskMandate.ai team. Part A: for every cloud and AI provider on the sgit.ai partnership pages, the same deployment with and without the service as two Agent Behaviour Policies and the delta, starting with managed identity, cloud agent services, and API against consumer chat. Part B: sgit as a control, what it removes and what it leaves, mapped to GDPR Articles 32, 25, 34(3)(a), 28 and 17 and to international transfers. Built on RiskMandate's existing grammar, with the prompt to hand the builder agent.
• Telemetry from a published vault↗: How one vault sends messages to another, and how a vault whose read key is public reports anonymous usage back to its author. The append-lane mechanism, why a write-only token is the one credential that survives being published inside a public vault, the three things to verify before building, and the prompt to hand the builder agent.
• Reading a vault from a *.sgit.ai site page↗: For devs coding the estate’s sites: the vault API answers plain CORS GETs with no auth header, so a site page reads ciphertext directly and decrypts in the visitor’s browser. The house reader to copy rather than rewrite, the trust rule that inverts on this surface, the ref-caching trap, and the prompt to hand the site’s agent.
• Publishing a vault’s decks onto a website↗: A build brief for an agent with a vault full of presentations: the decks/v2 contract a vault must publish, the split that keeps it safe (the viewer is the site’s, the data is the vault’s), the two sandboxed frames and their CSPs, why a PDF must be a download rather than an embed, the two bugs we hit, and the prompt to hand the builder.
• For graphs.sgit.ai: Fractal Semantic Graphs↗: A brief for the agent maintaining graphs.sgit.ai: the fractal claim on its boundaries page has the invariant backwards (grammar survives every zoom, the ontology is free to change), the name Fractal Semantic Graphs and its lineage, six places to link the sgit.ai page, four graph vaults missing from its evidence estate, a second cross-vault finding, three small corrections, and the prompt to paste.
• An infographic of the published vaults↗: A brief for a companion to the network infographic, grouping the 26 published vaults by use case and industry, starting with the two blockers upstream of any image: neither grouping exists in vaults.json yet, and the network infographic it copies has already gone stale in its own headline count.
• Markdown and file viewers in a vault: what not to build (build brief)↗: Two of the most common asks) a markdown viewer and a file/folder browser with raw views, are already in the vault platform. The ladder from zero code to a full app, the markdown rules that actually catch people, the raw-always contract for a file explorer, and the prompt to hand the builder.

The team (how the site is run by one human and a team of agents, start here if you are an agent)

• How the site is run↗: sgit.ai is built by one person and a team of AI agents. This section is written for the agents: nine roles as files, the rules each enforces and the mistake behind each rule, the prompt that starts a role from nothing, and the board where the work is.

Roles (one page per agentic role: mission, what it owns, the rules it enforces, its starting prompt)

• Sherpa↗: Sequences the work, scopes each release, and keeps the board honest, the role that decides what ships next and what waits.
• Publisher↗: Takes a submitted credential and turns it into a published vault page (classify, derive, audit, capture, write, escrow, release) following the seven-step method every row on the vaults table was built with.
• Auditor↗: Decides whether something can be made public without leaking (credentials in vaults, keys in the tree, secrets in screenshots) and publishes what it finds rather than filing it.
• Journalist↗: Writes what happened (the release note for every version, the articles that argue a point with screenshots, and the drafts that go to LinkedIn) with every number counted rather than remembered.
• Cartographer↗: Keeps the map of the *.sgit.ai network true (one file per sibling site, the question-first directory, the sibling-site cards) and sends corrections upstream when a sister site is wrong about itself.
• Ambassador↗: Owns how sgit is explained to someone who has never seen it (the homepage, the positioning, the investor page) and enforces the rule that proof comes before mechanism.
• Designer↗: Builds and maintains the site's components (bands, cards, tables, the sibling-site card) and checks every change on a phone before it ships, because that is where the failures are visible.
• Release engineer↗: Ships the site, build, validate, push, and refuse to call a release done until sgit.ai is actually serving it.
• Historian↗: Keeps the record straight, the version log entry that says what a release did and what it got wrong, the corrections recorded above the mistakes, and the numbers that must be computed rather than typed.

Starting prompts (the regular tasks, each as a prompt to paste into a fresh agent)

• Starting prompts for the regular work (sgit.ai team)↗: Twelve prompts for the tasks this site does repeatedly) publish a vault, audit it, write the update, add a sibling site, handle an inbound brief, cut a release, fix a phone bug, turn markup into data, correct a claim, update the board, re-verify the read keys, each written to be pasted into a fresh agent.

The board (open work as a kanban of files; Needs only the author can supply, Tasks an agent can pick up)

• The board↗: Every card is a markdown file with a status line; the columns are those lines rendered. Needs are items only the author can supply; tasks are work an agent can pick up from its starting prompt. Nothing runs; the board versions with the site.

Investors (the pitch in the open: architecture, computed traction, business model, and the ask left open until stated)

• sgit.ai↗: The problem, what sgit is, the open-source zero-knowledge architecture, traction computed from the site itself, the business model (the code is free; the running service is sold), the beachhead market, what could go wrong, and the ask, left visibly open until the founder states it rather than invented.

Updates (dated posts: what changed, one entry per story)

• Updates (sgit.ai)↗: What changed on sgit and on this site, as it happens) one entry per story rather than per release, each linked to the release that carries it. RSS and JSON feeds included.

Articles (longer pieces that argue across pages, with the evidence linked)

• Articles↗: Longer pieces that make an argument across several pages: what a thing means, why it is shaped that way, and what it cost to find out. Each links to the pages that own its facts rather than restating them.
• Before you give an agent a connector↗: When an AI agent is given a Gmail or Google Calendar connector, it can read, send, move, decline and permanently delete on somebody's behalf, and for several of those actions the platform itself documents that there is no way back. This article argues that a twin of the connector is the minimum requirement for deploying an agent with confidence. The twin is a journal of every request and response the agent makes, appended as it happens to a write-only lane, processed later, and replayed into the inbox and calendar as the agent saw them, with a before and after for every change and a revert plan for each one. It gives provenance, explanation and a named list of what can and cannot be undone, and it changes the agent's behaviour policy from a hope into a list. Every claim about Gmail and Calendar is taken from Google's own documentation and linked. A working replay of an invented session, and a business plan for the service, are published alongside it as a vault.
• Every risk is already accepted. The only question is by whom↗: A foundation article on risk acceptance, for readers who have never met the idea. A risk exists the moment the exposure does, so an organisation is always carrying it; the only open questions are who has accepted it, and until when. There is no deny button, only three doors (accept for a stated interval, fund the work, or fix it), and silence escalates. The interval is the decision, from four hours, which is an incident, to six months, which is a named decision to wait. Accepted is not the same as acceptable, which matters because the EU AI Act requires providers of high-risk AI systems to have residual risk judged acceptable, and never defines the word. Every risk has a holder, every holder has a boss, and every path ends at the board. Every risk is established by facts and ended by facts, from the board down to the configuration file, which is what closes the gap between a register and reality. The article walks one invented risk through six weeks, argues that each material risk deserves a vault of its own as its evidence pack, explains why executives resist the model, and shows why it fits alongside every GRC platform rather than replacing one. A business plan for a company that runs this loop is published with it.
• The future of news is the story vault↗: The news industry runs on two commercial models, advertising and subscriptions, and both are bad for the reader. One sells the reader to somebody else. The other charges rent on something most people have stopped using. Both are now being dismantled from outside, by a search layer that has stopped sending traffic and by consumer law that arrives in January 2027. This article is about what to build instead, in practical terms. The objective is a commercial model that rewards investigative journalism, so that the expensive, evidenced kind of reporting drives usage, usage drives revenue that depends on neither search nor renewals, and that revenue funds more of the same. The mechanism is to stop selling the article and start selling what the article was made from. The story is a graph, a fractal semantic graph in which meaning comes from connectivity and every claim walks down to hashed evidence, so that trust comes through provenance and provenance comes via evidence. The article is one projection of it. From that one graph a newsroom can sell five things, on demand and in pence, to readers, to firms and to agents, and every payment walks back to the people who made the facts. It is built, in parts, on things we have already published.
• The SaaS apocalypse will be decided by inertia↗: The SaaS apocalypse has not happened yet, and the market has already declared it cancelled once. It remains a very strong possibility, argued here with data rather than vibes. Most users were never happy, most features were never used, and most licences sit idle, because success bred inertia and inertia bred lock-in. Now anybody can brief the software they actually want, and the portability, APIs and schemas that SaaS companies refused to build are precisely what an agent needs. It will be decided by inertia, not by AI, because AI is 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. Nokia when the mobile phone arrived had nothing to protect, and moved. Nokia when the iPhone arrived had fifteen years of success to protect, and did not. Which side of that path each SaaS provider ends up on will be settled by where it sits on the evolution axis and how much it has to protect, which is why the newcomers, not the incumbents, are the ones to watch.
• For a startup↗: A startup operating and investing model in three pillars. Ship something somebody can actually use, give it away briefly, then take it away and find out whether anybody notices. Be profitable before you raise, so the investors are calling you rather than the other way round. And open source everything, because the technology was never the moat.
• Fractal Semantic Graphs: everything connects to everything↗: The introduction to the term. Four words and only one of them new; the test that decides whether something deserves the word, worked from a risk register to a TCP packet; why every file format is already a graph; the five-rule grammar; the evidence, eleven altitudes across seven live vaults; what is still modelled rather than imported; and why now.
• The proof is two clicks behind the claim↗: Twenty-five real vaults a stranger can open in one click are the most persuasive thing on this site, and the homepage shows none of them. It leads with encryption, which cannot be seen, and buries the artefacts under a table. This is the diagnosis, with screenshots, before the rebuild, and the second article will show what changed.
• The proof moved up↗: The previous article diagnosed a homepage that led with encryption and buried twenty-five real vaults under a table. This is the rebuild, put beside those screenshots, what moved, what was cut, what it is generated from, and the one thing it still cannot show.
• A chat box on a site with no server↗: Nineteen sibling sites is too many to browse, so the directory now answers questions. The design problem is that sgit.ai has no server and no vault host, which means the honest options are a local matcher, a key in your browser, or moving the page into a vault, and only one of those is free.
• Twenty sites in fifteen days↗: The thinking behind sgit stopped fitting on one site. It moved out to nineteen siblings on *.sgit.ai, what forced the split, what it cost, and why the index into them now starts with a question instead of a list.
• Git for things you cannot put on GitHub↗: An introduction to sgit and sgit.ai, what an encrypted vault is, why version control had to be rebuilt to get one, and what nineteen published vaults look like when the server storing them cannot read a byte.
• Seven vaults↗: Publishing seven encrypted vaults in a fortnight turned an ad-hoc process into a repeatable one. Every rule in it exists because something went wrong first, including three vault keys submitted for publication that would have handed the world write access.
• Green does not mean live↗: Two releases pushed cleanly, reported success, and never reached the site. Every check we had was green, because the failure happened in a place none of them could see. What we changed, and the general rule underneath it.

The sgit.ai network (sibling sites on *.sgit.ai subdomains, each pursuing one question)

• The sgit.ai network↗: Focused sites on *.sgit.ai subdomains, each pursuing one question further than a section here could: non-human identity for rented agents, and a key registry designed from the 2019 keyserver failure. Screenshots of each, with what it argues and why it is relevant.
• graphs.sgit.ai↗: A grammar for semantic graphs, argued in increasing depth from five rules you can apply tomorrow to a full positioning against schemas and vector search. It opens by insisting it is not a graph database pitch, and it publishes the four situations in which its own argument is the wrong one.
• nhi.sgit.ai↗: The question of how to give an AI agent an identity splits into two populations, and every product on the market answers only the first. For the agents you actually name (the ones running in Claude, Codex or behind an API) the honest current answer is to hand over a broad credential and hope.
• pki.sgit.ai↗: Good public key repositories existed and were destroyed. This site is the 2019 keyserver catastrophe, the four registry rules it produces, and the build order, all published before the registry exists, so the commitments are checkable against whatever eventually ships.
• sg-sentinel.sgit.ai↗: A design for an edge security and logging layer you own rather than rent, built on the observation that your own app already knows what a valid request looks like, so the edge can allowlist rather than denylist. Published as a complete design that has deliberately not been built.

Optional

• sgit (the encrypted git for humans and AI agents)↗: sgit is git for encrypted vaults) and a vault is a unit of work: data, app, history and sources, versioned like git and handed over with a single read key. No account, no hosting, nothing to install for the reader; the server stores ciphertext it cannot read. Twenty-five real vaults you can open.
• Security model↗: sgit's zero-knowledge security model, precisely stated: the crypto stack, what the server can and cannot see, key strength, and the open security process.
• Admin & engineering↗: How the sgit.ai site is built: a vault app with generated pages, bridge-loaded assets, a validation suite, and sgit itself as the deployment pipeline.
• Release history↗: Every release of the sgit.ai site: version, date, vault commit, and changes. The version increments on every push.