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 app-private Android storage rather than a Fenwix-hosted inspection database. The target shared architecture goes further: customer-controlled storage, portable record packages and provider-neutral connectors, with encryption, conflict handling and recovery completed 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
ANDROID APP-PRIVATE STORAGE
TARGET
ENCRYPTED LOCAL RECORD
↓
FIELD DATA PROTOCOL
↓
CUSTOMER-CONTROLLED STORAGEWhat is the current storage model?
CURRENT
Fenwix Solo writes operational inspection content to app-private storage on the Android device. Core work does not depend on a hosted account or inspection-content database. Users can produce reports and use explicit export, share and backup paths.
- Local database and evidence files
- 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. Fenwix must complete stable identity, data classification, encrypted local surfaces, a versioned bundle format, provider-neutral transfer, conflict and recovery behavior, then validate the first real provider against the same contract.
- Stable record, revision and evidence identity
- Encrypted database, evidence, temporary and backup surfaces as defined
- Canonical manifest plus payload hashes
- Explicit entitlement and operation matrix
- 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 app-private local storage on the Android device.
Is the current local database encrypted by Fenwix?
Encrypted local database and evidence-vault controls are architecture requirements, not a current Solo claim.
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