Skip to content

Review Model

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

The review model describes how document and fragment revisions can move through a governance step before becoming approved or ready for controlled publication. It provides a framework for content validation, accountability, and traceability.

The review model builds on the revision-first design of WEIC. Reviews attach to revisions because revisions are the stable units of content state.

Purpose

The review model exists to support several goals:

  • provide a formal review step for important knowledge changes
  • support governance and accountability
  • make approval decisions traceable
  • separate authoring from review
  • establish a foundation for publication controls

This is especially important for policy, compliance, architecture, and operational knowledge.

Review-first governance principle

WEIC does not require every change to be published immediately after authoring.

Instead, a revision may move through a review process before it is treated as approved content.

This allows the platform to support workflows such as:

  • draft authoring
  • peer review
  • editorial review
  • governance approval
  • publication readiness

The exact workflow may vary by document type, but the review layer should remain explicit.

Review scope

Reviews should attach to a specific revision.

This means a review record should identify:

  • the reviewed revision
  • the review status
  • the reviewer
  • the review timestamp
  • optional comments or notes

Attaching review to revisions rather than to mutable documents preserves traceability of what was actually reviewed.

Review statuses

The initial review model should remain simple.

Typical statuses include:

Status Meaning
pending revision exists but has not yet been reviewed
in_review review is currently underway
approved revision has passed review
rejected revision did not pass review
superseded revision was overtaken by a later revision before approval

These statuses provide a manageable foundation for future governance workflows.

Review workflow

A typical review lifecycle is:

  1. a new revision is created
  2. the revision enters pending review state
  3. a reviewer examines the revision
  4. the revision is approved or rejected
  5. publication or current-state rules react to the review result

This lifecycle keeps review decisions explicit and traceable.

Review records

A review record should include structured metadata such as:

  • review identifier
  • revision identifier
  • review status
  • reviewer
  • created timestamp
  • resolved timestamp, where applicable
  • review comments or notes

The exact schema may evolve, but review should remain its own first-class concept rather than a loose comment on a document.

Separation of author and reviewer

Where governance requires it, the model should support separation between the person who authored a revision and the person who approved it.

This supports:

  • accountability
  • independence of review
  • stronger governance controls
  • better auditability

Not every deployment of WEIC will require strict separation, but the model should be able to support it.

Relationship to revisions

The review model depends on the revision model.

Key rule:

  • a review is about a specific revision state

This means later edits should create new revisions rather than changing the reviewed content in place.

If a reviewed revision needs adjustment, the safest model is:

reviewed revision
        ↓
new corrected revision
        ↓
new review cycle

This preserves the history of both content and governance decisions.

Review outcomes and current state

Approval does not have to mean immediate current-state activation in every workflow, but the relationship should be explicit.

Possible models include:

  • current revision may be approved automatically for simple workflows
  • current revision may require approval before it becomes published
  • publication may require a distinct publication step after approval

The important architectural rule is that review outcome and content state should not be ambiguous.

Review notes and rationale

A review may include notes such as:

  • approved for publication
  • rejected due to factual error
  • requires architecture clarification
  • approved with editorial corrections in next revision

These notes provide context for governance decisions and support later audit or operational review.

Fragments and review

Fragments may also require review because reusable content can affect multiple documents.

The same general rules should apply:

  • reviews attach to fragment revisions
  • approvals and rejections are traceable
  • fragment governance may be even more important than single-document governance because of wider impact

This keeps reusable content from becoming an unmanaged blind spot.

Design principles

The review model follows several principles.

Review attaches to stable content

Reviews should identify the exact revision being reviewed.

Governance is explicit

Approval and rejection should be recorded, not implied.

Separation is supportable

The model should support independent review where required.

Revisions remain immutable

Reviewed content should not be silently altered after review.

Review history matters

Governance decisions are part of the knowledge record.

Relationship to the Oryvin plan

Traceable review is one of the mechanisms that turns WEIC into a governed knowledge platform.

authored revision
        ↓
review and approval decision
        ↓
controlled current state and publication

This supports the original compliance and evidence goals that motivated EIC while extending them into broader engineering governance.