Documentation rebuilt around the reader
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.
Find your track, in your language, at your depth.
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.
- Audience tracks
- Six
- Naming
- Product, not codename
- Reference
- Generated
- Drift
- Blocked in CI
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 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 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.
- 1The platform
The error registry and the API contract that the live API, SDK, and CLI already run on. One source of truth.
- 2Generated reference
The error reference and the OpenAPI surface render from that source on every build, so they cannot be hand-edited out of step.
- 3What you receive
Every error code in the docs carries the same message, an explanation of the cause, and a focused fix that you get on the wire.
- 4Drift check
Continuous integration regenerates the reference and fails the build if it differs from the platform, so the page cannot quietly go stale.
Why this is better for you
- Every audience landed in the same feature catalog and had to translate it.
- Pages used internal codenames that did not match the console or the contracts.
- The API and error reference were hand-maintained, so they drifted from the platform.
- Passive, jargon-heavy prose that buried the answer.
- Your role has a track in your language, at the depth your job needs.
- One canonical name per system, matching the console and the contracts.
- The API and error reference generate from the running platform and cannot drift.
- Plain active voice that opens with why a section matters to you, then shows you how.