Every figure,cited.
Prepared datasets for hedge funds and alternative asset managers. Point-in-time history, a source on every field, and a license that says in writing what you may do with it in a model.
https://mcp.deltadeskdata.com/sandboxAdd this to Claude, ChatGPT, or Copilot with a trial key. The key takes thirty seconds and arrives by email. Setup and examples
Prepared datasets. Ready to deploy.
What we publish arrives production-ready: sourced, cleaned, mapped, documented and licensed, with defined history, identifiers and provenance. What is still in preparation is listed with its figures marked unconfirmed rather than invented.
5 of 5 datasets
Available now
In preparation
Need a dataset that is not listed?
Tell us what you need. We will find it, test it against your use case, license it, and show you a sample.
Already a Delta Desk client? Ask your engineer. Any dataset here can be live in your environment this week.
Fourteen days. Three ways in.
One form. Everything arrives by email. No call, and nobody follows up unless you ask.
MCP key
Connect Claude, ChatGPT, Copilot, or any MCP client to the sandbox endpoint. 10,000 advisers, history from 2022, 60 queries an hour.
API key
REST access to the same slice. Search, history, and field-source endpoints. OpenAPI document included. 1,000 calls a day.
Sample dataset
5,000 rows from the dataset you choose, as Parquet and CSV, with the full data dictionary. Load it into Snowflake or a notebook and inspect the preparation yourself.
Trials use a work email. Keys expire after fourteen days and can be renewed once. The trial license permits evaluation only. Query logs are kept to enforce limits and to decide which datasets to prepare next.
FORM ADV Part 1A
Meridian Crest Capital LP
288401 New York, NY
$4,213,600,000
14
3
04/14/2026
| Field | Value | Source |
|---|---|---|
| Adviser | Meridian Crest Capital LP | |
| CRD | 288401 | |
| Principal office | New York, NY | |
| Regulatory AUM | $4,213,600,000 | |
| Clients | 14 | |
| Private funds | 3 | |
| Known on | 2026-04-14 |
Every value we deliver knows where it came from, and the date it became knowable.
Clean is not the same as ready.
A model cannot tell when a field is ambiguous, so it answers with confidence and it is wrong. We hold every dataset we publish to six conditions, and apply the same six to client data. Every dataset page publishes its coverage, history, sources, identifiers and license terms, alongside the limits we already know about.
Identified
Every entity has one stable key, mapped to ticker, ISIN, CUSIP, LEI, CIK, and to your own security master. Every field has a definition, its units, and its permitted values.
Sourced
Every field records the document it came from and the date it was retrieved. Any answer traces back to a page.
Point-in-time
History holds the value that was available on each date. A backtest sees only what was knowable. No look-ahead, no survivorship.
Retrievable
Text is segmented so each part keeps its context. Tables stay tables. Embeddings are refreshed when the source changes.
Governed
Access control, lineage, and a change log are in place at delivery. Corrections are issued in public, with dates.
Licensed
The agreement states in writing what you may do in a model, in a derived product, and in a client report. Nothing is left to interpretation.
Ask any data vendor for these six in writing, ours included. The answer should be a document, not a conversation.
Things that go wrong, and how to tell.
Most AI projects on the buy side do not fail on the model. They fail on nine decisions made early, usually by default. Here they are, each with a test you can run this week without us.
01
Putting numbers in a vector database
The mistake. Adviser records, positions, and AUM figures loaded into a vector store, then the assistant is asked to find advisers over $1 billion in New York.
What happens. A vector index answers “what is this about.” It cannot filter, sum, join, or match exactly. It returns advisers near the words “large” and “New York” and misses half the real answers.
What we do. Anything you would put in a WHERE clause or a SUM lives in a relational store. Anything described as “about” or “similar to” lives in a vector store. Most real questions need both: filter in SQL, rank by vector, join on the identifier.
TestWrite the question in plain English. If it contains a number, a date range, a comparison, or a count, part of it is SQL. If your system has no SQL in the path, it is guessing.
02
Picking the embedding model that came with the platform
The mistake. The default model from the AI vendor, chosen the way one picks a database driver.
What happens. A model trained on web text places “we reduced our delta exposure” near airline content. It truncates silently at its token limit, so the qualifying footnote is never embedded. When the vendor retires the model, the whole corpus must be re-embedded, because vectors from different models cannot be mixed.
What we do. Start from a strong general model and adapt it on financial text and on question-passage pairs your analysts wrote. Prefer a model you can run yourself, so the retirement date is your decision. Record the model version on every vector.
TestSearch twenty terms that mean one thing in finance and another thing everywhere else. Count how many top-five results are about the other thing.
03
Choosing chunk size by token count
The mistake. Every document cut into 500-token pieces with 50 tokens of overlap, because a tutorial said so.
What happens. Too small, and a side letter's MFN clause is separated from the carve-out in the next paragraph that reverses it. Too large, and the answering sentence is five percent of the chunk, so the embedding describes the general subject and the match is weak. Either way the passage is about the right topic and says the wrong thing.
What we do. Segment by structure: clause, section, table, footnote. A small segment for matching, the parent returned for reading, so the qualifier travels with the claim. Tables are never flattened into prose.
TestTake twenty questions. For each, find the sentence that answers it and the sentence that qualifies it. Check whether both landed in the same segment.
04
Trusting today's value for yesterday's question
The mistake. A backtest or a diligence memo reads a manager's AUM history from a table that stores only the current figure for each period.
What happens. Firms restate. A figure filed in March 2025 replaces the one filed in March 2024 for the same period. Your model sees the corrected number on a date when nobody could have known it. The backtest looks better than any real strategy could have been.
What we do. Every row carries a known-on date and a superseded-on date. “What was true on 2024-06-30” is a query, not an assumption. De-registered firms stay in the history.
TestPick a figure you know was restated. Query your system as of a date before the restatement. If it returns the restated value, every historical analysis on that system is optimistic.
05
Expecting an embedding to find a CUSIP
The mistake. A vector-only index asked to retrieve documents about 037833100.
What happens. Identifiers are strings with no meaning. The model has no idea this one refers to a specific company. It returns passages with similar-looking numbers about other companies.
What we do. Every index is hybrid. A keyword index for exact terms and identifiers, a vector index for meaning, and a fusion step that combines the two rankings.
TestSearch fifty identifiers you know are in the corpus. Count the misses.
06
Never scoring the retrieval system
The mistake. The system returned plausible passages in a demo, and nobody has measured it since.
What happens. Every later change, a new model, a new chunk size, a new document type, is judged by whether the demo still looks good. The system drifts and nobody knows which way.
What we do. Two hundred question-passage pairs written by the analysts who will use the system, before any model is chosen. Recall at five and at ten, run before and after every change.
TestAsk who owns the evaluation set and when it last ran. If the answer is a memory of a demo, there is no evaluation set.
07
Letting the vector store decide who sees what
The mistake. One index for the whole firm, because the assistant “only retrieves what is relevant.”
What happens. Vector stores have no row-level security. A junior analyst asks about compensation and retrieves the passage from the CIO's memo. The assistant quotes it, with a citation.
What we do. Every segment carries the access control of its source document as metadata. Permissions are applied as a filter before ranking, using the identity of the person asking.
TestLog in as the most junior user with access. Ask about the most sensitive topic you can think of. Read what comes back.
08
Fine-tuning a model to teach it facts
The mistake. Three months fine-tuning a model on fund documents so it will “know” them.
What happens. Fine-tuning changes how a model writes far more reliably than what it knows. The tuned model gives fluent, house-style answers about the documents, some of them invented, with no citation, because there is no retrieved passage to cite.
What we do. Retrieval for facts, fine-tuning for form. A memo in your template, a classification into your taxonomy, an extraction from a weekly document: tuning earns its cost. “Answer questions about our documents” does not.
TestAsk the tuned model a question whose answer is in one document. Then ask it to cite the page.
09
Embedding a document once
The mistake. The corpus was embedded at launch. Documents have been amended since. The embeddings have not.
What happens. The assistant retrieves a segment from the version of the LPA that was superseded eight months ago, and answers from it with confidence.
What we do. Every segment stores a hash of its source. When the source changes, the affected segments are re-embedded and the old vectors retired. Every vector records the model that produced it.
TestFind a document you know was amended after launch. Ask a question whose answer changed. See which version answers.
These nine are the first things we check on any engagement. Most systems fail four of them.
Have us check yoursWe turn messy data into usable infrastructure.
From migration and entity resolution to extraction, retrieval and integrations, we build the systems that make difficult data reliable enough to answer with.
Fixed-price pilot · Two to six weeks
01Snowflake conversion and hosting
Migration and preparation as one project. Also on Azure.
Point-in-time schema · Reconciliation · Semantic layer
Snowflake conversion and hosting
Migration and preparation as one project. Also on Azure.
Point-in-time schema, reconciliation against the source, and a semantic layer over the top. If you would rather not staff the administration, we run that as well.
You get
- Point-in-time schema
- Reconciliation against the source
- Semantic layer
- Administration, if you want it
02Entity resolution
Four strings, one company.
Cross-reference · Hierarchy · Review queue
Entity resolution
Four strings, one company.
We build and maintain the cross-reference, the corporate hierarchy, and the review queue for uncertain matches. It is the usual reason an AI project stalls.
You get
- Cross-reference table
- Corporate hierarchy
- Review queue for uncertain matches
03Document extraction
Documents into scored, sourced fields.
Fields · Confidence · Source
Document extraction
Documents into scored, sourced fields.
Filings, offering documents, side letters, capital account statements and questionnaires, read into fields. Every value carries a confidence score and a link to the page it came from.
You get
- Extracted fields
- A confidence score on every value
- A link back to the source page
04Embeddings and retrieval
Search that understands structure.
Hybrid search · Reranker · Test set
Embeddings and retrieval
Search that understands structure.
Hybrid search, a reranker and structure-aware chunking, measured against a test set your analysts wrote, so an improvement is a number rather than an impression. We tell you when fine-tuning is worth it. It usually is not.
You get
- Hybrid index and reranker
- Structure-aware chunking
- A test set your analysts wrote
05MCP servers
Controlled access from Claude, ChatGPT or Copilot.
Permissions · Read-only default · Audit log
MCP servers
Controlled access from Claude, ChatGPT or Copilot.
Your OMS, warehouse and documents, reachable from the assistants your team already uses. Permission model first, read-only by default, and every call logged.
06Integrations
One view across fragmented systems.
Prime broker · Administrator · CRM
Integrations
One view across fragmented systems.
Prime broker and custodian files into one view. Administrator data into your reporting. CRM and investor records into one record, including reconciliation where two systems disagree.
You get
- One reconciled view
- Administrator data in your reporting
- An exception report where systems disagree
Field notes
Short answers to the questions we are asked most, each with a test you can run without us.
You own data. We will make it sellable.
Operational records, a research archive, reference tables. Somebody in this industry will pay for them, and very few firms want to build a data business to find out who. We check the rights first, prepare the data to the six conditions above, then package it, price it, list it, and sell it. You keep the rights.
We will tell you when a dataset is not sellable. That answer is free, and it is often the correct one.
We have sat in your chair.
Delta Desk was founded by a former hedge fund CTO. We work only with alternative asset managers and the firms that serve them. Nobody here needs an explanation of how a prime broker file arrives, why a point-in-time schema matters, or what a CCO asks before a dataset is approved.
All preparation, hosting, and support is performed in the United States by Delta Desk employees, in New York and Atlanta. We do not offshore data handling and we do not train models on client data.