Platform systems at Nakafa
A safer release protocol for Nakafa content
Aksara is Nakafa's content release system. It signs and verifies releases, then prepares recovery before a candidate becomes visible.
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
| Release state | Visible to readers | Purpose |
|---|---|---|
| Active | Yes | The completed release currently selected by reads. |
| Candidate | No | The release being staged and verified. |
| Recovery | No | The signed inverse prepared for forward recovery. |
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.
Public implementation
The contracts, release protocol, CLI, and architecture decisions are public.
The Aksara repository includes the signed artifact contracts, publication workflow, recovery commands, tests, and the decisions behind them.
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.