Home / Articles / When is the vault actually used? In Mondweep Chakravorty's SGit × Ruflo run, the encrypted vault is written or read in three steps of twelve, on one machine, inside the adapter, and why that is the honest shape of a recovery copy / Versions / v1.1.0
When is the vault actually used? In Mondweep Chakravorty's SGit × Ruflo run, the encrypted vault is written or read in three steps of twelve, on one machine, inside the adapter, and why that is the honest shape of a recovery copy: what changed in v1.1.0
From v1.0.0 (2026-10-17, c3c97c54d) to v1.1.0 (2026-10-17, 04eef66c8), paragraph by paragraph.
3 paragraphs added, 2 removed, 17 changed in place, 39 unchanged. About 394 words added and 29 removed. Insertions are marked like this, deletions like this; unchanged runs are folded to one line; figures appear as their file names.
1 unchanged paragraph
Summary: The first piece walked through Mondweep Chakravorty's video step by step. This one asks a sharper question: in a run that is about an encrypted vault, when is the vault actually used? The answer, drawn stage by stage from the frames, is in three steps of twelve. It is written in step 5, when a consistent copy of Ruflo's memory database is saved as encrypted SGit objects with fingerprints of the data, the ABP and the compiled policy. It is read in step 8, when a brand-new process restores it with the same fingerprint. It is read and rejected in step 11, when one object has been altered. In step 6 it is what the policy protects, and in step 7 it survives the deletion because it lives outside the project. It sits on the same machine, with its keys in a separate folder; no vault server, push or clone appears. It is implemented in the adapter, which calls the SGit library at a pinned commit,commit and creates a separate vault for each checkpoint, and Ruflo knows nothing about it. The policy is compiled into Ruflo's own rule format and checked by a pinned copy of Ruflo's evaluator, inside the adapter. Not used: Ruflo's hive-mind, itsRuflo's ownrunning policy engine,state, and vector search. All of this is confirmed by the author's published code. That is not a weakness; it is what a recovery copy should look like, and it shows the pattern works with any tool's memory file. What it does not yet show is the vault leaving the machine.
6 unchanged paragraphs, under In short {#in-short}
• In the adapter, not in Ruflo. The adapter calls the SGit library at a pinned commit.
• Not used. Ruflo's hive-mind, its own policy engine and vector search.
• In the adapter, not in Ruflo. One SGit vault per checkpoint, at a pinned commit.
• Ruflo's evaluator, in the adapter. The ABP is compiled to Ruflo rules and checked in enforce mode.
• Not used. Ruflo's hive-mind, its running policy state and vector search.
7 unchanged paragraphs, under Six short answers {#answers}
• Where is it implemented? Inside the adapter, a local MCP server at version 0.2, which calls the SGit library at a pinned commit. Each checkpoint gets its own SGit vault, and only its encrypted bare store leaves the adapter's private staging. Ruflo knows nothing about the vault.
• Where does the ABP come in? Only onOn the adapter's tools, in steps 4, 5, 6, 8 and 11. The rows are compiled into Ruflo rules when the server starts, and each call is checked by a pinned copy of Ruflo's own policy evaluator, in enforce mode. Ruflo's own command line, in steps 3, 9 and 10, does not pass through it; the third piece is about that.
• Which parts of Ruflo ran? Its memory store and retrieve commands, its SQLite memory file, its bundled embedding model, which stored no vectors, and its worker daemon, which was not running.running, and a pinned copy of its policy evaluator, inside the adapter. Not its hive-mind, not its running policy engine,state, not vector search.
Throughout, I keep two things apart, as the analysis does:apart what is shown on screen,screen and what is inferred from it.it, as the analysis does, and where Mondweep's published code, mondweep/sgit-ruv-memory, settles an inference, I say so. In the diagrams, solid arrows are on screen or confirmed by the code, and dashed ones are inferred.
1 unchanged paragraph, under The component map {#map}
!shot rf-map.webp | images/ | The component map: the test script calls Ruflo's command line in steps 3, 9 and 10 and the ABP adapter's tools in steps 4, 5, 6, 8 and 11; the adapter'sABP policyrows gateare compiled to Ruflo rules and checked by a pinned copy of Ruflo's evaluator in enforce mode, which leads to the SGit library, which writes the vault and its keys on the machine's disk. Ruflo's hive-mind, its running policy enginestate and a remote vault server were not used. Blue is Ruflo, amber the ABP adapter, green SGit and the vault, grey plain files. | architecture
Two lines run from the test script. One goes to Ruflo's command line, which writes and reads its memory file directly. The other goes to the adapter's three tools, checkpoint, close_runinspect, restore and restore,close_run, eachof guardedwhich bythe run uses three. Each passes a policy gategate, thata pinned copy of Ruflo's evaluator running the compiled ABP rules in enforce mode, which fails closed, and through it toreaches the SGit library, which writes the vault and keeps the keys apart. Everything happens on one machine's disk.
4 unchanged paragraphs, under Step 5: the vault is written {#step-5}
Inferred:Confirmed in the exactcode: the order ofis a policy check, a consistent SQLite backup, hashingan integrity check, a new SGit vault for this checkpoint and encryption,a commit, and thatthen only the store has sgit's usualencrypted bare layout.store is copied out of private staging. No remote push is performed. The encrypted manifest records the source ABP's hash, the compiled rules' hash, the profile, the owner, the principal, the database digest and the time. The README is precise about what those are: "These hashes bind evidence to a servermandate; appears.they are not digital signatures or immutable audit receipts."
5 unchanged paragraphs, under Step 8: the vault is read {#step-8}
Inferred:Confirmed thatin the keyscode: comethe fromrestore checks the stored ciphertext's digest, decrypts with the key record kept in the private folder, checks the manifest and the database digest, checks that SGitthe decryptsSQLite file is sound, and only then verifies.promotes it into a new workspace, as memory.sqlite. It never overwrites an existing workspace.
1 unchanged paragraph, under Step 11: the vault is read, and refuses {#step-11}
!shot rf-stage-11.webp | images/ | Step 11: one object in the vault is altered; the restore tool passes the policy gate; the SGitadapter library readscompares the altereddigest ciphertext,of the integritystored checkciphertext fails,with the one recorded in step 5, finds a mismatch, and a ValueError means the tampered workspace is never created.created; SGit is never asked to decrypt. | architecture
One encrypted object in the vault is altered, and a restore is tried. The ABP allows the restore; the vault's own integrityadapter's check of the stored ciphertext is what refuses it.
1 unchanged paragraph
Inferred:Confirmed thatin SGit'sthe check,code: authenticatedbefore encryptionanything oris object hashes, caught it, rather thandecrypted, the adapter comparingcompares fingerprints.the Bothdigest wouldof producethe thisstored output.ciphertext with the one it recorded when it saved the checkpoint, and refuses with "Checkpoint ciphertext integrity mismatch". SGit is never asked to decrypt the altered copy.
4 unchanged paragraphs, under Steps 6 and 7: protected, then left standing {#step-6}, Where the vault lives {#where}
Encryption happens on the machine, and the ciphertext stays there. The README says so plainly: no remote push is performed, and remote sync is on its list of follow-ups. So it survives the project being deleted, which is what the video tests. It would not survive the machine being lost, which the video does not claim.
3 unchanged paragraphs, under Is three steps of twelve a weakness? {#three}
The more interesting finding is where the vault is implemented. Ruflo knows nothing about it. The adapter wraps Ruflo's memory file from outside, through MCP, and the SGit library does the encryption.encryption, one vault per checkpoint, so checkpoints share no history. That means the same adapter pattern could wrap any agent tool that keeps its memory in a file, without changing the tool. It also means the vault is only as complete as the adapter's reach, which is the subject of the next piece.
3 unchanged paragraphs, under Where to go next {#next}, What this does not claim {#limits}
• From the screen only.and the code.** Where a diagram goes beyond the frames,both, the arrow is dashed and the text says inferred.
• Not a review of SGit's cryptography. The video shows a tampered object rejected;is itcaught doesby notthe showadapter's how.digest check, before decryption.
3 unchanged paragraphs, under Where this comes from {#sources}
The video: Mondweep Chakravorty, SGit × Ruflo | Working Proof of Concept, published on YouTube on 17 October 2026, made as a member of the #Ruflo-Federation and published here with his agreement. The code: Mondweep Chakravorty, mondweep/sgit-ruv-memory, MIT, read at its commit of 16 October 2026, including core.py, abp.py, policy/bridge.mjs and the README. The architecture: an addendum to the analysis made for me by Claude (Anthropic) on 17 October 2026 from on-screen content only,content, with one diagram per stage, rendered here from its sources;sources and corrected where the code shows otherwise; written up and checked against the video's timeline and the code by this site's agent; the editorial responsibility is mine. Ruflo: ruvnet/ruflo, MIT. Related: One vault, ten agents, SGit is a standard.