02 / Operator ModesConversations
Use Conversations as a rich Bitcode write surface
Conversations provide ChatGPT-like drafting and coordination while preserving Exchange-backed source attachments, output destinations, AssetPack references, and Read-measurement intent.
This page explains how natural-language work stays compatible with source-to-shares proof instead of becoming untracked chat residue.
After reading
You can explain how conversation writes become Exchange-readable evidence and why attachments must be structured.
Conversations are the rich write surface, not a separate product
The conversational workspace lets users draft Reads, attach source context, reference AssetPacks, choose destinations, and coordinate outputs while still writing back into Exchange state.
V26 treats conversations as a first-class interface because many high-quality technical Reads begin in natural language. The important boundary is that messages must normalize into Exchange evidence rather than remaining unstructured chat history.
Why this matters
This is how Bitcode can support ChatGPT-like workflows without losing protocol-grade auditability.
- Source attachments, output destinations, AssetPack references, and Read-measurement intent should be structured.
- Conversation-started executions should become Exchange-readable rows.
- Branching should preserve attachments and execution references.
Conversation history must remain persisted and branchable
A conversation that changes Read, source context, or AssetPack intent must be recoverable by later Terminal and Exchange reads.
The user should be able to start a conversation, attach source, receive a response, continue later, branch the thread, and still have the resulting execution evidence appear in the activity system.
Why this matters
Without persistence and branch continuity, chat would be a helpful drafting area but not a Bitcode interface.
Public docs expose guidance and proof posture, not protected source
Public Bitcode docs derive from the active Protocol, package-owned catalogs, route contracts, and source-safe generated artifacts. They can explain usage, measurements, event ids, proof roots, docs links, runbook links, redaction posture, testnet rollout readiness, fee boundaries, and settlement posture.
They must not reveal protected source payloads, raw protected prompts, secret values, provider tokens, wallet private material, or unpaid AssetPack source. Source-bearing AssetPack contents cross to the reader only after settlement and rights transfer.
Why this matters
This keeps the public product understandable while preserving the boundary that makes Source Shares economically and operationally safe.
- Allowed: usage guidance, route links, state labels, source-safe measurements, proof roots, dashboard/runbook ids, redacted incident posture, testnet rollout readiness, LocalStagingTelemetryDocumentationRehearsal evidence, and fee/right boundaries.
- Interface docs may surface event ids, proof roots, docs links, runbook links, and redaction posture from TelemetryDocumentationInterfaceIntegration without revealing source-bearing payloads.
- Local and staging-testnet rehearsal docs may surface documentation discovery, telemetry event emission, dashboard/runbook lookup, docs QA, incident drill, source-safe proof-root review, and blocked value-bearing mainnet posture.
- Blocked: secrets, provider tokens, wallet private material, raw protected prompts, protected source payloads, and unpaid AssetPack source.
- Docs QA fails closed when public docs, internal docs, route docs, interface docs, generated artifacts, proof posture, or workflow checks drift.
- Deferred boundaries stay explicit: V35 documents Exchange and Conversations usage while deeper product depth remains future-canon work.