> ## Documentation Index > Fetch the complete documentation index at: https://docs.datafog.ai/llms.txt > Use this file to discover all available pages before exploring further. # 0.4.0 > Expanded detection, runtime capabilities, and strict locale validation. DataFog Core [**0.4.0 is published**](https://github.com/DataFog/datafog-core/releases/tag/v0.4.0) for Rust, Python, Node.js, and browser WASM. All four runtime tags point to source commit [`133bceff`](https://github.com/DataFog/datafog-core/commit/133bceff0d2a53a7f6d1a75693330c1797285654). Registry-installed artifacts were verified after publication: | Runtime | Distribution | Verification | | - | - | - | | Rust | [datafog-core 0.4.0](https://crates.io/crates/datafog-core/0.4.0) | crates.io artifact checksum and installed-crate smoke test | | Python | [datafog-core 0.4.0](https://pypi.org/project/datafog-core/0.4.0/) | PyPI wheel, 352 downstream adapter/contract checks, and `pip check` | | Node.js | [@datafog/node 0.4.0](https://www.npmjs.com/package/@datafog/node/v/0.4.0) | Clean registry installation and native smoke test | | Browser/WASM | [@datafog/wasm 0.4.0](https://www.npmjs.com/package/@datafog/wasm/v/0.4.0) | Registry installation and actual Chromium smoke test | ## Changes * JWT and complete PEM private-key detection run by default. * Context-labeled US routing numbers and National Provider Identifiers run by default. They detect lexical shapes without checksum or registry validation. * Canonical UUID detection is opt-in through `detect_uuid: true`. * German locale routing adds seven German entity types. * Rust and Python runtime capability metadata describes supported entities, default detection, locale additions, and configuration needed to activate scoped detectors. * Package versions are aligned at 0.4.0 across Rust, Python, Node.js, and WASM. The runtime-generated [capabilities reference](/reference/capabilities) is the inventory source. Detector details and limits are documented in the [JWT](/reference/jwt), [private-key](/reference/private-keys), [UUID](/reference/uuid), [routing-number](/reference/us-routing-number), [NPI](/reference/npi), and [German entities](/reference/german-entities) pages. ## Intentional locale-validation change Explicit locales are now checked against the runtime registry. The recognized aliases are `de`, `de-DE`, `de_DE`, `en-US`, and `fr`, compared after trimming and with ASCII case-insensitive matching. German aliases activate German detectors; `en-US` and `fr` retain base detection. Omitting the locale also runs base detection. UUID activation remains independent of locale. Previously, arbitrary nonempty locale strings were accepted and silently used base detection. In 0.4.0, unsupported explicit locales raise the binding's existing configuration error. Update callers that supplied placeholder or unrecognized locale strings before adopting 0.4.0. The [compatibility policy](/reference/compatibility) governs subsequent 0.4.x changes. ## Python adapter dependency and NPI selection The Core Python binding (`datafog_core`) and the higher-level `datafog-python` package have separate release lifecycles. The capability-aware adapter is tracked in [datafog-python draft PR #179](https://github.com/DataFog/datafog-python/pull/179), which targets `datafog-core>=0.4.0,<0.5`. The published Core wheel has passed the 352-check local adapter/contract suite. The adapter draft remains unreleased and must complete its hosted checks and separate release review before it is merged or released. Core availability alone does not release the higher-level adapter. A reviewed compatibility limitation remains in the legacy Python adapter. Core can return both `PHONE` and `NPI` for the same numeric span. Legacy processing resolves overlaps before filtering selected labels and gives `PHONE` priority, so selecting only `NPI` through that legacy path can return no finding. Default legacy redaction still protects the number. The native `datafog.v5.scan` path retains the NPI finding, and native transformations can select `NPI` explicitly. PR #179 tests this behavior while preserving the legacy overlap and selection rules. ## Release readiness gate The following procedure remains applicable to future releases. The 0.4.0 registry verification results are recorded above. Record artifact paths, checksums, tested commits, commands, and results in each release review. 1. Land the focused detector and capability changes; select the exact candidate commit. Confirm all package and lockfile versions with `python3 scripts/check-release.py python`. 2. Run Rust formatting, Clippy, and workspace tests; build and test the installed Python wheel and source distribution, Node package, and real-browser WASM package. Verify Rust and Python capabilities agree and metadata matches actual detector activation across runtimes. 3. Validate Mintlify content and links against the same candidate. Confirm the generated capabilities inventory is current. 4. Build a candidate Python wheel from that commit. Install that local artifact into an isolated environment for the downstream `datafog-python` checkout; record the wheel hash and both repository commits. Run its adapter, public API, German detector, transformation, structured-data, and regression suites. Test failure handling for unsupported locales and activation based on capability metadata. Fix and repeat against a newly identified artifact if integration fails. 5. Review downstream results and confirm the intended minimum Core dependency and release order in `datafog-python`. **Downstream integration remains a required gate; Core's installed-wheel tests do not replace it.** 6. After approval of the verified candidate, publish the runtime packages from the same release commit using the documented [release workflows](/development#publish-a-release-from-github-actions). Creating a tag or invoking a publish workflow is a separate release action. 7. Verify registry artifacts by installing the published versions before announcing availability. Complete any dependent `datafog-python` release only after its Core dependency is available.