💥 The Manifesto 💥

Imagine you’re creating an important document — whether it’s an instruction manual, a concept for a new system, or a commercial proposal. You send it to another person, they make edits, and then you open the document again and feel completely lost: what remains of your original ideas, and what has been rewritten? The change history or “track changes” mode partially solves this problem within a single file or article, but what if there are multiple documents?

Typically, information is stored across scattered documents and sources: email, messengers, wiki systems, task trackers. In such a situation, it’s impossible to determine the latest, most accurate state of information on a specific topic. Information often becomes outdated, duplicated, contradictory, and written in such a way that after six months it’s hard to understand what the author originally meant. When you try to update such information, it feels hopeless.

Large language models such as ChatGPT, Claude AI, and similar systems could automate the process of searching and enriching content. But if the information is fragmented, full of contradictions, and duplicated, an LLM will only get confused and produce inaccurate or meaningless responses.

As a result, collaborative work on documents — and on information in general — turns into chaos: you’re unsure about authorship or accuracy, it’s hard to track the history of edits, and innovations (such as AI integration) stall if the source data is inconsistent or scattered across dozens or hundreds of outdated files.

This is a problem everyone faces who has ever tried to manage shared projects, build internal knowledge bases, or simply figure out “which file version is actually final.”

Two Worlds

When observing how humanity works with text-based information, it becomes clear that there are two worlds:

  1. Developers, for whom text is primarily code, configurations, and technical documentation — they are used to strict processes like version control, code reviews, and automation.

  2. A broader audience, for whom text means articles, business documents, emails, social media posts, and reports.

In development, text (source code) is seen as a fundamental resource rather than a mere communication tool. Work around it is built on strict storage, versioning, and automation rules:

  • At the core of this culture is version control, such as Git, which allows every change to be tracked and reverted if necessary.

  • Code review runs in parallel: before an edit is merged into the main version, it’s carefully reviewed by others for correctness, style, and potential impact on the rest of the project.

  • Automated testing, formatting checks, and code consistency validation free developers to focus on creative problem-solving.

Outside of development, classic office tools dominate, where text documents are created and circulated in a far freer format. Most people rely on tools like Microsoft Word, Google Docs, Notion, or Obsidian.

Texts are published across multiple channels simultaneously — from corporate portals and social networks to CMS systems and office applications. Some write in Google Docs, others in DOCX files, and others only in email or messengers. This fragmentation complicates information management: if a document is updated in one place, it may remain outdated elsewhere.

Instead of strict version control and automation (standard in development), we often see ad-hoc draft documents that become obsolete the next day. The edit history is limited to “Track Changes” or email archives with file suffixes like “v3_final.”

As a result, in the non-developer world, text management remains a patchwork of tools and habits suited for short-term tasks but hardly forming a coherent system. Yet, more and more people realize that having a unified space with edit history makes life simpler.

This trend could bridge the two worlds and bring people clearer, more reliable information processes through a single source of truth.

The Single Source of Truth

A single source of truth is a common idea in technical documentation, project management, data architecture, and other fields. If you’ve ever tried to build one as a knowledge base within an organization, you’ve likely hit several limitations.

Barriers to Adding Information

  • It’s faster and easier to jot something down in a messenger or notes than to follow a link and find where to write it “properly.”

  • It’s unclear who edited the content or whether you’re allowed to edit it.

  • Making one change often requires updating several other places, which takes time you don’t have.

  • There’s no notification system when changes are made or proposed.

  • A clunky interface and too many text-formatting tools distract from the essence of the information.

Barriers to Distributing and Finding Information via a Knowledge Base

  • Documents often contain too much information, and you have to read them painfully in full.

  • When sharing a document with others, you realize it’s outdated — easier to summarize the current state from memory or others’ words.

  • Search in most knowledge bases is primitive — you can only find something if you know exact phrases or where the document is stored. It’s often simpler just to ask someone.

  • Even if you do find something, it’s likely outdated. Again, easier to ask someone who knows.

Principles of a Single Source of Truth

From this, we can define the core principles a single source of truth must uphold:

  • Quick access to information. Extracting and updating information should be fast, intelligent, and precise.

  • Ease of contribution. Adding and sharing information should be as easy as sending a message in a chat.

  • No duplication, contradictions, or other issues. When new content is added, it should go through automated and human checks — for duplication, consistency, and style.

In software development, the source code is the ultimate single source of truth because it defines how the program works. For organizations, the single source of truth should play the same role — a fundamental resource for decision-making. The information should be consistent, up-to-date, accessible, and uniformly written. It should be in constant use, just like code: if a function isn’t used, you can’t know for sure if it works correctly. Similarly, changes should go through review, automatic checks, and delivery to end users.

When people always have complete, reliable, and current information for decision-making, productivity rises — driving both technological progress and business outcomes. Much time today is wasted searching for the latest data, tracing causes, and worrying whether a change will break something else.

Practices for Maintaining a Single Source of Truth

Unified storage space. The first step toward knowledge management is creating a centralized repository where all organizational information resides. It should track the history of changes (for single documents and groups), provide fast access, and allow flexible access control.

Inbox. If it’s simple to add information to the system, the overall accuracy of the knowledge base greatly improves. When someone asks a question in a messenger, you can either take time to add the answer properly to the knowledge base — or save it temporarily in an inbox. From there, it can later be moved to the main source manually or by an LLM. The LLM can find where the information belongs and create a merge request for you to review.

Merge Request. No information should be added or changed without prior review. The merge request concept from software development introduces collaborative quality control. Every edit or new document goes through approval to ensure quality and compliance. However, the review process must remain lightweight — otherwise, it undermines the principle of ease of contribution.

Style checks. Texts in the single source should look professional, be easy to read, and follow uniform standards. Readers should grasp the meaning at first glance, and not struggle when moving between documents written in wildly different styles. Grammar mistakes, bureaucratic jargon, and clutter should be eliminated.

Content typing. As the single source grows, there’s a need for content reuse across documents, categorization for structure and faster search, and metadata (e.g., creation date). Typing documents and document blocks enables dynamic views and documents — for instance, showing courier instructions not updated for over a year.

Gramax — A Tool for Building the Single Source

To uphold these principles and apply them in real life, automation is essential. Without it, maintaining a single source would require a team of high-level experts covering all areas of the organization.

Gramax was created to help people collect, share, and maintain information in an up-to-date state.

Gramax Principles

  • Free forever. All features for working with the single source of truth will always be available for free — so that not only enterprises but also students, teachers, and professionals can benefit.

  • Spirit of collaboration. The computer industry has thrived over the past 200 years thanks to cooperation among developers. The Gramax team welcomes contributions and improvements. Its code is open for study, reuse, sharing, and modification.

  • Knowledge ownership. All information in Gramax is stored locally in simple files that can be opened in any text editor. Even if Gramax ceases to exist, the data remains accessible and usable.

  • External minimalism. Text work comes first. Nothing should distract the user. Gramax’s interface is simple as a hammer — but allows deep functionality when needed.

  • Modular integrity. Gramax includes all tools needed for managing the single source without switching to other apps. All modules are uniform and seamlessly connected.

  • Focus on change. The hardest part of any system is making updates. Gramax simplifies this through visual diff highlighting, intelligent search for relevant sections, and automation of the change process.