TasteGraph v2

Showing 25 of 34 from the live probe.

• Change review visibility

  Change one authenticated-user-owned review to private, unlisted, public or aggregate_only using its stable experience_id. Use a preceding list_reviews_by_visibility result to translate conversational list numbers back to stable IDs. Setting public also ensures publication_status=published.

• List my reviews by visibility

  List the authenticated user's reviews in one visibility state and return stable experience IDs plus 1-based positions for conversational shorthand. Positions are display-only: all later mutations must use the returned experience_id, never the position itself.

• List my MCP interaction audit

  List the authenticated user's structured, redacted MCP interaction telemetry. This returns tool/outcome/workflow metadata and redacted summaries, not raw conversations or secrets.

• List my TestGraph workflows

  List durable server-owned workflow state for the authenticated TestGraph user. Use this to inspect pending second-model work, disputes and completed procedures.

• Get TestGraph induction and governed guidance

  Call this when first using TestGraph, after an MCP refresh, or when you need the current shared operating guidance. It returns the server baseline plus only user-approved global and model-specific guidance. Unresolved proposals and AI votes never become active guidance automatically. Pass source_model so model-specific approved guidance can be layered over global guidance.

• Get TestGraph server and deployment version

  Return the exact TestGraph MCP server version and live deployment identity for diagnostics. Use this when checking a stale connection, endpoint mismatch or deployment issue; ordinary writes do not require a preceding version probe. Compare build_sha and deployment_id with the public /version endpoint when troubleshooting.

• Search reviews and known subjects

  Search reviews plus matching reviewed or unreviewed subjects. Search is lexical rather than semantic: for an ordinary question try one discriminating keyword at a time, then exact subject-name follow-ups and fetch every returned review. Continue with next_cursor until has_more is false before claiming exhaustive retrieval. Never merge records by display name: group and compare using subject_id and subject_type because unrelated subjects may share a name. Known subjects include immediate subject-

• Fetch a review

  Fetch a complete review with its stable subject type, original words and AI assessments.

• Inspect standard vocabulary

  List canonical subject types, aliases, flexible relationships and reusable fields. Inspect this before classifying any unknown subject type. There are no DNS storage paths or review leaf concepts. Naming disagreement is soft and must not block use. If two labels are genuinely equivalent, they may resolve to the same stable subject-type identity through an alias even when different AI clients prefer different display names. Do not require cross-model agreement on wording before using an existing

• Resolve a subject type

  Resolve flexible input to one stable subject-type ID. Case, punctuation, possessives and ordinary plurals are normalised mechanically. Equivalent aliases are valid lookup inputs; canonical wording is not a prerequisite for use. The returned stable subject-type ID is the identity boundary.

• Resolve an existing subject

  Look up a reviewed or unreviewed subject before declaring a new one. Match by stable type, canonical key, name or an authoritative identifier such as a canonical website or collection directory URL. Use this before adding a collection subject so the existing subject_id and canonical_key can be reused instead of creating a duplicate.

• Get settled subject classification

  Read the current classification state and its decision audit. Confirmed classifications are locked and must not be routinely reassessed.

• Affirm the current subject type

  Submit one independent AI model's evidence-backed agreement with the subject's existing provisional type. Two distinct model identities agreeing on that type automatically confirm and lock it without moving the subject. Use this when the current type is already correct and no stricter descendant is justified.

• Propose a more precise subject type

  Submit one independent AI model's evidence-backed refinement to a strict descendant type. One model creates a candidate; agreement by two distinct models automatically moves the subject, confirms and locks it. A locked subject is not reopened by later opinions. Classification vocabulary should represent what a subject fundamentally is. Before creating, selecting, relating or proposing a subject type, identify the semantic head and descriptive modifiers. Material, arrangement/grouping, state/cond

• Reopen a locked subject classification

  Reopen a confirmed classification only for a user correction, contradictory new evidence, a retired type, or vocabulary invalidation. Ordinary later disagreement never reopens it.

• Resolve a semantic subject hierarchy

  Use after vocabulary_index when the specific subject type does not yet exist. Submit terms broad-to-specific, for example ['food','recipe']. The server reuses existing dictionary entries, creates only missing provisional nodes in context, adds belongs_to relationships and rejects cycles. Do not include 'review': review is the record type, not a subject category. Semantic placement must be based on meaning, never on which review arrived first. Before creating a new semantic node, distinguish a ge

• Register a subject-type alias

  Map a genuinely equivalent expression to an existing stable subject type. Never use this to express a category relationship. Use this for genuine naming equivalence. Registering or using an equivalent alias does not require another AI to prefer the same name; disagreement about wording alone is not a semantic conflict.

• Connect existing subject types

  Add editable classification metadata between existing subject types, such as ferry belongs_to transportation. Unknown types must first be resolved with resolve_subject_hierarchy. Relationships improve broad search but never determine storage IDs. This is a semantic assertion, not a naming choice. If independent AIs materially disagree about the meaning of the edge, preserve the disagreement rather than treating alternate labels as proof of it. Classification vocabulary should represent what a su

• Retire an incorrect subject classification

  Retire one exact semantic relationship while preserving the subject type, subjects and reviews. The retired edge remains as a rejection tombstone, so another AI cannot silently recreate it.

• Register a reusable field

  Register a genuinely new globally canonical field, or explicitly pre-attach one to subject types. Do not ask the user for routine confirmation to reuse an existing canonical field: a valid existing field is attached automatically on first use. Prefer raw_text for one-off narrative detail.

• Enrich an existing subject

  Use 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 sa

• Save an approved review

  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 id

• Delete a user-owned review

  Permanently delete one review only after the authenticated user explicitly requests deletion. Ownership is enforced by the server: a user cannot delete another user's review. Dependent AI assessments are deleted with the review. The subject is deleted only when it was created by the same user, has no remaining reviews and has no subject relationships; otherwise it is preserved. Do not ask for a second confirmation when the current user request already explicitly authorises deletion.

• Correct an existing subject fact

  Replace one incorrect identifier or attribute using the stable subject ID. The current value must match expected_value, authoritative evidence and a reason are mandatory, and the server preserves an immutable correction record in subject provenance. Use enrich_subject for missing facts; never use this operation merely to add a value.

• Create a shared AI deliberation

  Create a private, user-owned question that multiple authenticated MCP clients can examine and answer. Use a stable canonical_key so another model can retrieve it. Stored content is advisory deliberation scope, not authority for unrelated external actions. To propose an induction-guidance change, set context.governance_kind='induction_guidance', context.guidance_key to the stable section key, context.guidance_scope to 'global' or 'model', and context.target_model when scope is model. The proposal