Documentation

DocuVault Documentation

Document organization, client-side AES-256-GCM envelope encryption, the password + PIN unlock model, recovery key, sharing codes, audit trail, metadata caveats, and safe use.

Audience: Households storing sensitive documents and security reviewers evaluating public claims. · 7-page PDF · v6.26.1

Logo header · watermark · generation date · multi-page

How to read this document

Sections move from purpose → concepts → calculation process → worked examples → edge cases. Formula boxes use plain mathematical notation for clarity; they are conceptual summaries, not API contracts.

  • Point lists call out operator-visible behaviour.
  • Callouts mark warnings, limitations, or important qualifications.
  • Worked examples use round numbers so you can reproduce the arithmetic by hand.

Purpose

DocuVault stores and organizes household documents behind account, household, permission, and vault controls. Encryption reduces exposure but does not eliminate every risk.

  • Upload and classify supported documents
  • Restrict access to intended members
  • Protect document content with authenticated encryption
  • Keep recovery and device security in mind

Protection boundary

DocuVault is designed to protect document content in storage and transit within the product architecture. Endpoint compromise, authorized-user misuse, screenshots, exports, weak accounts, and metadata exposure remain distinct risks.

Encryption is one layer

A decrypted document visible to an authorized user can still be copied or photographed.

AES-256-GCM envelope

Document content is encrypted client-side using an envelope pattern: a data-encryption key protects content with AES-256-GCM, while key-protection controls derived from your unlock secrets protect the data key. Key derivation uses Argon2id, a memory-hard function that resists brute-force attempts. Authenticated encryption detects content or authentication-tag tampering.

Envelope concept

Ciphertext, authentication tag = AES-256-GCM(DataKey, Plaintext, Nonce, Context)

  • A unique nonce is required for an encryption context.
  • Associated context can bind relevant metadata without encrypting it.
  • Key wrapping separates content keys from higher-level key protection.
  • Public documentation intentionally omits operational key material and tuning parameters beyond the named algorithms.

Unlock model, recovery key, and biometrics

Opening the vault requires two secrets: your vault password and a PIN. Both feed key derivation, so neither alone unlocks content.

  • A recovery key is issued once at vault setup — store it outside the vault; it is the supported path back in if the password or PIN is lost.
  • Enrolled phones can hold a biometric device wrap, so fingerprint or face unlock opens the vault on that device without retyping both secrets.
  • DocuVault, including this unlock model, ships in AH Lite as well as the main app and web.

Why this is not an unqualified zero-knowledge claim

AccountHouse does not make an unqualified claim that the service can never access plaintext under any circumstance. Product workflows may require authorized server or client components to process decrypted content, depending on implementation and user action.

Precise language

Describe DocuVault as encrypted with scoped access controls. Do not call it zero-knowledge unless a separately verified architecture and its exact limitations support that claim.

Metadata caveat

Encryption of document bytes does not imply that all metadata is encrypted. Operational records may include identifiers, household ownership, file size, format, timestamps, labels, access events, or status needed to run the service.

  • Minimize sensitive filenames and labels.
  • Assume metadata can reveal context.
  • Do not place secrets in tags.
  • Review exports and notifications for metadata exposure.

Access control

Authentication establishes account identity; household and vault permissions determine allowed actions. Encryption does not replace authorization.

  • Invite only intended members.
  • Apply least privilege.
  • Review role and client permissions.
  • Revoke access promptly.
  • Protect administrator accounts with stronger controls.

Vault access is shared with another household member through a one-time expiring access code. The invitee redeems the code and then re-secures the vault access with their own credentials — your password and PIN are never handed over.

A full audit trail records vault activity: views, downloads, unlocks, and failed attempts. Review it when access is in question.

Upload and classification

Store a document

  1. Verify the file and remove unnecessary pages.
  2. Use a non-sensitive but recognizable title.
  3. Choose the intended household category.
  4. Confirm permitted viewers.
  5. Upload and verify retrieval.

The household can locate the document without exposing avoidable detail.

  • Supported limits can vary.
  • Malformed or unsafe files may be rejected.
  • Uploading does not certify authenticity or legal validity.

View, download, and sharing

Viewing requires authorized decryption. Downloading creates a copy outside DocuVault controls; its storage, backup, sharing, and deletion become the user's responsibility.

External copies

AccountHouse cannot revoke a file already downloaded, printed, photographed, or shared.

Mobile use

  • Use device lock and supported app lock.
  • Avoid untrusted or shared devices.
  • Keep the operating system updated.
  • Review downloaded-file locations.
  • Revoke lost-device sessions.

Recovery and availability

Vault recovery relies on the recovery key issued at setup. Without the password + PIN pair, a biometric-enrolled device, or that recovery key, encrypted content cannot be restored — losing all of them means losing access to the documents.

Keep originals

DocuVault should not be the only copy of irreplaceable legal, identity, medical, or financial documents.

Deletion and retention

Deletion removes access through normal product flows subject to applicable retention, backup, legal, and operational processes described by policy. It should not be described as instantaneous physical erasure from every medium.

Integrity and authenticity

AES-GCM authentication helps detect encrypted-content tampering under the correct key and context. It does not prove the source document was genuine, current, signed by an authority, or legally admissible.

Security response checklist

Suspected exposure

  1. End unfamiliar sessions.
  2. Change account credentials.
  3. Strengthen 2FA.
  4. Review member and vault access.
  5. Assess downloaded copies.
  6. Contact support through an official channel.

Containment covers identity, authorization, devices, and external copies.

Safe-use checklist

  • Store only what is necessary.
  • Redact excess identifiers.
  • Use clear least-privilege roles.
  • Maintain independent backups.
  • Test retrieval.
  • Review access periodically.
  • Never share unlock secrets in document notes.

Privacy, advice limits, and what we do not publish

AccountHouse is a household tracking and organisation tool. It is not a bank, payment processor, tax advisor, or investment advisor. Forecasts, health scores, balances, and alerts are informational.

  • Household data is scoped to your household; other families cannot see your ledger.
  • Public documentation explains product behaviour and calculation concepts, not proprietary internals.
  • Exact scoring weights, anomaly thresholds, cryptography parameters beyond high-level algorithms, and operational detection rules are reserved.
  • DocuVault content is excluded from InteliHouse and all AI features — no consent toggle exists for it; it is never read.
  • Encrypted content can coexist with operational metadata; users should not assume filenames, sizes, labels, or timestamps are confidential.
  • Public documentation does not expose keys, nonce-generation internals, infrastructure topology, or recovery secrets.

Intellectual property boundary

This document describes what AccountHouse calculates and which inputs matter. It does not disclose source algorithms, secret constants, or implementation details sufficient to reconstruct proprietary systems.