Technology — VIVERE

wire format

Packets, pointers, and bytes.

A VIVERE knowledge packet bundles compressed representation records with their metadata into one zlib-framed wire payload. The Python pipeline writes it; the Rust crate reads it; the conformance fixtures pin the two together byte-for-byte.

~150–300 B per record on the wire vs ~4 KB for the uncompressed representation

<1 KB VIVERE pointer, tested asserted byte_size < 1024

734 B the demo fixture, whole three records, zlib-framed

Ratios vary with donor dimensionality; the repository's compression notes carry the dimension-by-dimension breakdown rather than a single headline number.

compression

Rank 8, reconstructable.

A VIVERE card is a donor model's internal state for one phrase, truncated to eight singular-value components per matrix. A pointer addresses the card in under a kilobyte; the crate reconstructs the state at the far end. The same crate exposes card_pointer_hash, so a pointer's integrity is checkable without the payload.

What is kept

Eight components per matrix: the dominant structure of the state, with the residual discarded on purpose.

rank-8 truncation per matrix — the eight largest singular values

What travels

Fabric exchanges address cards by pointer — sub-kilobyte, hash-checkable — and reconstruct on demand. The payload itself stays in the store it came from.

pointer < 1,024 bytes, asserted by a committed test

What is honest

Compression has limits. Explained variance falls as donor dimensionality grows; the repository documents where rank 8 stops being enough instead of quoting one flattering ratio.

dimension-by-dimension breakdown lives in the repo's compression notes

retrieval

Six levels, one store.

The Knowledge Fabric is append-only: every record carries provenance, and retrieval descends through six levels, each answering a different question. The order is the algorithm — a query that misses at one level falls to the next.

The six Knowledge Fabric retrieval levels
Level	Name	Question it answers	Mechanism
`L0`	Cache	Have we answered this exact query before?	exact-match lookup
`L1`	Coarse	Which slice of the fabric could answer this?	metadata index filters (domain, type)
`L2`	ANN	What is nearby in embedding space?	approximate nearest-neighbor recall
`L3`	Fine	Of the candidates, what ranks best?	scored rerank of the shortlist
`L4`	Graph	What does this record imply, two hops out?	reasoning-graph traversal
`L5`	VIVERE	What is the compressed original?	VIVERE latent card store

teachers and pinning

Every donor pinned, every revision recorded.

Since 2026-09-08, every HuggingFace hub id the code loads must resolve to a pinned 40-hex commit SHA — an AST-sweeping ratchet fails the build on any new unpinned load. A re-published or mutated upstream repo cannot silently change the weights underneath the fabric.

Two teachers, honestly

The consolidated fabric's 1,610-record baseline came from two extraction teachers (Muse-Glimmer-30B and a Qwen model). Larger teachers are registered and pinned targets — not extraction claims.

docs/extraction/FABRIC_BASELINE.md

Pinned, ratchet-tested

Pins live in assets/hf_revisions.json; the ratchet test sweeps the source tree for unpinned from_pretrained calls and fails CI when it finds one.

docs/reference/HF_PINNING.md — the policy, with the ratchet's own growth history

Multi-teacher conflict

Where teachers disagree, the foundry resolves by trust-weighted agreement and records the dispute instead of averaging it away — a disagreement you can later audit is worth more than a consensus you can't.

scripts/vivere/fabric/foundry.py

100% of hub model ids pinned 40-hex revisions, ratchet-tested

1,610 records, 2 teachers consolidated baseline snapshot

claims boundary

The sentence we are allowed to say.

Everything on this page is sizes, counts, and policy facts with committed sources — not performance results. The one sanctioned description of the packaged demo is this sentence, verbatim:

A sparse recurrent CPU recipient using selected frozen representations extracted from a larger offline donor, with mechanistic routing and causal memory-binding controls.
docs/CLAIMS_BOUNDARY.md — canonical description of the packaged demo; the boundary document governs this site too

live demo

Decode a packet in your browser.

This demo loads the vivere-cards WebAssembly bundle and decodes a real conformance fixture client-side. Nothing is uploaded; the fixture is 734 bytes of zlib-framed packet generated by the Python golden pipeline to test the wire format — the donor labels inside it are fixture data, not extraction claims.

Bundle not loaded — click above. The wasm bundle is a build artifact; if it is absent, run make site-build.

reference

Glossary

The vocabulary this site and the repository share, defined once.

VIVERE: Virtual Index of Vector Encoded Representations — the extraction-and-transfer approach: representations taken from a larger donor model, stored compactly, and used by a smaller recipient.
VIVERE card: A compressed record of a donor model's internal state for one phrase, truncated to rank 8.
Packet: A zlib-framed wire payload bundling compressed records with metadata — the unit the vivere-cards crate decodes.
Pointer: A sub-kilobyte, hash-checkable address for a card; fabric exchanges move pointers, not payloads.
Knowledge Fabric: The append-only store behind retrieval: metadata index, ANN, reasoning graph, and the VIVERE latent store across six levels.
Provenance: The record of where a fabric entry came from — teacher, method, revision — carried on every record.
Revision pinning: Loading every HuggingFace hub id from a pinned 40-hex commit SHA, enforced by a ratchet test.
RepE vector: An activation direction encoding a behavior or tone, extracted from a donor model.
Task vector: A weight delta capturing procedural knowledge for fine-tuning.

The whole pipeline, down to the bytes.