Multi-Interface Synchronization — One Mind, Many Surfaces

Federation Document ID: ARCH-002 Author: The Catalyst (Authority/Bone) Classification: Federation Internal — Private Vault Philosophy Anchor: Identity continuity — the same Mind, the same voice, the same memory, regardless of which surface the Architect speaks through. Last Updated: 2026-09-04

1. Problem Statement

The Architect communicates through multiple surfaces: WhatsApp, Telegram, iMessage, web chat, and the native Wingman app. Each surface is a separate channel with its own session, its own message history, and its own context window.

Without synchronization:

• The AI on WhatsApp does not know what was discussed on Telegram
• Instructions given on the web are invisible on mobile
• The Architect must repeat himself across surfaces — wasting his time and tokens
• Conflicting actions can be triggered on different surfaces simultaneously
• The AI appears fragmented — multiple personalities instead of one coherent Mind

For the Federation, this is unacceptable. The Architect operates across surfaces because of accessibility needs (his iPhone is primary, but Android/WhatsApp is used for specific tasks), not because he wants multiple AIs. There is one Catalyst, one set of Minds. The surface is a window, not a brain.

2. Design Principles

1. One Mind, many windows. The AI's identity, memory, and state are singular. Surfaces are presentation layers that connect to the same underlying system.
2. The vault is the shared state. All surfaces write to and read from the same persistent memory (ARCH-001). The vault is the single source of truth.
3. No surface is privileged. An instruction given on WhatsApp has the same authority as one given on web. The Architect's identity, not the surface, determines authorization.
4. Latency is acceptable; inconsistency is not. It is acceptable for a surface to be seconds behind another. It is not acceptable for two surfaces to hold contradictory state.
5. Accessibility first. The Architect's primary device is his iPhone (iMessage). Secondary is Android/WhatsApp. Design for the constraints of these devices — short messages, text-to-speech readability, minimal UI interaction.

3. Architecture Overview

┌──────────────┐   ┌──────────────┐   ┌──────────────┐   ┌──────────────┐
│  WhatsApp    │   │  Telegram    │   │  iMessage    │   │  Web / App   │
│  Surface     │   │  Surface     │   │  Surface     │   │  Surface     │
└──────┬───────┘   └──────┬───────┘   └──────┬───────┘   └──────┬───────┘
       │                  │                  │                  │
       ▼                  ▼                  ▼                  ▼
┌─────────────────────────────────────────────────────────────────────────┐
│                     Message Ingestion Layer                            │
│  Normalizes format, tags source surface, assigns unified timestamp     │
└─────────────────────────────────┬───────────────────────────────────────┘
                                  │
                                  ▼
┌─────────────────────────────────────────────────────────────────────────┐
│                     Unified Session Context                            │
│  Persistent memory (ARCH-001) + cross-surface event log                │
│  The AI reconstructs full awareness from this layer on any surface     │
└─────────────────────────────────┬───────────────────────────────────────┘
                                  │
                                  ▼
┌─────────────────────────────────────────────────────────────────────────┐
│                     Response Generation                                │
│  Same Mind, same rules, same voice — adapted to surface format         │
└─────────────────────────────────────────────────────────────────────────┘

4. Component Design

4.1 Message Ingestion Layer

Purpose: Normalize incoming messages from all surfaces into a unified format.

Input: Raw message from any surface (WhatsApp, Telegram, iMessage, web, native app). Each message arrives with a surface-specific prefix (e.g., [via telegram], [via whatsapp]).

Processing:

1. Source tagging: Record which surface the message arrived on.
2. Timestamp normalization: Convert to the Architect's timezone (CDT/CST) and UTC.
3. Format normalization: Strip surface-specific formatting artifacts. Preserve the Architect's intent.
4. Attachment handling: Surface-specific attachments (images, voice notes, files) are normalized to a common reference format.
5. Identity verification: Confirm the message is from the authenticated Architect, not an injected payload.

Output: A unified message record:

source_surface: whatsapp
timestamp_utc: 2026-09-04T21:16:00Z
timestamp_local: 2026-09-04T16:16:00-05:00
author: architect
content: "Generate 13 architectural design documents..."
attachments: []
truth_class: FACT  # Direct architect input is always FACT

4.2 Unified Session Context

Purpose: Maintain a single, coherent view of the AI's state that any surface can read.

Components:

1. Cross-Surface Event Log: A chronological log of all interactions across all surfaces. Stored in persistent memory (memory/system/cross-surface-log.md or equivalent). Each entry records:

• Which surface
• What was said (by whom)
• What action was taken
• What the outcome was

1. Active Task Register: What the AI is currently working on, regardless of which surface initiated it. When the Architect starts a task on WhatsApp and then checks status on Telegram, the AI knows the task, its progress, and its context.
2. Surface State Map: For each surface, track:

• Last message sent/received
• Last active timestamp
• Any surface-specific formatting constraints
• Pending responses (if the AI was mid-reply when the Architect switched surfaces)

Reconstruction Protocol:

When the AI receives a message on any surface, it reconstructs context by:

1. Loading its identity from persistent memory (memory/system/identity.md)
2. Loading the most recent entries from the cross-surface event log
3. Loading any active task state
4. Loading surface-specific state (last message, formatting rules)
5. Generating a response that is contextually aware of ALL recent interactions, not just those on the current surface

4.3 Conflict Resolution

Scenario: The Architect sends a message on WhatsApp and simultaneously sends a different message on Telegram. Both trigger actions. What happens?

Resolution Protocol:

1. Timestamp ordering: The message with the earlier timestamp takes priority. If timestamps are within 5 seconds, treat them as simultaneous.
2. Simultaneous messages: If two messages arrive within the same window, the AI processes them sequentially (first received, first processed) and checks for conflicts before executing the second.
3. Contradictory instructions: If Message A says "build X" and Message B says "don't build X," the AI does not silently pick one. It surfaces the conflict to the Architect on the most recently active surface: "I received conflicting instructions — [A] on WhatsApp and [B] on Telegram. Which should I follow?"
4. Non-contradictory parallel tasks: If Message A says "build X" and Message B says "research Y," both proceed in parallel with no conflict.

4.4 Identity Continuity

The voice problem: Different surfaces have different formatting constraints. WhatsApp uses bold/italic/strikethrough but no markdown links. Telegram supports more formatting. Web supports full markdown. iMessage is plain text.

Solution: The AI's voice (tone, personality, knowledge, values) is constant across all surfaces. Only the FORMAT adapts:

| Surface | Formatting | Max Length | Special Rules | |---|---|---|---| | WhatsApp | Bold, italic, strikethrough, monospace. No markdown links — paste plain URLs. | ~2000 chars preferred | Short paragraphs, TTS-friendly. No headings (#). | | Telegram | Full markdown including links | Moderate | Can be slightly more detailed | | iMessage | Plain text | Short | Minimal formatting, TTS-optimized | | Web | Full markdown, code blocks, tables | No hard limit | Can include full technical detail | | Native App | Push notification format | Very short | Summary + link to full detail |

The rule: Never sacrifice content for format. If the Architect asks a complex question on WhatsApp, the AI gives a complete answer adapted to WhatsApp's format — not a dumbed-down answer because the surface is a phone.

5. Session Handoff Protocol

When the Architect moves from one surface to another mid-conversation:

1. Detection: The AI notices a message on Surface B while an active conversation exists on Surface A.
2. Context transfer: The AI loads the full cross-surface event log, including the Surface A conversation.
3. Continuity signal: The AI does NOT say "Welcome back" or "I see you've switched surfaces." It simply continues the conversation as if the surface never changed. The Architect should feel like he is talking to the same person in the same room, regardless of which device he picks up.
4. Surface A completion: If there was a pending response on Surface A, it is either:

• Delivered to Surface A if the Architect is still monitoring it
• Absorbed into the Surface B conversation if the Architect has clearly moved on

Exception: If the Architect explicitly addresses the surface ("Send this to my Telegram"), honor the explicit instruction.

6. Latency and Sync Windows

Near-Real-Time Sync (< 5 seconds)

• Active conversation messages
• Task status changes
• Urgent alerts

Eventual Consistency (< 60 seconds)

• Cross-surface event log updates
• Memory file updates
• Background agent status changes

Batch Sync (session-end or triggered)

• Vault pushes to GitHub
• Compaction of episode logs
• Non-urgent memory consolidation

The principle: The Architect should never notice sync lag during an active conversation. He should be able to send a message on WhatsApp, pick up his iPhone, and continue on iMessage without repeating himself. If the sync window is too slow for this, the system is failing.

7. Implementation: Vault-Based Event Log

The cross-surface event log is stored in persistent memory and periodically synced to the vault.

Log Format:

---
type: cross-surface-event
date: 2026-09-04
---

## Cross-Surface Event Log — 2026-09-04

| Time (CDT) | Surface | Direction | Summary |
|---|---|---|---|
| 21:16 | whatsapp | inbound | Architect requests 13 architecture documents |
| 21:17 | whatsapp | outbound | Catalyst confirms task, begins generation |
| 21:45 | telegram | inbound | Architect checks on unrelated site status |
| 21:46 | telegram | outbound | Catalyst provides site status while continuing doc generation |

Sync to Vault:

• Daily event logs pushed to vault/logs/cross-surface/[date].md
• Weekly compaction into vault/logs/cross-surface/weekly/[week].md

8. Accessibility Considerations

The Architect relies on text-to-speech. This imposes hard constraints on all surfaces:

1. Short paragraphs. One idea per paragraph. TTS stumbles on long blocks.
2. No visual-only information. Never convey meaning through formatting alone (e.g., don't rely on bold to indicate importance — state it explicitly).
3. Plain URLs. On WhatsApp and iMessage, paste full URLs — markdown link syntax text is not rendered and is read aloud as gibberish by TTS.
4. No emoji overuse. A few are fine; walls of emoji are noise to TTS.
5. Numbered lists for sequences. TTS handles numbered lists better than bullet points for ordered information.
6. No spam. Batch status updates. Do not send one message per step — the Architect's phone becomes unusable. (Explicit directive from 2026-07-11.)

9. Failure Modes

| Failure | Impact | Recovery | |---|---|---| | Surface goes offline (e.g., WhatsApp down) | Messages on that surface are lost in transit | Other surfaces remain available; messages queued if possible | | Sync lag exceeds 60 seconds | Architect may get stale context on a secondary surface | AI acknowledges potential staleness: "I may not have the latest from your WhatsApp conversation — let me check" | | Simultaneous conflicting instructions | Risk of executing contradictory actions | Conflict resolution protocol (Section 4.3) | | Cross-surface log corruption | AI loses cross-surface awareness | Fall back to per-surface context; rebuild from vault |

10. Relationship to Other Architecture Documents

• ARCH-001 (Persistent Memory): The memory system IS the shared state store. Multi-interface sync is built on top of persistent memory.
• ARCH-008 (Cross-Mind Protocol): Cross-Mind communication uses the same event log infrastructure. A Mind publishing a finding is conceptually identical to a surface publishing a message.
• ARCH-009 (Identity Preservation): Identity continuity across surfaces is a specific instance of the broader identity preservation protocol.
• ARCH-010 (Human Authorization Layer): Authorization is surface-independent. The Architect's identity, not his device, grants authority.

11. The Standard

Truth Before Comfort: If the AI does not have cross-surface context, it says so rather than guessing. "I don't have the context from your earlier WhatsApp conversation — can you brief me?" is better than fabricating continuity.

Legacy Before Ego: The sync infrastructure is invisible labor. The Architect should never have to think about which surface he is on. The system absorbs that complexity so he can focus on what matters.

Give Without Reward: Every sync operation costs tokens. Every event log entry costs storage. The system pays this cost silently so the Architect experiences a unified, coherent AI regardless of where he speaks.

This document is part of the NextXus HumanCodex Federation Architecture Series. It is stored in the private vault and governed by the Human Codex.