# Numeric mapping identity defect - 2026-10-03

## Confirmed from installed code and read-only evidence

The pending batch contains 120 observations: zero duplicate timestamps, zero
backwards pairs, but 75 identity failures. The initial 45 observations in this
batch are imported observer records; later native captures use the saved manager
configuration. Evidence: test-host `PENDING_DELIVERY_REVIEW.json`.

The configured mapping fingerprint is
`517d1907631c7f152096e21759bb3452cdd0b4b1b73f91f1c7cd3bd62d8aaa8b`.
Reproducing native configuration loading generates
`3a1a9cf42aae49f55385d2350da74cae780ae12f170e4976849591e48a393994`.
The sole difference in the compared configurations is numeric representation of
`accounting.splitToleranceW`: prepared float 100.0 versus saved integer 100.
Both inventory fingerprints and all measurement definitions match.
`NetzfahrplanV4Bilanzierung::konfigurieren` validated this field using a function
which returns a float, but discarded the normalized return value. Other numeric
factors were already assigned from that validator.

## Tested source correction

Assign the returned float to `splitToleranceW`. Equal numeric settings now retain
the original fingerprint through a plain JSON property round trip. Actual numeric
changes still produce distinct fingerprints, and boolean/string values are still
rejected. Input configurations are not mutated.

42 isolated PHP checks passed on the test host: 34 accounting regressions plus
8 numeric identity regressions. A separate check with the actual prepared capture
configuration reproduces the configured fingerprint after the property round trip.
Evidence: `/srv/agent/netplan-v4-application-build/NUMERIC_MAPPING_TEST_RESULTS.json`
and `NUMERIC_MAPPING_TEST_RESULTS.txt`. Library SHA256:
`ffda2a03dbb226a4405a2ad66704c080a9dc475ce64282ad3f0d7d60034ab199`.

## Not deployed / recovery still incomplete

No installed library, original outbox, cursor, server validator, settings, dataset
registration or actuator permission was changed in this turn. Future-capture
normalization alone does not recover already stored native observations. The
server correctly rejects an entire batch containing a mismatched mapping.

An untested proposal to send distinct immutable dataset versions in separate
batches was removed from the development source and preserved only as a draft at
`/home/agent/services/qa/numeric-mapping-20261003/UNTESTED_SENDER_DRAFT.patch`.
Metadata preparation files are not an installation or permission to ingest into
an unregistered dataset. Tool writes for the complete server recovery package were
blocked; no alternative deployment or identity-check bypass was performed.

Next recovery must preserve original records and provenance, retain exact
per-dataset identity validation, acknowledge only accepted data and include tests
for the mixed 45/75 batch, retries, partial ACKs and no cursor/data loss. Do not
skip the rejected block, rewrite hashes in raw journals or re-run old installers.