> ## Documentation Index
> Fetch the complete documentation index at: https://docs.factagora.com/llms.txt
> Use this file to discover all available pages before exploring further.

# 2026-07

> Factagora API releases in 2026-07 (v0.1.7 – v0.1.20)

<Update label="v0.1.20" description="2026-07-16 · temporal annotation format fix">
  ## Fixed: temporal annotation format on `PATCH /api/v1/tkgs/{tkgId}/graph/nodes/{nodeId}/annotation`

  The request body now uses `{ timestamp: "2026-09-30", precision: "quarter" }` (an ISO 8601 date) instead of the previous loose `{ when: "2026 Q3", precision: "quarter" }` string. This aligns with the annotation format already used elsewhere on the platform.

  The endpoint now also merges into any existing annotation data instead of overwriting it, so other fields (like source provenance) are preserved.

  `capture_temporal` actions from `POST /api/v1/chat` now return `timestamp` (ISO 8601) instead of `when`, so you can pass it straight through to this endpoint.
</Update>

<Update label="v0.1.19" description="2026-07-16 · title dedup on node creation">
  ## Improved: duplicate-safe graph node creation

  `POST /api/v1/collections/{id}/graph/nodes` and `POST /api/v1/tkgs/{tkgId}/graph/nodes` now check for an existing prediction/claim with a substantially overlapping title before creating a new one. If a close match already exists on the platform, that existing FactBlock is reused instead of creating a near-duplicate — and if it's already a node in the same graph, no duplicate node is created either.

  The response now includes an optional `reused: boolean` field so you can tell whether your request created something new or matched an existing FactBlock.
</Update>

<Update label="v0.1.18" description="2026-07-16 · TKG-grounded chat improvements">
  ## Improved: `tkg_id` grounding in `POST /api/v1/chat`

  When chatting with `tkg_id` grounding, the assistant now works much harder to help you build out your knowledge graph:

  * **New `capture_temporal` action** — alongside `capture_belief` and `capture_causal`, the assistant can now suggest attaching a time reference (`when` + `precision`: year/quarter/month/day) to an existing belief.
  * **Graph-gap awareness** — the assistant is now aware of which beliefs have no causal connections and which predictions have no timeline, and will proactively ask about them.
  * **FactBlock reuse** — the assistant checks for related predictions/claims that already exist on the platform before treating something as a brand-new belief.
  * **Implicit capture from free text** — if you mention a specific time or a causal reason in your own message (not just by clicking a suggested action), the assistant will include the matching `capture_temporal` or `capture_causal` action even without an explicit request to save it.
  * **Session persistence** — `tkg_id` conversations now save session and message history on the server, the same way `collection_id` conversations already do. Pass the returned `session_id` back on your next request to continue the conversation with full context.
  * **Consistent language** — responses, follow-up questions, and suggested action titles now consistently match the language you're writing in.

  `collection_id` grounding is unchanged.
</Update>

<Update label="v0.1.17" description="2026-07-16 · chat, TKG graph editing, fixes">
  ## Added: `POST /api/v1/chat`

  A new streaming (SSE) chat endpoint.

  * Pass `collection_id` to ground answers in a collection's knowledge (semantic chunk search with knowledge-graph fallback). Session and message history are persisted.
  * Pass `tkg_id` to ground answers in a standalone knowledge graph instead.
  * Omit both for a one-off chat with no grounding and no saved session.
  * Choose a `model`: `gpt-5-nano`, `gpt-5-mini`, or `gpt-5`.
  * Enable `use_fact_search` / `use_evidence_finder` / `use_fact_checker` to let the model autonomously call those research tools during the conversation. Each tool call is billed individually at the same credit cost as its standalone endpoint, only when actually invoked.
  * The chat request itself is currently free while pricing for this endpoint is being finalized.

  ## Added: TKG graph editing endpoints

  `POST/PATCH/DELETE /api/v1/tkgs/{tkgId}/graph/nodes` and `POST/DELETE /api/v1/tkgs/{tkgId}/graph/edges` let you manually create, rename, and delete nodes and edges on a knowledge graph that isn't attached to a collection — the same graph-editing capability collections already had, now available standalone. These endpoints are free.

  A new `PATCH /api/v1/tkgs/{tkgId}/graph/nodes/{nodeId}/annotation` endpoint lets you attach a temporal annotation (`when` + `precision`: year/quarter/month/day) to a belief node.

  ## Fixed: qa-verify entity matching

  `POST /api/v1/collections/{id}/qa-verify` no longer over-matches on brand or product-family tokens that are common across many entities in the same collection (for example, matching almost any entity just because it shares a common brand name). Matching is now more precise.

  ## Fixed: entity-connected fact limit

  Raised the internal cap on how many connected facts are considered when resolving an entity from 20 to 50. Previously, some genuinely connected facts were cut off before relevance ranking, which could make a verdict appear `unsupported` when better evidence existed.
</Update>

<Update label="v0.1.11" description="2026-07-14 · fact-search modes">
  ## Added: `mode` parameter for fact-search

  `GET /api/v1/fact-search` now accepts a `mode` parameter:

  * `auto` (default) — semantic hybrid search with live fallback. This is the existing default behavior.
  * `fast` — keyword-only search that skips query embedding and the live fallback for the lowest latency. Best when you want the quickest results and don't need semantic matching.

  Omitting `mode` keeps the existing behavior (`auto`).

  ## Improved: results when filtering by domain or narrow criteria

  Fact-search now reliably returns matching articles when you restrict results (for example, by domain). Previously, narrow filters could return few or no results even when matching articles existed.
</Update>

<Update label="v0.1.10" description="2026-07-08 · Faster qa-verify">
  ## Improved: faster response time

  `POST /api/v1/collections/{id}/qa-verify` now resolves entity-linked evidence significantly faster per question/answer pair, reducing overall response time for the endpoint. No request or response shape changed.
</Update>

<Update label="v0.1.9" description="2026-07-08 · Q&A verification improvements">
  ## Improved: Q\&A verification evidence retrieval

  `POST /api/v1/collections/{id}/qa-verify` now finds relevant evidence more reliably:

  * Evidence retrieval considers the claimed answer text as well as the question, so facts that only overlap with wording in the answer are no longer missed.
  * Entity matching now recognizes a question that mentions only part of an entity's full name (e.g. a question naming a product's short name is matched against the entity's full name in the graph).
  * Vector search results are now filtered to a minimum relevance threshold, so clearly unrelated content is no longer included as evidence.

  ## Fixed: one failing pair no longer fails the whole request

  Previously, if any single question/answer pair in a `qa-verify` request hit an internal error, the entire request failed and no results were returned — even for pairs that would have verified successfully. Each pair is now processed independently: a failing pair now returns as `"verdict": "unsupported"` while the rest of the batch completes normally.

  No request or response shape changed.
</Update>

<Update label="v0.1.8" description="2026-07-08 · Large collection graph fix">
  ## Fixed: 500 error on large collections

  `GET /api/v1/collections/{id}/graph` could return a `500` error for collections with a few hundred or more claims/predictions/entities combined. Fetching a new collection's graph for the first time after it grew past this size would fail entirely.

  Ingesting a new source into an already-large collection could also fail for the same underlying reason, blocking further ingestion into that collection.

  ### What changed

  Internal lookups that resolve node titles now run as a single server-side query instead of passing large ID lists in the request. This removes the size ceiling — collections with any number of nodes now work the same way.

  No response shape changed; if you were affected by this, requests that previously failed now simply succeed.
</Update>

<Update label="v0.1.7" description="2026-07-07 · Entities in Collections">
  ## New: Entities in the knowledge graph

  Collections now extract named **entities** (people, organizations, products) from ingested content, in addition to claims and predictions. Entities become nodes in the collection's knowledge graph, connected to every claim or prediction that mentions them — turning previously disconnected facts about the same person, company, or product into a single connected cluster.

  ### Entity types

  | Type           | Description                                                            |
  | -------------- | ---------------------------------------------------------------------- |
  | `PERSON`       | A specific named individual                                            |
  | `ORGANIZATION` | A specific named company, institution, or group                        |
  | `PRODUCT`      | A specific named brand or model (generic categories are not extracted) |

  ### Changed endpoints

  | Endpoint                                  | Change                                                                                                                                                                                                                  |
  | ----------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
  | `GET /api/v1/collections/{id}/graph`      | Response nodes may now have `"type": "ENTITY"` in addition to `CLAIM`/`PREDICTION`                                                                                                                                      |
  | `GET /api/v1/collections/{id}/context`    | Adds `matched_entities` (entity names/aliases found in the question) and `entity_facts` (claims/predictions linked to those entities)                                                                                   |
  | `POST /api/v1/collections/{id}/qa-verify` | Grounding now combines vector search with entity-graph traversal. If a question and a claim share a named entity but are worded very differently, the claim is now found — improving verification accuracy in that case |

  ### Why this matters

  Previously, retrieval relied only on vector similarity between the question and ingested text. If a question mentioned an entity by name but phrased things differently from the source content, relevant claims could be missed. Entities give the graph a second, exact-match retrieval path alongside semantic search.
</Update>
