# K1366–K1369 shared page seal contract

An owner prepares two shared pages while it holds writable mappings, then
seals the object. A successful seal changes every live writable mapping to
read-only and prevents every later writable map. The recipient can read the
prepared bytes through a read-only mapping. The owner cannot write again.

The model tracks a process identity, two distinct frame identities, page
contents, grants, mapping permissions, seal state, and a revision. Access is
checked before a grant, map, read, write, or seal changes state. A rejected
post-seal writable map returns `Access` and leaves the full snapshot,
including contents, mapping permissions, frame identities and revision,
unchanged. Invalid pages and stale grants are also rejected before mutation.

The guest adapter must bind the caller to a running process and update each
live PTE from RW to RO, complete the required TLB invalidation, and only then
publish the sealed state. If a PTE change or invalidation fails, it must not
report a successful seal; retained resources and an explicit fault state must
prevent a writable mapping from being treated as sealed. Frame ownership and
pins remain valid until the final unmap and handle close. A model test or a
separate probe Image is development evidence, not product acceptance.