> For the complete documentation index, see [llms.txt](https://docs.scanbylens.xyz/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.scanbylens.xyz/business/roadmap.md).

# Roadmap

Three phases, three gates. A gate is a checklist, not a date.

The order follows one constraint: **a track record cannot be backfilled.** So calls and public posting start first, coverage and distribution come next, and money and the token come last, once the scorecard can speak for itself.

Each phase ends at a gate. A gate is a checklist, not a date: if it is not met, the next phase waits.

## Live today

* The engine: immutable capture, the factor state store, the mechanism graph, the divergence engine, the tool layer and verified narration.
* The desk: product-first, with the live pulse, evidence blocks streamed as they are gathered, and answers with Answer, Evidence and Steps.
* Nine agents over one engine, including Watches and Claim Check.
* **The call:** every market and token read ends in one call or a counted no call, recorded in an append-only table.
* **Liquidation capture:** Bybit (complete) and Binance (sampled), live, with honest hourly coverage.

## Phase 1: the scored desk

* Post every call publicly as it is made, to the site's call log and a public channel.
* Resolve and score calls at their horizon; publish the first monthly scorecard, misses first.
* A "verify a call" page linking each call to its data, post and outcome.
* Email and Google sign-in; daily caps and bot checks for free deep research.
* Telegram and email delivery for Watches; a public status page.
* Macro inputs widened: oil, the 2-year yield, the CPI and FOMC calendar.

**Gate:** every call posted as made, two monthly scorecards published, calibration measured and published, user retention baseline measured.

## Phase 2: coverage and distribution

* The top 50 perpetual markets across Binance, Bybit, OKX and Hyperliquid.
* Licensed cross-venue liquidation, open-interest, order-book and ETF-flow data; auto-deleveraging data.
* Incident Mechanics as the flagship: a brief within 48 hours of every major break, and a permanent incident archive.
* Claim Check on Telegram and on X when tagged, from a labelled automated account; a public "most-checked claims" feed.
* A free, standard MCP server, listed in the official registry and offered to agent platforms.
* Design partners: Market State and Claim Check widgets for exchanges, wallets and terminals.
* Results published on open crypto-analysis benchmarks.

**Gate:** three or more incident briefs within 48 hours, Claim Check live on Telegram and X, at least one live integration, 99% published uptime.

## Phase 3: business and token

* Business lines: API and MCP volume, team desks, data licensing.
* Five or more live integrations and an unbroken public record since the first call.
* $LENS launch, only if the token has a job the product needs, after securities counsel review, an independent audit, public vesting streams and the disclosure policy.

**Gate:** calls at each confidence level come true at about that rate (calls at 70% about 70% of the time), five integrations live, 99.5% uptime.

## Metrics we will report

| Metric                                        | What it shows                                  |
| --------------------------------------------- | ---------------------------------------------- |
| Calls posted publicly as made                 | Whether the record is complete                 |
| Monthly scorecards published, misses included | Whether the record is honest                   |
| Hit rate by confidence level                  | Whether the desk is calibrated                 |
| Weekly users active on two or more days       | Whether people come back                       |
| Claim checks per week                         | Whether the desk is useful where claims spread |
| Incident briefs within 48 hours               | Whether the flagship delivers                  |
| Published 30-day uptime                       | Whether agents can rely on it                  |


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.scanbylens.xyz/business/roadmap.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.