Feature Guide · v1.7.7

Memory Transparency

Every memory VEKTOR Slipstream holds is visible, searchable, and editable in the same interface you already work in — what kind of memory it is, when it was formed, which conversation it came from, and why the system judged it worth keeping. Nothing sits behind an export button or a support ticket.

What it is

Memory Transparency is a panel built directly on top of your local memory database. Every entry VEKTOR stores is a structured record, not a blob of raw text: alongside the content itself, each entry carries a kind (a decision, an open thread, an action item, an entity, a stance), a timestamp, a link back to the conversation it came from, and an importance score. That structure is what makes the panel a real interface instead of a search box over a text file — filtering by kind, jumping to a session, or spotting a stale entry all rely on that schema existing in the first place.

Every query in the panel runs directly against your local database, indexed and filtered server-side, so browsing thousands of memories stays instant rather than turning into a slow scroll through everything you’ve ever said.

Local-first, by design

Structured memory and the interface that reads it never leave your machine. The only thing that ever crosses out is the plain text of one memory you’ve chosen to consolidate, and the only thing that ever comes back in is a proposal, held in the browser, until you decide whether it becomes real.

Using the panel

Open Memory Transparency

Available from Desk and Jot in the SDK — the panel lists every memory in your active namespace, newest first, with its kind, timestamp, and source session visible at a glance.

Search or filter

Search runs against the live database and is sequenced: each search gets a request number, and only the response matching your most recent request is ever allowed to update the page. A slower result from a moment ago can never silently overwrite what you’re looking at now. Filter by kind, session, or importance to narrow a few thousand memories down to the handful that matter.

Edit directly

Every card is editable in place. If a memory is wrong, stale, or incomplete, correct it yourself, the same way you’d fix a typo in your own notes — no export, no ticket, no waiting.

Batch delete safely

Select multiple entries and delete them in one action. The delete runs as a single database transaction against the exact set of IDs you selected, so there’s no window where a partial failure leaves the list in a state that doesn’t match what actually happened underneath it.

Consolidation — it proposes, you decide

Not everything worth capturing arrives in a clean, tidy form — often it’s a full conversation, a rambling note, one useful sentence buried in a paragraph you no longer need. Consolidation distills a selected memory down to the durable fact, decision, or preference inside it, and nothing more.

Step	What happens
1. Select	Pick a memory in the panel and trigger Consolidation.
2. Read locally	VEKTOR reads the memory’s raw content from your local database. Nothing else is touched.
3. Send once	Only that one memory’s plain text is sent to your configured model, with a single, narrow instruction: distill this to the durable fact and discard the rest.
4. Propose	The model’s rewrite comes back as plain text and is held entirely client-side, in the same editable box you’d use to change any memory by hand.
5. Approve or edit	Nothing saves automatically. You read the proposal, adjust it if you want, and only your explicit approval writes it back. If there’s genuinely nothing worth keeping, the system says so instead of inventing a summary to fill the space.

Where the model's authority ends

The model never touches your database directly, and there is no code path where its output reaches stored memory without passing through your review first. It is a drafting tool operating on one entry at a time, in a supervised loop — never the system of record.

Related safeguards elsewhere in v1.7.7

The same verify-before-you-trust principle that governs Consolidation runs through the rest of the product:

Component	What it verifies
Sentinel	Re-checks a candidate memory directly against the database right before proactively injecting it into a turn, follows the supersession chain to the current active fact, and refuses to surface anything that has since expired.
Desk	Checks that a real, structured tool call actually came back from the model before treating the response as an answer, rather than accepting a plain-text description of an intended action as if it were the result.
Jot	Genuinely reads an attached image or document through a vision-capable model as part of forming its response, instead of reasoning about a note in isolation from the material sitting next to it.

Getting started

Memory Transparency ships in v1.7.7. Upgrade at any time:

bash

npm install -g ./vektor-slipstream-1.7.7.tgz

No config changes are required — the panel and Consolidation are both available immediately from Desk and Jot once you’re on v1.7.7.

Next steps

See the Memory Intelligence guide for how memories are formed, decayed, and pruned in the first place, the Faraday-Gate guide for the security layer sitting in front of every MCP tool call, or the release write-up for the full story behind why this shipped the way it did.