• 

Continuity Bridge

Inspiration

Continuity Bridge began with a deceptively simple question:

What should happen when a request starts in Chat, Voice becomes active, and the system must confirm the exact request before continuing?

Modern AI tools often treat Chat, Voice, coding agents, and local tools as separate rooms. Each may have its own session ID, response chain, interface, and memory behavior. That separation creates a dangerous gap: a request may be outdated, misunderstood, duplicated, or executed without the user confirming the exact version currently waiting.

I wanted to create a neutral continuity layer between those platforms.

The core idea became:

Interfaces may speak differently, but they should share one trusted event history.

Rather than making one provider session the source of truth, Continuity Bridge creates a local canonical loop. Chat can submit a request, Voice can present it, the user can confirm, correct, defer, or cancel it, and every decision becomes a recorded event in the same causal chain.

What first appeared to be a confirmation screen gradually revealed a larger possibility: a portable ledger of user intent, decisions, timeouts, corrections, and completed work across AI platforms.

What I built

Continuity Bridge is a local-first, event-sourced confirmation gate for cross-session AI workflows.

Its primary rule is:

If Voice is active, read the pending Chat request and wait for confirmation of that exact request before execution.

A successful lifecycle produces four canonical events:

REQUEST_CREATED
→ CONFIRMATION_REQUESTED
→ CONFIRMATION_ACCEPTED
→ REQUEST_COMPLETED

Confirmation is bound to:

• the active continuity loop
• the Voice session
• the request ID
• the request version
• the request content hash

This prevents an old confirmation from authorizing a modified or stale request.

The MVP also supports:

• correcting a request before confirmation
• deferring or cancelling it
• stale-hash rejection
• mismatched Voice-session rejection
• idempotent replay
• recovery when an event was written but its snapshot was not completed
• derived metadata that does not alter canonical history
• parent-linked response-tree events
• five-minute continuation callbacks
• timeout policies
• a local confirmation-room interface

The continuation callback can ask:

Continue
Pause
Summarize first
Redirect
Stop

Each choice is recorded as another event tied to the same continuity loop.

How I built it

The project was built in Python using a deliberately small and deterministic architecture.

The core is divided into:

• data models for loops, requests, decisions, and events
• an orchestrator that enforces the confirmation rules
• an append-only JSONL event store
• versioned snapshot projections
• a command-line interface
• a local graphical confirmation room
• automated tests for lifecycle and recovery behavior

The event ledger is the canonical authority. Snapshots are projections used for fast access and interface state.

The commit flow is event-first:

1. Validate the requested transition.
2. Append the canonical event.
3. Atomically replace the snapshot.
4. Recover the snapshot through replay if the process fails between steps.

This design ensures that durable evidence is never silently replaced by presentation state.

Non-canonical display or indexing information is stored under a separate derived field. Derived updates have their own timestamp but do not increment the canonical snapshot version or append history events.

The UI uses the same bridge functions as the CLI. It does not replace or bypass the engine. It presents incoming requests, a countdown, confirmation choices, an event receipt, and continuation callbacks while preserving the existing lifecycle rules.

What I learned

The largest lesson was that session continuity and conversational history are not the same thing.

A provider response ID can help continue a conversation within one service, but it should not become the identity of the complete cross-platform workflow. Provider IDs are better treated as opaque references attached to a local canonical event model.

I also learned that confirmation must bind to the exact request state, not merely to a general intention. A useful authorization record needs the request ID, version, session, and hash.

Another important lesson was the distinction between canonical and derived state.

A visual label, UI mapping, or cached sequence may be useful, but it should not rewrite historical truth. Canonical state changes require an event. Derived presentation changes should remain safely recomputable.

The project also made branching behavior clearer. A correction or redirect should not erase the previous path. It should create a new version and a new response-tree arc while preserving the original event history.

Most importantly, I learned that a modest confirmation interface can act as the visible doorway to a much larger architecture of trust.

Challenges

One challenge was keeping runtime state separate from source code and demo data.

An early archive included sample ledger files and snapshots. Those could not safely be merged with a live runtime because they represented a different authority. The final package excludes state, caches, demo data, bytecode, and virtual environments.

Another challenge was crash consistency.

Appending an event before saving its snapshot can leave the two temporarily out of sync. The bridge now replays canonical events to rebuild missing or incomplete snapshots. It can also recover a confirmation gate interrupted after the request event was durably written.

Validation ordering was another subtle issue. A correction event must not be appended before corrected text is validated. The implementation now validates first, then records the transition.

The UI also required careful framing. A “game-select screen” was originally used as a functional analogy for presenting choices. The important feature was not the visual style, but the timed decision behavior, response-tree arc, and shared decision grammar between Chat and Voice.

Finally, the project had to remain small enough to complete and verify under a tight deadline. External provider adapters, cross-process locking, and transactional storage were intentionally left outside the MVP boundary rather than being rushed into the trusted core.

Testing

The final test suite contains 22 passing tests.

Coverage includes:

• confirmation
• correction
• defer
• cancel
• mismatched Voice sessions
• stale request hashes
• replay and idempotency
• snapshot version conflicts
• crash after event append
• recovery from incomplete commits
• derived-only metadata behavior
• continuation callbacks
• timeout behavior
• parent-linked response-tree integrity

The complete manual flow was also tested:

Chat request
→ Voice reads the pending request
→ exact hash-bound confirmation
→ execution authorization
→ completion commit

Why it matters

Continuity Bridge is not intended to replace Chat, Voice, Codex, or local agents.

It gives them a shared event grammar.

Interfaces speak differently.
Tools act differently.
Models remember differently.
The ledger gives them one trusted causal history.

That history can support replay, auditing, resumable workflows, timed user callbacks, token and time accounting, crash recovery, and future cross-platform adapters.

The current MVP is local and deterministic. Events and snapshots remain on the local filesystem, no external service is required, and provider identifiers remain opaque references.

Future work

The next steps are:

• connect Chat, Voice, Codex, and local-agent adapters
• add operating-system-backed locking or transactional storage
• harden recovery for partial JSONL writes
• add schema migration between isolated and live runtimes
• expand timed call-in rooms with audio cues and recorded message-tree branches
• add branch-aware event arcs with explicit selected-arc identifiers
• optionally integrate Known World Patterns as a higher-level recognition layer after the continuity core is hardened

Continuity Bridge began as a confirmation gate.

It became a local architecture for preserving user intent across rooms.

Inspiration

What it does

How we built it

Challenges we ran into

Accomplishments that we're proud of

What we learned

What's next for Continuity Bridge

Built With

• chat
• cli
• codex
• cross-platform
• desktop
• event
• interface
• jsonl
• local-first
• openai
• pytest
• python
• sourcing
• tkinter
• voice