The questions an organisation’s open-source intake or due-diligence form usually asks, each answered in a sentence or
two with a link to the page that is the authority. This page restates no policy: when an answer and its source
disagree, the source is right, and the page needs fixing. Items not in place yet are in Known gaps, each
linked to its open issue.
Under the Developer Certificate of Origin: every commit carries a Signed-off-by trailer, and CI fails a pull request with an unsigned commit. See CONTRIBUTING.md.
Is there a legal or IP FAQ (copyright, patents, third-party licences)?
Each release attaches a per-module licence report (CSV: dependency, SPDX licence, how it is pulled in), and CI fails on a copyleft or unknown licence: see Dependency licences. Each module’s SBOM lists the same dependencies.
Governance
Question
Answer and evidence
Who decides, and how?
Contributors, committers and maintainers; lazy consensus day to day, a maintainer majority for larger or contested decisions, and an RFC for changes to a Frozen API, a tier, an SPI or a wire format. See GOVERNANCE.md.
Who maintains it (bus factor)?
Two maintainers, listed in MAINTAINERS.md; committers, committees and contributors are on the People page.
Who owns the project?
It is stewarded by the LLM4S Foundation, a community-led group: see the Foundation page. Neutrality, continuity and a trademark policy are not documented yet: see Known gaps.
Release and support
Question
Answer and evidence
How are versions numbered?
Semantic versioning, with versionScheme := early-semver in the published POMs. Before the compatibility baseline (0.5.x now) any release may break compatibility, each break listed in the CHANGELOG with a migration note. See the Compatibility and Deprecation Policy.
Fixes ship in the latest release only; older releases are not patched (SECURITY.md). There is no published release cadence, supported-lines policy or long-term-support line: see Known gaps.
Security
Question
Answer and evidence
Is there a security policy?
Yes: SECURITY.md covers supported versions, private reporting, what to expect and scope. Handling is best effort, with no response-time commitment.
Who handles reports, and how?
The Security Committee and the maintainers, following the steps in MAINTAINERS.md: acknowledge, assess, fix in a private fork, release, publish an advisory.
Can vulnerabilities be reported privately?
SECURITY.md names GitHub private vulnerability reporting as the preferred route and a private Discord channel as the fallback. Private vulnerability reporting is not enabled on the repository yet: see Known gaps.
Is there a threat model?
Yes: the Security Reference lists data flows, trust boundaries, known risks with their mitigations and residual risk, and a checklist for pull requests.
What is the track record?
No GitHub security advisory has been published (advisories).
Supply chain
Question
Answer and evidence
Is there an SBOM?
Yes: a CycloneDX SBOM per published module on each GitHub Release, also built and validated on every pull request. See Software Bill of Materials.
Are dependencies scanned?
OSV-Scanner scans the SBOMs weekly and on pull requests that change dependencies; a pull request that adds a HIGH or CRITICAL advisory fails. See Vulnerability scanning.
Are artifacts signed?
The Maven Central artifacts are PGP-signed by the release workflow (release.yml, sbt ci-release). There is no build provenance attestation, the SBOMs are not signed, and there is no guide to verifying a release yet: see Known gaps.
OpenSSF Scorecard or Best Practices badge?
Scorecard runs on every push to main (results); the branch-protection items it scores are still open. No Best Practices badge yet: see Known gaps.
Data protection
Question
Answer and evidence
Does the library send telemetry?
No. Every network call goes to a destination your configuration or code names: Data Protection.
What leaves the process, and where to?
A table per module, and the destinations for an egress allow-list: Data Protection.
As a library inside your service. Configuration, secrets, timeouts, lifecycle and deployment patterns: Production Deployment. A staged dev, staging and prod template with Kubernetes manifests and rollback: deploy/.
Tracing to Langfuse or OpenTelemetry, metrics to Prometheus or Micrometer: Monitoring.
Health checks?
Production Deployment, and the /health and /llm-check endpoints of the deploy template. Doctor checks a developer’s setup.
Secret rotation?
Keys come from configuration, which can bind environment variables: Configuration & Secrets. Rotating a key without a restart is not supported yet: see Known gaps.
SUPPORT.md. The maintainers are volunteers: replies are best effort and there is no service-level agreement.
Is commercial support available?
No paid support is offered. Questions about sponsoring or partnering with the project go to the contact on the Foundation page.
Known gaps
Reviewed 2026-10-25. Each item is an open issue; a CI check (scripts/check-cited-issues.sh) fails when one of them
closes, so this list is updated when the gap is.
Gap
Issue
No binary-compatibility baseline yet: MiMa checks nothing until a pre-1.0 release sets one, then 1.0
Project: LLM4S (Large Language Models for Scala), https://github.com/llm4s/llm4s
Licence: MIT (https://github.com/llm4s/llm4s/blob/main/LICENSE). Contributions under the DCO
(Signed-off-by on every commit, checked in CI).
Dependency licences: per-module licence report on each GitHub Release; CI fails on copyleft
or unknown licences (https://llm4s.org/reference/licences); per-module CycloneDX SBOMs
(https://llm4s.org/reference/sbom).
Governance: GOVERNANCE.md (lazy consensus; maintainer majority for larger decisions; RFCs for
Frozen API changes). Two maintainers (MAINTAINERS.md). Stewarded by the LLM4S Foundation
(https://llm4s.org/foundation/).
Versioning: semantic versioning (early-semver). Pre-1.0: any 0.5.x release may break
compatibility, with a migration note (https://llm4s.org/reference/compatibility-policy).
No binary-compatibility baseline yet (https://github.com/llm4s/llm4s/issues/1281).
Support policy: fixes ship in the latest release only. No published cadence, supported lines
or LTS (https://github.com/llm4s/llm4s/issues/2289). Volunteer-maintained, best effort,
no SLA, no commercial support (SUPPORT.md).
Security: SECURITY.md; reports handled by the Security Committee and maintainers, best
effort, no response-time commitment. Threat model: https://llm4s.org/reference/security.
No published advisories. Private vulnerability reporting not yet
enabled (https://github.com/llm4s/llm4s/issues/1465).
Supply chain: CycloneDX SBOM per module on each GitHub Release; OSV-Scanner weekly and on
dependency changes. Maven Central artifacts PGP-signed. OpenSSF Scorecard on every push to
main (https://scorecard.dev/viewer/?uri=github.com/llm4s/llm4s). No build provenance
(https://github.com/llm4s/llm4s/issues/2305) or Best Practices badge
(https://github.com/llm4s/llm4s/issues/2307).
Data protection: no telemetry; data goes only to the providers and stores you configure;
default tracing prints metadata only (https://llm4s.org/guide/data-protection).
Platform: Scala 3 (3.7.1), JDK 21. Java and Kotlin APIs; Spring Boot, Quarkus, cats-effect,
ZIO and Pekko integrations.
Adopters: ADOPTERS.md (by pull request).
Full answers with evidence: https://llm4s.org/reference/enterprise-evaluation