Continuum: A Private Digital World Model

Suppose you decide to start a business. The goal may stay relevant for years and involve research, naming, registration, a website, banking, suppliers, customers, accounting, marketing, hiring and hundreds of smaller decisions that change as the business develops. Even with capable AI, most of that work still depends on you carrying the continuity between sessions and applications. You explain the business again, bring the right documents into the conversation, remember what was decided elsewhere, notice when circumstances change and work out what deserves attention next.

Continuum is being built for a different kind of relationship between software and a long-running goal. The goal can remain part of the user’s digital world while everything surrounding it develops over time, including the people involved, decisions already made, documents created, current blockers, available accounts, commitments, permissions and results of earlier work. AI can reason across that context and help determine what should happen next, while Continuum keeps the durable history and current understanding required to continue the work later without rebuilding the situation from the beginning.

As that model develops, it can support increasingly autonomous work within boundaries the user has already established. A goal such as starting and operating a business could lead to research, planning, preparation and permitted actions across many sessions. Continuum could observe the results of that work, update Current State as circumstances change and continue from the newer situation, while Authority still determines which consequential actions are allowed, which require approval and which can operate under standing rules created ahead of time.

That kind of continuity is difficult because digital life is still fragmented across applications. A person can have years of messages in Gmail, files spread across cloud storage and local devices, work scattered between project tools, family information buried in text threads, decisions living inside old conversations, and increasingly, useful context sitting inside conversations with AI systems. Each product may work well within its own boundaries, yet the person using all of them is still usually responsible for remembering how the pieces connect, which information is current, what changed recently and why something that happened in one application matters somewhere else.

That fragmentation was manageable when software mostly stored information and waited for people to operate it. You learned where things lived and carried the relationships between them in your own head. You remembered that the PDF somebody sent on Tuesday belonged to the project discussed in another application, that the person in a calendar invite was the same person saved under a slightly different name in your contacts, and that a decision made months earlier explained why a task was still being handled a certain way. The software kept the records, while much of the meaning between those records stayed with you.

AI changes the importance of that gap because models can already do useful work once they have enough context. They can summarize complicated material, compare documents, draft communication, identify contradictions, research unresolved questions and help reason through decisions, but those capabilities depend heavily on what surrounds the model. Useful AI needs access to the right information, and that information has to remain understandable after the conversation is over. It matters whether something is current or outdated, whether it was stated directly or inferred, whether two records refer to the same person, whether a document has changed since an earlier action used it, and whether the person or software requesting an action is actually allowed to perform it.

Simply storing more conversations doesn’t solve that problem, and neither does giving a model a larger context window. If information is going to remain useful over months or years, the surrounding product needs to understand what that information refers to, how it relates to other parts of someone’s life or work, where it came from, what changed after it was recorded and how much confidence should be placed in it. Once software is capable of taking action, the same product also needs a durable way to determine what’s permitted, what happened, what failed to happen and why.

Continuum is CMX’s work on that layer. It’s being built as a private digital world model for a person, family or team, where important information can keep its identity, relationships, history and permissions as the applications and AI models connected to it change. The goal is to create enough durable structure that people, projects, files, commitments, decisions, current conditions, connected services and future AI reasoning can contribute to one coherent world without becoming trapped inside whichever application happened to encounter them first.

Organizing information around the things it actually describes

Most software organizes information around the application that stores it. Email is structured around messages, file managers around files, project platforms around tasks and projects, and CRMs around contacts. Those structures make sense inside each product, but real life rarely follows the same boundaries, which is why people end up mentally connecting information that software continues to treat as separate.

A house renovation is a simple example. The contractor may appear in contacts, email threads, invoices and calendar events, while estimates arrive as several versions of a PDF, a permit affects the schedule, a material choice changes the budget and a conversation with a partner settles a decision that later affects the contractor. Some information about the renovation may be shared, while private notes about the same project belong only to one person. None of those records is truly independent, even though traditional software may store each one according to the application that received it.

Continuum gives that underlying world more durable structure. A contractor can have a stable Person identity, the house can be represented as a Place, the renovation can remain one Project, and estimates or notes can live in Library while still connecting back to the same project. A Space can provide the context appropriate to a household, business or other group while respecting information that belongs only to an individual.

This prevents every interface from creating its own version of reality. A Person can appear in several Spaces and projects without becoming several unrelated people, a Library item can be relevant to more than one area while retaining one identity and one version history, and a Project can appear in a Brief, search result, Check In view or future AI conversation while continuing to refer to the same underlying Project.

Continuum uses different domains because different kinds of information need different behavior. Directory deals with people and identity, Spaces organize context, Library handles authored and imported content, Projects represent work that changes over time, and Connections represent outside services and accounts. Goals, Decisions, Commitments and other parts of the Personal World Model can add more structure as those concepts become useful in the product, but the value comes from how those domains connect to one another instead of existing as isolated features.

A document may belong to a project, a person may have a role in that project, a decision may change part of the plan, and a later message may change the current situation again. Once those relationships exist in a durable form, Continuum has something more useful than a collection of searchable records because it can begin to understand how information contributes to the same underlying world.

Natural language becomes more useful on top of that structure because people rarely speak in database terms. Someone will say “my accountant,” “the contractor,” “the London project,” “home,” or “that estimate from last week,” and Continuum can use context and evidence to connect those expressions to stable subjects when the relationship is sufficiently clear. When it isn’t clear, the product can preserve that uncertainty instead of forcing a confident answer and creating a false connection that later becomes difficult to unwind.

A useful world model should become more accurate as evidence improves. It shouldn’t need to pretend it understood every ambiguous reference correctly the first time.

Remembering history without confusing it with the present

A durable digital world needs memory, but useful memory involves more than keeping old information. It has to preserve history while still allowing the product to distinguish what happened before from what appears to be true now.

If a permit is pending on Monday and approved on Wednesday, both facts matter because they describe different points in the project’s history, while only one describes the current situation on Wednesday. If the project was delayed on Tuesday because the permit was still pending, the earlier State remains important when somebody later wants to understand why the delay happened.

The same problem appears in documents. An estimate may change several times while remaining recognizably the same estimate, a project plan may be edited for months, and a set of instructions may evolve while an automation running last week relied on an older version. Keeping only the newest text would make it much harder to reconstruct what earlier work actually used or what information was available at the time.

Continuum’s Library model gives content a durable identity while allowing important states to become immutable versions. Editable work can continue, while a specific ContentVersion can remain fixed once another part of the product depends on it. If an Automation ran using version three and versions four and five were created later, the historical Run can still point to version three instead of silently inheriting whatever exists today.

That distinction becomes increasingly important as AI and automation participate in real work because later explanations need to separate current information from the information available when an earlier decision or action occurred. Provenance adds another part of that history by preserving where important information came from, whether that was a document, connected service, direct user statement, email, API or another approved source.

Those origins matter when new evidence appears. If a contractor sends one schedule and later sends a revised schedule, Continuum should be able to preserve the relationship between them. If two sources disagree, the disagreement can remain visible until stronger evidence resolves it. If an old decision exists without a recorded explanation, the product shouldn’t invent a plausible reason months later simply because a language model can produce one.

This is one of the boundaries between durable product memory and generated language. A model may be capable of producing a coherent explanation from incomplete information, while Continuum needs enough structure around the underlying records to determine whether that explanation is actually supported by the available history.

Current State is part of that structure because it represents Continuum’s best supported understanding of something now while allowing earlier State to remain part of the record. Over time, that makes it possible to explain how a situation changed and which evidence contributed to the newer understanding instead of treating the latest value as though nothing existed before it.

The same discipline can eventually apply to less formal parts of someone’s world. Working late for several weeks during a launch may establish a recent behavior pattern without proving a permanent preference for late-night work, just as saying you may travel next month isn’t the same as having a confirmed trip. A tentative goal isn’t automatically a commitment, and something observed by Continuum shouldn’t carry the same meaning as something a user explicitly stated unless the evidence supports that interpretation.

Those distinctions become more important as software begins using accumulated context to make recommendations or prepare actions. The Personal World Model becomes more useful when it can represent uncertainty, different levels of confidence and changes over time instead of gradually flattening everything into one profile that looks certain simply because it has accumulated a lot of information.

Understanding what actually changed

Most software is good at recording activity and notifying people when something happens, whether that’s a new email, an updated task, a document being uploaded or a meeting moving on the calendar. As more services become connected, those notifications accumulate quickly, but they still leave the person to work out which events actually matter and whether anything in the wider situation has changed because of them.

Continuum is more interested in the meaning of those changes. An email may matter because a project is no longer waiting for a customer, a revised document may matter because an assumption behind a plan is now wrong, a completed approval may remove a blocker, and a failed service connection may affect several automations that depend on it. In each case, the useful information goes beyond the fact that another event occurred.

That creates a different product problem because Continuum needs enough understanding of the relationships around an event to determine whether the state of the wider world changed with it. Current State provides part of that foundation, and as more domains become connected to it, the product can become better at answering questions about what changed since somebody last checked, which projects became blocked or unblocked, which assumptions may now be stale, which commitments require attention and where the available information is still uncertain.

That same foundation can support surfaces such as Briefs and Check In without giving each interface its own competing memory store. A morning Brief may surface only a few meaningful changes, while Check In can give the user a simple way to add current context or correct something Continuum doesn’t understand. A project view can focus on the people, Library content, State and decisions relevant to that project, while future AI conversations can draw from the same underlying model when broader questions are asked.

The value comes from continuity across those experiences. If a person corrects something in one part of Continuum, another part shouldn’t continue working from an unrelated copy. If a project changes, a future Brief should be able to understand that change without maintaining a separate version of the project. If an AI conversation establishes something worth retaining, that information should be able to enter the wider model with appropriate provenance instead of disappearing when the chat ends.

Keeping a goal active over time

Goals become more useful when they remain connected to the world that affects them instead of existing as static entries on a list. A goal such as launching a business, moving to another country, completing a qualification or buying a home may stay active for months or years while the people, information, constraints and decisions surrounding it continue to change.

Continuum can use a Goal as durable context for that longer process. Projects may contribute work toward it, Decisions can record choices that shaped the path, Commitments can represent obligations that need to be honored, Library content can preserve research and plans, and Current State can show which parts of the situation have changed since the goal was created. AI can reason across those records to help determine what deserves attention next without treating every conversation as a fresh planning exercise.

As more execution capabilities become available, the same structure can support a continuing loop between understanding and action. Continuum can use the current situation and the user’s existing direction to identify possible next steps, prepare work or perform actions that are already permitted, retain the resulting receipts and update its understanding when the outside world changes as a result. The next decision can then begin from the newer State instead of from the assumptions that existed before the work happened.

That doesn’t require giving an AI unrestricted control over the goal. A user may allow research, organization or drafting to continue freely while requiring approval for spending money, sending external communication, changing an account or making another consequential commitment. A different goal may have standing rules that permit more work to happen automatically. The useful form of autonomy comes from continuing toward an objective while remaining inside the permissions and constraints that apply to the person and situation.

This is also why Goals need to remain part of the wider Personal World Model. A business goal may depend on financial limits, people, deadlines, previous decisions and connected services, while a personal goal may overlap with family, travel or health-related context that carries different privacy requirements. Continuum can keep the goal connected to relevant information without assuming that every piece of the user’s world belongs in every decision made in pursuit of it.

Allowing software to act without losing control of the boundary

Once a product understands more of someone’s world, the ability to act becomes more useful and more sensitive at the same time. A system that can identify a project, locate the right document, understand the current situation and access a connected email account may also be capable of preparing or sending a message, which creates a need for clear boundaries between what is technically possible and what has actually been authorized.

Continuum separates those concerns through Connections, Authority, Automations and Runtime. Connections represent outside services and the capabilities available through them, allowing an email provider, calendar, storage platform or another service to expose very different technical interfaces while Continuum represents the useful operations in a more consistent way.

Connecting a service establishes capability, but permission to use that capability still depends on the context and the requested consequence. An account might allow Continuum to read certain information while requiring approval before anything is sent, while an Automation may be permitted to operate within standing rules the owner created earlier. Another action may need fresh approval because it creates a larger consequence. The same connected service can therefore support different levels of activity without one successful connection becoming blanket permission to do everything the service technically allows.

Authority is responsible for determining whether a consequential action is permitted in the context where it has been requested, while Runtime handles work that has passed the appropriate checks and maintains the execution history around it. Automations provide versioned definitions for work that may continue beyond a single interaction, allowing a Run to remain connected to the exact AutomationVersion, ContentVersion and other relevant records that existed when the work happened.

That history also needs to account for situations where work didn’t happen. A provider may temporarily fail, an approval may expire, a Connection may become unavailable, an intended recipient may be ambiguous or a rule may prevent an action from continuing. In each case, the absence of an external consequence can still be meaningful, especially when someone later wants to know why an email was never sent or why an automation stopped.

Continuum is being designed so those outcomes remain inspectable through the Authority and Runtime history instead of requiring somebody to reconstruct the explanation manually. This becomes increasingly important as AI reasoning improves because better reasoning may allow Continuum to identify more useful actions, prepare better work and make stronger recommendations without silently increasing the authority available to the model.

Continuity policies can eventually support circumstances where someone has already established what should happen while they’re unavailable, but those policies need to exist before the situation arises and remain constrained by the authority that was deliberately granted. A missed response or period of silence can’t become an accidental approval mechanism.

Using AI without making the model the permanent home of your world

AI is an important part of Continuum because models are useful at turning context into understanding and useful work. They can summarize projects, compare choices, identify contradictions, research unresolved questions, draft communication and help reason through decisions, while Continuum keeps the longer-lived structure around that work.

The durable information lives in Continuum’s own model, where people retain their identities, Projects retain their history, Library content retains its versions, State can change over time and permissions or execution history remain connected to the relevant records. When AI needs context, Continuum can assemble the information appropriate to the request and provide it to a suitable model without requiring the entire Personal World Model to live inside that provider’s memory.

That gives the product flexibility as the model landscape changes. Cloud models may be appropriate for some work, while open-weight or self-hosted models may make sense elsewhere, and future local inference could provide another option when privacy, cost or latency matters more than access to the largest available model. Different providers will continue developing different strengths, and Continuum can make those choices at the reasoning layer while preserving the user’s longer-lived context outside the individual model session.

The same principle guides the long-term approach to integrations. Personal email is one example because users should be able to connect their own providers through explicit consent, select the identity a permitted action sends from and revoke that access when needed. Gmail, Microsoft 365, SMTP, IMAP and future providers can fit into the integration layer without forcing someone’s long-term identity, correspondence history or Personal World Model to depend permanently on a single provider, while Continuum-managed addresses can remain reserved for service communication from the product itself.

The broader architectural direction is toward portable user memory with selective access. A person should be able to control which parts of their world are available to a particular model, application, Space or other person, and that access should remain revocable. Provenance and version history should continue to make sense as information moves between tools or models, while recovery, key rotation, device loss and long-term portability become increasingly important once the accumulated information represents years of someone’s life or work.

Those concerns are easier to account for when they’re part of the architecture early instead of being treated as cleanup work after a particular provider has already become inseparable from the product.

Privacy becomes more complicated when everything is connected

Connecting information produces useful context, but it also creates more opportunities for information to cross boundaries accidentally. A project may be shared while some information about that project belongs only to one person, and a Person may exist in Directory and appear in several Spaces while different information about them is appropriate in each context. A private note may contribute to the owner’s understanding without belonging in a family Brief, while an AI model may need only a small amount of information to answer a question without requiring access to the entire Personal World Model.

Continuum therefore has to treat privacy as a property of information use as well as account access. The existence of a relationship in the graph doesn’t mean every connected record should become visible everywhere that relationship appears. Spaces can provide contextual boundaries, Authority can control consequential action, provider access can remain scoped, and personal information can stay outside shared experiences when the purpose doesn’t require it.

Derived information requires the same care because a summary, embedding, search index or inferred State created from private material shouldn’t become unrestricted simply because software generated it. The privacy characteristics of the underlying source need to continue influencing how the derived information can be used.

Purpose matters for the same reason. A model answering a question about a project may need project documents and recent State, while unrelated family, financial or other personal information may have no legitimate role in that request even if Continuum has access to those domains elsewhere. A richer world model creates more opportunities to provide useful context, but it also makes least-privilege access more important.

As the world model becomes deeper, inspectability matters more too. Users need ways to understand what Continuum knows, where important information came from, what has been inferred, what remains uncertain, what has been shared with connected services and what significant actions were carried out. The person represented by the model also needs the ability to correct it, because a durable model that can’t accept correction would eventually turn old assumptions into permanent product behavior.

What Continuum has actually built

Continuum is a long-term architecture being implemented in stages, so CMX separates design, source implementation, integration, executable validation, production availability and production proof when describing progress. That distinction matters because a detailed architecture diagram doesn’t make a feature live, code existing in a repository doesn’t necessarily mean it has passed the real path users depend on, and tests that prove an implementation behaves correctly under defined conditions are still different from proof through the deployed production environment.

The first complete Continuum Working Loop reached Production Proven and established a real baseline across protected identity, Library content, Automations, Authority-related boundaries, Runtime, receipts and the surrounding security behavior. That work demonstrated that the architecture could operate as a connected loop instead of existing only in documentation.

Library has working foundations for text and Markdown content, durable identity, version history and search, while Current State has entered production with connection.health as its first State kind. Check In is live as an account-facing surface where users can return to Continuum and interact with current context, and work on the broader account experience continues to bring these foundations into more normal product flows.

Other parts of the wider model remain at different maturity levels. Spaces represents an important part of the intended account experience, while the broader Personal World Model extends well beyond what’s currently exposed in production. Deeper learning and memory, richer relationship modeling, broader Goals, Decisions, Commitments, Places, Things and additional forms of State are part of the architecture without being presented as though every part already exists as a finished user-facing feature.

CMX uses the documentation layer for the exact contracts, implementation details and maturity evidence behind that work, while this article has a different job: explaining the product those pieces are gradually becoming. Keeping those roles separate allows the public product story to remain understandable without forcing somebody to read backend contracts, while the technical documentation can remain precise enough that architecture and implementation don’t quietly drift apart.

Where the Personal World Model can go

As more of Continuum becomes connected, the Personal World Model can become useful in ways that individual applications struggle to provide. Directory can develop a richer understanding of the people, relationships and roles that matter to someone, while Projects retain the history behind changing work and Goals provide longer-term context for current decisions. Commitments can remain visible across the places where they were created, Decisions and Assumptions can retain enough history to explain why a project took a particular direction, and Places or Things can give physical parts of life durable identities when that context becomes useful.

Learning and memory can build on the same provenance and State foundations without treating every observation as a permanent truth. Repeated behavior may establish a pattern without immediately becoming a preference, direct statements can carry different weight from inference, corrections can update the current model while preserving enough history to understand what changed, and conflicting evidence can remain unresolved until enough information exists to support a stronger conclusion.

That approach gives Continuum room to become more useful without requiring it to become falsely certain. Over time, a person returning after several days should be able to understand what materially changed across the parts of life and work they chose to connect, including which projects moved, where something became blocked, what now needs a decision, which commitments are approaching, where an assumption may be stale and what information Continuum still doesn’t understand well enough.

The same world can support AI conversations without every conversation rebuilding context from the beginning, while Automations can work against records with durable identity and history, Briefs can surface meaningful changes instead of simply collecting notifications, and shared experiences can operate against common Projects and Spaces while preserving personal boundaries.

Continuum will continue changing as those capabilities move from architecture into ordinary product use. Interfaces will be redesigned, AI providers will improve, integrations will come and go, and new kinds of information will become useful enough to deserve their own structure. The longer-term challenge is making sure those changes don’t destroy the continuity underneath them.

That continuity depends on preserving identity when the same person appears in several places, history when content changes, provenance when information moves between sources, uncertainty when the evidence is incomplete, privacy when contexts overlap and the authority boundary when software becomes capable of doing more. Those concerns are often handled separately across different products, but they become increasingly difficult to separate once AI is expected to understand and work across more of a person’s real digital life.

CMX is building that foundation gradually, proving the parts that exist while keeping the larger architecture visible enough that each new part has somewhere coherent to belong.