Skip to content

Trust, security, and support

This page owns public support scope, private vulnerability reporting, release support, and the evidence available to dependency reviewers. API and behavioral stability live in Compatibility and Guarantees; test execution policy lives in Quality and Operations.

Current supported releases

The latest published release of each runtime is supported:

Runtime Package or coordinate Supported release
Java org.egothor:radixor Latest published release
Python (PyO3) radixor Latest published release
Python-C radixor-c Latest published release

Older releases are supported only under a separate contract. The public project does not promise an extended-support period or response-time SLA for superseded releases.

Versioning across runtimes

Radixor runtimes share a project versioning model without requiring identical patch numbers:

  • the major number identifies major change affecting the project as a whole, including architectural change;
  • the minor number identifies a shared fix or improvement affecting all runtimes;
  • the patch number identifies fixes and improvements local to one runtime.

Java, Python (PyO3), and Python-C therefore maintain independent patch streams. Releases with the same major and minor components belong to the same shared project line even when their runtime-specific patch components differ. PyO3 and Python-C patch numbers may also diverge. Model artifacts and the model catalog are versioned independently from runtime software.

Support and ordinary defects

GitHub Issues is the public support channel for usage questions, integration problems, documentation problems and ordinary defects. Include the runtime, exact version, operating system, reproduction steps, expected result and observed result when relevant.

Support for older releases, private operational assistance, or contractual service levels requires a separate agreement.

Reports are most actionable when they identify a behavioral defect, reduction or boundary-condition weakness, benchmark-methodology problem, test or mutation gap, ambiguous published result, or reproducibility and auditability issue.

Report security issues privately

Do not put vulnerability details in a public issue. Submit suspected security problems through GitHub private vulnerability reporting. Include the affected runtime and version, reproduction conditions, potential impact and any known mitigation. Public disclosure should follow coordinated assessment and remediation.

Radixor has no network service, authentication layer or authorization model, but it can still have security-relevant defects. Its trust boundaries include:

  • malformed, hostile or excessively large dictionaries and compiled models;
  • decompression and resource-exhaustion behavior;
  • memory safety in native Python runtimes;
  • parser, serialization and binary-format validation;
  • package, model and build-pipeline supply-chain integrity.

Treat dictionaries and compiled models as controlled inputs. Package manifests and SHA-256 checks detect accidental corruption; they do not authenticate a malicious model provider.

Dependency and artifact trust

Radixor's Java core has no external runtime dependencies. That narrow dependency surface simplifies source review, behavioral auditing, release inspection, software-composition analysis, and long-term maintenance. It does not by itself make an application secure: downstream code must still review the model artifacts it installs and the native-runtime wheels it executes.

Build source dictionaries and compiled artifacts in controlled environments, version them explicitly, and keep benchmark, test, and quality reports attached to the revision that produced each artifact. Do not load untrusted binary stemmer files.

Published engineering evidence

The Reports and Published Build Artifacts page links to the latest test, static-analysis, coverage, mutation-testing, dependency-vulnerability and SBOM reports. Python releases additionally publish checksums and GitHub artifact attestations; installation guidance explains how to verify them.

These reports are evidence tied to a particular build. They do not replace an application-specific threat model, dependency review or acceptance test.

Compatibility and upgrades

The Compatibility and Guarantees page defines the supported Java API and behavioral boundaries. Because model releases may change stemming outcomes independently of runtime releases, production upgrades should pin both runtime and model versions and run application vocabulary and search-relevance regression tests.

Accessibility and documentation feedback

The documentation provides text or tabular evidence for material claims shown in charts, keyboard-accessible navigation, visible focus indication, and responsive layouts. Report accessibility defects through GitHub Issues. The project does not currently claim certification against a particular WCAG conformance level.