A safer release protocol for Nakafa content

Why content needed a release protocol

Nakafa's content and its renderer can change independently. The database and a Vercel deployment do not share one transaction, so a release cannot safely assume that every moving part changes at the same moment.

I designed the protocol around an invisible candidate, a verified inverse, and one atomic visibility change. A failed preparation stays invisible instead of leaving a half-published release for readers.

The candidate never becomes visible before its signed recovery path and renderer compatibility have been verified.

What the system verifies

Every release binds its content, routes, projections, renderer contract, and provenance. The candidate stays hidden while its counts, hashes, signatures, and renderer compatibility are checked. Activation changes visibility in one database mutation, while acceptance and recovery remain explicit operator decisions.

Result

A failed candidate remains invisible. A verified candidate can become active through one visibility change, and the operator already has an exact signed inverse if recovery is needed. The protocol turns partial preparation, activation, acceptance, and recovery into separate states that can be inspected and tested.

The trust boundary

Aksara treats authors as trusted production code authors. It does not pretend MDX is safe for arbitrary public uploads. The signature and verification chain protects the reviewed release path, while the application still checks delivery and access rules before returning content.

That boundary matters because a strong release protocol should state what it protects and what it does not.

Operating a risky release path?

I can make its states, failures, and recovery explicit.

That can apply to content, data migrations, internal workflows, or any release where partial success is more dangerous than a clear failure.