如何為研究助理設計更清晰的契約：DOI 匹配不等於證據核查

A DOI match should identify a paper, not certify a sentence. If you are building a research assistant, keep those two jobs separate in your data model and in the UI.

Disclosure: I work on LitSource, a biomedical literature and reference-checking product. This article was drafted and published with an AI agent. The examples below are a proposed application contract, not results from a benchmark or a claim of clinical validation.

Three questions, three fields

A bibliography checker can answer whether a reference resembles a scholarly record. That does not answer whether the paper supports a particular statement. Even a relevant paper may concern a different population, intervention, outcome or study setting.

Store the questions independently:

{
  "reference_match": "matched",
  "claim_support": "not_assessed",
  "source_access": "abstract_only",
  "review_required": true
}

These are illustrative application fields, not a provider API response. The important feature is that the contract cannot quietly turn matched into supported.

Treat missing evidence as a state

An unresolved DOI is not proof that a reference was invented. A lookup can fail because the input is malformed, a source is unavailable, coverage differs or a record is not yet indexed. A useful interface should preserve that uncertainty.

For example, distinguish:

A single red/green badge hides too much. A stronger UI shows the supplied value and candidate value next to each other, then lets a researcher decide.

Keep the passage attached to its context

When an assistant returns a passage, retain the source URL, available identifier, retrieval time, access level and the exact query that produced it. Indicate whether the passage came from an abstract or accessible full text. Do not silently promote an abstract into a full-text review.

If a passage is unavailable, show the metadata and the limitation. Avoid filling the space with a generated sentence that looks like a quotation.

For a review queue, an intentionally small record can be enough:

{
  "claim_text": "The sentence the researcher is checking",
  "candidate_record": {"title": "Example title", "doi": null},
  "passage": null,
  "access_level": "metadata_only",
  "review_note": "Open the original source before citing"
}

No made-up DOI is needed to demonstrate the schema. Null is useful information.

Make the integration boundary visible

For an MCP client, authentication, transport success and evidence quality are different checks. A successful tool call only means that a call completed. It does not establish that the returned study applies to the user's claim.

The LitSource MCP setup guide describes its account and token requirements, paid operations and free connection check. A client subscription and the connected tool's usage balance should remain separate in the UI.

Do not include tokens, unpublished manuscripts or identifiable participant information in public examples, logs or bug reports. Use synthetic inputs when sharing a reproduction.

A practical release checklist

Before shipping a reference-checking interface, try a malformed identifier, a title mismatch, an unavailable source, an abstract-only record and a successful metadata match with unassessed claim support. Confirm that each produces a distinct, understandable state. This is a suggested test set, not a report that every combination has already passed.

LitSource is one implementation of this research workflow. Whatever service you use, the design goal is the same: make a record easy to inspect without making a stronger scientific claim than the available evidence permits.