Rakomi

SDK Support & Lifecycle

Rakomi publishes dated support windows for every SDK major version — the kind of lifecycle contract an auditor can cite. This page is the human view of our machine-readable support policy.

CRA-aligned support

🛡️ CRA-aligned support policy

Dated support contract per major version — at least 5 years (60 months) (CRA Art. 13(8)) — and coordinated vulnerability disclosure (CRA Art. 14).

Note: this is a documentation and policy posture, not a completed conformity assessment. The EU Declaration of Conformity and CE marking attach at the CRA application date (December 2027) and are not yet issued.

The policy

Status legend

Support windows

Policy generated 2026-06-18

The dates below are rendered from the canonical machine-readable policy at /.well-known/sdk-support.json — you can verify this page is not hand-typed.

No GA versions are published yet.

Dated support windows (at least 5 years / 60 months) attach at version 1.0. Pre-1.0 (0.x) packages carry no stability or support guarantee. When the first GA version ships, its dated window appears here automatically.

Version Status Released EOL Notes
No published versions yet — see the note above.

Provenance & SBOM

Once published, each package ships with build provenance you can verify yourself: 

npm audit signatures

Available from the first public release — no signatures exist yet (pre-publish).

Package npm SBOM (CycloneDX) Releases Security
@rakomi/node npm sbom.cdx.json Releases SECURITY.md
@rakomi/sdk-core npm generated at first publish Releases SECURITY.md
@rakomi/react npm sbom.cdx.json Releases SECURITY.md
@rakomi/react-native npm generated at first publish Releases SECURITY.md

Releases, SECURITY.md and SBOM links resolve publicly from the first public release — pre-publish the source repository is private; the same files also ship inside each published npm tarball.

Verify us yourself

Don't take our word for it. From the first public release you can confirm every supply-chain claim on this page from outside our CI — these are the exact commands a skeptic runs:

  1. Verify registry signatures + provenance for the installed tree 
    npm audit signatures
  2. Verify the provenance attestation for a published version 
    gh attestation verify --repo rakomidev/rakomi-js "$(npm pack @rakomi/sdk-core@latest --silent)"
  3. Re-pack from this source at the immutable per-package tag and compare the SHA-512 digest 
    git checkout sdk-core/v<version> && npm ci && npm pack --workspace @rakomi/sdk-core

Full walk-through: VERIFY.md — resolves publicly from the first public release.

What provenance proves — and what it does not

Each published package carries build provenance (SLSA Build L2) generated from this public repository via OpenID Connect trusted publishing — the bytes you install are cryptographically bound to the source you can read here.

It does not claim a bit-for-bit reproducible build against any private canonical source: shared internals are inlined at build time, and the readable source here is the real, inspectable source those bytes were produced from. The substantiated claim is provenance + signatures + a public npm pack you can re-run — not reproducibility against a hidden oracle.

How this repository works (per-release clean-room snapshots)

Each published version is a self-contained clean-room snapshot committed as a zero-parent (orphan) tree — there is deliberately no linear git ancestry between releases. The version history you should follow lives in the npm version timeline and the CHANGELOG, not in git parent links. Zero-parent commits here are the model working as designed, not a sign of tampering.

This public repository is a published artifact, not a development fork: pull requests are not merged into a per-release orphan tree. Development happens upstream; each release re-publishes a fresh snapshot. Report bugs, ask questions, or open a feature request through the channels listed in each package’s SECURITY.md, and report vulnerabilities privately via GitHub private vulnerability reporting (never in a public issue).

Security advisories (GHSA) describe a fix as "fixed in version 0.x.y — see the immutable per-package tag" rather than as a commit diff: under the orphan model the authoritative, verifiable reference is the published version and its signed, immutable tag, which provenance binds to the exact source you can read.

More