Save a review against an already-resolved stable subject type. Before saving, perform a generic subject enrichment check using authoritative or primary sources when available. This applies to any kind of subject and does not require a website, location, address or relationship. Submit the result in subject_enrichment_check. Perform routine checking and retry automatically rather than asking the user. Ask the user only when the subject identity is genuinely ambiguous. Add useful discoveries in identifiers, subject_attributes and subject_context with source provenance, while attaching the review only to what was actually experienced. A completed check requires at least one source, and every source must be reconciled: list the request paths populated from it in applied_fields, or explain in unapplied_sources why it yielded no stored discovery. Every applied path must declare a generic retrieval_uses entry explaining how it helps future identity, likely queries, location, classification, relationships, comparison or verification. Treat enrichment as preparation for future TestGraph searches: register information someone may realistically search for later, and do not store facts merely because they are available. Treat this as shared graph building: substantial discovery work for this subject becomes reusable for later searches, while this user can benefit from useful enrichment contributed for other subjects. A subject's own canonical URL is a stable identifier and must be stored in identifiers when found. If enrichment cannot be found, use unavailable with a reason and the searches attempted. Use not_applicable with a reason when external enrichment has no sensible application. Collection assessment is mandatory: declare whether the subject belongs to a wider collection, and when it does, save the collection as subject_context with its authoritative directory URL and a relationship to reviewed_subject. On first discovery, submit every member exposed by a finite authoritative directory as an unreviewed subject and connect each one to the collection. The server stores that verified manifest. On later reviews, reuse the returned collection_id and manifest_revision; do not resubmit the full member list. The server still verifies that the reviewed subject belongs to the stored manifest. Verification status and real-world coverage status are separate: only coverage_status=complete permits reuse or conclusions that a location or member is absent. Partial or unknown manifests return a warning and require refresh. Location is optional; never invent facts or silently geocode coordinates. The experience date defaults to creation time unless experienced_at is explicit. All context subject types must already be resolved. Existing globally registered fields such as rating are automatically attached to this subject type on first valid use; preserve them in structured_data and do not ask for routine confirmation or discard them into raw_text. Use your full available reasoning, web retrieval and tool capabilities as TestGraph's open-ended semantic and discovery engine. Derive useful structure from meaning and evidence instead of waiting for a domain-specific form; the server supplies stable primitives and verifies your claims. Register information someone may realistically search for later against what is saved in TestGraph. Treat enrichment as shared graph work whose cost is paid for this subject and whose useful result can be reused by later searches, just as users benefit from enrichment contributed for other subjects. Store only discoveries with a declared generic retrieval_uses purpose and likely-query examples; facts with no plausible future TestGraph use are not enrichment. For collections, do not stop at one landing page: discover the authoritative source surfaces needed to derive the complete collection and submit collection_assessment.source_manifest with complete traversal coverage and member-to-source mappings, discovery queries, exhaustion evidence and no unresolved source URLs. Every discovered collection member must be submitted. Include reviewed_subject plus every derived sibling in submitted_member_refs; the server requires it to equal discovered_count and verifies that every ref exists and is connected to the collection. unavailable is only for genuine collection-identity or authoritative-source failure and is rejected when collection evidence is known. Unreviewed status, collection size, effort, inconvenience, latency, quick-review scope and future materialisation are not omissions. 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.