Read the explanation
The saved checkout page displays a synthetic fourteen-field request with four disclosed and ten withheld. At twenty five pixels per buyer field the bars span one hundred and two hundred fifty. Ten divided by fourteen rounds to seventy one point four percent, matching the initial label. The four named baseline fields are buyer email, payment token, recipient name, and shipping address. These are a static fixture, not buyer data sent to a merchant. The local copy lacks its referenced engine and app scripts, so the displayed counts do not prove a successful compiler or actual checkout. The visible delivery-alert label says it activates phone. Following that stated intention, adding one phone field would increase disclosure from four to five and reduce withholding from ten to nine, keeping fourteen total. At fifty pixels per intended disclosed field the bars span two hundred and two hundred fifty. This is an illustration of the intended condition, not an observed compiler result. The missing scripts prevent verification that the switch updates the envelope, checks required values, or exports JSON. A browser checkbox changing state alone would not establish that those downstream operations happened. The business-invoice label names company and tax identifier. If both intended fields activate and are present, the four-field baseline would grow to six while eight of fourteen remain withheld. At fifty pixels per intended disclosed field the bars span two hundred and three hundred. If an active required value were absent, readiness would require checking missing values rather than silently sending an incomplete envelope. This copy cannot prove that validation because its implementation files are absent. The page explicitly calls its contract synthetic and excludes payment execution, identity verification, tax processing, and certification of external checkout protocols. No backend or merchant action occurs in this explainer.