> ## Documentation Index
> Fetch the complete documentation index at: https://docs.mixpeek.com/docs/llms.txt
> Use this file to discover all available pages before exploring further.
# Explore the sample data
> Run real multimodal queries against a live sample namespace — no account, no API key, no setup
The fastest way to understand Mixpeek is to run it. **`sample-data`** is a live
namespace loaded with real content — video, ad creatives, PDFs, and a product
catalog, already extracted and searchable — and the retrievers below are published
publicly, so **every example on this page runs with no account and no API key**.
Copy any `curl` here into a terminal right now. It will return real results.
It is also the working version of the two diagrams on the
[Introduction](/docs/overview/introduction) page: how content decomposes into layers,
and how a retriever reassembles those layers at query time.
## Run your first query
No `Authorization` header. No `X-Namespace`. Just a query.
```bash cURL theme={null}
curl -X POST "https://api.mixpeek.com/v1/public/retrievers/sample-document-knowledge/execute" \
-H "Content-Type: application/json" \
-d '{
"inputs": { "query": "chevron quarterly revenue" },
"pagination": { "method": "offset", "page_size": 10, "page_number": 1 }
}'
```
```python Python theme={null}
import requests
resp = requests.post(
"https://api.mixpeek.com/v1/public/retrievers/sample-document-knowledge/execute",
json={
"inputs": {"query": "chevron quarterly revenue"},
"pagination": {"method": "offset", "page_size": 10, "page_number": 1},
},
)
for hit in resp.json()["results"]:
print(hit["score"], hit["title"], "—", hit["description"][:60])
```
```javascript JavaScript theme={null}
const resp = await fetch(
'https://api.mixpeek.com/v1/public/retrievers/sample-document-knowledge/execute',
{
method: 'POST',
headers: { 'Content-Type': 'application/json' },
body: JSON.stringify({
inputs: { query: 'chevron quarterly revenue' },
pagination: { method: 'offset', page_size: 10, page_number: 1 },
}),
}
);
const { results } = await resp.json();
```
On this **public** path, hits come back under **`results`**. This differs from the
authenticated path — `POST /v1/retrievers/{retriever_id}/execute` returns hits
under `documents`, where `results` is a deprecated field that is no longer
populated. Read the field that matches the path you called, or you will parse an
empty list from a working query.
## Diagram 1 — how content decomposes
The first diagram on the Introduction page (source → temporal segments → detected
entities) is a real two-tier pipeline here. Each bucket is extracted into a
**tier-0** collection, and tier-0 is extracted *again* into a **tier-1**
collection — the layer you actually search.
| Bucket | Tier 0 — segments | Tier 1 — entities |
| ------------------ | ---------------------------------------------------------------- | --------------------------------------------------------------------------------- |
| `video-library` | `video-scenes` — scene segments with transcript + on-screen text | `scene-entities` — faces per scene (512-d ArcFace, with crops and bounding boxes) |
| `ad-creatives` | `ad-visual` — creative-level embeddings | `ad-entities` — faces per creative |
| `document-archive` | `document-text` — PDF text + embeddings | `document-graph` — a knowledge graph: **7 PDFs fan out into 59 nodes** |
| `product-catalog` | `product-images` (SigLIP) and `product-text` (E5) | `product-attributes` — structured attributes per product |
The `document-archive` row is the clearest illustration: decomposition is a real
**one-to-many fan-out**, not a reformat. Seven PDFs become 59 independently
searchable nodes — and each node still knows which PDF it came from, which is what
makes the next section work.
## Diagram 2 — how retrieval reassembles
The second diagram (query → vector search → entity filter → similarity rank →
enrich) is exactly what **Scene Moment Reassembly** does. The other three apply the
same reassembly idea to different content. Every one is runnable as-is.
`sample-scene-reassembly` — all four stages in the diagram's order:
`feature_search` (vector) → `attribute_filter` (genre) → `rerank`
(cross-encoder) → `document_enrich` (join the tier-1 faces back in).
```json theme={null}
{ "inputs": { "query": "functions in C programming" } }
```
Returns 8 scene moments — `title`, `description`, `start_time`/`end_time`,
`genre` — each carrying a `face_crop_url` for the person detected **in that
scene**. That join is the whole point: the tier-0 scene and its tier-1 entities
come back reassembled into one result, so you get "who is on screen, and when."
`sample-person-across-media` — `feature_search` over ArcFace embeddings spanning
**two buckets' tier-1 collections** (`scene-entities` + `ad-entities`) →
`document_enrich` to join back to the source.
```json theme={null}
{
"inputs": {
"query_image": "https://mixpeek-public-demo.s3.us-east-2.amazonaws.com/demo-faces/mixpeek-brand-reel-face.jpg"
}
}
```
Returns **2 hits with different `title`s** — *Pipeline is product reel* and
*Vector DB scam reel*. That is the lesson: the same person found across two
**different** documents, not a single self-match.
Swap in any face image URL. A face that does not appear in the sample content
correctly returns nothing — that is reverse-face search working, not failing.
This retriever needs an image; a text query has no face to embed.
`sample-document-knowledge` — `feature_search` over the graph **nodes** →
`document_enrich` to join back to the parent PDF.
```json theme={null}
{ "inputs": { "query": "chevron quarterly revenue" } }
```
Each hit's `description` is the matched **node** text and `object_type` tells you
what it is (e.g. `paragraph`) — but `title` is the **parent document**
(*Chevron Financial Filing*). You search fine-grained pieces and still get the
source back. Several hits often share one parent: that is the 7-PDFs-to-59-nodes
fan-out from Diagram 1, seen from the query side.
`sample-hybrid-catalog` — a single `feature_search` running **two modalities at
once** (SigLIP text-to-image over `product-images` + E5 text over
`product-text`), fused with [RRF](/docs/relevance/fusion-strategies).
```json theme={null}
{ "inputs": { "query": "adjustable LED lamp" } }
```
Returns products with `product_name`, `price`, `category`, and `description`.
A product can appear from **both** its imagery and its text — the same item
reached down two independent paths and merged into one ranking.
RRF scores are rank-based (all hits land near `0.017`), so read the **order**,
not the magnitude — the score is not a similarity. The sample catalog is small
(8 products), so a broad query returns most of it; ranking is what changes.
Media fields (`thumbnail_url`, `video_segment_url`, `face_crop_url`) are signed
URLs minted fresh on every request and expire after about a day. The fields are
always present — just don't expect a URL you copied yesterday to still resolve.
## Make it yours
These pipelines use the same stages you would configure yourself. Fork the
namespace in Studio for an editable copy, or read how the pieces work:
Compose search stages into a pipeline
How content is decomposed into searchable layers