VOLEs, Lists, and ARCs

The Primitive

The missing primitive is not task, not goal, and not project. It is a future-facing formation in consciousness. We have been calling that a VOLE.

A VOLE can be tiny or enormous. Get milk is one. I want to be rich is one. Egypt motorcycle tour is one. The difference is not whether they are future-facing. The difference is stage, charge, scope, and immanence.

The Continuum

The best recovered sequence so far is:

latent → forming → immanent → active → done/dormant

Latent is the right word for the below-ground phase. Not yet a plan, not yet a ticket, not yet even clean intention. Just real psychic material with directional pull.

Lists Are Not The Primitive

The current Lists work is valuable, but it is too flat to explain the life-cycle of meaningful future-facing material. Lists are better understood as views or durable named collections, not the root ontology.

That does not make lists fake. In product terms, named lists matter a lot. Users need stable handles like Grocery, Boat, Egypt prep, or Books to read. The key is to understand that these are surfaces over deeper material.

Not All Lists Behave The Same

A crucial distinction: not all lists are future-facing. favorite colors is a list, but it is not a VOLE. That means list behavior needs at least a few modes.

Action lists: can progress, stall, complete. Reference lists: collected sets, no completion semantics. Ordered lists: ranking matters. Sequence lists: order is temporal or procedural.

This matters because done should not be treated as a universal property of all list items. Some things complete. Some things are simply held, sorted, or revisited.

ARCs May Also Be Views

The current ARCs design frames them as higher-order temporal threads, which is right. But they may not need to be a primitive any more than lists do. ARCs can be emergent coherence views over VOLEs, their history, and the evidence linked to them.

That is cleaner than inventing another first-class root object too early. It also makes ARCs more honest: a way of seeing continuity, not a mandatory thing the user has to hand-author.

Identity Through Mutation

This is the hard part. A VOLE is not static. An Egypt trip might begin as a vague urge, then appear in chats, search queries, budget fragments, friend conversations, lodging ideas, flight browsing, and finally a booked ticket.

So the system needs lineage, not just objects. The same underlying future-vector can mutate through many expressions. New artifacts should usually attach to an existing VOLE, sometimes to several named lists, and only occasionally justify a brand-new named list or a fresh branch of lineage.

Keep It Base-Level Stupid

This only works if the rules stay light. The system should mostly do three things when new material appears:

attach to an existing VOLE, create a new VOLE, or ignore it.

That is enough to start. Complex split/merge logic can come later. The first victory is continuity, not ontological perfection.

MCP Changes The Economics

The user should not be expected to manually maintain a graph of future-directed life material. The good version is ambient. Journal entries, Claude conversations, searches, emails, calendar events, and later purchases or bookings can all feed the same substrate.

If Claude can see a user's VOLE field through MCP, much of the expensive noticing can happen on the user's dime instead of the app owner's. TameYeti becomes the substrate and renderer. Claude becomes the ambient sense-maker.

Proposed Direction

VOLE becomes the future-facing primitive. Lists remain real as durable named collections with behavior modes. ARCs become emergent higher-order views over continuity. Molecules may be simplified or deferred if tags, entities, linked artifacts, and VOLE lineage are enough to generate the useful views.

This is not a final spec. It is the first disciplined version of an older intuition: life is not a checkbox system, but some parts of it absolutely do need checkboxes. The model has to hold both truths at once.