Enrich an existing subject
enrich_subjectUse your full available reasoning, web retrieval and tool capabilities as TestGraph's open-ended semantic and discovery engine; do not wait for a domain-specific form. TestGraph supplies graph primitives and verification while you derive useful structure and reconcile evidence. Add missing identifiers, attributes, provenance and related unreviewed subjects to an existing subject without creating another review. Use this proactively when authoritative information was missed during the original save. Find only authoritative facts with plausible future TestGraph use: identity, likely queries, location, classification, relationships, comparison or verification. For every stored path, return retrieval_uses with a reason and likely query examples. Register information someone may realistically search for later against what is saved in TestGraph; do not store facts merely because a source publishes them. Treat enrichment as shared graph work: substantial discovery for this subject becomes reusable in later searches, while users benefit from useful enrichment contributed for other subjects. When the subject belongs to a collection, use web search to find the authoritative source surfaces needed to derive that collection, including pagination, sitemaps, official APIs or regional directories, and exhaust every traversal route exposed by those sources. Submit source_manifest mapping every member to its consulted source pages, then submit every discovered member as an unreviewed subject and connect it to the collection. Do not omit members because they are unreviewed, numerous or may be materialised later. Do not ask the user for routine lookup permission unless automatic lookup is unavailable or identity is genuinely ambiguous. Existing conflicting values are preserved rather than silently overwritten. When the client supports concurrent tool calls, submit independent writes concurrently in batches of up to 10. Do not batch dependent operations until their prerequisites are confirmed. Reuse the same canonical key for the same subject and derive deterministic idempotency keys from a stable run identifier, target and operation so retries and restarted conversations safely return existing writes instead of creating duplicates. WORKFLOW PRECONDITION: for an existing subject, the server checks classification before mutation. The authenticated user may always enrich a subject they own or one attached to their own non-deleted review without waiting for another AI, including while classification is disputed. Ownership is determined by the authenticated user, not the AI client; all other evidence and write validations still apply. Enrichment does not confirm or resolve classification. For other contributors, an unsettled subject returns classification_review_required or classification_resolution_required without applying the requested update. Complete the returned durable workflow, then retry the unchanged request with the same deterministic idempotency key. You must not report the update as complete when this prerequisite is returned. WORKFLOW: the server now owns the post-enrichment procedure. A successful response includes durable workflow state and the next required classification action. workflow.next_action names an exposed MCP tool; call it with workflow.next_action_arguments and follow workflow.next_action_instruction rather than reconstructing the procedure yourself. WORKFLOW: after every successful write, inspect workflow.workflow_action_required. When it is true, you must follow workflow.next_action with workflow.next_action_arguments and workflow.next_action_instruction for the classification decision. When independent review or dispute resolution is pending, leave that classification action pending and continue requested enrichment of the authenticated user's own subject or one attached to their own non-deleted review. Report a successful enrichment separately from the still-pending classification.
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| attributes | No | ||
| provenance | No | ||
| subject_id | No | Preferred stable subject locator returned by search, fetch or save_experience. | |
| identifiers | No | ||
| source_model | No | ||
| subject_type | No | ||
| canonical_key | No | ||
| idempotency_key | Yes | ||
| subject_context | No | Optional related subjects and relationships. Use subject as the reserved ref for the existing subject being enriched. | |
| collection_assessment | Yes | Required collection assessment for enrichment. For member status, use subject as the existing target ref, discover every authoritative source surface, submit an exhaustive source_manifest, and submit the target plus every derived sibling. unavailable is only for genuine collection-identity or authoritative-source failure; it is invalid when collection evidence is known and cannot be used for size, effort, inconvenience, latency, quick-review scope or deferred work. | |
| subject_enrichment_check | Yes | Required evidence check for this enrichment. Reconcile sources against identifiers, attributes, provenance or subject_context request paths. |