forked from chiki2bum2/SniperGold_ML
78 lines
2.3 KiB
Markdown
78 lines
2.3 KiB
Markdown
# P3-S25.1C — CHUNK-SIZE INVARIANCE
| |||
| |||
```text
| |||
Date : 2026-08-28
| |||
Phase : P3-S25.1C
| |||
Status : PASS - CHUNK-SIZE INVARIANCE VERIFIED
| |||
```
| |||
| |||
## Invariant under test
| |||
| |||
```text
| |||
same source
| |||
+ same parser
| |||
+ same aggregator
| |||
+ same initial state
| |||
+ different chunk boundaries
| |||
= same semantic output
| |||
```
| |||
| |||
## Test definition (output/chunk_size_invariance.json)
| |||
| |||
For the SAME byte range `[75,497,639 -> 113,246,416)` (`37,748,777` bytes,
| |||
chunks 6-8) we compared:
| |||
| |||
- a **single-stream reference** (entire range processed as ONE chunk), and
| |||
- the range **chunked into 12 / 24 / 48 / 64 MiB** line-safe chunks.
| |||
| |||
Each config was seeded from a FRESH deep copy of the same initial carry
| |||
(carry isolation - no cross-config mutation).
| |||
| |||
Required to be identical across ALL configurations:
| |||
| |||
```text
| |||
rows_processed, malformed counts, first/last timestamp,
| |||
M15 count, M15 hash, M30 count, M30 hash, output hash,
| |||
final carry hash
| |||
```
| |||
| |||
## Result
| |||
| |||
```text
| |||
reference : rows=844772 M15=3959 M30=2112
| |||
output_hash=0ddefa471d259d0c329bfe302274674b12f2cc80287403fae575e167cf3e63a8
| |||
final_carry_hash=5a70c058e0cf7eff28a50e95a19d8ba6c3269187578ce91a789a9adfb1ae47a1
| |||
| |||
12 MiB (3 chunks) : identical (differences_vs_reference == {})
| |||
24 MiB (2 chunks) : identical (differences_vs_reference == {})
| |||
48 MiB (1 chunk) : identical (differences_vs_reference == {})
| |||
64 MiB (1 chunk) : identical (differences_vs_reference == {})
| |||
| |||
chunk_size_invariant : true
| |||
```
| |||
| |||
All configurations are byte-identical to the single-stream reference for the
| |||
full invariance signature. **No carry contamination and no boundary-dependent
| |||
semantics were observed.**
| |||
| |||
## Production end-to-end oracle
| |||
| |||
The 12 MiB config reproduces the committed production chunk 6+7+8 cumulative
| |||
output exactly:
| |||
| |||
```text
| |||
expected rows 844772 -> actual 844772 (281662+281576+281534)
| |||
expected M15 3959 -> actual 3959 (1279+1320+1360)
| |||
expected M30 2112 -> actual 2112 (673+707+732)
| |||
production_cross_check.ok : true
| |||
```
| |||
| |||
This binds the disposable benchmark engine to the same semantics as the real
| |||
run that produced the committed evidence.
| |||
| |||
## Conclusion
| |||
| |||
Chunk boundaries do NOT change semantic output. The chunk size is
| |||
computationally invariant under this parser/aggregator/carry/hash regime, so
| |||
the chunk size is NOT part of the business semantics. Safe to increase the
| |||
chunk size under these verification results.
|