AutoGraph Graph Operations

This page describes the endpoints that build and maintain the Layer 3 knowledge graph. POST /v1/orchestrate starts the Importer workers for the strategy profiles. The POST /v1/graph/* endpoints insert, delete, update, and recluster individual documents in a graph that has already been built.

To learn when to use the /v1/graph/* endpoints, how they compare to a full rebuild, and how the partition divergence is measured, see Incremental Graph Updates.

Trigger Orchestration

Spawn Importer workers for the strategy profiles that are not in the knowledge graph yet. Called after RAG strategizer is completed.

Recommended path: Call after a successful corpus build and strategizer run, when rags is non-empty. This is the final step of the standard workflow. Omit categories to process every eligible strategy profile; list bare category labels to scope the run to those categories. Do not overlap with an active build (409).

Request

{
  "project": "my_project",
  "replicas": 3,
  "max_retries": 3,
  "categories": ["legal", "finance"],
  "importer_env": {
    "CUSTOM_ENV": "value"
  }
}

Parameters

Credential precedence

AutoGraph is replacing raw API keys with secret profile IDs. When a profile ID is available, it takes priority, and the Importer resolves the key from the platform secret manager at runtime, so no plaintext key is written into the Importer pod environment.

Chat and embedding credentials are resolved independently, each in this order:

1. chat_secret_profile_ids and embedding_secret_profile_id on the request.
2. The persisted project model configuration, for any profile field that the request omits. See Update Model Config Credentials.
3. Inline keys, only when no profile ID exists at either of the levels above: CHAT_API_KEY and EMBEDDING_API_KEY in importer_env, and then the environment of the AutoGraph service itself.

Response

{
  "orchestration_id": "orch_1711812345_a1b2c3d4",
  "success": true,
  "message": "Orchestration started",
  "total_jobs": 0,
  "completed_jobs": 0,
  "failed_jobs": 0,
  "job_results": [],
  "unmatched_file_ids": []
}

Orchestration runs in the background. The counters start at zero in this immediate response. Poll GET /v1/orchestrate/{orchestration_id} for the per-partition results, or watch your platform’s job tracking and service logs.

Telling the three 409 responses apart

All three share the status code. The message and error_type of the response distinguish them, and each calls for a different reaction:

A request that matches some of its file_ids is not rejected. The unmatched ids are skipped and reported in unmatched_file_ids on the 202 response, and the run continues with the rest. A NoMatchingFilesError therefore always means that every ID missed. The request is refused before any importer pod is created and before the single-flight slot is taken, so there is nothing to clean up.

HTTP Example

curl -X POST \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer <token>" \
  -d '{"project": "my_project", "replicas": 2, "max_retries": 3}' \
  https://<EXTERNAL_ENDPOINT>:8529/autograph/v1/orchestrate

Monitor an orchestration

Returns the status of the orchestration run that POST /v1/orchestrate started, using the orchestration_id from its response. This is where the per-partition results of the run become visible, including the authoritative partition divergence.

Each entry of jobs reports one Importer job, that is, one strategized partition. For a FullGraphRAG partition, the entry carries the divergence_score and needs_reclustering of that partition, measured after the job has created its Layer 3 entities. This is the value to act on, not the one from an insert or update response, see Where to read the score.

Response

{
  "orchestration_id": "orch_1711812345_a1b2c3d4",
  "status": "running",
  "phase": "importing",
  "total_jobs": 4,
  "completed_jobs": 2,
  "failed_jobs": 0,
  "running_jobs": 2,
  "pending_jobs": 0,
  "skipped_jobs": 0,
  "entities_added": 18432,
  "elapsed_seconds": 3420,
  "seconds_since_progress": 7,
  "message": "Running: 2/4 completed, 0 failed",
  "jobs": [
    {
      "rag_partition_id": "myproject_legal_0_a",
      "category": "myproject_legal",
      "strategy_type": "FullGraphRAG",
      "status": "completed",
      "retry_count": 0,
      "error_message": null,
      "divergence_score": 0.12,
      "needs_reclustering": false,
      "entities_added": 9216,
      "imported": true
    }
  ]
}

What status and phase mean

The two status-shaped fields answer different questions and do not substitute for each other.

status turns terminal only once every import job is terminal, and completed additionally requires that the partitions the Importer reported writing were found in the knowledge graph. A terminal run always reports phase: "finished", whatever the outcome — including a cancelled or reaped one, which is the fourth status value that a client mapping only running, completed, and failed meets unhandled. See Cancel an orchestration.

phase is the field to render as progress. A run in starting_importers has imported nothing yet, whatever elapsed_seconds reports: the Importer pods are created, health-checked, and given 60 seconds for route registration before the first job is dispatched, which is minutes on a large fleet.

message carries the human-readable outcome and never reads “completed” for a run that lost jobs:

Response fields

Waiting for a graph to be ready

Poll until status leaves running, then treat only completed as ready. The example prints phase while it waits, because the counters alone do not distinguish a fleet that is still starting from one that is importing. The JSON keys come back in camelCase:

while [ "$(curl -sH "Authorization: Bearer $TOKEN" \
  "$HOST/v1/orchestrate/$ORCH_ID" | jq -r .status)" = "running" ]; do
  curl -sH "Authorization: Bearer $TOKEN" "$HOST/v1/orchestrate/$ORCH_ID" \
    | jq -r '"\(.phase): \(.completedJobs)/\(.totalJobs) jobs, \(.entitiesAdded) entities"'
  sleep 30
done

HTTP Example

curl -H "Authorization: Bearer <token>" \
  https://<EXTERNAL_ENDPOINT>:8529/autograph/v1/orchestrate/orch_1711812345_a1b2c3d4

Cancel an orchestration

Ask the running orchestration to stop and release the single-flight slot of the project, so that a wedged run can be cleared without database surgery.

The request takes no body. Pass the orchestration_id in the path.

Response

{
  "orchestration_id": "orch_1711812345_a1b2c3d4",
  "cancellation_requested": true,
  "status": "running",
  "message": "Cancellation requested; the run will release the slot at its next loop pass"
}

Notes:

• You can only cancel the run that currently holds the slot.
• If the run does not release the slot within a grace period of 3 minutes, the admission reaper force-releases it, so a cancellation that the run never observed cannot hold the slot indefinitely.
• While the cancellation is in flight, a 409 from POST /v1/orchestrate reports cancellation_requested in its diagnostics.
• Partitions that finished before the stop are in the knowledge graph and count as built. The rest are not. Orchestrate again to pick up what is left.

HTTP Example

curl -X DELETE \
  -H "Authorization: Bearer <token>" \
  https://<EXTERNAL_ENDPOINT>:8529/autograph/v1/orchestrate/orch_1711812345_a1b2c3d4

Automatic reaping of a wedged run

Independently of cancellation, a run that stops making contact is stopped automatically, so that a dead importer fleet cannot hold the slot for the full wall-clock cap:

Both budgets are measured against worker contact, not against job counters, because a single large partition sits at unchanged counters for hours while it imports normally. A reaped run ends with status: cancelled and releases the slot. The orchestration wall-clock cap of 3 days remains as a final backstop. These two budgets and the 3-minute cancellation grace period are fixed constants, not operator-configurable settings.

Insert documents

Adds documents that are not in the graph yet. The call is synchronous.

The corpus and the target category have to exist already. If the project has exactly one category, you can omit category. Otherwise, it is required.

Request

Every document is identified by its File Manager file_id. Insert takes no inline content, so upload the document with POST /_platform/filemanager/_db/{database}/rag-input first and pass the returned ID.

{
  "files": [
    {
      "doc_name": "new-contract.pdf",
      "file_id": "<file-manager-file-id>"
    }
  ],
  "category": "legal"
}

Parameters

There is no citable_url request field. AutoGraph reads the citable URL from the custom_metadata of the File Manager file and validates it the same way a corpus build does, so it has to be an http or https URL with valid characters. Set it on the file when you upload it.

Response

{
  "results": [
    {
      "doc_name": "new-contract.pdf",
      "success": true,
      "cluster_key": "cluster_legal_0",
      "rag_partition_id": "legal_0_a"
    }
  ]
}

Insert extracts the text, creates an embedding, stores the source, assigns the closest existing cluster, and adds the membership and similarity edges. It only updates Layers 1 and 2. To add the document to Layer 3, run a targeted orchestration with its file_id. AutoGraph resolves the partition itself, so you do not pass one. Because every insert is keyed by a File Manager ID, an inserted document is always targetable, see Identifying documents for Layer 3.

HTTP example

curl -X POST \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer <token>" \
  -d '{
    "files": [{
      "doc_name": "new-contract.pdf",
      "file_id": "<file-manager-file-id>"
    }],
    "category": "legal"
  }' \
  https://<EXTERNAL_ENDPOINT>:8529/autograph/v1/graph/insert

Delete documents

Removes documents from an existing corpus graph. The call is synchronous and performs the whole removal itself. It cleans up Layer 3 first, then Layers 1 and 2. No Importer worker is involved, and there is no background job to wait for. The response is the final result.

Use File Manager IDs in file_ids if you can, as they are stable. Otherwise, provide doc_names, which are looked up in the requested category. You need to provide at least one of the two lists.

Request

{
  "file_ids": [
    "<file-manager-file-id-1>",
    "<file-manager-file-id-2>"
  ],
  "category": "legal"
}

By file name instead:

{
  "doc_names": ["old-contract.pdf"],
  "category": "legal"
}

Parameters

Response

{
  "delete_id": "delete_1711812345_a1b2c3d4",
  "results": [
    {
      "file_id": "<file-manager-file-id-1>",
      "status": "LAYER2_DELETE_STATUS_SUCCESS",
      "rag_partition_id": "legal_0_a",
      "cluster_key": "cluster_legal_0",
      "similarity_edges_removed": 4,
      "divergence_score": 0.31,
      "needs_reclustering": true
    }
  ],
  "affected_rag_partitions": ["legal_0_a"],
  "removed_rag_partitions": [],
  "affected_cluster_ids": ["cluster_legal_0"],
  "removed_cluster_ids": [],
  "layer3_results": [
    {
      "status": "LAYER3_DELETE_STATUS_SUCCESS"
    }
  ],
  "overall_status": "COMMITTED"
}

The response reports the outcome of the complete deletion, Layer 3 included. There is no importerOrchestration entry to poll, because a standalone delete does not write one.

overall_status covers both stages and tells you whether you can retry:

The status of a layer3_results entry is one of LAYER3_DELETE_STATUS_SUCCESS, LAYER3_DELETE_STATUS_FAILED, LAYER3_DELETE_STATUS_NOT_ATTEMPTED, or LAYER3_DELETE_STATUS_UNSPECIFIED.

When the deletion commits, AutoGraph calculates the divergence of every affected partition again and stamps divergence_score and needs_reclustering onto the result of each file. The fields are only present if overall_status is COMMITTED. A deletion that ends in ROLLED_BACK or FAILED writes no score. See Where to read the score.

HTTP example

curl -X POST \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer <token>" \
  -d '{
    "file_ids": ["<file-manager-file-id>"],
    "category": "legal"
  }' \
  https://<EXTERNAL_ENDPOINT>:8529/autograph/v1/graph/delete

Update documents

Replaces the content of documents that are already in the graph. The call is asynchronous.

Every document has to exist and belong to the requested category. A single invalid document makes the whole batch fail before anything is changed.

Request

Like an insert, every document is identified by its File Manager file_id. Update takes no inline content: the replacement is always read back from the File Manager. Upload the new version with POST /_platform/filemanager/_db/{database}/rag-input and pass the returned ID.

{
  "files": [
    {
      "doc_name": "existing-contract.txt",
      "file_id": "<file-manager-file-id>"
    }
  ],
  "category": "legal"
}

Parameters

Update still accepts the deprecated module field, which is only honored when category is empty. Send category. Insert and delete have no module field at all.

Immediate response

{
  "update_id": "update_1721840400_a1b2c3d4",
  "accepted": true,
  "message": "Update started",
  "results": []
}

accepted: true means that the update has been validated and started, not that it is done. Poll the importerOrchestration entry in the metadata of your platform project. The update goes through the following phases:

1. DELETE_L3: AutoGraph removes the old knowledge graph data with AQL queries of its own. This is synchronous, and no Importer is involved.
2. DELETE_L12: Removes the old source and the corpus graph data.
3. INSERT_L12: Inserts the new version and assigns a cluster to it.
4. DONE: The update has succeeded or failed.

The order is Layer 3 first, for the same reason as a standalone delete: an update reuses the same deletion core, which snapshots and removes the knowledge graph data before it touches Layers 1 and 2.

A final status message looks like this:

{
  "phase": "DONE",
  "status": "completed",
  "summary": "Updated 1 file(s) in Layers 1-2; run orchestrate to re-import Layer 3",
  "files": [
    {
      "file": "existing-contract.txt",
      "result": "updated",
      "cluster": "cluster_legal_0",
      "previous_cluster": "cluster_legal_1",
      "partition": "legal_0_a",
      "file_id": "<file-manager-file-id>"
    }
  ]
}

Only file and result are always present. The service adds every other key conditionally, so read them as absent rather than empty when the value does not apply.

An update waits for the old Layer 3 data to be removed before it inserts the new version, so that old and new knowledge graph data do not exist side by side. It is still not a database transaction.

After a successful update, run a targeted orchestration to import the new version into Layer 3.

HTTP example

curl -X POST \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer <token>" \
  -d '{
    "files": [{
      "doc_name": "existing-contract.txt",
      "file_id": "<file-manager-file-id>"
    }],
    "category": "legal"
  }' \
  https://<EXTERNAL_ENDPOINT>:8529/autograph/v1/graph/update

Trigger reclustering

Schedules a Layer 3 reclustering for up to five FullGraphRAG partitions. The call returns right away and reports whether each partition was taken up, which is weaker than a queue position, see the response below. The reclustering itself runs asynchronously, and only one runs at a time.

Call this endpoint if needs_reclustering: true is reported for a partition and you decide that refreshing the communities is worth the cost. AutoGraph never starts a reclustering on its own. The flag is reported by GET /v1/orchestrate/{orchestration_id}, by a delete once its Layer 3 cleanup has committed, and by the rags profile of the partition. Insert and update responses do not report it, see Where to read the score.

Only FullGraphRAG partitions have a community layer that can be rebuilt. A VectorRAG partition has no Entities or Communities, so there is nothing to rebuild, and such a partition is never flagged for reclustering in the first place.

How the flag you are reacting to is calculated. The divergence_score is the higher of two signals, both measured on the Entities of the partition:

divergence_score = max(gross_churn_score, multi_batch_score)

gross_churn_score = cumulative_churn / baseline_entity_count
multi_batch_score = (total_entities - largest_batch) / total_entities

• Gross churn counts every entity that has been added and deleted since the last clustering, gross rather than net. A same-size replacement therefore still counts: an update that removes 100 entities and adds 100 new ones adds about 200 to the churn, not 0. The baseline_entity_count is the entity count at the last successful clustering or reclustering.
• Multi-batch spread groups the entities by import_number, takes the largest batch as the stable baseline, and counts everything outside it as changed. A partition with a single batch, or with no entities, scores 0 here.

needs_reclustering is set when the score is strictly above the threshold, which is 0.25 and not configurable. For the baseline bootstrap, worked examples, and the lifecycle of the values, see Partition divergence and reclustering.

Request

{
  "partition_ids": ["legal_0_a", "engineering_0_a"]
}

Response

{
  "results": [
    {
      "rag_partition_id": "legal_0_a",
      "accepted": true
    },
    {
      "rag_partition_id": "engineering_0_a",
      "accepted": true
    }
  ]
}

Read the per-partition outcome from the rags strategy profile, not from importerOrchestration. The importerOrchestration entry in your project metadata carries the status of the job that holds the slot. It is not a per-partition ledger. A partition that gave up waiting behind another reclustering is not published there at all, so it is invisible in that slot; a deferral behind any other operation is published as failed. The rags node of the partition is authoritative:

If needs_reclustering is still true and last_reclustered_at has not moved, the partition was not reclustered, whether it failed or never got the slot. Trigger it again. See Where the values are stored.

Notes:

• If a reclustering is already running for a partition, a second request is merged into it and does not start another Importer job.
• Reclustering uses the same service-wide slot as build, insert, update, and delete, so it cannot run at the same time as these operations.
• A reclustering that fails or is skipped does not clear needs_reclustering. Start it again once the slot is free.
• Triton projects cannot be reclustered, but this endpoint does not reject them. A recluster of a Triton project is accepted (accepted: true) but fails in the background: the Importer rejects it with gRPC FAILED_PRECONDITION before doing any work, see Reclustering. The failure appears in the importerOrchestration status slot, and needs_reclustering stays set.
• A partition without entities is a successful no-op. The job reports 0 communities over 0 entities and finishes, so a completed job is not evidence that anything was refreshed. Check last_reclustered_at and the Communities of the partition.
• To learn what the Importer does during a reclustering and how long it takes, see Importer Incremental Updates.

HTTP example

curl -X POST \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer <token>" \
  -d '{
    "partition_ids": ["legal_0_a"]
  }' \
  https://<EXTERNAL_ENDPOINT>:8529/autograph/v1/graph/recluster

End-to-end example of an incremental update

The following calls assume that the corpus graph has already been built.

# 1. Add a new document to Layers 1 and 2
curl -X POST \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer <token>" \
  -d '{
    "files": [{
      "doc_name": "new.txt",
      "file_id": "<new-file-id>"
    }],
    "category": "legal"
  }' \
  https://<EXTERNAL_ENDPOINT>:8529/autograph/v1/graph/insert

# 2. Delete an obsolete document (synchronous, Layer 3 included)
curl -X POST \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer <token>" \
  -d '{
    "file_ids": ["<old-file-id>"],
    "category": "legal"
  }' \
  https://<EXTERNAL_ENDPOINT>:8529/autograph/v1/graph/delete

# 3. Replace an existing document (returns an update_id immediately)
curl -X POST \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer <token>" \
  -d '{
    "files": [{
      "doc_name": "existing.txt",
      "file_id": "<existing-file-id>"
    }],
    "category": "legal"
  }' \
  https://<EXTERNAL_ENDPOINT>:8529/autograph/v1/graph/update

After an insert or a successful update, run a targeted orchestration so that Layer 3 contains the new content:

curl -X POST \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer <token>" \
  -d '{
    "project": "my_project",
    "replicas": 1,
    "file_ids": ["<new-or-updated-file-id>"]
  }' \
  https://<EXTERNAL_ENDPOINT>:8529/autograph/v1/orchestrate

Then read the results of that run, which is where the divergence of each affected partition is reported:

curl -H "Authorization: Bearer <token>" \
  https://<EXTERNAL_ENDPOINT>:8529/autograph/v1/orchestrate/<orchestration_id>

If needs_reclustering: true is reported for a partition, by the orchestration status above or by the delete result, you can start a reclustering. It is optional and never automatic:

curl -X POST \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer <token>" \
  -d '{
    "partition_ids": ["legal_0_a"]
  }' \
  https://<EXTERNAL_ENDPOINT>:8529/autograph/v1/graph/recluster

Then read the rags profile of the partition. If the reclustering succeeded, needs_reclustering is false, last_reclustered_at has moved, and the divergence_score is back to 0. Reclusterings run one at a time and block every other write while they do, so send at most five partitions per request and pick a maintenance window for them.

Troubleshooting

• The insert succeeded but the document is not in Layer 3. An insert only updates Layers 1 and 2. Run a targeted orchestration with the new file_id.
• The update was rejected with 400 and a list of doc_name values. Those entries have no file_id. Update reads the replacement from the File Manager and takes no inline content, so every entry needs one, and one missing ID rejects the whole batch. Upload the new version first, then send the returned ID. See Identifying documents for Layer 3.
• The delete reports overall_status: "ROLLED_BACK". Something failed, and the state from before the call has been fully restored, so the documents are still in the graph. There is nothing to poll and nothing to clean up by hand. Fix the underlying problem and send the same batch again.
• The delete reports overall_status: "FAILED". The restore did not complete either, so the corpus can be in a partial state. Do not retry blindly. Inspect the affected partitions and clusters first, then decide what to send again.
• The delete reports LAYER3_DELETE_STATUS_NOT_ATTEMPTED. There were no knowledge graph collections to clean up. This is expected for a corpus that has no Layer 3 yet, and it does not stop the Layer 1 and Layer 2 removal.
• The update returned accepted: true but the document has not changed. Updates are asynchronous. Poll importerOrchestration until the JSON message reports phase: "DONE".
• The update failed and the source document is gone. The deletion succeeded but the insertion failed. Fix the input or the underlying problem and add the document again with POST /v1/graph/insert, using the file_id that the status message reports for that file.
• A call returns 409. Another operation, such as a build, insert, update, delete, or reclustering, is using the service-wide slot. Wait for it to finish and try again. On POST /v1/orchestrate the same status code covers two more conditions, see Telling the three 409 responses apart.
• POST /v1/orchestrate returns 409 with “Nothing to orchestrate”. Every category that has strategies is already in the knowledge graph. This is the expected steady state when you re-run without new data, so do not retry. Check knowledge_graph.new_categories in Project Overview to see what would actually be built. After an insert or update, send the file_ids of the changed documents, which skips the stale filter.
• An orchestration seems stuck and POST /v1/orchestrate keeps returning 409. Read the diagnostics in the message: the age of the run, the job counts, and above all the time since the last worker contact. Static job counters are normal for a large partition, a long silence is not. A run without a usable worker for 15 minutes, or without any worker contact for 30 minutes, is reaped automatically. To clear it sooner, call DELETE /v1/orchestrate/{orchestration_id} and allow about two minutes.
• The orchestration status reads cancelled. The run was cancelled explicitly, or reaped for worker inactivity. The partitions that finished before the stop are in the knowledge graph and count as built, the rest are not. Orchestrate again to pick up what is left.
• The orchestration reports failed with unverified_partitions. Every import job reported success, but those partitions were not found in the {project}_kg graph afterwards, so the run does not claim your knowledge graph is ready. message names the missing partitions. Delete the affected category, build it again, re-run the strategizer, and orchestrate.
• The orchestration seems to hang at total_jobs: 0. While phase is initializing the job set is not loaded yet, so 0 means “not known”, not “nothing to do”. Watch phase rather than the counters.
• elapsed_seconds keeps growing but no job finishes. Check phase. In starting_importers the fleet is still coming up, which takes minutes on a large fleet, and nothing has been imported yet. In importing, check seconds_since_progress: the Importer only reports counts on a terminal job, so a single large partition stays at unchanged counters for hours while importing normally.
• The orchestration completed but entities_added is 0. A VectorRAG partition writes Documents, Chunks, and Relations but no entities, so a VectorRAG-only run legitimately reports 0. To tell that apart from a run that imported nothing, read skipped_jobs and jobs[].imported. See Retrieval capability per strategy.
• The orchestration succeeded but the graph is unchanged. Compare skipped_jobs with completed_jobs. When they are equal, every job was a no-op success, because the file_ids you sent matched nothing in any of the dispatched partitions. Check unmatched_file_ids on the 202 response of the trigger request.
• needs_reclustering is true for a partition. The divergence score of the partition is above its threshold, which is 25% and not configurable. Nothing is reclustered automatically. Call POST /v1/graph/recluster with the rag_partition_id if you want to refresh the communities.
• The insert or update result has no divergence_score. This is by design, not a missing field. Neither response reports a divergence, because it would be measured before Layer 3 holds the new entities. Read the score from GET /v1/orchestrate/{orchestration_id} after the targeted orchestration, or from the partition’s rags profile. See Where to read the score.
• The reclustering was accepted but needs_reclustering is still true. accepted: true only means the request was taken up. The partition may still be running, it may have failed (a Triton project always fails here), or it may never have got the mutation slot: reclusterings are serialized, and a partition that waits behind a peer gives up after about ten one-second attempts. None of that clears the flag. Check last_reclustered_at on the rags node to tell “not yet reclustered” from “reclustered and drifted again”, and trigger the partition again. importerOrchestration only shows the job that holds the slot, and it does not see a partition that gave up waiting behind another reclustering.
• A recluster request returns 400. Either partition_ids is empty, or it lists more than five partitions.
• A reclustering completed but the communities look unchanged. A partition with no entities is a successful no-op that reports 0 communities over 0 entities. Confirm that the partition has Entities before you expect a refreshed community layer.

Next Steps

• AutoRAG: Query your built knowledge graphs
• Monitor Results: Verify import success
• Incremental Graph Updates: When to use the /v1/graph/* endpoints and how the partition divergence is measured
• Design Guide - Categories to partitions: How category labels flow into partition IDs
• Error Handling: HTTP codes and general troubleshooting