Appropriate use
Use for players, mobile apps, kiosks, edge devices, cached web apps, and any product expected to tolerate connectivity loss.
Scope and intent
A controlled workflow specification
This page defines the behaviour, controls, evidence, and outputs required from the skill. It does not claim that a language model can enforce security or correctness by wording alone.
Non-goals
Do not use to claim indefinite offline support from short tests or to clear caches and reset state before preserving the original failure evidence.
- 8
- versioned workflow phases
- 4
- explicit approval gates
- 6
- defined result states
- 9
- versioned output artifacts
Material changes to the source, environment, identity, approved actions, or expected behaviour invalidate dependent approvals and require revalidation.
Workflow
The 8 phases
Each phase has explicit inputs and outputs. Approval gates are hard stops bound to exact versions and hashes.
Phase 1: Offline contract preflight Gate 1 · approve expectation
Resolve supported offline duration, cached features, required periodic connectivity, token and certificate behaviour, storage limits, clock assumptions, and recovery expectations.
support policy · cache policy · auth expiry · storage · time
Phase 2: Build, device, and cache attestation
Verify device model, OS or firmware, application version, deployment artifact, current content or data version, cache completeness, free space, and clock state.
device · build · cache manifest · storage · clock
Phase 3: Scenario timeline design
Create time-based scenarios for fresh offline start, online-to-offline transition, reboot, partial download, long-offline aging, commands while offline, and reconnect.
T0 state · interruption point · duration · expected state · recovery
Phase 4: Data and network-control approval Gate 2 · approve actions
Approve network shaping, interface changes, clock manipulation, reboots, queued commands, content updates, and cleanup. Preserve original cache before destructive actions.
airplane/offline control · clock offset · reboot · queued actions
Phase 5: Offline execution
Run the timeline with continuous state, playback, storage, process, and log observations. Record actual offline duration and every interruption.
startup · cache use · UI state · playback · process health
Phase 6: Reconnection and synchronization
Restore network and verify authentication, downloads, conflict handling, queued actions, metadata, time recovery, and convergence to the current server state.
reconnect time · sync order · stale state · conflict · duplicate work
Phase 7: Outcome and support-limit assessment Gate 3 · confirm outcome
Classify supported, degraded, recovered, data-loss, loop, stale-state, blocked, or duration-limited behaviour. Keep laboratory duration distinct from product policy.
observed duration · confidence · recoverability · residual state
Phase 8: Publish report and restore state Gate 4 · publish
Publish the time-sequenced evidence, cleanup or preserve diagnostic state as approved, restore clock and network settings, and propose focused regression tests.
timeline · evidence · cleanup · residual data · test proposal
Approval contract
Every gate approves an exact decision object
An approval cannot be reused after its environment, source, action plan, or approved document changes.
| Gate | Decision | Required binding |
|---|---|---|
| 1 | Gate 1 · approve expectation | Approval stores approver, role, timestamp, context hash, approved document hash, expiry, and invalidation state. |
| 2 | Gate 2 · approve actions | Approval stores approver, role, timestamp, context hash, approved document hash, expiry, and invalidation state. |
| 3 | Gate 3 · confirm outcome | Approval stores approver, role, timestamp, context hash, approved document hash, expiry, and invalidation state. |
| 4 | Gate 4 · publish | Approval stores approver, role, timestamp, context hash, approved document hash, expiry, and invalidation state. |
Result model
Defined states prevent vague conclusions
Attempt outcomes remain separate from these workflow results. Errors, cancellations, and invalid context are never silently converted into a pass.
SUPPORTED
Required offline behaviour and reconnection pass for the tested duration and state.
DEGRADED
Core function continues with explicit, acceptable limitations.
RECOVERY FAIL
The product does not converge correctly after connectivity returns.
DATA LOSS OR CORRUPTION
Offline or reconnect behaviour loses, duplicates, or corrupts required state.
LOOP OR UNAVAILABLE
The product becomes stuck, repeatedly restarts, or cannot reach an offline-capable state.
DURATION NOT COVERED
The requested offline duration was not actually observed.
Evidence contract
Evidence must directly support the claim
Evidence has provenance, capture context, privacy classification, retention, and integrity metadata. A convenient artifact is not automatically sufficient proof.
| Claim | Primary evidence | Required validation |
|---|---|---|
| Initial state | Build and cache manifest | Content/data version, completeness, storage, and clock are known. |
| Offline transition | Network state and runtime timeline | The exact loss point and active interface are recorded. |
| Cached operation | Video or trace plus logs | Required function uses cached state rather than hidden connectivity. |
| Reboot | Boot timeline and process logs | Startup path and cached output are observed. |
| Reconnect | Network, sync, and state evidence | The client converges without duplicate or stale outcomes. |
| Long duration | Timestamped health samples | Actual observation duration and gaps are explicit. |
Trust and safety
Controls that must be enforced outside the prompt
These controls belong in the runtime, connector permissions, sandbox, renderer, storage layer, and review process.
Runtime control
No cache destruction first
Preserve original state before clear-cache, reset, re-pair, or factory-reset actions.
Runtime control
Clock restoration
Time changes are isolated, approved, and restored.
Runtime control
Duration honesty
A short accelerated test cannot replace a real long-offline observation without explicit modelling limits.
Runtime control
Storage monitoring
Disk pressure and cache eviction are recorded separately from network loss.
Runtime control
Queued-action safety
Commands, uploads, and edits are bounded and tracked to prevent duplicates.
Runtime control
Policy distinction
Observed capability does not silently redefine the officially supported offline contract.
Decision policy
Ordered outcomes, not averaged pass counts
The first applicable high-severity outcome takes precedence. A manual override is recorded separately and never rewrites the calculated result.
INVALID TEST
Initial cache, clock, build, or network state cannot be trusted.
REJECT
Required offline behaviour causes data loss, loops, or failed recovery.
BLOCKED
Required duration or state could not be tested.
SUPPORTED WITH LIMITS
Core behaviour works with documented and accepted degradation.
SUPPORTED
Required offline and recovery behaviour pass for the tested contract.
Known limitations
Uncertainty and coverage limits remain visible
The workflow documents what it cannot prove and what further evidence would change confidence.
- Limit 1. Long-offline tests require real elapsed time or carefully bounded simulation.
- Limit 2. Authentication and certificate expiry may depend on external identity providers.
- Limit 3. Storage eviction can vary by OS and device firmware.
- Limit 4. Offline behaviour can differ between complete and partial cache states.
- Limit 5. A successful reconnect may still leave stale metadata temporarily.
- Limit 6. Shared laboratory networks can accidentally restore connectivity.
Outputs
Versioned records for review and continuation
Human summaries are generated from validated structured records. They are not maintained as separate, drifting sources of truth.
offline-context.jsonVersioned output produced by the workflow.
cache-manifest.jsonVersioned output produced by the workflow.
timeline-plan.yamlVersioned output produced by the workflow.
action-approval.jsonVersioned output produced by the workflow.
runtime-timeline.jsonlVersioned output produced by the workflow.
evidence-manifest.jsonVersioned output produced by the workflow.
sync-analysis.mdVersioned output produced by the workflow.
cleanup-report.mdVersioned output produced by the workflow.
offline-report.htmlVersioned output produced by the workflow.
artifacts/qa/offline-qa/<run-id>/ ├── offline-context.json ├── cache-manifest.json ├── timeline-plan.yaml ├── action-approval.json ├── runtime-timeline.jsonl ├── evidence-manifest.json ├── sync-analysis.md ├── cleanup-report.md └── offline-report.html
Example
Example request and controlled output
Input
Test PIXI after 14 days offline with one cached video. Include reboot while offline, content playback, reconnect, queued screenshot command, and metadata sync.
Output excerpt
Offline outcome: SUPPORTED WITH LIMITS Observed: - Cached video played after offline reboot. - Device remained stable for the observed 14-day period. - Queued screenshot executed after reconnect. - Content metadata took 2 minutes 18 seconds to converge. Limit: This run does not prove one-month offline support. No cache clear, reset, or re-pair was used.
Production readiness
Required before operational use
The written skill is only one layer. The repository, runtime, connectors, evidence storage, and publication path must implement these requirements.
- Required. Tool, filesystem, repository, command, secret, and network permissions are enforced outside the model.
- Required. Every source, environment, build, plan, and approval has a version or content hash.
- Required. Untrusted values are escaped, length-bounded, path-safe, and separated from executable instructions.
- Required. Attempt outcomes, scenario verdicts, workflow decisions, and publication status remain separate.
- Required. Raw evidence, publishable evidence, access control, retention, redaction, and deletion are defined.
- Required. Concurrent runs use unique IDs, locks, idempotency keys, and conflict-aware updates.
- Required. Material changes invalidate dependent approvals and outcomes.
- Required. The repository validator passes before the skill is considered production-ready.
In one line
/offline-qa
Validates startup, cached operation, interruption, reboot, clock changes, queued work, reconnection, synchronization, and long-offline limitations with explicit observation duration.