Merge pull request #77 from powerloom/feat/dsv-bds-agentic-workflows

Feat/dsv bds agentic workflows

Author: anomit

.gitignore

@@ -3,7 +3,7 @@
 
 # Production
 /build
-
+/typesense/
 # Generated files
 .docusaurus
 .cache-loader

docs/Protocol/Protocol_v2/overview.md

@@ -4,6 +4,10 @@ sidebar_position: 0
 
 # Overview
 
+:::info
+This page documents the Protocol v2 upgrade path and its historical architecture framing. For the live decentralized sequencer-validator network, see [`DSV Mainnet`](/category/dsv-mainnet), especially [`Why DSV Exists`](/dsv-mainnet/why-dsv-exists) and [`Protocol Workflow`](/dsv-mainnet/protocol-workflow).
+:::
+
 
 ## Necessity of an upgrade
 
@@ -30,7 +34,7 @@ The above approach required the snapshotter peers to send out their submissions
 
 ### Composed snapshots finality
 
-A combination of the above couple of issues also affects the [composability principle](/Protocol/data-composition.md) of building higher order snapshots. Dropped transactions and increased delays in confirmation times of snapshot submissions ultimately affect the aggregate data points that power complex use cases like the [Uniswap V2 dashboard](/build-with-powerloom/use-cases/existing-implementations/uniswap-dashboard/) and [Aave V3 dashboard](/build-with-powerloom/use-cases/existing-implementations/aavev3-dashboard/).
+A combination of the above issues also affects the [composability principle](/Protocol/data-composition.md) of building higher order snapshots. Dropped transactions and increased delays in confirmation times of snapshot submissions ultimately affect aggregate data products and downstream consumers.
 
 
 ## Upgraded workflow

docs/Protocol/Protocol_v2/sequencer.md

@@ -5,6 +5,10 @@ sidebar_position: 1
 
 # Sequencer
 
+:::info
+This page describes the Protocol v2 sequencer model. For the live DSV mainnet flow, including two-level validator aggregation and VPA-based submission, see [`Protocol Workflow`](/dsv-mainnet/protocol-workflow) and [`Roles and Topology`](/dsv-mainnet/roles-and-topology).
+:::
+
 :::warning
 The sequencer listening interfaces for specific data markets are listed in the following trusted sequencer JSON file hosted on the Powerloom Github repository:
 

docs/Protocol/Protocol_v2/validator.md

@@ -4,6 +4,10 @@ sidebar_position: 3
 
 # Validator
 
+:::info
+This page describes the Protocol v2 validator flow. For the live DSV mainnet consensus path, see [`Protocol Workflow`](/dsv-mainnet/protocol-workflow), [`On-Chain Submission and Verification`](/dsv-mainnet/onchain-submission-and-verification), and [`Stability and Scale`](/dsv-mainnet/stability-and-scale).
+:::
+
 ## Overview
 
 ![Protocol V2 validator worklow](/images/validator-workflow.png)

docs/Protocol/Specifications/Snapshotter/components.md

@@ -113,4 +113,4 @@ In the end,
 
 Its API endpoints are used by a decoupled frontend adapter logic that ultimately support building of rich data products for smart contracts and other web3 based applications. 
 
-In our [`All about Data` section of docs](/build-with-powerloom/snapshotter-node/data), find out more about the way this API is used by a frontend adapter to serve the Uniswap V2, Uniswap V3, and Aave V3 dashboards.
+In the [`All about Data` section](/build-with-powerloom/snapshotter-node/data), learn how resolver APIs serve finalized data while preserving verification metadata for applications and agents.

docs/Protocol/Specifications/Snapshotter/snapshot-build.md

@@ -7,7 +7,7 @@ sidebar_position: 2
 ## Snapshot Computation Modules
 ---
 
-As briefly introduced in the section on Snapshotter implementations that [leverage Git Submodules for specific computation logic](/build-with-powerloom/snapshotter-node/architecture), the modules are specified in the configuration for project types under the key `processor`.
+As briefly introduced in the section on [Snapshotter architecture](/build-with-powerloom/snapshotter-node/architecture), compute modules are pulled into the node runtime by setup scripts and are specified in the configuration for project types under the key `processor`.
 
 ```json reference
 https://github.com/powerloom/snapshotter-configs/blob/39e4713cdd96fff99d100f1dea7fb7332df9e491/projects.example.json#L15-L28
@@ -102,7 +102,7 @@ https://github.com/powerloom/pooler/blob/634610801a7fcbd8d863f2e72a04aa8204d27d0
 
 ### Example of snapshot computation
 
-#### Base snapshot of trade events for the [Uniswap V2 and V3 dashboard data markets](/category/uniswap-dashboard):
+#### Base snapshot of trade events:
 ```python reference
 https://github.com/powerloom/snapshotter-computes/blob/6fb98b1bbc22be8b5aba8bdc860004d35786f4df/trade_volume.py#L14-L44
 ```
@@ -111,13 +111,13 @@ https://github.com/powerloom/snapshotter-computes/blob/6fb98b1bbc22be8b5aba8bdc8
 ## Aggregate Snapshots
 ---
 
-Aggregate and higher-order snapshots that build on base snapshots are configured in their specific repositories, such as the following in our [Uniswap Dashboard use case](/category/uniswap-dashboard). This is where you can observe the [dependency graph of snapshot composition](/Protocol/data-composition#dependency-graph) in action.
+Aggregate and higher-order snapshots that build on base snapshots are configured in market-specific repositories. This is where you can observe the [dependency graph of snapshot composition](/Protocol/data-composition#dependency-graph) in action.
 
 :::info
 
 - [Single Project Composition](/Protocol/data-composition#single-project-composition)
 - [Multi-Project Composition](/Protocol/data-composition#multiple-projects-composition)
-- [Walkthrough of the Snapshotter Implementation for the Uniswap V2 and V3 Dashboards](/build-with-powerloom/use-cases/existing-implementations/uniswap-dashboard/)
+- [BDS Data Market](/category/bds-data-market)
 :::
 
 The order and dependencies of these compositions are specified according to the `aggregate_on` key.
@@ -133,7 +133,7 @@ https://github.com/powerloom/snapshotter-configs/blob/fcf9b852bac9694258d7afcd8b
   * For example, a base snapshot built on a project ID like `pairContract_trade_volume:0xb4e16d0168e52d35cacd2c6185b44281ec28c9dc:UNISWAPV2` triggers the worker `AggregateTradeVolumeProcessor` as defined in the `processor` config, against the pair contract `0xb4e16d0168e52d35cacd2c6185b44281ec28c9dc`.
 * The span of epochs on which corresponding base snapshots will be aggregated is determined by the logic contained in the module specified in the `processor` key.
 
-The following implementation aggregates [trade volume snapshots](/build-with-powerloom/use-cases/existing-implementations/uniswap-dashboard/closer-look-at-snapshots.md) across a span of 24 hours worth of epochs, if available. Otherwise, it aggregates the entire span of epochs available on the protocol against the data market and reports it back.
+The following implementation aggregates trade volume snapshots across a span of 24 hours worth of epochs, if available. Otherwise, it aggregates the entire span of epochs available on the protocol against the data market and reports it back.
 
 
 ```python reference

docs/Protocol/Specifications/state-v1.md

@@ -130,4 +130,4 @@ event SnapshotFinalized(uint256 indexed epochId, uint256 epochEnd, string projec
 ## See Also
 ---
 
-* [Build with Powerloom – All about data](/build-with-powerloom/snapshotter-node/data.md#verifying-data)
+* [Build with Powerloom – All about data](/build-with-powerloom/snapshotter-node/data.md)

docs/Protocol/Specifications/state-v2.md

@@ -4,6 +4,10 @@ sidebar_position: 1
 
 # Protocol State: V2
 
+:::info
+This page documents the Protocol v2 state model. For the live DSV mainnet submission and verification path, see [`On-Chain Submission and Verification`](/dsv-mainnet/onchain-submission-and-verification) and [`Why DSV Exists`](/dsv-mainnet/why-dsv-exists).
+:::
+
 ## Overview: Smart Contract Architecture
 
 The smart contracts that maintain the state of the protocol V2 interact are arranged as depicted in the diagram that follows.

docs/Protocol/data-composition.md

@@ -24,7 +24,7 @@ As defined by the data sources configuration, the protocol state collects snapsh
 
 ## Higher-Order Aggregations
 
-An example of this can be found in the [Uniswap V2 and V3 dashboard implementation](/build-with-powerloom/use-cases/existing-implementations/uniswap-dashboard/), where a trade activity aggregation dataset is generated by:
+A market can generate higher-order aggregation datasets by:
 
 - Combining individual snapshots of trade volume and fees across multiple pair contracts.
 - Spanning a specific set of epochs that satisfy a time duration (e.g., 24 hours).

docs/Protocol/data-sources.md

@@ -11,18 +11,15 @@ The data sources defined by a market can be static or dynamic, depending on the
 
 ## Static Data Sources
 
-Our implementation of a data market serves datasets to render live Uniswap V2, Uniswap V3, and Aave V3 dashboards. Further details about the data source configurations and snapshot schemas can be found in the following sections of our documentation:
+Static data sources are useful when a market tracks a known set of contracts. In the current BDS market, snapshotter nodes track active Uniswap V3 pools on Ethereum mainnet and submit market-specific snapshots for DSV finalization.
 
-* [Building with Powerloom -- Uniswap V2 and V3 Dashboards](/build-with-powerloom/use-cases/existing-implementations/uniswap-dashboard/)
-* [Building with Powerloom -- Aave V3 Dashboard](/build-with-powerloom/use-cases/existing-implementations/aavev3-dashboard/)
-
-Continuing with the Uniswap V2 example, you can explore the data sources list defined as part of the Uniswap v2 specific configuration in the [`snapshotter-configs`](https://github.com/powerloom/snapshotter-configs/blob/fcf9b852bac9694258d7afcd8beeaa4cf961c65f/projects.example.json#L1-L11) repository.
+You can explore an older static configuration example in the [`snapshotter-configs`](https://github.com/powerloom/snapshotter-configs/blob/fcf9b852bac9694258d7afcd8beeaa4cf961c65f/projects.example.json#L1-L11) repository.
 
 ```json reference
 https://github.com/powerloom/snapshotter-configs/blob/fcf9b852bac9694258d7afcd8beeaa4cf961c65f/projects.example.json#L1-L11
 ```
 
-The `projects` field in the above configuration snippet represents the Uniswap v2 pair contract addresses that are tracked, and snapshots are generated for these contracts. To further understand how snapshots on these contracts are tracked, refer to the section on [Project Types and IDs](#project-types-and-ids).
+The `projects` field in the above configuration snippet represents contract addresses that are tracked, and snapshots are generated for those contracts. To further understand how snapshots on these contracts are tracked, refer to the section on [Project Types and IDs](#project-types-and-ids).
 
 ## Dynamic Data Sources