# Portability & Offline

> Canonical HTML: https://initkoa.org/technology/kristal/portability-and-offline
> Markdown mirror: https://initkoa.org/technology/kristal/portability-and-offline/index.html.md
> Route: /technology/kristal/portability-and-offline
> Source: app/technology/kristal/portability-and-offline/page.mdx
> Generated: 2026-04-09T23:01:26.288Z

[Open the HTML page](https://initkoa.org/technology/kristal/portability-and-offline)

'How Kristals stay usable under weak networks: portable artifacts, offline runtime packs, verifiable provenance, and safe degraded modes.',

# Portability & Offline

A Kristal is designed to **travel** and to **work under degraded conditions**.

That means two things:

1. **Portability:** you can move the artifact between systems, teams, and places without losing integrity.
2. **Offline-capability:** you can still browse, query, and rely on it even when the network is weak—or absent.

## What “portable” means (in practice)

A Kristal can be copied, mirrored, archived, and shared as a package. It does not depend on one central server to
remain meaningful.

When you receive a Kristal from somewhere else, you can verify its integrity and provenance locally before trusting
it.

## Offline capability: what users actually get

Offline does not mean “no functionality.” It means **the core functions still work** without network dependency.

<li><strong>Browse and search</strong> the knowledge locally.</li>
<li><strong>Inspect sources and reasoning traces</strong> that are packaged with the Kristal.</li>
<li><strong>Defer network operations</strong> (updates, federation, publishing) until connectivity returns.</li>

## Runtime packs vs. exchange truth (conceptual)

To make offline use practical, a Kristal can ship with an **offline runtime pack**: a local bundle optimized for reading and querying.

- **Exchange layer (canonical):** the authoritative structured content and provenance.
- **Runtime pack (offline bundle):** a read-optimized package for local use.

This page stays at the “what it does” level. Technical formats belong in reference pages.

## Safe degraded mode (fail-closed integrity)

Offline systems can be dangerous if they silently drift into unverified state.

kOA uses a simple rule:

You can still view what you have, but the system should clearly mark what is verified, what is outdated, and what
cannot be trusted until checks succeed.

## How updates work (user-facing behavior)

Offline-capable doesn’t mean “never updates.” It means updates are **explicit** and **checkable**.

You always know which version you are using. “What changed?” is answerable.

Updates are not trusted by default. They are verified before becoming active.

Updates can travel via local mirrors, removable media, or “air-gapped” transfer when needed.

## Typical scenarios

### 1) Field or crisis conditions
A team needs reliable procedures and references while connectivity is intermittent.
- They carry a Kristal runtime pack locally.
- They apply updates only when verifiable.

### 2) Institutional memory without platform lock-in
An organization wants durable knowledge that outlives vendors and tools.
- Kristals act as portable memory objects.
- Migration is “copy + verify,” not “rebuild everything.”

### 3) Community distribution
A community distributes curated knowledge packs for education or local services.
- The bundle is usable offline.
- Provenance remains attached.

## Quick answers

**Does offline mean “no accountability”?**
No. Offline use increases the importance of clear verification status and versioning.

**Can two people have different versions?**
Yes, temporarily. That’s why versions and provenance must be visible, and updates must be explicit.

The system should behave well in both modes: online when available, offline when needed.

## Next

- **Trust & provenance:** how verification and publication policies keep Kristals contestable.
- **Distribution & versioning:** how Kristals evolve over time without breaking history.