telosieve 0.2.0-rc.4

Read-only infrastructure instruction evaluation that refuses when trusted evidence cannot agree
Documentation
# Productisation Decision

Date: 2026-08-08

## Decision

The owner approves Telosieve as a product with an enduring identity independent of research, evaluation, release-candidate, production, and support maturity. Brand `2.0.0` established that permanent identity; successive governed distinctiveness reviews advanced current source through brand `3.0.0` to the owner-selected Fractured Oracle identity in brand `4.0.0`, without changing the product platform or relabelling signed rc.3 bytes. This supersedes the 2026-07-29 productisation prohibition for the product and public-source presentation lanes. It does not supersede production, actuation, independent-assessment, legal-clearance, hosted-CI, package-publication, or safety-claim gates.

The permanent product layer comprises the Telosieve name, Fractured Oracle mark, `Question the instruction before enforcing it` tagline, corroborated desired-state control category, brand platform, visual system, and canonical assets. Current read-only evaluation status is a separately versioned release overlay and must not be encoded into the canonical mark, brand version, core tagline, or design tokens.

## Supported product profile

- primary user: platform reliability, infrastructure security, research, and independent assessment practitioners;
- enduring category: corroborated desired-state control;
- authority boundary: `read-only-no-target-mutation`;
- supported integration contract and modes: the exact machine-readable inventory in `evaluation/contract.json`;
- distribution posture: source and exact signed evaluation handoff only after their separate gates;
- support posture: evaluation candidates only, without response-time or production-availability SLA;
- telemetry: absent and unauthorized by default;
- exit: open evidence export, uninstall and preserved evidence procedures, Apache-2.0 source rights.

## Evidence and claim boundary

The current maturity overlay is backed by current implementation, local qualification, deterministic packaging, threat and risk documentation, and a defined assessor workflow. The permanent identity expresses purpose and product mechanism, not maturity evidence. Neither layer may imply that the project is independently validated, production-ready, legally cleared, generally safe, novel, commercially proven, or able to prevent arbitrary agent or infrastructure compromise.

Productisation completion is separate from candidate freeze. The exact `v0.2.0-rc.2` candidate passed its project-controlled freeze at commit `3539e3825a97a107703fccbf6f4a8de92c786c09`; that candidate is revoked by the privacy-preserving history migration and is not present as a tag in the replacement repository. Current source corrects the permanent identity without overstating candidate status. Public visibility must still pass the final history/privacy gate.