> For the complete documentation index, see [llms.txt](https://docs.canhav.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.canhav.com/getting-started/two-tracks.md).

# The two ideation tracks

**Available now.** The studio, draft editors, public project and token design pages, the Explore board and optional linking are live on the product site (testnet).

CanHav Projects has two tracks: **Product** and **Token**. They are independent by design.

## Independence

* You can start from either end.
* Neither track gates the other.
* You can optionally **link** a product to a token design (or leave them unlinked).
* A **product with no token** is a legitimate outcome.
* A **token designed but never deployed** is also a legitimate outcome.

The point is to make the design document honest before anyone confuses a plan with a live market.

## How linking works

Linking is optional and owned by you in studio.

1. Open a project or token design editor. The link panel lists entities you own.
2. Create a link only when you own both sides. v1 linking is **one-to-one** (one project to one token design). You can link an existing record or create the other one and link it in one step.
3. Once **both** sides are published, each public page shows a cross-card to the other entity (`/p/...` ↔ `/t/...`).
4. Credibility signals stay scoped to the entity they belong to. Linking does **not** copy project verify signals onto the token page, or float/unlock metrics onto the project page.

Unlinking, from the same panel, removes the cross-reference. It does not delete either document.

A project can also be linked to a **launched token**, which is a separate link. See [Projects and launches](/token-launch/projects-and-launches.md).

See [Public pages](/public-pages/public-pages.md).

## Product track

Captures what you are building: sector, what it does, users and payers, why this chain, stage, contract architecture, worst-case bug impact, and security status declarations.

See [Product track](/product-track/product-track.md).

## Token track

Eight sections: token rationale, supply and allocation, vesting and lockups, distribution, market, governance, legal, and post-launch. The platform computes float, unlock calendars, and warnings from those answers.

See [Token track](/token-track-ideation/token-track.md), [Computed outputs](/token-track-ideation/computed-outputs.md), and [Warnings](/token-track-ideation/warnings.md).

## Three answer types

Both tracks use the same answer model: decisions you make, outputs the platform computes, and status declarations for work that may live elsewhere. See [The three answer types](/getting-started/three-answer-types.md).

## Studio and publish

You draft in the [studio](/studio/studio.md) (`/studio`), publish snapshots to public pages (`/p/...` for projects, `/t/...` for token designs), and optionally attach a deployed token address to a published design. Explore has two views, Tokens and Projects; published token designs are not on the board. Details: [Public pages](/public-pages/public-pages.md) and [Deploy paths](/token-launch/deploy-paths.md).

Studio editing requires an [account](/accounts/clerk-accounts.md). Reading published pages does not.


---

# 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.canhav.com/getting-started/two-tracks.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.