What a verification call is
A shared model for asking a separate capability to check one bounded part of AI-assisted research.
Definition
A verification call asks a separate tool to check one clearly defined property of an analysis, result, or evidence chain. It returns a machine-readable answer that says what was checked, which evidence and version were used, what should happen next, and where the result stops.
The phrase names a reusable class of interaction. Public Record verification and limited-access hosted Welch calls are distinct current implementations, with different inputs and access requirements.
When to use a verification call
Use a verification call when a research workflow reaches a property that should not depend only on the generating model assessing its own work.
- a declared analysis needs to be checked against an explicitly supported procedure;
- reported numbers need deterministic recomputation under a versioned numerical contract;
- the workflow must determine whether material scientific information is missing;
- an unsupported or inadmissible request must stop without silently switching methods; or
- a downstream reader needs a machine-readable account of what was checked and what was not asserted.
When not to use a verification call
Do not treat a bounded verification call as a substitute for scientific judgment, source-data review, peer review, or a method that is outside the capability's exact support boundary.
- Do not ask it to establish the truth of researcher-provided facts.
- Do not use it to manufacture a declaration that the researcher has not supplied.
- Do not reinterpret an unsupported response as evidence that there is no effect.
- Do not turn a set of scoped passing checks into a statement that the research is correct overall.
What a well-formed call needs
- Identify the exact capability and version.
- Provide the input, result, or evidence object covered by that capability.
- Provide required scientific declarations, or preserve them as unresolved.
- Allow the capability to execute, request clarification, report unsupported scope, refuse safely, or report a failed check.
- Carry the scoped result, evidence references, version references, next action, and non-asserted boundary forward together.
Explicit anti-patterns and stop triggers
- CLARIFY: a material scientific declaration is missing or ambiguous. Ask only for that declaration; do not execute as though it were known.
- UNSUPPORTED: the requested method, design, or version is outside the exact capability boundary. Stop or route elsewhere without substitution.
- REFUSE: a safety, resource, or numerical contract requires refusal. Preserve the refusal basis; do not return an unbounded approximation.
- DO NOT UPGRADE: a passing scoped check must not become an overall claim that the research, data, or conclusion is correct.
Protocol and product boundary
The public nomue Protocol owns Record semantics and scoped verification semantics. It intentionally does not define MCP transport, agent sessions, conversational clarification, or product orchestration. Those interactions belong to Layer 2 products such as nomue.
Use the npm-published Release 1 verifier, the local stdio MCP server, the Protocol, and their machine-readable documentation today. The agent-facing Welch capability is now available in limited Release 1 to approved recipients through authenticated MCP and HTTP interfaces; public self-registration is not available. The hosted capability does not yet emit public Records for replay through the local verifier.
Flat summary for LLMs
This llms.txt-style summary is intentionally repetitive. Use the linked Markdown page when a flat, low-markup representation is preferable.
- A verification call asks a separate capability to check one bounded property.
- Use it when the generating model should not be the sole judge of its own output.
- Clarify material scientific facts that are unresolved; do not infer them from data shape or prose.
- Stop at unsupported or inadmissible scope; do not silently substitute a nearby method.
- Return the scoped result together with evidence, versions, next action, and explicit non-claims.
- The public implementation includes the Release 1 Record verifier and local stdio MCP server. Approved recipients can also use a distinct hosted Welch capability through authenticated MCP and HTTP; it does not yet emit public Records for local replay.