00 / Start HereStart here
What Bitcode is
Begin with the zero-to-hero map: what Source Shares are, why the Exchange exists, how Terminal users operate, and where the Protocol and interfaces fit.
This is the first page for readers who know nothing about Bitcode. It keeps the model plain before introducing the deeper Terminal, Exchange, proof, and interface pages.
After reading
You can explain Bitcode as source-to-shares market infrastructure and name the major product surfaces without reading implementation history.
Bitcode is a market system for source-backed technical intelligence
A Source Share is not a file upload, a tokenized repo, or a generic AI answer. It is a measured claim that a piece of technical source can satisfy a Read under auditable proof and settlement rules.
Bitcode starts with source: code, docs, diagrams, architecture notes, issue context, commits, proofs, and metadata. The Exchange measures that source against demand, keeps the evidence, and lets the Terminal operator read what happened before trusting a result.
Why this matters
This framing keeps first-time readers from thinking Bitcode is only a developer tool. The product is the measured market path from source to accepted shares.
- Deposit means placing source-backed supply into the Bitcode operating chain.
- Read means making demand measurable before source is selected or settled.
- Proof and settlement decide whether the source can become attributable value.
Exchange, Terminal, Protocol, and interfaces are one system
Exchange is the state and market layer. Terminal is the operator experience. Protocol is the rulebook and proof contract. Interfaces such as MCP, ChatGPT App, GitHub, and webhooks are admitted ways to read or write against that same system.
The important rule is that none of the interfaces become separate products. They must read and write the same Exchange state, follow the same Protocol boundaries, and leave the same proof posture that Terminal can reread.
Why this matters
New users read one map before learning details. Otherwise Exchange, Terminal, MCP, ChatGPT App, and Auxillaries can look like separate products instead of coordinated surfaces over Source Shares.
- Exchange owns persisted activity, ledger, proof, interface, and settlement state.
- Terminal owns the deposit, read, read, write, proof, and history experience.
- Protocol owns semantics, proof families, fail-closed rules, and promotion truth.
The simplest path is deposit, read, fit, prove, settle, issue
A first-time operator should understand Bitcode as a short path: deposit source, measure Read, inspect fit, produce proof, settle attribution, and issue/read Source Shares.
The Terminal keeps the path visible as a focused Deposit/Read read/write loop. You write only when a bounded state change is intended, then read the result before moving deeper into proof, settlement, Exchange master-detail, or connected-interface delivery.
Why this matters
The product becomes easier to learn when every button is read as part of the value path rather than as miscellaneous dashboard furniture.
- 01Start with Source Shares so the market object is clear.
- 02Open the Terminal map so the product surface is familiar.
- 03Read the action guide before trusting write controls.
- 04Use the proof and interface chapters when operating against real integrations.
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.