---
title: Signals, Briefs and Records
category: read
summary: Know what each part of a Manifest is for, read it cheaply first, and go deeper only when the answer needs it.
order: 13
updated: 2026-10-07
next: present-manifests-to-your-users
related: manifest-anatomy-field-guide, charts-tables-and-infographics
reference: /docs/api, /agent-guide.md
---

Every source item Synorb ingests becomes one **Record**, and that Record normally yields one **Manifest**, one **Signal** and one **Brief**. They are three views of the same source, built for different readers.

## When to use this

Use this guide before you write any code that reads a Manifest. It decides what you read, what you show, and when you pay the cost of reading more.

| Part | Built for | Use it to | Where it lives |
| --- | --- | --- | --- |
| **Signal** | Your reasoning | Extract atomic Claims, check facts, compare numbers, and decide what matters | `signal.body.claims[]`, plus `claims_summary` and `claims_rollup` |
| **Brief** | Your user's eyes | Write the human narrative: what happened and why it matters | `brief.summary`, `brief.body`, `brief.body_markdown` |
| **Record** | Verbatim source text | Quote exactly, resolve a thin Brief, or audit | `record.content` (plan-gated) |

Read in that order: Signal and Brief headlines first, the Brief body for the stories you will show, and the Record only when you must. Most answers never need the Record.

## Smallest working call

Scan first. `compact` is on by default and returns Claim counts, a short Signal preview, and the Brief's scan fields (`tldr`, `facts`, `why_it_matters`, `timeline`, `unresolved`). Keep `target_count` small.

```mcp billed
synorb-manifests
{"stream_ids": ["STREAM_ID"], "days": 2, "target_count": 3, "compact": true}
```

Then go deeper on the one or two Manifests you will show. Ask for full bodies on a small result set. Use the agent-friendly Markdown layout:

```mcp billed
synorb-manifests
{"stream_ids": ["STREAM_ID"], "days": 2, "target_count": 2, "compact": false, "markdown_version": "2"}
```

Over REST, the same pull is `POST /manifests/query`, and a single Manifest is a direct read by its ID:

```bash
curl -sS "https://api.synorb.com/manifests/by-id/MANIFEST_ID" \
  -H "Authorization: Bearer $SYNORB_KEY"
```

## What you get back

A Manifest has this shape. Values here are illustrative, and the field names are the live contract.

```json response
{
  "manifest_id": "...",
  "record_id": "...",
  "stream_names": ["..."],
  "published_date": "2026-10-06",
  "source": {
    "source_name": "...",
    "source_channel_display": "...",
    "source_url": "https://...",
    "source_class": "company_first_party",
    "content_quality": "sufficient"
  },
  "signal": {
    "headline": "...",
    "summary": "...",
    "significance": "high",
    "claim_count": 18,
    "body": {"claims": [], "claims_summary": "...", "claims_rollup": {"total_claims": 18}}
  },
  "brief": {
    "headline": "...",
    "summary": "...",
    "body": {"tldr": "...", "facts": [{"label": "...", "value": "..."}], "why_it_matters": "..."},
    "body_markdown": "## TL;DR\n..."
  },
  "record": {"content": "..."}
}
```

Alongside the Manifests, a delivery also has `presentation_items[]` and a `render` hint. They are already shaped for people. The next guide uses them.

### Reading each part well

- **Signal Claims** are atomic assertions, typically 15 to 50 per source. Each Claim has these keys:
  - `claim_text`: one self-contained sentence.
  - `claim_type`: `statement`, `data`, `event`, `forecast` or `analysis`.
  - `confidence`: `stated`, `implied`, `inferred` or `measured`.
  - `evidence`: `direct_quote`, `paraphrase`, `derived` or `observed`.
  - `quote`: the exact words, for a direct quote.
  - `claim_id`: the server adds it at delivery.

  Use `claims_rollup` for a quick profile. A source that is mostly `direct_quote` is a different type of evidence than a source that is mostly `inferred`. Read each key defensively, because not every Claim fills every key.
- In compact output, `facts` (up to three), `timeline` and `unresolved` sit directly on `brief`. In full output (`compact: false`) they sit in `brief.body`.
- **Brief** fields are `tldr` (one-sentence scan), `why_it_matters`, `facts` (source-traceable `label` and `value` pairs), `timeline` (dated events) and `unresolved` (explicit unknowns). Audio and podcast Briefs add guest details, takeaways and cross-promotion. The server omits empty sections, so rely on field names and never on presence.
- **Record** content is the full source text. The Startup and Enterprise plans include it. Below those plans, the Record fields are marked as plan-gated. They are not empty.
- **`source.content_quality`** is `sufficient` or `thin` and is available on every plan. It sits under `source`, not at the top of the Manifest. A `thin` Manifest means the Brief alone does not give a real story. Read the Record before you write, if your plan includes it. Otherwise read the cited source.

Write parsers that ignore unknown JSON keys and unrecognized `##` sections. Existing Brief fields never change name or type. New fields can appear.

## Failure modes

| Symptom | Cause | What to do |
| --- | --- | --- |
| `brief` is missing for one item | Brief generation produced nothing for it | Build from the Signal (`headline`, `summary`, Claims) and say less. Every plan includes Briefs. |
| `record` fields are marked plan-gated | Records are on Startup and Enterprise | Rely on the Signal and Brief, or open the cited `source_url`. |
| `content_quality: "thin"` | The extraction was short | Read further before you write. Do not pad a bare headline into a story. |
| `signal.body.claims` is absent | You asked for `compact` output | Re-request that Manifest with `compact: false`. |
| `facts` or `timeline` missing | Not every Brief family fills them | Skip that element. Do not fabricate it. |
| Duplicate stories across Streams | One source can route to several Streams | Dedupe on `manifest_id`, and group same-story Manifests into one item. |
| `synorb-records` suggested somewhere | That tool is a legacy raw read on the Advanced profile | Prefer `synorb-manifests`. |

## Make it good for your user

Your user never asked to read a Manifest. They asked to know what is going on.

Treat the Signal as your notes. Treat the Brief as the article you write from the notes. Treat the Record as the footnote you check only when needed. Show the narrative and the link, not the machinery. Never paste raw Manifest or Signal JSON at a person.

## Next guide

[Present Manifests to your users](/agent-resources/present-manifests-to-your-users): turn what you read into an update that your user enjoys reading.