Object Model Overview

Read the workspace object model: its types of data, the links between them, and the unresolved references nobody on file carries, via GET /v1/object-model.

The object model describes a workspace as a graph of object types and the links between them, counted at type level. It answers questions a list of documents cannot: which kinds of things does this workspace hold, how many of each, which kinds point at which others, and where do documents cite something that nobody on file carries. One read, GET /v1/object-model, returns the whole graph. The model is computed on each request from what the workspace holds, makes no model calls, and writes nothing.

A type is one of four kinds. A master type is a Master Records domain: the golden records across the workspace's systems of record. A spec type is the set of documents captured by one Spec, and a document_type type is the set of documents of one classified type; which of the two the documents form is chosen with the group query parameter. A table type is a bound reference table. Each type carries its count (golden records, documents, or table rows), a stable id such as master:<domain>, spec:<schema id>, doctype:<name> or table:<reference data id>, and the systems or Specs its records come from.

An edge connects two types and says how the link was found. A link either comes from structured keys (origin: "structured": a deterministic join on system ids and captured fields) or from document text (origin: "document_text": a relation claim read from a document, with the quoted words that carry it). Every edge names its method, the number of links on it, how many source-side items carry a link (from_items), and one example, so a number on the graph can be traced to a real document and quote. Claims that cite an identifier nobody on file carries are grouped in the wanted list.

Visibility follows the person behind the key. The model counts only documents visible to the key's minting user under Sources IAM, evaluated as that user rather than as the workspace: a document hidden from them leaves the types, the edges and the wanted list. Two keys of one workspace can therefore return different counts. Documents that are deleted, hidden, or excluded by a tag filter still matter to claims that end at them; those claims count as claims_outside in the totals instead of vanishing.

Worked Example: Find What Documents Cite but Nobody Carries

A contracts team wants to know which references in their documents point at nothing on file. Read the model grouped by Spec, then look at wanted: each group is one kind of identifier (key_type) cited by claims of one source type, with the number of distinct identifiers and one example with its quote.

curl "https://api.talonic.com/v1/object-model?group=spec" \
  -H "Authorization: Bearer $TALONIC_API_KEY"

{
  "generated_at": "2026-10-21T08:30:12.402Z",
  "grouping": "spec",
  "types": [
    { "id": "spec:5b2e0d7a-3c11-4e0f-9a64-7f1c2d8e9b40", "kind": "spec", "label": "Supply contracts", "count": 212, "sources": [], "ref": "5b2e0d7a-3c11-4e0f-9a64-7f1c2d8e9b40" },
    { "id": "master:suppliers", "kind": "master", "label": "suppliers", "count": 84, "sources": ["erp", "crm"], "ref": "suppliers" }
  ],
  "edges": [
    {
      "id": "e1",
      "source": "spec:5b2e0d7a-3c11-4e0f-9a64-7f1c2d8e9b40",
      "target": "master:suppliers",
      "relation": "names_party",
      "key": "supplier_name",
      "origin": "structured",
      "method": "party_name",
      "links": 187,
      "from_items": 187,
      "unlinked": 25,
      "truncated": false,
      "example": { "quote": null, "document_id": "a3f9c1d2-0b7e-4c55-8d1a-90e2f4b6c7d8", "filename": "supply-contract-0412.pdf", "page": null, "target_document_id": null, "target_label": "Example Energie GmbH" }
    }
  ],
  "wanted": [
    {
      "source": "spec:5b2e0d7a-3c11-4e0f-9a64-7f1c2d8e9b40",
      "relation": "amends",
      "key_type": "contract_no",
      "claims": 9,
      "documents": 7,
      "identifiers": 6,
      "example": { "raw": "Contract 2019-0033", "quote": "amends Contract 2019-0033", "document_id": "c7e1a2b3-4d5f-4a60-b1c2-d3e4f5a6b7c8", "filename": "amendment-3.pdf", "page": 1 }
    }
  ],
  "totals": { "documents": 212, "claims": 140, "claims_resolved": 110, "claims_unresolved": 21, "claims_on_record": 4, "claims_outside": 5 },
  "tag": null,
  "tags": [{ "tag": "2026-renewal", "documents": 38 }]
}

The excerpt reads as follows. Of 212 contract documents, 187 name a party that matches a golden record in the suppliers domain, and 25 do not. Nine claims in seven documents cite a contract number nobody on file carries, which is the list of documents to load or the references to correct. Narrowing the read to one cohort adds tag: GET /v1/object-model?group=spec&tag=2026-renewal counts only the documents carrying that tag. See Reading the Graph for how edges, claims and totals fit together.