LokiOS
A private, self-hosted publishing system that takes an article from evidence to published page.
At a glance
- 2026-NOW
- PRODUCT / SYSTEM DESIGN / IMPLEMENTATION
- AI WORKFLOWS / EDITORIAL SYSTEMS / PUBLISHING INFRASTRUCTURE
- An active private build rather than a commercial launch. Current work covers editorial contracts, repeatable workflows, verification gates and WordPress delivery.
The question
What would publishing software look like if it optimised for accountability instead of raw output?
Generating an article is cheap now. Running a publication readers can trust is not: identity has to hold, sources have to exist, commercial arrangements have to stay visible, claims get reviewed, output gets checked in the real publishing environment, and pages need maintaining afterwards.
Most tools compress all of that into one prompt and one output box. LokiOS treats generation as one step inside a longer pipeline.
The approach
LokiOS runs as a private, self-hosted environment for multiple independent publications. Each site needs its own identity, writer context, policies, sources, monetization rules and publishing destination. The system makes those differences explicit instead of relying on an operator to remember them at the right moment.
The central workflow is:
IDENTITY → EVIDENCE → DRAFT → REVIEW → VERIFY → PUBLISH → MAINTAIN
Supporting context feeds the workflow at every stage: site profile, writer identity, business model, disclosure policy, prompt and skill definitions, source material and publishing configuration.
The system is larger than generation
Text generation answers one narrow question: can the model produce a plausible article from an instruction?
Publishing software has to answer harder ones:
LokiOS treats these as requirements, not polish added after drafting.
- Which publication is speaking?
- What does its writer know and what should they verify?
- Which claims are supported by evidence?
- Where do commercial relationships affect the content?
- Who or what reviews the work before publication?
- Does the output survive the real WordPress environment?
- When should an article be updated, corrected or removed?
My role
I defined the product direction, operating model and quality bar, then translated the publishing problem into workflows, contracts, skills, interface modes and verification gates. Coding agents inside a containerized development environment implemented and audited the system.
That made orchestration part of the product work: the hard part was leaving enough structure for long-running coding sessions to continue without losing the original intent.
Decisions
Self-hosted by default
Publication context, source material and working knowledge stay under the operator's control, in a private environment rather than a generic hosted dashboard.
Site identity is data
Writer identity, audience, business model and policies cannot live only inside a long prompt. They need structures that can be inspected, reused and changed deliberately.
Guided and detailed modes share one workflow
Guided Mode reduces cognitive load through constrained choices; Detailed Mode exposes the underlying controls. They are two interfaces over the same pipeline, not separate products with drifting behaviour.
Verification must reach the publishing environment
A draft that looks correct in isolation can still fail inside a real theme, layout or publishing integration. WordPress preview and verification belong inside the quality loop.
Preflight should be deterministic
Before an expensive workflow starts, the system checks required context, paths, dependencies and contracts in a repeatable way. Failure produces a structured report, not a vague agent explanation.
What exists
The private build includes, or is being developed around:
- Multi-site profiles and site-specific context
- Reusable writer identities and editorial skills
- Contract-driven workflows
- Deterministic preflight and structured reporting
- Guided and detailed operating modes
- Article preview and quality inspection
- WordPress publishing and theme verification
- Containerized services for the web application, API, data and object storage
- Evidence captured across long-running implementation and audit sessions
Development is ongoing. Nothing here claims users, revenue or a launch, because none exist.
What it taught me
The most useful shift was learning to tell an AI feature apart from publishing software.
A feature can succeed once. Software that runs a publication has to make success repeatable, inspectable and recoverable: carry context across sessions, make failure legible, and leave as few important decisions as possible to memory.
That lesson extends past publishing. Producing text keeps getting cheaper; deciding what gets produced and what counts as publishable does not.
Generation takes seconds. Making the result publishable is the product.