# Documentation rebuilt around the reader
Source: https://docs.settlemint.com/docs/changelog/dalp-3-0/documentation
DALP 3.0 splits docs into six audience tracks so each role reads pages written for their job, not a shared feature dump.
**DALP 3.0 ships six audience tracks, one per role. Each track uses the product's real names throughout and links to a reference generated from the running platform.**
The old docs were organized the way the product was built, one growing pile of feature pages. A bank evaluating DALP, an architect designing a deployment, an operator running a book, and an integrator writing code all landed in the same place and had to translate it into their own job. The 3.0 documentation starts from the reader instead.
Documentation now opens into six tracks, one per audience, so you read pages written for your role rather than wading through everything. Each track follows one discipline: it opens with why a thing matters to you, then teaches the mechanism, in plain active language. The reference under it generates from the platform itself, so what you read matches what the platform returns.
## Six tracks, one per audience [#six-tracks-one-per-audience]
The single biggest change is structure. Instead of one feature catalog, the docs split into tracks aimed at the people who actually use them. You go to your track and find the depth and vocabulary your job needs.
For the team deciding whether and how to adopt DALP. What the platform does, the asset classes it covers, the use cases it serves, and the compliance posture behind them, in business terms.
For the people designing the deployment. The system map, component relationships, end-to-end flows, and self-hosting and high-availability guidance.
For the team running the book day to day. Asset creation, compliance operations, user management, asset servicing, platform setup, and runbooks for the recurring work.
For the people integrating. The CLI, the SDK, the API, data feeds, and runbooks that walk a real integration from first call to production.
For auditors and risk owners. How compliance is enforced on-chain, the identity model, privacy handling, the security posture, and source verification.
For anyone calling the platform. Authentication, request headers, the typed error reference, webhooks, and the full token and settlement surface, with a generated OpenAPI client.
## The docs speak the product's language [#the-docs-speak-the-products-language]
The platform was mapped end to end, and every system and subsystem was given one canonical name. The docs now use those names throughout: Asset Registry, Compliance and Identity, the Transaction Lifecycle Engine, Custody and Settlement, the Ledger Index, Market Data, the Operations Console, and the Core Platform. The name you read in a guide is the name you see in the console and the name on the contract. No internal codename to decode, and no mismatch between a screen, a doc, and an API. For a client, that means one vocabulary across the product, the documentation, and a support conversation.
## A reference you can trust, not just read [#a-reference-you-can-trust-not-just-read]
A reference is only useful if you can rely on it. The pages that describe the API and the error surface no longer come from someone remembering to update them. They generate from the platform itself.
## Why this is better for you [#why-this-is-better-for-you]
[Browse the documentation →](https://docs.settlemint.com)