Roadmap V43 agentic depositing

Document the later V43+ deposit-side AssetPack option experience: repository agents compare connected codebases, Depository state, and Reading demand to propose source-safe sub-critical positive-ROI deposit options for enterprise approval.

Capture the later product navigation split from /terminal to /read and /deposit plus /exchange to /packs renaming, while keeping V41 scoped to prompt-program work and V42 scoped to reliable MVP shortest paths.

Validation: pnpm run check:v41-gate1; pnpm run check:v41-gate4; git diff --check.

Author: geraldarthurdavis

BITCODE_SPEC_V41_DELTA.md

@@ -73,6 +73,7 @@ Bind all V41 prompt artifacts, tests, workflow checks, generated proof support,
 - No prompt content is rewritten during Gate 1.
 - New commercial product behavior is deferred unless needed to make prompt-program tests truthful.
 - Production-mainnet value-bearing prompt rehearsals remain opt-in.
+- V43+ agentic enterprise depositing is deferred: deposit AssetPack option synthesis, repository-installed deposit agents, sub-critical/positive-ROI IP filtering, `/read` and `/deposit` route separation, and `/exchange` to `/packs` renaming are planning notes only until a later version explicitly opens that scope.
 
 ## Pre-Implementation Sequence
 

BITCODE_SPEC_V41_NOTES.md

@@ -33,6 +33,27 @@ Depositing must minimize the path to admitting source material and later receivi
 Reading must minimize the path from Read Request to synthesized Need review/resynthesis, Finding Fits, source-safe AssetPack preview, BTD/BTC purchase and settlement, and repository delivery.
 V42 must keep depositor compensation, reader purchase, BTD/AssetPack rights, and repository delivery visible in the shortest path without widening V41 beyond Prompt and PromptPart excellence.
 
+## V43+ agentic depositing roadmap note
+
+V43 or a later explicitly opened version should evolve the deposit side from manual source admission into an agentic AssetPack option experience for enterprises that own connected codebases.
+The central object is a deposit AssetPack option: an unminted AssetPack in all but BTD, synthesized from proprietary or otherwise non-public source material and held for enterprise review before Depository admission.
+BTD remains minted only when an industrial Need-Fit is made for a Reader; the deposit-side option is not BTD yet, but it is shaped as an AssetPack candidate so that future Finding Fits can search, rank, synthesize from, and compensate it cleanly.
+
+Bitcode Agents installed in an enterprise repository should compare three live contexts:
+
+- the enterprise's connected codebase and its evolving source/measurement state;
+- the existing Bitcode Depository and pre-existing deposits/AssetPacks;
+- current and historical Reading activity that indicates demand for technical knowledge.
+
+The deposit-side synthesis pipeline should propose AssetPack options only when the option appears sub-critical to the enterprise, not likely to leak strategic or protected IP the enterprise would not sell, and likely positive ROI after considering development cost, uniqueness, expected demand, and likely future BTD mint value.
+Those criteria must be configurable and promptable by the enterprise, but the default UX should minimize manual decision-making by surfacing clear approve/reject options with source-safe measurements, demand evidence, criticality assessment, ROI posture, and compensation route expectations.
+Approved options enter the Bitcode Depository and become eligible for Read-Need Finding Fits; rejected options remain out of the Depository and must not be searched or disclosed.
+
+That version should also split the product navigation now concentrated in `/terminal`.
+`/read` should own Read Request submission, synthesized Need review/resynthesis, Finding Fits, source-safe AssetPack preview, purchase, settlement, and repository delivery.
+`/deposit` should own connected repository state, agentic deposit AssetPack option synthesis, manual reruns reflecting the latest connected repositories and Bitcode state, approve/reject review, Depository admission, and later compensation readback.
+`/exchange` should be renamed to `/packs` across routes, code naming, docs, and operator vocabulary, because the product object is AssetPacks and BTD rights rather than a generic exchange abstraction.
+
 ## Gate 3 registry and interpolation contract note
 
 Gate 3 makes the prompt registry call chain source-checkable before prompt rewrites.

README.md

@@ -46,6 +46,11 @@ Need review/resynthesis, Finding Fits, source-safe AssetPack preview,
 BTD/BTC settlement, repository delivery, and an AI-reading dominant
 demonstration whose AssetPack measurably improves an AI system beyond
 public-data-only performance.
+V43+ is roadmapped as the later agentic depositing evolution: repository
+agents synthesize deposit AssetPack options from connected enterprise code,
+Depository state, and Reading demand; enterprises approve or reject
+sub-critical positive-ROI options; `/terminal` separates into `/read` and
+`/deposit`; and `/exchange` is renamed to `/packs` across product naming.
 
 Exchange is inherited V36 canon: market-wide activity master-detail, buy/sell/
 bid/ask/cancel/accept/settle/history flows, AssetPack range trading,

SPECIFICATIONS_ROADMAP.md

@@ -30,6 +30,7 @@
 - V41 Gate 4 working anchor: prompt-program work now owns package-backed `V41ReadingPromptBenchmarkBaselines` source, deterministic `.bitcode/v41-reading-prompt-benchmark-baselines.json`, 10 source-safe Reading baseline rows, 120 passing source predicates, all five Reading UX steps, both `ReadNeedComprehensionSynthesis` and `ReadFitsFindingSynthesis`, V38 benchmark fixture binding, Gate 2 inventory binding, Gate 3 registry/interpolation binding, parser target binding, source-safe disclosure tiers, protocol tests, workflow wiring, and `check:v41-gate4`.
 - Forward planning note: V41 should focus singularly on Prompt and PromptPart implementation quality: prompts as programs. V38's inference correctness hardening and V40's testing/benchmark depth should empower V41 to examine every raw PromptPart, every composed Prompt, every benchmark, every meaningfully benchmarkable semantic part, title, template, interpolation contract, registry binding, inference callsite, and downstream parsed return type; then repartition, retitle, rewrite, catalogue, and validate them across Reading pipelines and conversational interactions. V41 should primarily harden `ReadNeedComprehensionSynthesis` and `ReadFitsFindingSynthesis` prompt surfaces while also covering conversational and other inference prompts with the same catalogue-and-benchmark discipline.
 - Forward planning note: V42 should focus on the reliable MVP product experience after V41's prompt-program hardening. Depositing should become the shortest path to adding any source material, proving its Depository admission, and later receiving BTC compensation when that deposit contributes to a synthesized AssetPack. Reading should become the shortest path to submitting a Read Request, reviewing or resynthesizing Bitcode's synthesized Need, requesting Finding Fits, reviewing source-safe AssetPack measurements and preview metadata, buying the AssetPack through BTD/BTC settlement semantics, and receiving post-settlement repository delivery. The demonstration should be AI-reading dominant: any deposit source can contribute proprietary or otherwise non-public training, prompt, context, or evaluation material to an AssetPack that measurably improves an AI system beyond a public-data-only baseline.
+- Forward planning note: V43+ should evolve the deposit side into an agentic AssetPack option experience for enterprises that own connected codebases. Bitcode Agents installed on an enterprise repository should compare the repository, the current Bitcode Depository, and current Reading activity to propose deposit AssetPack options: unminted AssetPacks in all but BTD that can later become BTD only when a Reader's industrial Need-Fit mints one. The deposit pipeline should optimize for enterprise IP governance by filtering out critical IP, estimating whether selling would be positive ROI against development cost and expected Read demand, and presenting everything else as approve/reject deposit options. The product route plan for that version is to split `/terminal` into `/read` for Reading and `/deposit` for agentic deposit AssetPack option review, and to rename `/exchange` to `/packs` across routes, code names, and docs.
 - V34 Gate 2 closure anchor: deployment-depth now owns package-backed `DeploymentHostCapabilityCatalog` and `EnvironmentLaneContract` source, deterministic `.bitcode/v34-deployment-host-capability-catalog.json` and `.bitcode/v34-environment-lane-contracts.json`, and visible `value-bearing-mainnet` blocking through `blocked_future_canon_required`.
 - V34 Gate 3 closure anchor: deployment-depth now owns package-backed `DistributedExecutionRuntimeReceipt` source, deterministic `.bitcode/v34-distributed-execution-runtime-receipts.json`, `request_response_not_required` long-running work posture, and source-safe roots for pipeline, PTRR agent, ThricifiedGeneration, tool, ledger, wallet, proof, object-storage, and repair work.
 - V34 Gate 4 closure anchor: deployment-depth now owns package-backed `DeploymentStoragePosture` source, deterministic `.bitcode/v34-deployment-storage-posture.json`, ledger/database/object-storage drift repair fixtures, retention/encryption/backup/rollback/audit posture, and source-bearing AssetPack storage remains locked before settlement.
@@ -151,6 +152,7 @@ They are referenced here for specification history only; active implementation w
 | V40 | `BITCODE_SPEC_V40.md` | active canon | Exhaustive commercial application testing depth after V39: rich browser E2E for all website interactions and state possibilities, visual/screenshot comparison coverage, API and integration suites for pipelines, conversations, routes, ledger/database/storage synchronization, unit coverage for packages, primitives, isolated implementations, real commercial implementations, local/staging rehearsal automation, prompt benchmark smoke, and promotion readiness. |
 | V41 | `BITCODE_SPEC_V41.md` | active draft target | Prompt and PromptPart excellence, treating prompts as programs: audit every raw PromptPart and composed Prompt, run and harden benchmarks, repartition prompts into meaningfully benchmarkable semantic parts, retitle and rewrite PromptParts/Prompts where optimal, catalogue registry bindings, interpolation contracts, benchmark fixtures, benchmark outputs, inference callsites, and parsed return types, and elevate all Reading and Conversation inference points after V38 inference scaffolding and V40 testing depth make that work measurable. The primary surface is Reading, especially `ReadNeedComprehensionSynthesis` and `ReadFitsFindingSynthesis`; conversations and other inference prompts follow with the same benchmarkable catalogue discipline. |
 | V42 | `BITCODE_SPEC_V42.md` | planned future | Reliable MVP experience after V41 prompt hardening: shortest-path Depositing for any source material with Depository admission proof and later BTC compensation when deposits contribute to synthesized AssetPacks; shortest-path Reading for Read Request submission, synthesized Need review/resynthesis, Finding Fits, source-safe AssetPack measurement/preview review, BTD/BTC purchase and settlement, and repository delivery; and an AI-reading dominant demonstration proving an AssetPack can improve an AI system's training, prompt/context, or evaluation performance beyond public-data-only baselines using proprietary or otherwise non-public deposit and read materials. |
+| V43+ | future specification family | planned future | Agentic enterprise deposit-side AssetPack option synthesis after the MVP paths are reliable: repository-installed Bitcode Agents compare a connected enterprise codebase, the Bitcode Depository, and Reading activity to propose deposit AssetPack options for review; filter out critical IP; estimate positive ROI against development cost and likely demand; let enterprises approve/reject options for Depository admission; split `/terminal` into `/read` and `/deposit`; and rename `/exchange` to `/packs` throughout product routes, code naming, docs, and operator vocabulary. |
 
 ## Current Planning Spine
 
@@ -171,12 +173,14 @@ They are referenced here for specification history only; active implementation w
 15. V40 promoted exhaustive testing for the rich commercial application: E2E, visual, screenshot comparison, interaction/state matrices, integration, unit coverage, ledger/storage synchronization, local/staging rehearsal automation, and prompt benchmark smoke across the website, APIs, pipelines, conversations, packages, primitives, and real implementations.
 16. V41 is the current prompts-as-programs draft target after V40: every PromptPart, Prompt composition, benchmark, meaningfully benchmarkable semantic division, title, template, interpolation contract, registry binding, inference callsite, benchmark result, and parsed return type should be examined and improved across Reading and Conversation inference, using V38's inference correctness scaffolding and V40's testing/benchmarking depth as the measurement base.
 17. V42 is planned as the reliable MVP experience version after V41: refine the shortest path to Depositing any source material and later receiving BTC compensation, refine the shortest path to Reading from request through synthesized Need review/resynthesis, Finding Fits, source-safe AssetPack preview, BTD/BTC purchase, settlement, and repository delivery, and ship a strong AI-reading dominant demonstration where Bitcode reads non-public technical intelligence into an AssetPack that measurably improves an AI system beyond a public-data-only baseline.
+18. V43+ is planned as the agentic deposit-side product evolution after the MVP paths are reliable: enterprises should get deposit AssetPack options synthesized from their connected repositories and Bitcode's observed Depository/Reading demand, then approve or reject source-safe, sub-critical, positive-ROI options for Depository admission.
 
 ## Boundary Rules
 
 - Do not treat `_legacy/` ENGI specifications as active implementation authority.
 - Do use `_legacy/` specifications to understand why current Bitcode concepts exist and what must not regress.
 - V41+ work must build on V40 active canon and V27 `$BTD` law unless a future promoted spec explicitly supersedes it.
 - V42 is roadmap/planning only until V41 promotion opens it as the active draft target; V41 remains singularly scoped to Prompt and PromptPart excellence.
+- V43+ agentic depositing, `/read` and `/deposit` route separation, and `/packs` renaming are roadmap/planning only until a later version explicitly opens them; V41 remains singularly scoped to Prompt and PromptPart excellence.
 - No implementation route should be versioned by spec number; source should move in place with the active canon.
 - Future notes files are planning memory only until their version is explicitly opened as the draft-target SPEC family.