A Kristal is meant to travel: between devices, communities, institutions, and time.
This page explains how Kristals are released and updated in a way that preserves the core promise: portable knowledge, verifiable integrity, and offline-correct use.
A Kristal release is immutable. If you need a change, you publish a new release.
This gives users and institutions a stable foundation: you can always know exactly what was used, when, and where.
Kristal is typically distributed as two complementary artifacts:
The Exchange is the reference artifact: what you cite, verify, and federate.
The Runtime Pack is what you deploy for everyday use: a portable, offline-friendly bundle optimized for lookup and constrained querying.
Exchange = canonical truth object
Runtime Pack = deployable offline package
A channel is a named distribution target: a tenant, a community, a region, a device cohort, or an environment (production / field / classroom).
Examples:
university-publicheritage-officialschool-lab-offlinepersonal-notesChannels are not just “folders”. They are policy scopes: each channel can define what signatures are accepted, what gets pinned, and what is revoked.
Kristal uses two ideas at once:
Every artifact has an identity tied to its content (so “same content” stays comparable).
On top of strong identity, you can use semantic / calendar version labels for usability.
Recommended practical rule:
A Runtime Pack is not “active” just because it exists on disk.
Activation is a controlled switch that should be:
This prevents “partial installs” and “quiet corruption”.
Two things must be true simultaneously:
If a new release behaves badly, you need a deterministic rollback mechanism:
Rollbacks must not become a downgrade vulnerability.
Practical controls:
When devices update asynchronously (especially offline), “ship it and pray” doesn’t work.
Two rollout patterns fit Kristal well:
Keep two slots:
Green is verified and warmed up first, then the channel pointer flips to Green. Blue remains available for rollback during a defined window.
Roll out to a small cohort first (e.g., 1% of devices), then expand only if stability checks pass.
The key is not the pattern itself; it’s the invariant: every activation must be traceable to an explicit release record.
If you use domain sharding, you get a clean update story:
This supports real-world distribution: weekly updates for fast-moving domains, yearly updates for slow ones, without forcing everything to move together.
Kristal distribution should support:
The principle stays the same: verification must be possible offline before activation.
If the environment cannot verify, it should not activate.
/technology/kristal/trust-and-provenance/technology/kristal/portability-and-offline/technology/kristal/integrations