No internet connection
  1. Home
  2. LOGOS
  3. REQUIREMENTS

Event-sourced editing with full revision history

By @IvanTheGeek
    2026-03-01 17:14:15.721Z2026-03-01 17:20:37.430Z

    Every edit to any content in LOGOS — wiki posts, discussion posts,
    problems, ideas, questions — is an immutable event. The full history
    of every piece of content is visible, diffable, and revertable by
    any user.

    Why It's Needed

    Talkyard tracks revision numbers internally but exposes no history
    UI of any kind. Once a post is edited, the previous content is gone
    from the user's perspective. This applies to all content types —
    not just wikis. The refinement of a requirement, the evolution of a
    design decision, the correction of a limitation description — none
    of it is traceable after the fact.

    This was experienced directly: a requirement topic was refined from
    a simpler model to a richer one during discussion. The reasoning
    behind that refinement exists only in the AI conversation where it
    happened — not in the topic itself. With edit history, the evolution
    would be part of the record.

    The Requirement

    Every save of any post or topic is an immutable timestamped event
    with author, timestamp, and full content snapshot. Nothing is
    overwritten. Current state is always a projection from the edit
    history. Any user can:

    • View the full edit history of any post
    • Compare any two revisions
    • See who changed what and when
    • Revert to any previous state

    This applies uniformly across all content types — wiki, discussion,
    problem, idea, question, and any custom type.

    Time Travel

    Because current state is always a projection from events, a user
    can navigate to any point in the history of a topic and see exactly
    what it looked like at that moment. Not just a diff — the full
    reconstructed state at that point in time.

    This is the same capability GIT provides for code: step through
    each commit, see the full state at each point, understand not just
    what changed but the sequence of changes that produced the current
    state. Applied to knowledge and requirements, it means the evolution
    of understanding is fully traceable — not just the destination but
    the journey.

    This capability is a natural consequence of the storage model, not
    a bolted-on feature. See: LOGOS Requirements — Event-sourced storage
    as the foundation.

    Acceptance

    A user edits a post. Another user opens the history view and sees
    both the original and the edited version, with a diff, timestamp,
    and author. A third revision is made. All three are visible and
    individually selectable. Selecting any revision shows the full
    reconstructed content at that point — not just the diff. Revert to
    revision 1 restores that content as a new revision event — the
    revert itself is part of the history.

    Sources

    • 0 replies