P3-S25.1D — MULTI-CHUNK TURN SEMANTIC INVARIANCE

Document type : Governance / evidence (P3-S25.1D) Date : 2026-08-28 Scope : VERIFICATION ONLY. No real-source ingestion.

Question

batching != semantic transformation. Grouping several already-validated 24 MiB atomic chunks into a single multi-chunk turn must not change the final semantic output of the tick -> M15/M30 aggregation:

single-stream reference == batch 1 == batch 2 == batch 4 == batch 6

The turn boundary must have ZERO semantic significance.

Semantic contract compared

rows_processed, m15_count, m30_count, m15_hash, m30_hash, output_hash, output_carry_m15, output_carry_m30, final_state_hash.

Method

On a fresh-allocated disposable range — bytes [0, 150,994,944) = 6 full 24 MiB atomic chunks, wholly within the committed chunks 0..10 region (which ends at byte 163,578,081) and before real chunk 11 — the same hardened driver runs:

single-stream reference : the whole range as one stream;
batch 1 / 2 / 4 / 6 : each turn processes a bounded batch of atomic chunks, one disposable checkpoint after EVERY atomic chunk, then proceeds.

All configurations start from the same initial empty carry and use identical parser, aggregator, canonical ordering, canonical serialization, and SHA-256 hashing. Byte-contiguity is enforced at the actual line-safe consumed offset (pos += len(raw)), as in production.

Exact result (machine-readable)

Authoritative evidence: ml/p3/p3_s251_external_ingest/multichunk_benchmark/output/multichunk_invariance.json -> semantic_invariant = true (classification PASS).

config	rows_processed	m15_count	m30_count	final_state_hash
reference	3,379,465	17,374	9,315	cb1e7d17d6..
batch 1	3,379,465	17,374	9,315	cb1e7d17d6..
batch 2	3,379,465	17,374	9,315	cb1e7d17d6..
batch 4	3,379,465	17,374	9,315	cb1e7d17d6..
batch 6	3,379,465	17,374	9,315	cb1e7d17d6..

Conclusion: CHUNK-BATCH SEMANTIC INVARIANCE — PASS. Grouping chunks into turns is an execution detail, never a semantic transformation.

Boundary-continuity requirement (recorded & resolved)

Chunking at nominal fixed byte multiples is unsafe: a tick record can straddle the chunk boundary. Each chunk must be read line-safely and the next chunk must start at the actual consumed end of the previous one. After that driver correction, the batched row count exactly equals the reference with identical hashes. See P3_S25_1D_VERIFICATION_DRIVER_HARDENING.md.

2.6 KiB 원본 고유링크 Blame 히스토리