Offline Mission Mode · mission autonomy
Earth can disappear. The health loop must not.
P14 keeps mission health data encrypted locally, preserves reviewed protocol content, and queues records for deterministic store-and-forward synchronization. The cloud is not in the critical sensor-to-astronaut path.
Optional session-only retry while this page is visible, online and signed in with active mission access. No background transmission, clinical automation, or automatic conflict resolution.
Paused — enable foreground sync for this session.
Local mission state
NOT READY
AES-GCM encrypted records; non-extractable device-local key held by the browser origin.
0
Append-only encrypted event records available on this device.
0
Pending and retryable failures only. Records requiring review are excluded.
NOT READY
Versioned P13 protocol definitions are cached locally with SHA-256 integrity metadata.
Records requiring review: 0
These encrypted records were definitively rejected by the cloud and are not retried automatically. They remain on this device. Do not reassign old placeholder records to a real astronaut automatically. Contact an authorized mission administrator for reviewed remediation; no automatic reset or deletion is available.
Review queue (read-only)
Record identifiers and rejection reasons only. No medical payload is displayed or modified. Do not assign placeholder records to an astronaut without independent provenance review.
No records awaiting review on this device.
Cloud persistence evidence
Read-only comparison of locally synced event IDs with cloud event IDs visible to your authorized account (up to 300 records per side).
A match is useful evidence, not a real-device end-to-end certification. Missing matches can also reflect query limits or access policy. No test data is created and no records are changed.
Authenticated persistence validation
Manual research-only test protocol. This panel does not create records, change memberships or simulate a sign-in.
- Sign in through Mission identity with a provisioned crew-self membership; select the correct active mission.
- Confirm Bone Health mission and crew selectors display only authorized choices. Use clearly labelled synthetic values, never real patient data.
- Record a synthetic measurement in the supported capture flow, then return here and select Sync now while online.
- Select Verify cloud records. Inspect mission_events and crew_health_record_index under the same authorized mission and crew; confirm event ID, metric and idempotency.
- Repeat offline capture and online reconnection on a real device; separately test ground medical visibility and crew isolation with approved test accounts.
Current access: authentication or cloud configuration required. A cloud match alone does not prove camera or offline-device validation.
Supabase synchronization boundary
Checking governed Supabase access…
Mission events are never written anonymously. When authenticated mission membership is unavailable, records remain encrypted on this device and queued for later idempotent synchronization.
Offline readiness and autonomy
Connectivity: UNKNOWN
Local monitoring and storage do not require network connectivity. Connectivity only affects remote synchronization.
Application shell: NOT REGISTERED
The service worker caches only public shell/assets. It deliberately does not cache health API responses.
Sync conflicts: 0
Conflict resolution is deterministic by payload identity, source version, event timestamp and source priority; ambiguous ties require manual review.
Runtime health nominal
No local offline runtime error is currently recorded.
• Live device streams continue locally when the device transport itself is available.
• Accepted observations and private readiness records can be encrypted into the append-only local event store.
• P12 intelligence and P13 protocol logic remain local, deterministic software modules.
• Reviewed P13 protocols are cached locally with version/authority integrity metadata.
• Remote synchronization is transport-agnostic. P14 provides queue/conflict semantics; the secure Supabase persistence target is connected with the ground/backend work rather than granting unsafe browser write access here.