Skip to content

Publication Model

This document defines the publication model used by WildEditorInChief (WEIC).

The publication model describes how governed knowledge moves from internal authored and reviewed state into a controlled published form. It separates storage of knowledge from exposure of knowledge, which is important for accuracy, governance, and operational safety.

The publication model builds on the HTML storage model, revision model, and review model.

Purpose

The publication model exists to support several goals:

  • distinguish internal authoring from published output
  • control which revision becomes externally or operationally visible
  • support stable publication even while new revisions are being authored
  • preserve traceability between authored content and published content
  • provide a foundation for future release and publishing workflows

This is an important part of turning WEIC into a true publishing backend rather than only an editing system.

Publication principle

Authoring and publication are not the same thing.

A document may have:

  • a current authored revision
  • a reviewed revision
  • a published revision

These may be the same revision in simple workflows, but the model should not assume they always are.

This separation allows knowledge to evolve internally without destabilizing published content.

Publication scope

Publication should attach to a specific revision.

This means publication records should identify:

  • the document or fragment
  • the published revision
  • publication timestamp
  • publication actor or workflow
  • optional publication note or channel

Publication is about exposing a specific content state, not about exposing a mutable document in general.

Published state

The initial publication model should remain simple.

A document may exist in one or more of these practical states:

State Meaning
unpublished not currently published
published a specific revision is currently published
superseded a previously published revision has been replaced by a later published revision

This is sufficient for an initial controlled publication workflow.

Publication workflow

A typical publication lifecycle is:

  1. a revision is authored
  2. the revision may pass review
  3. a specific revision is selected for publication
  4. a publication record is created
  5. published output is rendered or exported from that revision

This keeps published state explicit and stable.

Publication records

A publication record should include metadata such as:

  • publication identifier
  • document or fragment identifier
  • revision identifier
  • publication timestamp
  • publisher or workflow identity
  • optional publication note
  • optional publication channel

Publication records should remain separate from revision records so that publishing history can be tracked independently.

Relationship to review

In most governed workflows, review should precede publication.

This means the common path is:

revision authored
        ↓
reviewed
        ↓
approved
        ↓
published

Simple environments may collapse these steps, but the architectural model should preserve the distinction.

Stable published output

Publication should produce stable output even if newer draft revisions already exist.

This means:

  • a document may continue evolving internally
  • published output remains tied to the selected published revision
  • new publication requires an explicit publication action

This is one of the main reasons publication must attach to revisions rather than to mutable current state.

Publication channels

Future versions of WEIC may support publication channels such as:

  • internal
  • public
  • draft-preview
  • compliance-package

These channels are not required in the initial model, but the publication model should allow them to be added later without redesigning the core concept.

Publication outputs

Published output may take several forms depending on workflow.

Examples include:

  • HTML publication
  • exported documentation bundles
  • PDF output
  • DOCX export
  • artifact bundles for downstream systems

Because HTML is the canonical source format, publication should derive output from the published HTML revision.

Fragments and publication

Fragments may also participate in publication workflows.

Possible approaches include:

  • fragments are published independently as managed reusable knowledge assets
  • fragments are published only through documents that include them
  • both, depending on use case

The important architectural point is that fragment publication should remain traceable and revision-based just like document publication.

Publication and evidence

Publication activity is part of the evidence chain.

Publication records can demonstrate:

  • what revision was exposed
  • when it was exposed
  • who or what published it
  • how published state changed over time

This supports auditability, compliance preparation, and operational traceability.

Design principles

The publication model follows several principles.

Publication attaches to revisions

Published output must identify a stable content state.

Publication is explicit

Knowledge should not become published accidentally through general editing.

Stable published state matters

Published output should remain stable until explicitly replaced.

Review and publication are separable

Governance and exposure are related but distinct concerns.

Publication history matters

Publishing decisions are part of the long-term knowledge record.

Relationship to the Oryvin plan

The publication model is one of the steps that connects governed knowledge to operational use.

authored knowledge
        ↓
reviewed revision
        ↓
published revision
        ↓
rendered output, export, and downstream consumption

This allows WEIC to serve as a reliable knowledge and publishing backend for the broader Oryvin ecosystem.