Freeze SIMD decode admission scope

Author: eldryoth

README.md

@@ -96,9 +96,15 @@ Implemented now:
 
 Planned behind admission evidence:
 
-- Additional admitted wasm `simd128`, custom alphabet, in-place, and decode
-  fast paths after the SIMD admission evidence is complete. Default builds and
-  unsupported runtime CPUs remain scalar.
+- SIMD decode acceleration for strict Standard and URL-safe alphabets after
+  the `1.3.0` decode admission evidence is complete. The frozen first scope is
+  padded and unpadded strict decode only: no line wrapping, no legacy
+  whitespace, no custom alphabets, no bcrypt/crypt profiles, and no
+  constant-time-oriented secret decode. Default builds, unsupported runtime
+  CPUs, `no_std`, and all out-of-scope decode surfaces remain scalar.
+- Additional admitted wasm `simd128`, custom alphabet, and in-place encode
+  fast paths only after separate SIMD admission evidence is complete. Default
+  builds and unsupported runtime CPUs remain scalar.
 - Full async streaming wrappers only after the `tokio` feature passes the
   cancellation-safety admission bar in [docs/ASYNC.md](docs/ASYNC.md). The
   `base64-ng-tokio` companion crate currently provides bounded async

docs/SECURITY_CONTROLS.md

@@ -263,6 +263,11 @@ constant-time behavior is required. Streaming decoders intentionally use the
 normal strict decoder so they can preserve I/O-style behavior and avoid
 buffering unbounded frames. For secrets, collect one complete protocol frame
 under an application size limit and decode it with `ct::CtEngine`.
+Future normal SIMD decode admission is not a secret-decoding claim. The
+`1.3.0` decode acceleration scope is limited to strict Standard and URL-safe
+interoperability decode, and the `base64_ng::ct` constant-time-oriented decode
+path remains scalar unless a separate formal side-channel evidence package
+admits otherwise.
 Deployments that require the most conservative side-channel posture should
 combine `base64_ng::ct` with
 `runtime::BackendPolicy::HighAssuranceScalarOnly` so sensitive decode paths

docs/SIMD.md

@@ -74,6 +74,14 @@ The SIMD roadmap separates implementation evidence from active acceleration:
   the `1.2.x` decode evidence line is complete and the encode acceleration line
   has remained stable.
 
+The `1.3.0` decode scope is frozen before implementation starts: strict
+Standard and URL-safe decode only, padded and unpadded, through the normal
+strict decode backend boundary. Wrapped decode, legacy whitespace decode,
+custom alphabets, bcrypt-style and `crypt(3)` profiles, in-place decode,
+`no_std` SIMD dispatch, wasm runtime dispatch, and the `base64_ng::ct`
+constant-time-oriented secret decode path remain scalar unless separately
+admitted with their own evidence package.
+
 The detailed `1.2.3` to `1.3.0` workflow is commit-based rather than
 tag-based. Each planned commit is followed by pentest and CI review before the
 next implementation commit starts. See
@@ -196,6 +204,12 @@ runtime behavior for that line.
   prototype-only unless the SIMD admission manifest, scalar differential tests,
   fuzz evidence, unsafe inventory, architecture evidence, benchmark evidence,
   and release wording are updated together.
+- Decode acceleration is higher risk than encode acceleration because the
+  accelerated path must match scalar behavior for invalid bytes, padding
+  placement, non-canonical trailing bits, undersized outputs, partial-output
+  cleanup, and public error behavior. No decode backend may dispatch until
+  those properties are covered by tests, fuzz evidence, generated-code review,
+  unsafe inventory, hardware evidence where applicable, and release wording.
 - CI checks the reserved `simd` feature in `no_std` mode for x86_64, aarch64,
   FreeBSD, wasm32, and Cortex-M targets.
 - Performance claims must be backed by local benchmark evidence, not roadmap

docs/SIMD_ADMISSION.md

@@ -23,6 +23,29 @@ only for backends named in this file and the release gate.
   may use admitted fixed-block encode for its unwrapped staging step;
   line-ending insertion remains scalar.
 
+## `1.3.0` Decode Admission Scope Freeze
+
+The first decode acceleration line is intentionally narrower than the full
+decode API. Any `1.3.0` decode backend admission must start with strict
+Standard and URL-safe alphabets only, for padded and unpadded inputs, through
+the normal strict decode backend boundary. The following surfaces remain
+scalar unless a later evidence package separately admits them:
+
+- line-wrapped MIME/PEM decode
+- legacy whitespace-tolerant decode
+- bcrypt-style and `crypt(3)`-style profiles
+- custom alphabets
+- `no_std` SIMD dispatch
+- wasm `simd128` runtime dispatch
+- in-place decode
+- constant-time-oriented `base64_ng::ct` secret decode
+
+This scope is frozen before implementation work starts so security review can
+separate normal strict decode acceleration from the constant-time-oriented
+scalar path. Future normal SIMD decode must not be routed into `ct::CtEngine`
+or advertised as a secret-decoding acceleration path without a separate formal
+side-channel evidence package.
+
 ## Required For Every Admitted Backend
 
 Before a backend is admitted, complete