FamilyVault AI: A Fully Offline, Local-First Knowledge Basefor Your Family's Most Important Documents

The Problem With “Just Use the Cloud”

Every family accumulates a pile of documents that matter enormously and are consulted rarely: the property deed, the term life policy, the trust document, the safe deposit box key location, grandma's medication list, the Wi-Fi password for the router nobody remembers configuring. The obvious modern answer is “scan it and put it in Google Drive” or “ask ChatGPT to summarize it.” And for most day-to-day files, that's fine.

It is not fine for this category of document.

Property deeds, insurance policies, tax records, banking statements, and emergency instructions are exactly the class of data where the calculus of convenience-versus-exposure flips. These documents contain Social Security numbers, account numbers, medical histories, and the kind of information that, if it ends up in a breached cloud bucket or gets fed into a third-party model's training pipeline, cannot be un-leaked. At the same time, this is precisely the information a family needs to retrieve fast and reliably during a crisis — a house fire, a hospitalization, a death in the family — often when the person who normally manages it isn't available to help.

FamilyVault AI was built around a simple constraint: the intelligence layer has to be as good as a cloud LLM, but the data must never leave the device. That constraint shapes every architectural decision in the system, and it's worth walking through in detail, because “local-first RAG” is a very different engineering problem than “RAG with a hosted vector DB and a hosted model.”

1. Local-Only RAG with Ollama + Qwen3 14B

Why not just call an API

Retrieval-Augmented Generation (RAG) is now a well-understood pattern: embed documents into a vector store, retrieve the most relevant chunks for a query, and pass them to an LLM as context so it can answer grounded in the user's actual data rather than hallucinating from parametric memory. The overwhelming majority of RAG implementations assume a hosted embedding model and a hosted LLM behind an API.

That assumption is disqualifying here. Sending a scanned tax return or insurance policy to a third-party API — even one with a strong data-handling policy — means trusting that provider's infrastructure, retention practices, and threat model with the single most sensitive document set a family owns. FamilyVault AI's entire premise is that this trust requirement should not exist. So the model has to run on the user's own hardware.

The model choice: Qwen3 14B via Ollama

Running everything through Ollama as the local model runtime, with Qwen3 14Bas the reasoning/generation model, was chosen after weighing three constraints against each other: capability, latency, and what's actually feasible to run on consumer hardware (a modern laptop or a modest home server, not a data-center GPU rack).

• Capability: Qwen3 14B sits in a sweet spot for local deployment — strong enough instruction-following and long-context reasoning to handle document-grounded Q&A, multi-document synthesis, and structured extraction, without requiring the VRAM budget that 70B+ models demand.
• Quantization tradeoffs: The default deployment uses a 4-bit quantized GGUF build, which brings memory footprint down to a range that runs comfortably on a machine with 16–24GB of RAM/VRAM while preserving the vast majority of benchmark performance relative to full precision.
• Ollama as the runtime layer: Ollama abstracts away the raw llama.cpp/GGUF plumbing and gives FamilyVault AI a stable local API surface to build against, plus straightforward model swapping.

The retrieval pipeline, entirely offline

A local RAG pipeline has to replicate every stage a cloud pipeline has, using only local compute:

1. Chunking: Documents are split using a structure-aware chunker rather than naive fixed-length windows — a lease agreement's clause boundaries, a policy's section headers, and a tax form's line items are used as natural chunk boundaries where possible, falling back to overlapping token windows for unstructured scans.
2. Local embeddings: Text chunks are embedded using a compact local embedding model (served through Ollama's embeddings endpoint) and stored in a local vector index. No embedding call ever leaves the machine.
3. Local vector store: The vector index runs embedded in-process (no external database service to configure or expose on a network port), backed by an on-disk index so it persists across restarts and rebuilds incrementally as new documents are added.
4. Retrieval + generation: A query is embedded locally, the top-k relevant chunks are retrieved via similarity search (with metadata filters — document type, family member, date range — layered on top for precision), and the assembled context plus the user's question is passed to Qwen3 14B for a grounded answer, with source chunks cited back to the originating document.

Living with local-hardware constraints honestly

Running a 14B model locally is genuinely different from calling a hosted frontier model, and FamilyVault AI doesn't pretend otherwise. Generation latency is higher, especially on CPU-only fallback. The mitigations are practical rather than magical: response streaming so the user sees output immediately rather than waiting on a full generation; a smaller model tier for lower-end hardware where 14B is impractical; and aggressive context pruning so the model isn't re-processing irrelevant retrieved chunks. The tradeoff is stated plainly to users: this is slower than ChatGPT, and that's the price of your tax records never touching a server you don't control.

2. Upload, OCR, Embed, and Search

The document ingestion pipeline

Family documents rarely arrive as clean digital text. They're phone-camera photos of a paper deed, PDF scans from a bank's portal with inconsistent quality, or multi-page insurance policies with tables, stamps, and handwritten annotations. The ingestion pipeline has to handle all of it, locally.

Search: semantic, not just keyword

The retrieval layer supports natural-language queries — “when does our home insurance renew” or “what's the account number on the joint checking account” — resolved through the same embedding-and-retrieval pipeline used for RAG generation, so search and Q&A share one underlying index rather than being two separately maintained systems. Metadata filters (document type, uploader, family member, date) can be combined with semantic queries, and exact-match lookups (account numbers, policy numbers) bypass semantic search entirely in favor of direct metadata index lookups.

Keeping the index honest over time

Documents get renewed, superseded, and occasionally revoked (an old will replaced by a new one, a lapsed policy). Each document carries a lifecycle status, and superseded documents are retained (for historical/audit reasons — families sometimes need the old policy to resolve a claim dispute) but demoted in retrieval ranking and clearly labeled as outdated in both search results and RAG-generated answers, so the assistant doesn't confidently answer a coverage question using a policy that expired two years ago.

3. Role-Based Access and the Emergency Binder

Why access control matters more here than in a typical app

A family knowledge base has a genuinely unusual access-control problem: the set of people who need access, and what they need access to, changes based on circumstances that are unpredictable and time-critical. A teenager doesn't need to see the parents' life insurance payout details day-to-day, but an adult child absolutely needs to see medical directives and account information if a parent is incapacitated. Getting this wrong in either direction — over-sharing normally, or under-sharing during an actual emergency — has real consequences.

Role-based access model

FamilyVault AI implements a permission model with a small number of well-defined roles rather than a sprawling permissions matrix, because family members are not going to configure granular ACLs and the system shouldn't assume they will:

• Owner/Administrator — Typically the primary household manager(s); full read/write access, manages roles and the emergency-access configuration.
• Full Member — Adult family members with broad read access and upload rights to shared categories, without administrative control over roles.
• Limited Member — Narrower access scoped to specific document categories (e.g., a young adult child seeing their own records but not parents' financial details).
• Emergency Contact — A role held by someone who normally has no standing access at all but is pre-designated to receive it under defined trigger conditions.

Every access grant, upload, and query against sensitive documents is written to a local audit log, so the household administrator can see who accessed what and when — important in a multi-person household where “who looked at this” is a legitimate question and not just a compliance checkbox.

The Emergency Binder

The emergency binder is the feature that most directly reflects why this product exists. It's a curated, pre-assembled subset of the vault — critical documents and instructions (medical directives, insurance contacts, financial account summaries, emergency contacts, funeral/end-of-life wishes) — configured in advance by the vault owner, that becomes accessible under emergency conditions without requiring the normal owner-mediated access flow.

Because the system is fully offline, “emergency access” can't rely on a cloud-based break-glass flow triggered by a support ticket. It has to be solved locally:

• Pre-configured emergency contacts are granted a dormant credential (set up in advance by the owner) that activates only through an explicit unlock mechanism — for example, a local PIN/passphrase combined with device possession.
• Time-delayed or dual-authorization unlock options are available for higher-sensitivity binders, where a single emergency contact triggering access starts a countdown (or requires a second designated person to confirm) rather than granting instant full access.
• Print/export fallback: the emergency binder supports generating a physical printed summary or an encrypted portable export, so the emergency plan doesn't have a single point of failure in one piece of hardware.

Threat model for the access layer

The access control system is designed against two distinct threat models simultaneously: unauthorized routine access (a family member snooping on documents outside their role) and emergencyaccess failure (the right person being unable to get in during a genuine crisis because the security was too strict). Most consumer security design optimizes only for the first. FamilyVault AI treats failing the second as an equally serious design failure, which is why the emergency binder exists as a first-class feature rather than an afterthought “share” button.

Architecture Summary

What “Local-First” Actually Buys You

It's worth being explicit about the tradeoff, because it's real. A cloud-backed assistant will generally be faster, require no local compute budget, and improve continuously without the user managing model updates. FamilyVault AI gives up some of that in exchange for a property that can't be retrofitted after the fact: the guarantee that a scan of a parent's will, a child's Social Security number, or a bank account statement never transits a network, never sits in a third party's storage, and never becomes training data, a breach headline, or a subpoena target for a company the family has no relationship with.

For most software, “runs in the cloud” is simply the right default. For the specific category of documents a family keeps in case of fire, death, or disaster, the local-first constraint isn't a limitation bolted onto the product — it's the actual point of it.