Current local store
The Android device is the operational source for the current Solo workflow.
Architecture direction
Storage architecture without unnecessary vendor custody
Fenwix currently stores core Solo inspection content in an encrypted app-private Android database and evidence vault rather than a Fenwix-hosted inspection database. Stable identities and a versioned canonical bundle are implemented foundations. The target shared architecture goes further with customer-controlled storage, provider-neutral connectors, resumable transfer, conflict handling and recovery before production synchronization is claimed.
ARCHITECTURE DIRECTION
Local Solo storage is current. Customer-controlled shared repositories, remote end-to-end encryption and provider connectors are planned architecture and must not be read as available product features.
Planned shared store
The customer chooses and controls the repository used by authorized devices.
Portable protocol
Record identity and integrity must survive a storage-provider change.
Architecture flow
CURRENT FOUNDATION
ENCRYPTED APP-PRIVATE RECORD
↓
VERSIONED CANONICAL BUNDLE
TARGET SHARED LAYER
PROVIDER ADAPTER + QUEUE
↓
CUSTOMER-CONTROLLED STORAGEWhat is the current storage model?
CURRENT
Fenwix Solo writes operational inspection content to an encrypted app-private database and evidence vault on the Android device. Core work does not depend on a hosted account or inspection-content database. Users can produce reports and use explicit Save, Share, Full Export and backup paths.
- Encrypted local database and evidence objects
- Offline-first record creation
- User-directed report and backup output
- Historical access remains separate from entitlement to create new work
- Device loss, clear-data and uninstall remain recovery risks
Why is backup not the same as synchronization?
A backup is a recovery artifact taken at a point in time. Synchronization coordinates ongoing records across devices, handles identity and conflict, resumes interrupted transfer and preserves causality. Calling a copy operation sync would hide these obligations.
- Backup can be periodic and manually restored
- Sync must be idempotent and resumable
- Two offline edits require explicit conflict semantics
- Remote deletion and retention cannot be improvised
- Recovery must be tested against partial and corrupt states
What must exist before customer-owned synchronization?
ARCHITECTURE DIRECTION
The roadmap requires more than a provider API. Stable identity, data classification, encrypted local surfaces and a versioned canonical bundle are implemented foundations. Fenwix must still complete provider-neutral transfer, entitlement rules, conflict and recovery behavior, then validate the first real provider against the same contract.
- Current: stable record, revision and evidence identity
- Current: encrypted database and evidence-vault surfaces
- Current: canonical manifest plus payload hashes
- Remaining: explicit entitlement and operation matrix
- Remaining: deterministic fake-provider tests and real-provider conformance
- No blind last-write-wins for sealed records
How does the architecture reduce lock-in?
Provider-specific file IDs, paths, cursors and transfer metadata belong to the transport layer, not the canonical inspection identity. If the design holds, changing storage provider does not change what the record is or how its integrity is interpreted.
- Canonical content separate from protocol envelope
- Protocol envelope separate from provider state
- Report PDF treated as derived output, not the canonical record
- Bounded recovery scan within the Fenwix repository
- Export format documented and versioned
Frequently asked questions
Where are current Fenwix Solo records stored?
Core inspection content is stored in an encrypted app-private local database and evidence vault on the Android device.
Is the current local database encrypted by Fenwix?
Yes. Current Fenwix Solo encrypts its app-private database and evidence-vault objects at rest with device-local protected keys. This is not remote E2EE or cloud synchronization.
Can Fenwix use customer-owned shared storage today?
No. Shared customer-controlled storage and its connector layer are planned.
Is a PDF the canonical inspection record?
No. The PDF is a derived artifact; the structured source record and evidence context are the verification basis.
Will a storage provider own the record identity?
The target architecture keeps canonical identity independent of provider file IDs and paths.
Related architecture and product surfaces
Separate current storage from the synchronization target
Use Fenwix Solo's local behavior as the current baseline. Treat shared customer storage as available only after its encryption, identity, conflict and recovery gates are implemented and verified.
Content status: ARCHITECTURE_DIRECTION · Last reviewed: 2026-08-16
Claim basis: Fenwix Zero-Custody master plan · Fenwix product decision record · Fenwix.net aligned master brief