Release history

Updates

Every Caisson release, dated, versioned, and tagged by what changed, plus a way to follow along.

Release notes for every base-substrate and kernel version
Notable module and bundle changes as they ship

Coverage window

What keeps versions pulling

Compliance Updates is the annual subscription that keeps a Compliance bundle license current with new package versions. Each paid cycle stamps a coverage horizon that the registry Worker enforces at the edge, so a version published after the window lapses is fail-closed invisible: it renews reach, never rewrites the code you already own.

Every paid cycle stamps a coverage horizon

Each granting invoice writes a subscription-sourced grant that sets updates_expires_at to now plus one cadence on the buyer's compliance entitlement.

computeUpdatesWindows folds the most-favorable bound

The buyer's one-time bundle window and any active subscription coverage horizon are folded together, taking whichever bound reaches furthest.

windowFilterEntry enforces it fail-closed, at the edge

The registry Worker keeps only versions published at or before the resolved cutoff on every pull, so a module with zero in-window versions returns exactly like one never bought.

Cancelling doesn't touch code you already pulled

Cancelling only stops new coverage-horizon stamps going forward. Nothing revokes or breaks a version already sitting in your node_modules.

registry/worker/handler.ts

export function windowFilterEntry(
  entry: ModuleEntry,
  cutoff: string,
): ModuleEntry | null {
  const bound = Date.parse(cutoff);
  const versions = entry.versions.filter(
    (v) => Date.parse(v.publishedAt) <= bound,
  );
  let newest = versions[0];
  if (newest === undefined) return null;
  for (const v of versions) {
    if (Date.parse(v.publishedAt) > Date.parse(newest.publishedAt)) newest = v;
  }
  const latest = versions.some((v) => v.version === entry.latest)
    ? entry.latest
    : newest.version;
  return { ...entry, latest, versions };
}

Is Compliance Updates the same as the Compliance bundle?

No. The Compliance bundle ($1,649, one-time) is the code; Compliance Updates ($1,499/yr) is the subscription that keeps its control mappings and evidence packs current by extending the license's per-entitlement updates window.

Does an active subscription make my organization compliant?

No. No module or subscription makes an organization compliant; that determination is your organization's and its auditor's to make. Compliance Updates keeps the technical control mappings and evidence-pack generation current as frameworks revise. The administrative controls and the audit itself remain yours.

Compliance Updates: $1,499/yr

2026-07-30

The kernel's main entry is browser-safe; refunds now net against upgrade credit

v0.6

@caisson/kernel reaches 0.7.0 and its main entry no longer reaches a Node built-in, so packages built on it — the trust-page generator and the artifact renderer among them — can be imported directly into a browser bundle. Everything that needs Node moved to a new @caisson/kernel/node entry point: constant-time secret comparison, audit-chain hashing, migration assembly, and the SSRF guard. That entry re-exports the main one in full, so server code that uses a moved function changes one import path and keeps the rest of its import list; nothing changed about what any of them do. If you import verifyChain, safeEqualFixed, assembleMigrations, or any of the SSRF helpers, point that import at @caisson/kernel/node — type-only imports need no change. Separately, a partial refund now reduces what a purchase counts as paid, so an upgrade quote credits what you were actually charged rather than the original amount, and a refund notice that names the same purchased line twice is rejected outright instead of being half-applied. The reference compliance pack gains a fourth control, risk identification and assessment, evidenced by a traversal of a scored AI risk register. @caisson/frameworks-pack gains a @caisson/frameworks-pack/registry entry point exposing the control model on its own. Full per-module detail ships in each package's changelog.

kernelbrowser-safebillingcompliancerelease

2026-07-28

oscal-spine ships as its own module; field-crypto moves to scoped key operations

v0.5

The OSCAL surface — catalog loading, profile resolution, and component-definition assembly — moves out of the bundles it was embedded in and ships as @caisson/oscal-spine, installable on its own and included for Compliance and Everything buyers. field-crypto changes shape underneath: key material now lives in a request-scoped context that is provisioned when the context binds and zeroized when it unbinds, and callers borrow a key for the length of one operation instead of receiving one to hold. A key-management adapter for Azure Key Vault and an immutable-storage adapter for Azure Blob are available for deployments that want the key or the archive outside the application. Background jobs gain an Inngest v4 driver alongside the existing Trigger.dev, pg-boss, BullMQ, and in-memory ones. Current prices for every module and bundle are on the marketplace page.

oscal-spinefield-cryptocatalogrelease

2026-07-12

Catalog-wide release: kernel 0.4.3, installable-version guarantee, lifecycle emails

v0.4

A coordinated release across the whole module catalog. The registry now enforces an installable-version guarantee: every advertised version of every module resolves to a downloadable, hash-verified tarball, checked in CI before anything ships. Purchases and renewals send lifecycle confirmation emails. The kernel reaches 0.4.3, project templates track it, the support bot's answer quality is regression-gated against a recorded baseline, and modules across the catalog pick up hardening and fixes. Full per-module details ship in each package's changelog.

kernelregistryrelease

2026-06-27

Base substrate: RLS, field-crypto, audit chain, create-caisson

v0.3

The Caisson base substrate is available. Ships: fail-closed Postgres RLS (FORCE-enabled, cross-tenant isolation CI-tested), per-tenant AES-256-GCM field encryption (HKDF-SHA256 key derivation, one key per tenant), an append-only SHA-256 audit chain via kernel verifyChain, auth and billing primitives, and the create-caisson generator. Start with bunx @caisson-sh/cli@latest.

substraterlsfield-cryptoaudit-chaincreate-caisson

2026-06-10

field-crypto: per-tenant AES-256-GCM encryption at the column level

v0.2

field-crypto ships as part of the base substrate. Per-tenant encryption keys derived via HKDF-SHA256, AES-256-GCM authenticated encryption, and a key-derivation layer that scopes each tenant's key material to their row context. No plaintext key material in the application layer. Covers HIPAA §164.312(a)(2)(iv) (encryption and decryption).

field-cryptosubstrate

2026-05-15

Kernel, registry runtime, and fail-closed RLS: initial release

v0.1

The Caisson kernel and registry runtime are available. The kernel provides verifyChain (append-only SHA-256 audit chain), tenant context primitives, and fail-closed RLS helpers. The registry exposes typed module definitions for every bundle. Fail-closed Postgres RLS (FORCE-enabled, cross-tenant isolation tested in CI) is available in the base substrate.

kernelregistryrls