Summary
A Profile can declare a Judgment Item, but nothing states whether it is a standing per-batch, per-page obligation. open -> merge-ready requires one batch-review receipt yet only verifies which Delta page receipts it binds — not whether the Profile's judgments were performed. Extension Gates are property-state transitions and the wrong shape for a content review that changes no property. check_batch_close runs after merge-ready, so it cannot supply a precondition for entering it.
The first real adopter demonstrated the consequence: a standing four-class content-form sorting obligation, declared in prose since its 3.6.3, was skipped entirely on a batch that closed with twelve gates green. Its own register entry states the systemic reading: the obligation had exactly one chance per page, and "not writing it down equals not checking" had no machine face.
Required design
Profile Judgment Item
-> declared as a Batch Review Requirement
-> expanded at activation into a Frozen Review Plan
-> delivered to the executing Agent with the Card Activation Bundle
-> answered per target as judgment receipts
-> aggregated by the batch-review wrapper binding the exact set
-> open -> merge-ready verifies expected = actual
- A requirement is not an Extension Gate: a Gate changes one persisted property after a judgment; a requirement proves the judgment happened for every applicable target and writes nothing back.
- First-version target selectors are closed (
each-manifest-page, batch); no natural-language applicability, so a declared rule can never again be one the machine does not know when to apply.
- Per-record evidence must be produced by an independent producer before
open -> merge-ready; the close gate is too late to be the first door.
- Invalidation must cover: page semantic drift, Profile contract drift, batch reopen (new activation, new judgments), pre-era activations (replay under their own protocol), and requirement-free Profiles (no shape change at all).
Fixed by #118.
Summary
A Profile can declare a Judgment Item, but nothing states whether it is a standing per-batch, per-page obligation.
open -> merge-readyrequires one batch-review receipt yet only verifies which Delta page receipts it binds — not whether the Profile's judgments were performed. Extension Gates are property-state transitions and the wrong shape for a content review that changes no property.check_batch_closeruns aftermerge-ready, so it cannot supply a precondition for entering it.The first real adopter demonstrated the consequence: a standing four-class content-form sorting obligation, declared in prose since its 3.6.3, was skipped entirely on a batch that closed with twelve gates green. Its own register entry states the systemic reading: the obligation had exactly one chance per page, and "not writing it down equals not checking" had no machine face.
Required design
each-manifest-page,batch); no natural-language applicability, so a declared rule can never again be one the machine does not know when to apply.open -> merge-ready; the close gate is too late to be the first door.Fixed by #118.