A visual tour of how Silan-Viking turns a rough thought into source-backed, stateful content, a derived projection, and a deployed website without making the database the source of truth.

Silan-Viking, Explained as a Publishing Loop

SSilan-Viking is easiest to understand when it is drawn as a loop rather than described as a CMS. It begins with an unfinished thought, preserves that thought as source, moves it through explicit states, derives a serving model, and finally closes the loop with private operational feedback.

Figure 1
The Silan-Viking content and publishing loop

An idea becomes durable source

The first object may be a sentence, a rough article, a project note, or an experiment. Capturing it creates a real content Item immediately. The Item has a stable identity, typed parts, language variants, and media that live beside it. A draft is therefore not a disposable editor buffer; it is already part of the same system that will publish the finished work.

Lifecycle is state, not a folder

Publishing does not mean copying a Markdown file into a special directory. Blog posts and episodes move through draft → published → archived; ideas and projects use state machines suited to their own lifecycles. Visibility is an independent decision. The Desktop action Publish sets a prose Item to published + public, while Unpublish returns it to draft + private.

This separation matters: authoring changes content, lifecycle changes intent, and deployment changes the running website. Those are three different operations and the interface should make each one visible.

The database is a projection

The content tree is authoritative. Sync parses and validates the source, then rebuilds a database optimized for the Go API and React website. If projection fails, the source mutation is rolled back atomically. Desktop, CLI, and agents all use the same application use cases, so none of them grows a private SQL implementation.

Deployment preserves live facts

A content deployment promotes the new projection and mirrors referenced media. Visitor-created facts—comments, likes, identities, request logs, and cached statistics—remain runtime-owned and are not overwritten by the author's local snapshot. The deployed content commit is recorded so Desktop can verify exactly which source version is online.

Analytics returns through a private path

Public pages, content APIs, images, search crawlers, and AI crawlers remain accessible. Detailed visitor records, sources, crawler history, and the full-site statistics snapshot require a machine bearer token. Desktop pulls that private snapshot in one operation and turns it into useful feedback without exposing the underlying data publicly.

The practical loop

The resulting workflow is deliberately small:

Capture a thought.
Develop it in the source-backed editor.
Publish its lifecycle state.
Deploy and verify the exact content commit.
Learn from private statistics and continue writing.

This article and its illustration went through that same loop. The system is not merely describing a publishing workflow here; it is executing it.