Padding

Length is metadata. An observer who cannot read a payload can still measure it, and a distribution of exact sizes identifies content classes with uncomfortable precision. Where SOVM/1 pads, it pads the same way, with a function whose overhead is bounded and whose bucket boundaries are principled rather than ad hoc.

14. The function is Padmé

SOVM/1’s padding function is Padmé (section 4.4 of PADME), which pads a length L by allowing progressively fewer low-order bits as L grows, giving a maximum overhead of about 12% that decreases with size, while collapsing the space of observable lengths to O(log² L) buckets.

An implementation MUST NOT substitute fixed size classes, per-deployment bucket tables, or any other target-length function where a page of this specification requires padding. One function, stated once, is the property that makes padded sizes comparable across implementations — a second function is a fingerprint.

15. Where padding is required

Padding is an instantiation decision of the layer pages; this page defines only what padding is when a layer requires it:

Surface	Requirement	Home
Object-plane control-plane payloads	Padmé, required	SOP/1 §10.5
Encrypted Parquet objects (SOP-PME-1)	Padmé, required, with no fail-open	SOP/1 §11.8
Blob chunk streams	Padmé over the plaintext length, required, with no fail-open	Blob format §8
Synchronization transport payloads	SHOULD pad; where a binding pads, it pads with Padmé	SSP/1 transport §27

16. What padding does not do

Padding reduces length leakage. It does not eliminate traffic analysis: timing, direction, frequency and correlation survive it entirely, and an implementation SHOULD NOT describe padding as defeating traffic analysis. The security pages of the layers carry the honest statement of what an on-path observer still learns.