Pre-alpha releases exist (latest v0.0.20), but no release is stable, Verified, Compatible, or supported. Normative requirements in this policy are Accepted contract, not shipped product behavior.

Once a supported release exists, this table will list each supported version range and its support status.

Normative requirements here are Accepted contract. No stable, supported, or Verified release is claimed. Where experimental code exists in the bitty workspace, it is at most Implemented-only, never Verified, per the Panel Runtime RFC implementation-status table and the Risk Evidence RFC evidence lifecycle.

The small-core extraction boundaries are decided as direction, and every focused contract preserves the P0 trust boundaries that the canonical bitty-docs security corpus governs. Decision records: ADR 0015 and ADR 0016.

The focused contracts that define this platform's trust surface, and that must not weaken a P0 control, are (the W-71 observability contract is still a draft; the rest are accepted):

• Observability Boundary (W-71, draft): read-only observation, default-deny authorization, redaction, and bounded buffers stay in Core.
• Package Manager and Runtime Loader Boundary (W-72): P0-AC-027 through P0-AC-030 and Core's read-only startup validation are preserved; Core stays network-free.
• Composer Boundary (W-73): input capture, paste inspection, and argv-first process and temp-file controls stay Core-gated.
• Legacy Chrome Retirement (W-74) and ADR 0017: retirement preserves the capability, grant, and safe-mode enforcement points.
• Validation Suite Ownership (W-75): validation tooling gains no product authority; P0-AC-002 and P0-AC-034 remain gating.

Reconciling these pages changes no control; where a control or threshold appears to need change it is recorded as an open point in the owning contract, never downgraded here. The dependency order and the retained-mechanism summary are in the small-core refactor execution handoff.

To report a security vulnerability, open a private GitHub Security Advisory.

Do not report security vulnerabilities via public GitHub issues, pull requests, discussions, or chat channels.

When reporting, include as much of the following as applicable:

• A description of the suspected vulnerability and its impact.
• The affected document, specification section, or (once they exist) component and version.
• Steps or inputs needed to reproduce the issue.
• Any suggested mitigation, if you have one.

• Reports are handled privately from intake through fix, coordination, and disclosure. Details are not discussed publicly while a fix or mitigation is being prepared.
• Reporters will receive an acknowledgment and a tracking reference, and will be kept informed of assessment outcomes and resolution timelines.
• Coordinated disclosure is the default: a public advisory accompanies or follows the release of a fix. Credit for reporters is given by default and may be declined on request.
• Security requirements for future Bitty implementations live in the canonical security corpus under bitty-docs docs/security/; that corpus takes precedence over historical notes when statements conflict.

These targets are process commitments for this documentation repository, not claims about shipped product behavior:

• Acknowledgment of a new report: within 5 business days.
• Initial severity and impact assessment: within 10 business days of acknowledgment.
• Fix or mitigation guidance for confirmed issues: targeted within 90 days, sooner for high-severity findings; complex issues receive a communicated timeline instead of silence.