Core 1.0 release candidate scope
Decision date: October 30, 2026. The owner authorized preparing Core v1 and the minimum FogVault packaging needed to consume it. Nothing in this document authorizes registry publication, a release tag, or an extension product launch. Publication was authorized separately. The 1.0.0 release records the published packages and public-install evidence. The preparation decisions below remain the scope policy; extension launch is still separate.What Core v1 commits to
Core is an independently usable SDK, with Rust, Python, native Node and browser WASM entry points. Its public API and value representations, explicit errors, Unicode offsets, source/record admission, workspace ownership, approved saves, complete-head comparisons, restoration and recovery follow the reviewed contract inventory and compatibility statement. The Workspace API contract is version 1. The snapshot writer remains version 3, with supported readers for versions 1, 2 and 3. The package version, Workspace contract version, snapshot version, fixture versions and DFVBRG01 storage binding are separate identifiers. An unchanged package version label is not evidence of compatibility. The exact published Core 0.5.0-beta.3 interchange test remains a separate regression; it is not replaced by testing the current source twice. Core-owned FogVault integrations are included as independently installable packages with explicit supported profiles. Their one-active-preparation policy does not impose a new limit on raw Rust Core callers. Node/Python integration factories currently admit password-only profiles; unsupported profiles reject without fallback. Host authentication and protected native control storage remain host responsibilities.Qualification boundary
This separates the SDK release from extension acceptance. It does not mark the
old broader G1/G2/G4 product issues passed, lower their product thresholds or
manufacture an accuracy result. Any failure of a supported Core contract remains
a Core release blocker.
The bounded measurement command is
cargo dfv check --core-sdk, after explicit
tool/model provisioning and a fresh SDK build. It uses the existing reference
MV3 harness as an SDK consumer; that harness is not Josh’s shipping extension.
The raw quality measurements and six approved-value recall/recovery phases stay
separate. See qualification and limitations.
Existing issue and PR dispositions
- PR #115 remains preserved historical fixture/scoring work. Its partially labelled corpus contains EMAIL and DATE examples without those gold labels; adding it to global rule scoring penalized correct detections. Its old native scores are not the browser Small baseline. Use the already scoped browser corpus/scorer for this candidate; salvage additional fixtures separately after their label coverage and evaluation scope are reviewed.
- PRs #184 and #202 remain external-provider preparation, with no actual provider preservation result. Review/consolidate them for the product’s G1 campaign.
- Issue #85 records an older native GLiNER2 checkpoint/configuration’s contraction false positive. The browser corpus separately measures its own contractions, names and false positives; those observations do not close the native report. No blanket removal of PERSON findings is part of Core v1 preparation.
- Issue #90 remains broader native/device fault qualification. Existing tests cover real worker death, cancellation, busy admission and close/cleanup paths. They do not establish every allocator-OOM, GPU or custom backend behavior.
- CSV is owner-deferred from v1. Shared engine redesign, new engines, CUDA, batching, city/state entities and compression are not added to this release.
Release sequence and evidence
- Prepare versioned Core candidates and the reviewed contract inventory.
- Prepare only the FogVault dependency distribution needed by Core. FogVault has its own 0.1.0 candidate and release schedule; Core’s package number does not require a FogVault 1.0 label. Preserve its current backup/API behavior, cryptographic source provenance and upstream advisory coverage.
- Verify package archives and clean registry-style consumers without local source overrides. Retain exact source, dependency, tool and artifact identity. An unpublished local registry proof is not a claim of public availability.
- Run final Core SDK/reference-host acceptance, contract parity and both joint FogVault scopes on the exact candidate. Resolve material supported-path failures before release under the recorded contract freeze.
- Finish changelog/version/notice/dependency checks and safe publication dry runs. Actual publication and post-publication registry checks require a later explicit release action. Uploads remain disabled during this preparation.