Repair over prevention
Prefer observable state and ordinary correction over elaborate consistency machinery.
Everything assumes an owner publishes relatively infrequently and can inspect mistakes. It therefore accepts some temporary inconsistencies instead of adding locks, a transaction coordinator or a separate authoritative page-head database.
The philosophy has three parts: preserve source, interpret deterministically and make repair ordinary. If two revisions are published, select predictably and expose the situation to owner inspection. If a template association is wrong, change its tag. If a write is interrupted, keep the asset ID and inspect before retrying.
This tolerance does not weaken authorization or bounded retrieval. Public readers must still be denied private content. Incomplete required retrieval coverage must fail explicitly rather than masquerading as a successful complete result.
Nor does repair mean automatically rewriting all awkward metadata. Unknown unrelated tags can remain. Correct only the state that matters to the intended interpretation, and preserve retained revisions for comparison and rollback.
The practical question is: can the owner understand what happened and fix it cheaply through normal tools? A clear diagnostic and two tag edits are often better than a new subsystem designed to prevent a rare overlap.
Accepting presentation staleness
Page rendering uses the tags returned by selection instead of checking them repeatedly around rendering. Successful templates stay cached without a timeout in a warm instance. That accepts a selected response finishing during an edit and layouts differing between instances until eviction or replacement. Authorization still runs for owner tools, and page selection still applies public eligibility. The tradeoff avoids multiple network round trips for a single-owner wiki.