Website Workspace: Page, Version, Block, Navigation, and Release

1. Do not model “the page” as one mutable row

If content, block order, navigation placement, and release state all live in one editable row, later edits can erase what yesterday’s public release actually contained. This lesson separates stable identity, immutable versions, and independent projections.

2. CON-007 ownership boundary

CON-007 owns the Page/Version/Block/Navigation/Release workspace model. CON-006 owns locale routing, CON-008 form intake, CON-009 canonical/redirect records, and CON-010 rollback/monitoring. Do not absorb those outcomes here.

3. Stable Page ID, immutable Page Version

A page_id such as P-42 is the logical page identity. Every publishable state gets a new page_version_id, such as PV-8. If publishable state changes, never overwrite PV-7; create a new immutable version and record its parent/supersedes relation.

4. Borrow only Git’s version-versus-pointer pattern

Official Git documentation describes history as commit snapshots and refs as named pointers to object identities that can move. That is a useful pattern, not a claim that MAKNOW page versions are Git commits.

5. Bind every snapshot to content evidence

Each page_version_id needs a snapshot_digest and exact ordered block-instance references. A timestamp or draft label is not enough because distinct states can share convenient mutable metadata.

6. Separate Block Instance from Block Payload

A block instance has its own identity, type, and payload ref/digest. A payload may be reused, but the order of instances is part of the page snapshot. Reordering blocks changes publishable state even when payload bytes remain unchanged.

7. Never repair missing history with the newest payload

If a historical release references an immutable payload that is missing, reconstruction must fail closed. Substituting the newest payload silently rewrites history and produces false audit evidence.

8. Bind provenance to derivation

W3C PROV distinguishes Entity, Activity, and Agent and provides wasDerivedFrom for derivation. A new page version can therefore point to its parent version and the change activity. PROV supplies vocabulary; it does not prescribe the MAKNOW schema.

9. Navigation is a versioned projection

Do not hide navigation placement as a mutable field inside the content snapshot. A navigation_projection_id records node, parent, and order for a specific projection so today’s move cannot erase yesterday’s navigation release.

10. A Release is a projection, not a synonym for Page Version

release_id and release_projection_id bind the exact page versions and navigation projection used by a release. A release pointer may move forward or backward, but historical releases remain immutable.

11. Mutable refs are convenience, not historical authority

A workspace_draft, branch-like label, or “current release” ref may move. Historical authority comes from immutable identities and digests, not the current label. Moving a pointer back does not rename or rewrite versions.

12. Reconstruction is a testable property

For every important release you should reconstruct the same page version, block order, payload digests, and navigation membership. Missing immutable dependencies or projections must remain BLOCKED or UNKNOWN rather than being silently repaired.

13. Negative example: same content, different navigation

If page bytes are unchanged but the node moves from /docs to /learn, the page snapshot may stay the same while navigation requires a new projection. Overwriting the old projection destroys historical reconstructability.

14. Transfer: reorder + payload replacement + nav move

For P-42, reorder two blocks, replace one hero payload, and move the navigation node. Create PV-8 and fresh navigation/release projections, then prove the previous release still reconstructs its original block order and navigation membership.

15. Auditable output

Website Workspace Version Graph & Release Projection v1 records Page ID, Page Version, Parent, Snapshot Digest, Block Instance/Type/Payload Ref-Digest/Order, Navigation Projection/Node/Parent/Order, Release ID/Projection/Pointer, Supersedes, Reconstruction Result, Projection Validation, Decision, Reason, and Provenance. RELEASE_PROJECTION_READY is bounded to the closed evidence for that fixture.