108: Concept/Visibility

For a system of evolving, interconnected Ideas to be useful, there must be a clear and predictable way to determine which version of an Idea is seen—or visible—in any given context. This document describes the two-part model that governs visibility: the versioning system that creates the possible states of an Idea, and the selection mechanism that chooses which state becomes visible.

Versioning: Creating the States to Be Seen

Before a version can be selected, it must exist. Hierarchical Versioning is the mechanism for creating and tracking the different states of an Idea over time. A version is not just a simple number but a rich, dot-separated hierarchy that tells the story of an Idea's evolution.

<<<<<<< Updated upstream Versions consist of integer revisions for sequential, public releases (like 1.2) and branched revisions for named development lines (like feature-x). For example, a version like 1.2.feature-x.3 tells us this is the third revision of a feature-x branch that was created from version 1.2.

Stashed changes

The rules for evolving a version are:

• Compatible Changes: A non-breaking edit where the new version can be safely used as a drop-in replacement for the old. Examples include changing the context or solution data, or adding a new field to the schema. Such changes create a new minor revision (e.g., 1.2 becomes 1.2.1).
• Breaking Changes: A change where the new version cannot be used as a substitute for the old. This typically involves removing or modifying existing fields in the schema. These changes must "bubble up" to a higher level of the version hierarchy (e.g., a change breaking compatibility with 1.2 would create 1.3). The system can automatically detect schema-based breaking changes.

Selection: Choosing the Visible State

With a rich history of versions available, a selection mechanism is needed to choose the correct one. This is handled by a clear separation between how an Idea is published and how it is retrieved. The process has two retrieval dimensions: spatial (which partitions to search) and temporal (as of what point in time).

Branches: Publication and Partitioning

For example, every Idea version in the database is associated with one or more branches like ["main", "feature/new-billing"]. This act of publication makes the Idea available within those specific partitions, enabling a safe workflow.

This provides two fundamental benefits:

• Isolation: Work on a new feature (e.g., on a feature/new-billing branch) doesn't interfere with the stable main branch. This prevents half-finished or buggy work from affecting production systems.
• Experimentation: Branches are cheap and easy to create. This encourages experimentation, allowing developers to discard a branch if an experiment doesn't work out, with no impact on the main system.

The Search Path: Prioritized Retrieval

This retrieval mechanism is core to the development workflow and answers the spatial question. For example, a developer's typical search path might be set to ['feature/my-new-idea', 'staging', 'main'].

This configuration creates a cascading overlay system for retrieval:

1. First, search for a matching Idea in the feature/my-new-idea partition.
2. If not found, search in the staging partition.
3. Finally, fall back to searching in the main partition.

This allows a developer to see a specific, intended reality composed of their local changes seamlessly layered on top of the stable system.

The Cutoff Time: Temporal Retrieval

The second dimension of retrieval is temporal. Every resolution query is performed against the state of the system as it existed at a specific moment. This is controlled by the Cutoff Time.

If a cutoff time is not provided, it defaults to the current time (now()), retrieving the most recent visible versions. However, by providing a timestamp from the past, you can perform a "time-traveling query." This instructs the resolver to find the version of an Idea—and all its dependencies—that was latest according to the search path at that exact moment. This capability is the technical foundation for perfect reproducibility.

From Model to Application

This chapter has defined the theoretical model for visibility—the mechanisms for creating different states and selecting between them. With this model in place, the final piece is the practical language for interacting with it.

The next document, 109: Concept/Addressing, introduces the idea: URI scheme, the concrete syntax used to request a specific view and navigate this rich, versioned, and branched reality.