Publishing and rendering
Cronkite
A CMS-directed rendering service that turns approved content and presentation manifests into authorized publishing artifacts.
I designed and built this project independently, using my own resources.
01 / Context
The problem behind the project
Editorial systems need a repeatable path from approved content to the formats and destinations used by readers.
A publishing system must turn approved editorial content into pages and artifacts without acquiring the authority to decide what should be published. I separated the CMS’s content and workflow decisions from the renderer’s responsibility for producing and delivering bytes.
The work includes tenant-specific presentation packages, declared system pages, article output, and media-collection surfaces. A real gallery repair exposed why route configuration, a template manifest, authorization to write the output, and the output object itself are separate pieces of a successful publication.
02 / Implementation
Design and implementation
I build the rendering and distribution pipeline behind the newsroom publishing workflow.
I built the rendering/distribution service and its contract with the CMS and presentation packages. The CMS supplies a canonical document and exact signed write targets. A package manifest declares the renderable and its presentation needs; Cronkite validates the request, renders the artifact, executes the authorized writes, and returns receipts.
The current boundary removes autonomous feed discovery and hidden publication cascades. Startup loads and validates enabled presentation packages but does not publish pages. The CMS owns editorial status, retries after process exit, social composition/posting, and durable receipt reconciliation.
I also worked on tenant isolation, standalone/system pages, shared media galleries, and immutable program-renderer registration. These are contract and deployment problems as much as template problems: a renderer cannot safely invent bucket authority or publish undeclared output.
03 / Architecture
Architecture and workflow
Authorize content and scope
The CMS chooses the canonical content version and the exact renderable/output targets.
Load a declared presentation
Cronkite validates the tenant’s presentation package and manifest rather than discovering work implicitly.
Render and write
The renderer produces bytes and uses only the caller-authorized HTTP write operations.
Return authoritative receipts
The CMS persists outcomes and decides whether and how to retry or progress the editorial workflow.
04 / Approach
Engineering decisions
Publication authority stays with the CMS
The CMS chooses canonical content, publication state, renderables, and signed write targets. Cronkite executes that request rather than discovering new work, deciding editorial scope, or holding ambient storage authority.
Declare presentation and return receipts
Presentation packages declare supported output. The renderer validates the contract, produces bytes, and returns receipts; the CMS persists outcomes and owns later retries. Boot validates packages without publishing autonomously.
05 / Evidence
Evidence and outcomes
The media-gallery investigation separated a deployed routing change from an absent HTML object. Package declaration and signed-target permissions were prepared and tested, while configuration/release/cutover remained explicit follow-up work. That distinction prevents a successful build from masquerading as a completed publication.
The CMS ownership contract documents request validation, tenant boundaries, declared output scope, and receipt semantics. It also records the tradeoff that an invalid enabled presentation package blocks startup.
06 / Current scope
Where it stands
A private implementation of the newsroom publishing pipeline.
Editorial workflow, social-provider credentials, and publication scheduling remain CMS-owned. Older descriptions that imply Cronkite autonomously polls and posts content are too broad for the current contract.
Loading a package, releasing that package, deploying the renderer, authorizing a target, and verifying the final page are separate delivery steps. Private implementation and tenant configuration are not exposed here.