EnRuSimple EnSimple Ru
Acts of Emergence

108: Concept/Visibility

Visibility

This is how the system decides which version of an Idea you should see at any given time. It's like asking for a book in a library that has many different editions and drafts; visibility rules figure out exactly which copy to hand you based on the Idea's history, where it's being worked on, and the order you've asked to search for it.

Imagine a world full of Ideas that are always growing and connecting to each other. For this to work without being a confusing mess, we need a clear way to know which version of an Idea we're looking at. This is called visibility. It's a two-part system:

  1. Versioning: This is how we create and keep track of all the different drafts and editions of an Idea.
  2. Selection: This is how we choose the right version to show you from all the ones that exist.

Versioning: Creating All the Different Versions

Before you can see a version, someone has to make it. We use a system called Hierarchical Versioning to track how an Idea changes. A version isn't just a simple number; it's like a family tree that tells the story of the Idea's life.

Versions have two parts: number updates for official public releases (like 1.2) and named updates for new experiments (like feature-x). For example, a version named 1.2.feature-x.3 tells you it's the third update on an experiment called feature-x, which started from the official version 1.2.

Versions have two parts: number updates for official public releases (like 1.2) and named updates for new experiments (like feature-x). For example, a version named 1.2.feature-x.3 tells you it's the third update on an experiment called feature-x, which started from the official version 1.2.

mainfeature-x1.11.21.2.feature-x.11.2.feature-x.21.2.feature-x.31.3

Here are the rules for changing an Idea's version:

  • Compatible Changes: These are small, safe edits, like fixing a typo or adding extra information. The new version works just like the old one. This kind of change adds a new number at the end (for example, 1.2 becomes 1.2.1).
  • Breaking Changes: These are big changes that make the new version incompatible with the old one, like completely changing how a part of it works. These changes require a bigger version jump (for example, a big change to 1.2 would create a new version 1.3).

Selection: Choosing Which Version to See

Now that we have all these different versions, we need a way to pick the right one. This is done by separating how an Idea is saved from how you ask for it. Think of it like a librarian finding a book for you. They need to know two things: where to look (which shelf) and when it was published (from what time period).

Branches: Different Shelves for Your Ideas

Branch

A branch is like a separate workspace or a different shelf in the library where you can work on things without messing up the main collection. Putting an Idea on a branch is like publishing it to that specific shelf.

For instance, every version of an Idea is tagged with the branches it belongs to, like ["main", "feature/new-billing"]. This makes the Idea visible only in those workspaces.

This gives us two big advantages:

  • Safety: You can work on a new feature (on a feature/new-billing branch) without affecting the stable, official main branch. This keeps messy, unfinished work away from everyone else.
  • Freedom to Experiment: It's super easy to create new branches. This lets you try out new things freely. If an experiment doesn't work, you can just delete the branch, and it's like it never happened.

The Search Path: The Order You Check the Shelves

Search Path

This is your personal set of instructions that tells the system which branches to look in and in what order. It's like telling the librarian, "First, check my personal desk, then check the 'New Arrivals' shelf, and finally, check the main library."

This answers the where question. For example, a developer's search path might look like ['feature/my-new-idea', 'staging', 'main'].

This tells the system how to find an Idea:

  1. First, look for it on the experimental feature/my-new-idea shelf.
  2. If it's not there, look on the staging shelf (where things are tested).
  3. If you still haven't found it, look on the official main shelf.

This lets you see your own in-progress work as if it were already part of the main system, without actually changing the main system for anyone else.

The Cutoff Time: Finding a Version from the Past

Cutoff Time

This is a timestamp you can add to your request. It tells the system to find the version of an Idea that was the latest at that exact moment in the past.

This answers the when question. It's like asking the librarian for the book as it existed last Tuesday. Every search you do is for a specific point in time.

If you don't give a cutoff time, the system just assumes you mean right now. But if you provide a timestamp from the past, you can do a "time-traveling search." The system will find the version of the Idea (and everything it depends on) that was considered the latest at that moment. This is super important because it means we can perfectly recreate how things were at any point in history.

From Rules to Reality

So far, we've talked about the rules for how visibility works — how different versions are made and how we choose between them. Now, we need a simple way to actually use these rules.

The next document, 109: Concept/Addressing, will show you the special kind of web address we use, called the idea: address, to ask for exactly the version you want to see.