A Kristal is designed to travel, to remain verifiable, and to keep working under degraded conditions.
That means two things:
Offline use does not mean blind trust. It means the artifact carries enough structure for local verification, explicit status labels, and reader-policy-controlled visibility.
A Kristal can be copied, mirrored, archived, shared, or carried into another environment. It does not depend on one central server to remain meaningful.
When you receive a Kristal from somewhere else, you can verify its identity, hashes, signatures, provenance, and declared source references locally before relying on it.
A portable Kristal is not just a data dump. It preserves the labels needed to understand what the information is and how it should be read.
A Kristal may carry:
This is what makes the artifact portable without flattening everything into a single “truth” label.
Offline does not mean “no functionality.” It means the core functions continue to work without network dependency.
To make offline use practical, Kristal separates compiled artifacts from runtime-optimized packages.
A Runtime Pack must not erase the meaning of the source artifact. It should preserve the labels needed by reader policies: assertion status, certainty level, validation status, authority channel, recognition status, scope, provenance, and lineage.
Offline access does not mean all packaged material becomes visible by default.
A reader policy may expose only:
For example, a validated_only reader policy does not mean every visible assertion is universally true. It means every visible assertion satisfies that policy’s validation, authority, certainty, and scope filters.
A Runtime Pack should therefore preserve enough metadata for the local reader to know:
Offline systems can be dangerous if they silently drift into unverified state.
kOA uses a simple rule:
Users may still inspect what is locally available, but the interface should clearly mark what is verified, what is stale, what is outside the active reader policy, and what cannot be relied on until required checks succeed.
Integrity checks protect the artifact boundary. They do not decide that every assertion inside the artifact is universally true.
Offline-capable does not mean “never updates.” It means updates are explicit, inspectable, and checkable.
You always know which artifact, Runtime Pack, or reader policy you are using. “What changed?” remains answerable.
Updates are not accepted merely because they arrived. Identity, integrity, signatures, revocation state, and policy compatibility can be checked before activation.
Updates can travel through local mirrors, removable media, air-gapped transfer, peer distribution, or normal online synchronization.
A team needs reliable procedures and references while connectivity is intermittent.
An organization wants durable knowledge that outlives vendors and tools.
A community distributes curated knowledge packs for education, local services, culture, or research.
Different groups may publish or recognize different shards.
Does offline mean “no accountability”? No. Offline use increases the importance of clear verification status, versioning, provenance, and visible labels.
Can two people have different versions? Yes, temporarily. That is why versions, source references, hashes, and provenance must remain visible.
Can offline users see unvalidated material? Only if the active reader policy allows it. If shown, the material should keep its assertion status, certainty level, validation status, authority channel, and scope labels.
Does verification mean every assertion is true? No. Verification means the artifact is technically the artifact it claims to be. Assertion truth, certainty, validation, authority recognition, and reader visibility remain separate.
Is offline the default? The system should behave well in both modes: online when available, offline when needed.
