Meetings and extraction
Cockpit stores meetings and other activity as rows, then proposes CRM changes from them. You accept or reject the proposals. The product does not auto-create a contact from a single fuzzy name.
What you see in the app
| Screen | What it is |
|---|---|
Calendar (/calendar) | Month, day, multi-day, and list views of events. /timeline redirects here |
Activities (/activities) | Ingested mail, calendar, meetings, and other activity. Filter by type, quality, whether it is linked, and date |
Meeting pipeline (/meeting-pipeline) | Health of the ingest lane. It is not the review queue |
KG Health (/health) | Counts and extraction gaps. It is not the review queue |
| Approvals | The queue where extraction proposals wait |
Activity quality classes are substantive, transactional, notification, digest, and noise. Digest and noise are kept out of the embedding index.
How a meeting gets in
A connected calendar or mail sync writes an activity. An agent can also submit a meeting with meeting_graph_checkin (scope graph:write). That call writes the activity, the entity proposals, the links, and the notes in one shot. meeting_brief_checkin attaches a pre-call brief to a calendar activity and does not mutate entities. graph_checkin is the older name for meeting_graph_checkin.
graph_checkin_revert undoes a check-in by its run id.
Extraction review
After an activity is stored, an extraction pass proposes actions such as linking a known record, enriching a fact, adding a mention, creating a record, or filing an action item. Each proposal has a confidence.
Thresholds live in extraction_thresholds, one row per action type, from 0 to 1. Seeded thresholds are 1.0, which queues every proposal. A proposal at or above the threshold is applied only when the threshold is below 1.0. Otherwise it becomes an approval with type extraction.<action>.
Review those cards on Approvals, or with the MCP tools:
| Tool | Scope | Use |
|---|---|---|
extraction_pending | approvals:read | List queued extraction cards |
extraction_review | approvals:write | Approve or reject one |
extraction_review_bulk | approvals:write | Resolve a batch of one action type |
extraction_threshold_set | approvals:write | Set the auto-pass threshold. The database write also requires an admin |
extraction_metrics | approvals:read | Counts by action type |
There is no Cockpit screen for editing thresholds. Use extraction_threshold_set or SQL, as an admin.
Approve marks the card approved and applies the proposal that card was filed with (a link, a field, a mention, a create card, or a task proposal). Reject leaves the activity in place and does not apply the proposal. The exact side effect is the card's own action, not a second queue.
Lowering a threshold means more proposals skip the queue. Leave thresholds at 1.0 until you trust a specific action type.
Identity rules that affect extraction
- A single-token name with no email and no account is not treated as a confirmed person. The contact card should use lifecycle stage
needs-review. prospecton a lifecycle field is normalized tolead.- Creating the actual account or contact still waits on a human when the card type is a create. Extraction may file that create card. It does not skip the human-only rule.
Decisions
Decisions (/decisions) is a separate audit of activity-quality classification (auto, hold, escalate, blocked). It does not approve extraction cards. Decision flows under Automations are the declared flow graphs, also separate from this queue.