Representing Unresolved Work as Revisable Continuity State

This paper proposes a product-oriented computational framework for Vortyx. It is not a peer-reviewed research publication, does not report experimental results, and does not claim that the current Vortyx product implements every formalism discussed here.

The paper describes:

• a conceptual framework for unresolved work
• the theoretical traditions that inform that framework
• practical Vortyx primitives that already align with it
• open design questions for future formalization and evaluation

Most productivity software represents work as tasks, reminders, messages, or calendar events. That representation is useful, but incomplete.

In communication-heavy work, the important unit is often not a task that someone remembered to enter. It is an unresolved obligation or expectation distributed across people, evidence, tools, and time.

Someone may owe a reply. A user may be waiting on approval. A recurring responsibility may be slipping. A promised document may not arrive. A follow-up may become relevant only because an expected transition did not occur.

This paper argues that unresolved work should be represented as revisable continuity state rather than merely extracted tasks.

The central proposition is:

A continuity system should not treat every extracted action as a fact.
It should treat unresolved work as a reviewable hypothesis supported by
evidence, timing, lifecycle state, and user correction.

Vortyx's architecture and product direction are guided by this principle.

That proposition leads to a framework built on three foundations:

• Social commitments: unresolved work often represents obligations between participants.
• Partial observation: the system rarely sees the complete world.
• Temporal lifecycle reasoning: obligations become active, stale, satisfied, contradicted, reopened, or dismissed over time.

A task list stores work that has already been recognized and entered.

Unresolved work often appears earlier and less cleanly:

"I'll send the revised contract after legal approves it."
"Can you follow up with the client next week?"
"Waiting on Priya to confirm the budget."
"Let's review invoices every Friday."
"I sent the proposal. If they do not reply by Thursday, ping them."

These examples are not just task titles. They include actors, expected outcomes, timing constraints, dependencies, conditions, and uncertainty.

Some are user-owned actions. Some are external waits. Some are conditional commitments. Some are recurring responsibilities. Some are only soft intent and should not become tracked work unless confirmed.

The problem is therefore not only:

Can an AI extract a task-like sentence?

The harder problem is:

Can the system preserve what remains unresolved, update it as evidence arrives,
and resurface it when follow-through may be at risk?

That is the continuity problem.

This paper uses continuity loop to mean a unit of unresolved work that may persist across messages, tools, elapsed time, and user correction.

A continuity loop is not necessarily a task. It can represent:

• a user-owned commitment
• a waiting item
• a delegated request
• a recurring responsibility
• a blocked dependency
• a follow-up opportunity
• a reviewable candidate that may or may not become tracked work

A minimal conceptual representation is:

Where:

• A = actors involved
• O = obligation specification, expected outcome, or tracked expectation
• E = evidence history
• T = temporal constraints and checkpoints
• D = dependencies
• S = lifecycle state
• H = interpretation or hypothesis state

H is intentionally not called a formal belief distribution. In a future formal model, it could become a calibrated belief state. In the current framework, it means the system's working interpretation: category, confidence indicators, ambiguities, supporting evidence, contradictions, and review status.

The loop changes over time:

Where:

• L_t is the previous loop state
• e_t is newly observed evidence
• u_t is user feedback or correction
• τ is elapsed time or a temporal checkpoint
• F is the state-transition procedure

This transition function may be implemented by rules, learned classifiers, LLM-based interpretation, deterministic lifecycle checks, user actions, or a combination of those mechanisms.

The important point is not the specific implementation technique. The important point is that unresolved work has state, and that state must remain revisable.

In multi-agent systems, social commitments provide a formal way to model obligations between participants [1].

A common commitment form is:

Conceptually:

If the antecedent holds, the debtor is committed to the creditor
to bring about the consequent.

For example:

"I'll send the deck by Friday."

can be understood as:

And:

"I'll send the revised contract after legal approves it."

can be understood as:

This distinction matters because communication-centered work is often relational. A user is not only managing private intentions; they are participating in a network of expectations.

Send the deck.
Approve the budget.
Share the revised contract.

Keep the incident-response channel staffed until the incident closes.
Maintain daily account reconciliation throughout the reporting period.
Keep the customer informed while the service issue remains unresolved.

The true state of work is often hidden.

The system may observe:

• an email
• a Slack message
• a calendar event
• a voice capture
• a user-confirmed review item
• a user dismissal
• a marked-handled action

But it may not observe:

• a phone call
• a hallway conversation
• a reply in another account
• an offline cancellation
• manual completion outside Vortyx
• a change in priority that was never written down

This makes continuity a partial-observation problem [3]. The system is not determining truth directly from a message. It is maintaining a working hypothesis from incomplete observations.

A promised reply did not arrive.
An approval expected before Friday is absent.
A recurring review was not completed.
No meaningful activity occurred after a commitment.
A requested document remains missing.

This may still need follow-through.

This definitely has not been handled.

A continuity loop should have lifecycle state.

The following table is a framework, not a claim that every state is exposed as a user-facing label.

Recurrence mode: A loop may be one-time or recurring. Each recurring cycle can independently be open, waiting, stalled, completed, skipped, or dismissed.

In this paper, Done denotes the terminal lifecycle state. A loop may enter Done because its outcome was satisfied, the user marked it handled, or other sufficiently strong evidence indicated completion.

A simple transition model:

candidate → open
  when the user confirms or tracks the item

candidate → dismissed
  when the user rejects it

open → waiting
  when progress depends on another actor or external event

waiting → done
  when evidence supports the expected outcome

waiting → stalled
  when the expected checkpoint passes,
  no satisfying evidence is observed,
  and the loop has not been dismissed, snoozed, or rescheduled

stalled → waiting
  when a follow-up is sent and a new response is expected

stalled → dismissed
  when the user says it is no longer relevant

done → open
  when newer evidence suggests the loop was not actually resolved

new evidence associated with a dismissed matter
  → new candidate for review

This lifecycle view is what makes continuity different from reminders.

A reminder fires at a time. A continuity loop changes state as evidence, time, and user correction arrive.

Not all evidence has the same role.

A useful continuity system should distinguish at least the following evidence types.

"I'll send it Friday."

"Attached is the final contract."

"Actually, Maya will send it."

"Hold off until next month."

Friday passed.
No response has been observed in the connected channel.

The user marks the item handled.
The user dismisses the suggestion.
The user edits the expected date.

Consider this message:

I'll send the revised contract after legal approves it.

At t0, the system may identify a candidate continuity loop:

• debtor: sender
• creditor: recipient
• dependency: legal approval
• expected outcome: revised contract sent
• state: candidate

At t1, the user confirms tracking. The loop becomes open, with legal approval still represented as a dependency.

At t2, new evidence arrives:

Legal approved the revisions.

The dependency is now satisfied. The contract-sending obligation becomes actionable, but the loop remains open until there is satisfying evidence or user correction.

At t3, the expected checkpoint passes and no contract attachment or sending evidence is observed in the connected account. Because observation is incomplete, the system should not assert failure. It should surface a reviewable hypothesis:

The revised contract may still need to be sent.

At t4, the user marks the item handled because the contract was sent through another account. The loop moves to done based on authoritative user evidence.

This example shows why continuity requires relational commitment, dependency tracking, temporal progression, partial observation, negative evidence, review-first resurfacing, and user correction.

Continuity systems must handle contradiction, not merely accumulation.

Examples:

"I'll send it Friday."
"Actually, Maya will send it."

The expected actor changed.

"Please follow up Thursday."
"Hold off until next month."

The timing changed.

"We still need approval."
"Approval came through on a call."

The system may not have observed the satisfying event directly, but user-provided evidence changes the interpretation.

An informal precedence hierarchy is useful:

1. Explicit user correction
2. Evidence that directly satisfies or supersedes the expectation
3. Direct evidence from an authoritative source
4. Recency and source relevance
5. Inferred classification
6. Elapsed-time evidence

This hierarchy should not be treated as universal law. Evidence type, provenance, authority, and recency must be evaluated together; recency alone does not establish precedence.

The critical principle is:

Elapsed time alone should not override explicit correction or newer direct evidence.

This is where belief revision becomes relevant as a supporting idea [4]. The system must update its interpretation when new evidence conflicts with old evidence. It does not need to implement AGM belief revision to benefit from the basic principle that beliefs should remain revisable and consistency matters.

A continuity system should preserve certain invariants.

These invariants help turn review-first design from a product preference into a principled systems requirement.

Review-first behavior is not merely safety UI.

It is part of state estimation.

When a user confirms a candidate, that is evidence:

This hypothesis is useful enough to track.

When a user edits it:

The system found a real loop but represented it imperfectly.

When a user dismisses it:

This should not continue as active unresolved work.

When a user snoozes it:

The timing model should change.

When a user marks it handled:

The loop should stop resurfacing unless materially new evidence appears.

In other words, user actions are not only commands. They are corrective observations.

This is why Vortyx's review-first model is aligned with the underlying uncertainty of knowledge work. The system should assist with hypotheses, evidence, drafts, and resurfacing. It should not pretend that LLM extraction is equivalent to truth.

The current Vortyx product implements practical primitives that align with this framework.

This framework should be evaluated beyond ordinary extraction accuracy.

Quantitative claims should be published only with a documented evaluation set, annotation policy, sample size, model version, prompt version, product version, and evaluation date.

The framework draws on several research traditions, but it should not be confused with a complete implementation of any one of them.

Vortyx is designed as a continuity system.

Its purpose is not merely to extract tasks, summarize inboxes, or trigger reminders. Its deeper technical direction is to preserve unresolved work as revisable state across people, evidence, tools, and time.

The framework can be summarized as:

Continuity loop = relational expectation + evidence + time + lifecycle state + correction.

The current product already implements meaningful continuity primitives, including review-first capture, evidence-backed review, waiting states, expected checkpoints, lifecycle transitions, stalled resurfacing, recurring loops, and user correction.

Several elements remain open design and research questions, including formal observation coverage, calibrated hypothesis state, contradiction policies, cross-channel resolution, and quantitative evaluation.

Vortyx therefore represents an early practical implementation of a computational continuity framework. It helps users keep unresolved work visible until it is reviewed, acted on, dismissed, or handled, while the broader formal model continues to evolve.

1. Singh, M. P. "An Ontology for Commitments in Multiagent Systems: Toward a Unification of Normative Concepts." Artificial Intelligence and Law, 1999. https://link.springer.com/article/10.1023/A:1008319631231
2. Telang, P., Singh, M. P., and Yorke-Smith, N. "Maintenance of Social Commitments in Multiagent Systems." Proceedings of the AAAI Conference on Artificial Intelligence, 2021. https://ojs.aaai.org/index.php/AAAI/article/view/17355
3. Kaelbling, L. P., Littman, M. L., and Cassandra, A. R. "Planning and Acting in Partially Observable Stochastic Domains." Artificial Intelligence, 1998. https://www.sciencedirect.com/science/article/pii/S000437029800023X
4. Hansson, S. O. "Logic of Belief Revision." Stanford Encyclopedia of Philosophy. https://plato.stanford.edu/entries/logic-belief-revision/
5. Cai, L., Mao, X., Zhou, Y., Long, Z., Wu, C., and Lan, M. "A Survey on Temporal Knowledge Graph: Representation Learning and Applications." arXiv, 2024. https://arxiv.org/abs/2403.04782
6. Dey, A. K. "Understanding and Using Context." Personal and Ubiquitous Computing, 2001. https://link.springer.com/article/10.1007/s007790170019