Skip to main content

Docs-Insights (Tatsu)

Docs-Insights (Tatsu) — a reference card for a crypto project: what the product does and how verifiable the project’s key claims are; also — alignment with the Decentralized AI thesis (DecAI Fit).

Docs-Insights (Tatsu) — an AI/Other | Infra project on Bittensor (subnet), token (symbol: —).

Disclaimer

Important: this page is a reference overview of the project. Within DecAIHub, we separately record a verification based on open sources within the AI thesis (what is real AI/onchain/why a token, and which sources this is based on).
This is not financial advice and not a recommendation to buy/sell/hold any asset. We do not assess price, returns, or entry/exit timing.
Conclusions are based on publicly available materials found as of the verification date. The absence of confirmation does not imply the absence of the technology.

TL;DR (for readers who are not into AI)

  • What it is: a Bittensor subnet (SN84) that performs “document understanding” tasks: OCR/vision/VLM/LLM pipelines for extracting information from documents and structuring the result.
  • Who it’s for: operators of Bittensor miners/validators and teams that need automated data extraction from documents.
  • Why onchain/token: the onchain part is the subnet mechanics on the Bittensor network (participation/incentives/weights); in the Dynamic TAO model the subnet has a subnet‑specific “alpha” token and TAO reserves (see Evidence).

How it works (very briefly)

  1. The user does: launches a subnet miner/validator following the repository instructions.
  2. The system does: the validator generates tasks (for example, synthetic images + ground truth) and sends them to miners.
  3. The user gets: recognition/classification/parsing results and an accuracy score that affects incentives.
  4. Where the blockchain is: the subnet’s parameters/participants and incentives are recorded as part of the Bittensor network (netuid 84).
  5. Token role (if any): an external project token (ERC‑20 etc.) is not recorded per Tier‑1; at the same time, the subnet on Bittensor has a subnet‑specific “alpha” token (Dynamic TAO) and an onchain incentive economy.

Quick links: AI thesis fit

Project passport

Field Value
Project name Docs-Insights (Tatsu)
Also known as (aliases) Document Understanding Subnet, SN84
Logo (logo) ../assets/438_docs-insight-tatsu_logo.svg
Token symbol (ticker) —
Category AI/Other | Infra
Primary chain (chain) Bittensor
Type Appchain
Network status mainnet
Consensus (consensus) —
Launch date (launch_date) —
Project status (status) active
Token (standard) native
Token contract Subnet netuid 84 (Bittensor)
Token model (token_type) —
Max supply —
Issuance —
Tokenomics (tokenomics, brief) subnet “alpha” token + TAO reserves/emissions (Dynamic TAO)
Governance —
Admins/keys —
Audit —
Bug bounty —
Team (team) —
Funding (investors/funding) —
AI component (ai_component) document understanding pipeline
Use‑case (use_case) OCR + VLM/LLM document parsing
DecAI Fit — AI thesis fit 5/6 — high alignment with the Decentralized AI thesis
DecAI Fit component summary 2 / 3 / 1 / 3
Last verified 2026-02-11

General project overview

Per Tier‑1 (README), the project describes a set of document understanding tasks (checkbox/text detection, document classification, document parsing, JSON structuring) and the architecture “validator generates task + ground truth → miner processes → validator scores”. There is a technical guide for launching a miner/validator.

Features/modules

  • A multi‑modal pipeline: vision models, language models, VLM, OCR.
  • Generation of synthetic tasks and ground truth on the validator side.
  • Quality evaluation by coordinates/text and rewarding of the best miners (per the description in the README).

Typical scenarios

  • Scenario 1: an operator launches a miner → receives tasks → returns the recognized document elements → receives a score.
  • Scenario 2: an operator launches a validator → generates tasks/ground truth → evaluates miners.

Getting started (wallet/network)

  • What you need: follow the Technical Guide in the repository (dependencies, tesseract for miners, the checkbox detector service).
  • Network/chain: Bittensor subnet netuid 84 (per taostats and the README).
  • Fees: depend on participation in the Bittensor network and infrastructure requirements.

Architecture/tech (non‑AI)

  • Components: validator + miner + preprocessing/OCR/vision model services.
  • Where logic runs: the models/pipeline run offchain; onchain — participation accounting and incentives of the Bittensor subnet.

Token/economics (expanded, no forecasts)

  • Economics: miner rewards are described in the README as a function of accuracy and of the gap to “second place”.
  • Subnet token (Dynamic TAO): the subnet has a subnet‑specific “alpha” token and TAO reserves (see Evidence); an external project token (ERC‑20 etc.) is not recorded per Tier‑1.

Governance

  • Not established per Tier‑1 as of the verification date.

Security and incidents

  • Audits / bug bounty / incidents: not established per Tier‑1.
  • Threat model: typical risks of a distributed offchain system (manipulation of results/ground truth, attacks on the validator/evaluation) and risks of the Bittensor subnet economics (attacks on scoring/incentives).

Project status and timeline

  • Current status: active; subnet on Bittensor mainnet.
  • Roadmap: not recorded by Tier‑1 as of the verification date (links_* has —).

Ecosystem/integrations

  • Ecosystem: participation is observable via the subnet’s onchain metrics (taostats); other integrations/partners are not recorded per Tier‑1.

AI component of the project

  • What is real AI here? Tier‑1 describes the use of CV/VLM/LLM and OCR for document understanding and extraction of structured data.
  • What is truly onchain? subnet netuid 84 on the Bittensor network (the onchain part of the incentive mechanics).
  • Why is a token needed? on Bittensor, subnet economics use TAO and the subnet‑specific “alpha” token (Dynamic TAO) for incentives/emission distribution.
  • Red flags (based on the information found): Technical_Guide.md contains an example of commands with a netuid that conflicts with the README (SN‑84) and taostats (probably an outdated/erroneous fragment of the document); for this card we record netuid 84 per the README and onchain observability.

DecAI Fit component summary

  • DecAI Fit: 5/6 — high alignment with the Decentralized AI thesis
Component Level Score
AI reality medium 2
Onchain necessity high 3
Token necessity low 1
Evidence Tier‑1 present 3
Details

AI reality

AI_0 — AI intent (Tier‑1 roadmap) (1/0)

  • AI_0 (decision): 0
  • Claim (one line): AI is described as a working pipeline (document understanding), not only an intent.
  • Evidence: Tier‑1 — https://github.com/TatsuProject/Document_Understanding_Subnet
  • Why sufficient / why not (one line): when a Tier‑1 description of the operation is available, the intent flag adds no signal.

AI_1 — what the AI does (1/0)

  • AI_1 (decision): 1
  • Claim (one line): recognizes/classifies/parses documents (OCR+vision+VLM+LLM) and returns a structured result.
  • Evidence: Tier‑1 — https://github.com/TatsuProject/Document_Understanding_Subnet
  • Why sufficient / why not (one line): the purpose and the tasks are listed in the README.

AI_2 — demos/examples (1/0)

  • AI_2 (decision): 0
  • Claim (one line): a public app/demo “what you can touch” is not recorded per Tier‑1.
  • Evidence: Tier‑1 — —
  • Why sufficient / why not (one line): there are instructions for launching nodes, but without a separate demo surface the flag is 0.

AI_3 — metrics/quality (1/0)

  • AI_3 (decision): 0
  • Metrics: —
  • Context (version/date/how measured): —
  • Evidence: Tier‑1 — —
  • Why sufficient / why not (one line): reproducible quality metrics with context (version/date/dataset) were not extracted in Tier‑1.

AI_4 — tech description/architecture/versions (1/0)

  • AI_4 (decision): 1
  • Claim (one line): the validator/miner architecture and the set of tasks (checkbox/doc-class/doc-parse) are described, as well as the launch steps.
  • Evidence: Tier‑1 — https://github.com/TatsuProject/Document_Understanding_Subnet ; https://raw.githubusercontent.com/TatsuProject/Document_Understanding_Subnet/main/docs/Technical_Guide.md
  • Why sufficient / why not (one line): there is a tech description and an operational guide.

Onchain necessity

OC_1 — contracts/addresses/chain (1/0)

  • OC_1 (decision): 1
  • Chain: Bittensor
  • Addresses/identifiers: subnet netuid 84
  • Evidence: Tier‑1 — https://taostats.io/subnets/84/chart
  • Why sufficient / why not (one line): taostats records the existence of the subnet on the Bittensor network.

OC_2 — onchain beyond just a token (1/0)

  • OC_2 (decision): 1
  • What useful logic is onchain: the onchain layer participates in the subnet mechanics (accounting/incentives/weights).
  • Evidence: Tier‑1 — https://taostats.io/subnets/84/chart
  • Why sufficient / why not (one line): the subnet is part of the Bittensor onchain network.

OC_3 — onchain is critical (1/0)

  • OC_3 (decision): 1
  • “Replace the blockchain” test: without onchain the trustless mechanics of distributing incentives/evaluation break down.
  • Evidence: Tier‑1 — https://docs.learnbittensor.org/subnets/understanding-subnets ; https://taostats.io/subnets/84/chart
  • Why sufficient / why not (one line): the subnet’s incentive network relies on onchain state.

Token necessity

TK_0 — no token (1/0)

  • TK_0 (decision): 0
  • Claim (one line): on Bittensor the subnet has a subnet‑specific “alpha” token (Dynamic TAO); an external project token (ERC‑20 etc.) is not recorded per Tier‑1.
  • Evidence: Tier‑1 — https://docs.learnbittensor.org/subnets/understanding-subnets
  • Why sufficient / why not (one line): “no token” is incorrect for a subnet; at the same time, a separate external project token is not established.

TK_1..TK_4 (1/0)

TK_1 — payment for the service (1/0)

  • TK_1 (decision): 0
  • Claim (one line): payment for the service with the project token is not established per Tier‑1.
  • Evidence: Tier‑1 — —
  • Why sufficient / why not (one line): there is no Tier‑1 description of pay‑per‑call on the project token.

TK_2 — incentives/collateral/penalties (1/0)

  • TK_2 (decision): 1
  • Claim (one line): subnet economics distribute emissions/incentives and rely on the onchain mechanics of Bittensor (Dynamic TAO).
  • Evidence: Tier‑1 — https://docs.learnbittensor.org/subnets/understanding-subnets ; https://taostats.io/subnets/84/chart
  • Why sufficient / why not (one line): Tier‑1 docs describe incentives/emissions in subnets; taostats confirms the specific netuid.

TK_3 — governance (1/0)

  • TK_3 (decision): 0
  • Claim (one line): the governance role of the project token is not established per Tier‑1.
  • Evidence: Tier‑1 — —
  • Why sufficient / why not (one line): there is no Tier‑1 description of governance via the project token.

TK_4 — token is replaceable (1/0)

  • TK_4 (decision): 0
  • Claim (one line): the replaceability of the token/subnet economics with an alternative model is not established per Tier‑1.
  • Evidence: Tier‑1 — —
  • Why sufficient / why not (one line): for subnets, the role of the token/TAO is built into the Bittensor economy; a conclusion about replaceability requires separate analysis.

Evidence (table)

Tier Source What it proves
Tier‑1 https://github.com/TatsuProject/Document_Understanding_Subnet Tier‑1 description of the subnet’s tasks and architecture (validator/miner + model pipelines).
Tier‑1 https://raw.githubusercontent.com/TatsuProject/Document_Understanding_Subnet/main/docs/Technical_Guide.md Tier‑1 technical guide for launching a miner/validator and the dependencies.
Tier‑1 https://docs.learnbittensor.org/subnets/understanding-subnets Tier‑1 description of Bittensor subnets: onchain consensus/emissions/incentives; subnet‑specific “alpha” tokens (Dynamic TAO).
Tier‑1 https://taostats.io/subnets/84/chart Onchain fact of the existence of subnet netuid 84.
Tier‑2 https://www.coingecko.com/en/coins/docs-insight-tatsu Reference profile and link navigation.
Tier‑2 https://coinmarketcap.com/currencies/docs-insight-tatsu/ Reference profile and link navigation.