A
licenseA
qualityD
maintenanceEnables agents to verify claims against live web evidence with calibrated confidence, paying per call via x402 and receiving offline-verifiable signed receipts.
3
20 PyPI
MIT
R/IV — Verify Claims, Citations & Agent Actions
Server Details
Verify claims, citations & agent actions. Free receipt trial; paid prices via live R/IV quotes.
If you are the author of this connector, you can claim ownership by verifying the domain or GitHub account it belongs to. Claimed connector authors can inspect health checks, view analytics, and manage their listing.
- Status
- Healthy
- Uptime
- 99.7% over 22 days
- Last Tested
- Transport
- Streamable HTTP · MCP 2025-06-18
- URL
TDQS
C2.5/5.0
Scored across 35 tools
Disambiguation2/5
Many tools are described as 'independent evidence-verification primitive' with only a different target noun, making it hard to tell claim.check from answer.audit, citation.verify, source.verify, and others. The descriptions are boilerplate and do not clarify boundaries or when to choose one over another. This creates significant misselection risk.
Naming Consistency4/5
Tool names consistently use lowercase dot-separated namespaces (e.g., agent.action.verify, evidence.monitor, pricing.quote), which is predictable across the set. A few names end in nouns rather than actions (provenance.receipt, evidence.bundle), but overall the pattern holds well.
Tool Count2/5
35 tools is heavy for a single MCP server, even one covering broad verification capabilities. The count includes many highly similar verification primitives that could overwhelm an agent and cause selection confusion. This exceeds the typical well-scoped 3-15 range by a wide margin.
Completeness4/5
The surface covers verification, monitoring, audits, evidence, provenance, pricing, trials, and system status, which maps well to the stated claim/citation/agent-action verification domain. Minor gaps may exist around retrieving past receipts or listing execution history, but the core lifecycle appears well represented.
Available Tools
35 toolsagent.action.verifyCInspect
R/IV agent.action.verify — independent evidence-verification primitive for agent assurance. Completed paid execution returns an RVO plus signed R/IV Verification Receipt.
| Name | Required | Description | Default |
|---|---|---|---|
| target | No | ||
| request_id | Yes | Caller-generated idempotency key for this paid execution attempt. | |
| claimed_action | Yes | ||
| evidence_records | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
| cost | Yes | |
| jobId | Yes | |
| result | Yes | R/IV Verification Object with evidence, limitations, verdict and resultHash. |
| status | Yes | |
| receipt | Yes | |
| verdict | Yes | |
| requestId | Yes | |
| timestamps | Yes | |
| operationId | Yes | |
| schemaVersion | Yes | |
| operationVersion | Yes |
TDQS
C2.7/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, and it does disclose two useful traits: this is a paid execution and it returns an RVO plus a signed verification receipt. It omits other behavioral facts (auth/permission needs, cost, rate limits, idempotency behavior beyond the request_id field). Partial but real added context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, front-loaded with the identifier and purpose, with no filler. The density of undefined acronyms slightly undermines clarity, but structurally it is tight.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return values need not be explained, but the description leaves the 25%-coverage parameters, the safety/permission profile (no annotations), and usage routing unresolved. For a paid verification primitive with four parameters, this is under-specified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 25% (only request_id is described in the schema), so the description is expected to compensate for claimed_action, evidence_records, and target. It says nothing about any parameter, leaving three required/optional inputs semantically unexplained in both places.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a verb-ish concept ('independent evidence-verification primitive for agent assurance'), so the general purpose is discernible. However, it is heavy on undefined internal jargon (R/IV, RVO) and does not differentiate itself from the many verification siblings (claim.check, citation.verify, transaction.verify, source.verify). An agent cannot tell precisely what it verifies or how it differs from those.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no when-to-use or when-not-to-use guidance and no named alternative among the numerous sibling verifiers. The only contextual hint is 'Completed paid execution,' which implies a paid step but does not tell the agent when to invoke this versus claim.check or transaction.verify.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
agent.monitorCInspect
R/IV agent.monitor — independent evidence-verification primitive for monitoring. Completed paid execution returns an RVO plus signed R/IV Verification Receipt.
| Name | Required | Description | Default |
|---|---|---|---|
| target | Yes | ||
| cadence | No | daily | |
| request_id | Yes | Caller-generated idempotency key for this paid execution attempt. | |
| public_urls | No | ||
| materiality_rule | No |
Output Schema
| Name | Required | Description |
|---|---|---|
| cost | Yes | |
| jobId | Yes | |
| result | Yes | R/IV Verification Object with evidence, limitations, verdict and resultHash. |
| status | Yes | |
| receipt | Yes | |
| verdict | Yes | |
| requestId | Yes | |
| timestamps | Yes | |
| operationId | Yes | |
| schemaVersion | Yes | |
| operationVersion | Yes |
TDQS
C2.7/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It does add two genuinely useful facts beyond structured fields: execution is paid, and a completed run returns an RVO plus a signed Verification Receipt. However it omits auth/permission requirements, rate limits, what actually gets verified, and what an incomplete or failed run produces.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
It is short, front-loaded, and free of padding, with the output guarantee placed second. The only weakness is heavy reliance on undefined internal jargon, though that is a clarity rather than a length problem.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists so return values need not be explained, but for a 5-parameter, 20%-coverage, annotation-free tool the description is too thin: it never explains the parameters, the monitoring semantics, or how it relates to the many sibling monitors. An agent would struggle to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 20%, so four of five parameters (target, cadence, public_urls, materiality_rule) are documented only by name and type. The description adds no meaning for any parameter and instead introduces undefined terms (RVO, R/IV Receipt) that map to nothing in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
It states a general function ("independent evidence-verification primitive for monitoring") and names an output, but "monitoring" largely restates the tool name and "agent.monitor" is never differentiated from the many sibling monitors (evidence.monitor, claim.monitor, policy.monitor, vendor.monitor). Jargon like "RVO" and "R/IV" is left undefined, so the agent cannot tell what it actually monitors.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No indication of when this tool should be chosen over the numerous *monitor and *verify siblings, and no exclusions or prerequisites beyond the implicit "paid execution." The agent is left to infer selection criteria entirely.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
ai.use.auditCInspect
R/IV ai.use.audit — independent evidence-verification primitive for enterprise assurance. Completed paid execution returns an RVO plus signed R/IV Verification Receipt.
| Name | Required | Description | Default |
|---|---|---|---|
| scope | Yes | ||
| questions | No | ||
| request_id | Yes | Caller-generated idempotency key for this paid execution attempt. | |
| public_urls | No | ||
| workflow_description | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
| cost | Yes | |
| jobId | Yes | |
| result | Yes | R/IV Verification Object with evidence, limitations, verdict and resultHash. |
| status | Yes | |
| receipt | Yes | |
| verdict | Yes | |
| requestId | Yes | |
| timestamps | Yes | |
| operationId | Yes | |
| schemaVersion | Yes | |
| operationVersion | Yes |
TDQS
C2.7/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, and it does disclose two useful traits: the execution is paid and it returns an RVO plus a signed verification receipt. However, it says nothing about authentication requirements, cost magnitude, latency, retry/idempotency behavior (only the schema's request_id hints at that), or whether the call is read-only or stateful. Useful but incomplete.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences with no filler, and the output artifact is stated up front. Minor waste from restating the tool name and abbreviation, but overall tight and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return values need not be re-explained, but for a paid, five-parameter enterprise audit primitive the description is thin: no usage context, no parameter meaning, and no behavioral detail beyond the payment/receipt note. It does not give an agent enough to invoke this correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 20% — just request_id is documented, and only in the schema itself. The description adds no meaning for scope, questions, public_urls, or workflow_description, leaving four of five parameters unexplained in both places. It fails to compensate for the coverage gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific function — "independent evidence-verification primitive" — which is a real verb+resource pairing, but it stays at an abstract assurance level and gives no basis for distinguishing it from siblings like evidence.bundle, claim.check, answer.audit, or evidence.monitor. An agent cannot tell from this text why it should pick ai.use.audit over those alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no when-to-use guidance, no prerequisites, and no mention of alternatives. The only implicit cue is "completed paid execution," which hints at billing but not at the conditions that select this tool. Sibling names in context are not referenced at all.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
answer.auditCInspect
R/IV answer.audit — independent evidence-verification primitive for verification. Completed paid execution returns an RVO plus signed R/IV Verification Receipt.
| Name | Required | Description | Default |
|---|---|---|---|
| answer | Yes | ||
| request_id | Yes | Caller-generated idempotency key for this paid execution attempt. | |
| strictness | No | standard | |
| public_urls | No |
Output Schema
| Name | Required | Description |
|---|---|---|
| cost | Yes | |
| jobId | Yes | |
| result | Yes | R/IV Verification Object with evidence, limitations, verdict and resultHash. |
| status | Yes | |
| receipt | Yes | |
| verdict | Yes | |
| requestId | Yes | |
| timestamps | Yes | |
| operationId | Yes | |
| schemaVersion | Yes | |
| operationVersion | Yes |
TDQS
C2.4/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full behavioral disclosure burden. It mentions 'Completed paid execution' implying cost and a specific lifecycle state, and returns an 'RVO' and 'signed R/IV Verification Receipt', but never explains what RVO is, what the receipt signifies, whether the operation is idempotent, what happens on failure, or what 'independent' verification means operationally. The vague terms obscure more than they reveal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The single-sentence structure is concise but front-loads opaque terminology ('R/IV', 'RVO') rather than the actual function, forcing the reader to parse jargon before understanding the tool. It is appropriately sized but poorly structured for clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema (which reduces the need to explain return values), the description fails to cover fundamental aspects: no annotations, incomplete parameter semantics, unexplained acronyms, and no usage context. For a tool involving paid execution and signed receipts, this is inadequate to enable correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 25%, with only 'request_id' documented as an idempotency key. The description adds no meaning for 'answer', 'strictness', or 'public_urls', leaving three of four parameters without explanation in either schema or description. This is a significant gap for a paid execution tool where parameter semantics are critical.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies this as an 'independent evidence-verification primitive for verification', which is a vague restatement of the tool name 'answer.audit' rather than a clear verb+resource specification. 'R/IV' and 'RVO' are unexplained jargon that an agent without prior context cannot interpret. It does not distinguish from siblings like 'claim.check' or 'citation.verify'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit guidance on when to use this tool versus alternatives such as 'agent.action.verify', 'claim.check', or 'citation.verify'. The phrase 'for verification' is circular and provides no decision criteria or preconditions for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
capabilities.listBInspect
List all 29 production R/IV verification capabilities.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
TDQS
B3.2/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It implies a read-only enumeration and reveals the item count (29), but says nothing about authorization requirements, whether capabilities are filtered by tenant, pagination, or whether the list is stable/versioned.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single short sentence with the verb, scope, and count front-loaded. No padding or redundant restatement of the name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, read-only list tool with no output schema, the description conveys what will be returned (capabilities). However, with no annotations and no return-shape documentation, details like the format of each capability entry and whether this is a discovery prerequisite for the sibling verify tools remain unstated.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so there is no parameter semantics to explain; baseline 4 applies. The empty schema with additionalProperties=false is self-explanatory and the description needs to add nothing further.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Specific verb + resource ('List ... capabilities') with a quantified scope ('all 29 production R/IV verification capabilities'). It is distinguishable from verification-action siblings like claim.check or number.verify in that it is a discovery/enumeration tool, though the description never explicitly contrasts itself with those siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No statement of when to call this versus the many sibling verification tools, and no prerequisites or sequencing advice. An agent can infer it is a catalog-lookup, but the description provides no explicit usage guidance or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
citation.verifyCInspect
R/IV citation.verify — independent evidence-verification primitive for verification. Completed paid execution returns an RVO plus signed R/IV Verification Receipt.
| Name | Required | Description | Default |
|---|---|---|---|
| claim | Yes | ||
| request_id | Yes | Caller-generated idempotency key for this paid execution attempt. | |
| citation_url | Yes | ||
| quoted_or_cited_text | No |
Output Schema
| Name | Required | Description |
|---|---|---|
| cost | Yes | |
| jobId | Yes | |
| result | Yes | R/IV Verification Object with evidence, limitations, verdict and resultHash. |
| status | Yes | |
| receipt | Yes | |
| verdict | Yes | |
| requestId | Yes | |
| timestamps | Yes | |
| operationId | Yes | |
| schemaVersion | Yes | |
| operationVersion | Yes |
TDQS
C2.6/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations the description carries the full burden. It does disclose two meaningful traits beyond the schema: this is a 'paid execution' and a completed run returns a signed receipt. However, it omits auth requirements, rate limits, and the idempotency/replay behavior implied by the request_id key.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, so it is short, but it front-loads a redundant tool-name echo and spends its second sentence on return-value details (RVO, receipt) that the output schema already covers. Jargon reduces signal rather than adding it.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists so return values needn't be re-explained, but for a 4-param paid tool with no annotations and 25% schema coverage the description is too thin. It leaves the verification semantics, cost model, and invocation prerequisites unstated.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 25% (only request_id is documented), so the description should compensate but adds nothing about claim, citation_url, or quoted_or_cited_text. Names are largely self-explanatory, but no semantics, formats, or relationships are clarified.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names the resource (citation) and an action (verify), and mentions evidence verification, but 'independent evidence-verification primitive for verification' is circular and jargon-laden ('R/IV', 'RVO'). It never plainly states that it verifies a claim against a cited URL, and among many sibling verifiers (quote.verify, source.verify, number.verify) it draws no boundary.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no when-to-use, when-not-to-use, or alternative guidance despite a crowded field of verification siblings. An agent cannot tell from the text why it would pick citation.verify over source.verify or claim.check.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
claim.checkCInspect
R/IV claim.check — independent evidence-verification primitive for claims. Completed paid execution returns an RVO plus signed R/IV Verification Receipt.
| Name | Required | Description | Default |
|---|---|---|---|
| claim | Yes | ||
| context | No | ||
| request_id | Yes | Caller-generated idempotency key for this paid execution attempt. | |
| public_urls | No |
Output Schema
| Name | Required | Description |
|---|---|---|
| cost | Yes | |
| jobId | Yes | |
| result | Yes | R/IV Verification Object with evidence, limitations, verdict and resultHash. |
| status | Yes | |
| receipt | Yes | |
| verdict | Yes | |
| requestId | Yes | |
| timestamps | Yes | |
| operationId | Yes | |
| schemaVersion | Yes | |
| operationVersion | Yes |
TDQS
C2.7/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It does disclose two meaningful behavioral facts beyond the schema — the execution is paid (and idempotent via the receipt/idempotency framing) and a successful run returns an RVO plus a signed Verification Receipt. However, it omits auth requirements, error/failure behavior, cost magnitude, and what an RVO actually is.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tight sentences with the core purpose front-loaded and no filler. It loses a point only for jargon density that substitutes opacity for precision rather than trimming it.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists so return values needn't be described, but three of four parameters are undocumented, there are no annotations, and the 'paid execution' mechanic (cost, preconditions, failure modes) is name-dropped without explanation. For a 4-parameter paid verification primitive this leaves notable gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 25% (just request_id), and the description adds nothing about claim, context, or public_urls — the meaning of `claim` vs `context` and the role of supplied URLs go unexplained in both places. With low coverage the description should compensate, and it does not.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies a specific purpose — an independent evidence-verification primitive for claims — but relies on undefined jargon (R/IV, RVO) and never distinguishes itself from the many sibling verify tools (citation.verify, source.verify, number.verify, agent.action.verify, etc.). An agent can grasp the general intent but not what makes claim.check the right pick over its neighbors.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no when-to-use, when-not-to-use, or alternative-routing guidance. With ~10 near-synonymous '*.verify' siblings, the absence of any differentiation language is a real gap; the agent must infer selection from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
claim.monitorCInspect
R/IV claim.monitor — independent evidence-verification primitive for monitoring. Completed paid execution returns an RVO plus signed R/IV Verification Receipt.
| Name | Required | Description | Default |
|---|---|---|---|
| target | Yes | ||
| cadence | No | daily | |
| request_id | Yes | Caller-generated idempotency key for this paid execution attempt. | |
| public_urls | No | ||
| materiality_rule | No |
Output Schema
| Name | Required | Description |
|---|---|---|
| cost | Yes | |
| jobId | Yes | |
| result | Yes | R/IV Verification Object with evidence, limitations, verdict and resultHash. |
| status | Yes | |
| receipt | Yes | |
| verdict | Yes | |
| requestId | Yes | |
| timestamps | Yes | |
| operationId | Yes | |
| schemaVersion | Yes | |
| operationVersion | Yes |
TDQS
C2.6/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden, and it does disclose one genuinely important trait: this is a 'paid execution' that returns a signed receipt, so an agent learns the call costs money and produces an artifact. However, it omits side-effect/reversibility details, permission requirements, and cadence/rate-limit behavior for an ongoing monitor.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences are appropriately short, but the opening 'R/IV claim.monitor — ' restates the tool name and consumes front-loaded space with jargon rather than a plain purpose statement. It is compact but not maximally informative per word.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given five parameters at 20% schema coverage and no annotations, the description is too thin: it explains neither the inputs nor the monitoring semantics (what cadence does, what materiality_rule governs). The output schema covers return values, so that is not a gap, but the input/side-effect guidance is insufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 20% (only request_id is documented), and the description adds no meaning for target, cadence, public_urls, or materiality_rule. For a 5-param tool it should compensate for the coverage gap but instead explains none of them, leaving key inputs like materiality_rule and target opaque.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names the resource (claim) and a mode (monitoring) plus 'evidence-verification,' but it leans heavily on undefined jargon (R/IV, RVO, Verification Receipt) that obscures what the tool actually does. It only marginally distinguishes claim.monitor from siblings like claim.check or evidence.monitor, leaving an agent unsure of the precise delimitation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no statement of when to use this tool versus the many sibling monitors (evidence.monitor, policy.monitor, vendor.monitor) or the check/verify tools (claim.check, citation.verify). No prerequisites, exclusions, or alternative-routing guidance are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
contradiction.scanCInspect
R/IV contradiction.scan — independent evidence-verification primitive for evidence. Completed paid execution returns an RVO plus signed R/IV Verification Receipt.
| Name | Required | Description | Default |
|---|---|---|---|
| items | Yes | ||
| question | No | ||
| request_id | Yes | Caller-generated idempotency key for this paid execution attempt. |
Output Schema
| Name | Required | Description |
|---|---|---|
| cost | Yes | |
| jobId | Yes | |
| result | Yes | R/IV Verification Object with evidence, limitations, verdict and resultHash. |
| status | Yes | |
| receipt | Yes | |
| verdict | Yes | |
| requestId | Yes | |
| timestamps | Yes | |
| operationId | Yes | |
| schemaVersion | Yes | |
| operationVersion | Yes |
TDQS
C2/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It does disclose two useful facts — that execution is paid and that a successful run yields an RVO plus a signed receipt — but it says nothing about permissions/auth, failure modes, cost magnitude, rate limits, or how partial/empty results behave. Coverage is far short of what an unannotated mutating/paid operation requires.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
It is short (two sentences) with no obvious padding, but the second sentence describes output (RVO, receipt) that the output schema likely already covers, and the jargon makes the brevity read as under-specification rather than efficiency.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 3-parameter, partially-undocumented tool with no annotations, the description is too thin: it omits the meaning of `items`/`question`, omits behavioral constraints, and uses undefined acronyms. The presence of an output schema excuses it from explaining return values, but many agent-relevant details are still missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 33% (just request_id), and the description adds nothing about parameters at all — it never mentions the two required-to-satisfy `items` (2–30 strings/objects) or the optional `question`. For a low-coverage schema the description is expected to compensate, and it entirely fails to do so.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description leans on unexplained jargon ('R/IV', 'RVO', 'Verification Receipt') and labels the tool an 'independent evidence-verification primitive for evidence,' which is close to circular and does not actually say what a 'contradiction scan' detects or returns. It also fails to distinguish this tool from any of the many sibling verification tools (claim.check, citation.verify, source.verify, transaction.verify). An agent cannot confidently tell what this does versus its neighbors.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no when-to-use guidance, no preconditions, and no named alternative among the ~35 sibling verification/monitoring tools. The single hint is the word 'independent,' which loosely implies it should be used for independent verification, but nothing states when this is preferable to claim.check or citation.ver.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
control.checkCInspect
R/IV control.check — independent evidence-verification primitive for enterprise assurance. Completed paid execution returns an RVO plus signed R/IV Verification Receipt.
| Name | Required | Description | Default |
|---|---|---|---|
| request_id | Yes | Caller-generated idempotency key for this paid execution attempt. | |
| control_type | No | ||
| control_claim | Yes | ||
| evidence_records | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
| cost | Yes | |
| jobId | Yes | |
| result | Yes | R/IV Verification Object with evidence, limitations, verdict and resultHash. |
| status | Yes | |
| receipt | Yes | |
| verdict | Yes | |
| requestId | Yes | |
| timestamps | Yes | |
| operationId | Yes | |
| schemaVersion | Yes | |
| operationVersion | Yes |
TDQS
C2.7/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full disclosure burden, and it does add one genuinely useful behavioral fact: execution is paid and produces a signed receipt. However, it omits permissions/auth requirements, idempotency behavior beyond the schema's request_id note, latency or rate limits, and whether the check is side-effect free — leaving important behavioral traits unstated for a paid operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two front-loaded sentences with no filler, and the paid-execution/return fact is placed immediately after the identity statement. Minor deduction for unexplained internal acronyms (R/IV, RVO) that consume space without adding clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return values need not be explained, and the description correctly does not belabor them. But for a four-parameter, paid, no-annotation tool with three undocumented required parameters and no usage routing, the description leaves far too much unspecified for an agent to invoke it confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 25%: only request_id is documented, while control_claim, evidence_records, and the control_type enum have no schema descriptions. The description adds nothing about any of these parameters — not the expected shape of a control claim, what constitutes a valid evidence record, or how control_type values map to checking behavior — so it fails to compensate for the coverage gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names the resource class (control / evidence-verification) and frames it as an 'independent evidence-verification primitive,' which is more than a pure name restatement, but 'primitive' and 'enterprise assurance' are jargon that stop short of plainly stating the action, e.g. 'check whether a stated control claim is supported by supplied evidence records.' It also does not differentiate itself from close siblings such as claim.check, evidence.bundle, or citation.verify.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no statement of when to call this tool, when not to, or which sibling to prefer for adjacent tasks like claim checking or evidence bundling. 'Enterprise assurance' is a domain hint, not usage guidance, so an agent must infer the trigger conditions entirely.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
data.flow.verifyCInspect
R/IV data.flow.verify — independent evidence-verification primitive for enterprise assurance. Completed paid execution returns an RVO plus signed R/IV Verification Receipt.
| Name | Required | Description | Default |
|---|---|---|---|
| request_id | Yes | Caller-generated idempotency key for this paid execution attempt. | |
| public_urls | No | ||
| evidence_records | No | ||
| flow_description | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
| cost | Yes | |
| jobId | Yes | |
| result | Yes | R/IV Verification Object with evidence, limitations, verdict and resultHash. |
| status | Yes | |
| receipt | Yes | |
| verdict | Yes | |
| requestId | Yes | |
| timestamps | Yes | |
| operationId | Yes | |
| schemaVersion | Yes | |
| operationVersion | Yes |
TDQS
C2.7/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, and it does disclose two real traits: execution is paid, and a successful run returns an RVO plus a signed verification receipt. It omits permissions/auth requirements, failure and partial-completion behavior, cost magnitude, and what 'RVO' actually denotes, leaving meaningful gaps for a mutating paid operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the tool identity and immediately followed by the outcome contract; nothing is padded. It loses a point only because the second sentence is dense with undefined acronyms (R/IV, RVO) that consume space without conveying meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return-value explanation is not required, but this is a paid, high-complexity tool (50 URLs, 200 evidence records, 50k-char description) with no annotations and sparse schema coverage. The description says nothing about input composition, prerequisites, or how evidence_records and public_urls interact, leaving the agent under-informed before a costly call.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 25% — only request_id is documented, and that by the schema itself. The description adds nothing about flow_description (50k-char payload), public_urls (up to 50 URIs), or evidence_records (up to 200 objects), nor how those inputs relate to the verification result. It fails to compensate for the coverage gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies an action ('evidence-verification') and a domain ('data flow'), but 'R/IV ... primitive for enterprise assurance' is abstract jargon that never says what a data flow is or what evidence gets verified. With ~30 sibling 'verify/audit/check' tools (workflow.verify, transaction.verify, source.verify, citation.verify), there is zero differentiation, so an agent cannot tell why it would pick this over the others.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no when-to-use, when-not-to-use, or alternative guidance at all. The only contextual hint ('completed paid execution') describes cost mechanics, not the conditions under which this tool is the right choice versus the many sibling verification tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
dependency.mapCInspect
R/IV dependency.map — independent evidence-verification primitive for dependency risk. Completed paid execution returns an RVO plus signed R/IV Verification Receipt.
| Name | Required | Description | Default |
|---|---|---|---|
| request_id | Yes | Caller-generated idempotency key for this paid execution attempt. | |
| public_urls | No | ||
| workflow_description | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
| cost | Yes | |
| jobId | Yes | |
| result | Yes | R/IV Verification Object with evidence, limitations, verdict and resultHash. |
| status | Yes | |
| receipt | Yes | |
| verdict | Yes | |
| requestId | Yes | |
| timestamps | Yes | |
| operationId | Yes | |
| schemaVersion | Yes | |
| operationVersion | Yes |
TDQS
C2.3/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It does disclose two real behavioral traits beyond the schema — execution is paid, and a completed run returns an 'RVO plus signed R/IV Verification Receipt' — but acronyms are left undefined and there is no mention of cost, auth, latency, or failure behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
It is short and the useful behavioral clause is in the second sentence, but the first sentence is largely a restated name plus undefined jargon ('R/IV', 'RVO') that consumes space without adding actionable information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists so return values needn't be spelled out, but for a paid, multi-parameter analysis tool with zero annotations and 33% param coverage, the description leaves the core operation, prerequisites, and acronym definitions unexplained.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 33%; request_id is documented but workflow_description and public_urls are not. The description adds no parameter meaning at all — it never explains what a workflow_description should contain or how public_urls are used, so it fails to compensate for the coverage gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description labels the tool an 'evidence-verification primitive for dependency risk', essentially restating the name with R/IV branding rather than stating a concrete verb+resource action. It never says what actually gets mapped or produced from the workflow_description/public_urls inputs, and it does not separate itself from the close sibling dependency.monitor.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no statement of when to use this versus siblings such as dependency.monitor, workflow.verify, or provenance.receipt. The only faint signal is the word 'independent', which hints at a verification use case but gives no explicit trigger or exclusion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
dependency.monitorCInspect
R/IV dependency.monitor — independent evidence-verification primitive for monitoring. Completed paid execution returns an RVO plus signed R/IV Verification Receipt.
| Name | Required | Description | Default |
|---|---|---|---|
| target | Yes | ||
| cadence | No | daily | |
| request_id | Yes | Caller-generated idempotency key for this paid execution attempt. | |
| public_urls | No | ||
| materiality_rule | No |
Output Schema
| Name | Required | Description |
|---|---|---|
| cost | Yes | |
| jobId | Yes | |
| result | Yes | R/IV Verification Object with evidence, limitations, verdict and resultHash. |
| status | Yes | |
| receipt | Yes | |
| verdict | Yes | |
| requestId | Yes | |
| timestamps | Yes | |
| operationId | Yes | |
| schemaVersion | Yes | |
| operationVersion | Yes |
TDQS
C2.4/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It does disclose that execution is 'paid' and that completion yields an RVO plus a signed receipt, which is useful context, but it says nothing about permissions, failure behavior, rate limits, or what happens to a monitoring cadence once established.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tight sentences that are front-loaded with the tool name and its role. Nothing is padded, though the heavy jargon slightly reduces immediate legibility.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a paid, five-parameter tool with mostly undocumented schema and no annotations, the description is far too thin. It needn't explain return values (an output schema exists), but it should clarify target semantics, cadence behavior, and the materiality_rule, which it does not.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 20% (just request_id), yet the description explains none of the five parameters. The meaning of 'target', 'cadence', 'public_urls', and especially 'materiality_rule' is left entirely to the bare schema, so the description fails to compensate for the coverage gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies a 'dependency monitoring' verification primitive, but it is wrapped in proprietary jargon (R/IV, RVO, Verification Receipt) that obscures what the tool actually checks. It never differentiates itself from the closely-named sibling dependency.map or the many other *.monitor tools, leaving the agent to infer the distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no statement of when to use this tool versus dependency.map, evidence.monitor, or claim.monitor. The only hint is the word 'monitoring', which is implied rather than explained, and no prerequisites or exclusions are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
evidence.bundleDInspect
R/IV evidence.bundle — independent evidence-verification primitive for evidence. Completed paid execution returns an RVO plus signed R/IV Verification Receipt.
| Name | Required | Description | Default |
|---|---|---|---|
| context | No | ||
| question | Yes | ||
| request_id | Yes | Caller-generated idempotency key for this paid execution attempt. | |
| public_urls | No |
Output Schema
| Name | Required | Description |
|---|---|---|
| cost | Yes | |
| jobId | Yes | |
| result | Yes | R/IV Verification Object with evidence, limitations, verdict and resultHash. |
| status | Yes | |
| receipt | Yes | |
| verdict | Yes | |
| requestId | Yes | |
| timestamps | Yes | |
| operationId | Yes | |
| schemaVersion | Yes | |
| operationVersion | Yes |
TDQS
D1.9/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It usefully flags that this is a "paid execution" and returns a signed receipt, but it does not disclose permissions, idempotency behavior, cost, or what the RVO/Receipt contain — and "RVO"/"R/IV" are undefined.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no obvious padding, but the space is spent on opaque acronyms rather than the load-bearing information (what the tool verifies, cost, expected inputs). Front-loading the tool name is redundant.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a paid, receipt-producing verification tool with an output schema, the description is too thin: it never explains the paid-execution implications, the receipt's role, or the semantics of the undocumented parameters. An output schema removes the need to explain return values, but the gap around cost and inputs remains.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 25% (only request_id is documented in the schema), so the description must compensate. It adds nothing about question, context, or public_urls, leaving three of four parameters without meaning beyond their types.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The core phrasing "independent evidence-verification primitive for evidence" is near-circular and leans on undefined internal jargon ("R/IV", "RVO"). It signals a verification verb but never plainly states what the bundle actually does or how it differs from siblings like claim.check, source.verify, or citation.verify.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no when-to-use guidance, no exclusion of alternatives, and no mention of the nearest siblings despite ~35 verification-oriented tools in the list. An agent cannot infer from the text when this tool is the right choice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
evidence.monitorCInspect
R/IV evidence.monitor — independent evidence-verification primitive for monitoring. Completed paid execution returns an RVO plus signed R/IV Verification Receipt.
| Name | Required | Description | Default |
|---|---|---|---|
| target | Yes | ||
| cadence | Yes | ||
| request_id | Yes | Caller-generated idempotency key for this paid execution attempt. | |
| public_urls | No | ||
| monitor_type | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
| cost | Yes | |
| jobId | Yes | |
| result | Yes | R/IV Verification Object with evidence, limitations, verdict and resultHash. |
| status | Yes | |
| receipt | Yes | |
| verdict | Yes | |
| requestId | Yes | |
| timestamps | Yes | |
| operationId | Yes | |
| schemaVersion | Yes | |
| operationVersion | Yes |
TDQS
C2.7/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and discloses some behavior: execution is paid, completion yields an RVO plus a signed 'R/IV Verification Receipt.' That reveals a cost and an output, which the schema doesn't. It still omits what a monitor does over time (state changes, cadence effects), auth/permission needs, and failure behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two compact sentences with the identity front-loaded and no filler. The density of unexplained acronyms (R/IV, RVO, R/IV Verification Receipt) wastes the limited space on terms the agent cannot decode.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists so return values needn't be detailed, but with five parameters, 20% schema coverage, no annotations, and two enums whose semantics are unexplained, the description is far too thin. An agent cannot confidently populate target, monitor_type, or cadence from this text.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 20% (just request_id), yet the description explains none of the five parameters: the crucial target, monitor_type ('claim','source','entity','dependency'), cadence, or public_urls. It fails to compensate for the low coverage, leaving four parameters defined only by type and enum.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
It states a broad category ('independent evidence-verification primitive for monitoring') but the jargon 'R/IV' and 'RVO' is unexplained, and it never says what a monitor actually tracks. Against siblings like claim.monitor, dependency.monitor, and source.verify, an agent gets no basis for choosing this one. Purpose is only loosely conveyed.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no when-to-use guidance, no description of when monitoring is preferred over one-shot verification siblings (e.g., citation.verify, transaction.verify), and no exclusions. The closest thing to guidance is the mention of 'completed paid execution,' which hints at a paywall but not usage conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
example.getBInspect
Return a synthetic example only; never counts as demand.
| Name | Required | Description | Default |
|---|---|---|---|
| capabilityId | No |
TDQS
B3.2/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, and it does disclose one important behavioral trait: the output is synthetic and has no bearing on demand accounting. However, it says nothing about read-only safety, side effects, or how capabilityId influences the result, so coverage is partial.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single short sentence with no filler; the key constraint is front-loaded. It is efficient, though its brevity borders on under-specification rather than tightness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter read tool with no output schema, the description conveys what comes back (a synthetic example) and one caveat, which is the minimum needed. The unexplained capabilityId and lack of any behavioral detail beyond the caveat leave a gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter capabilityId has 0% schema description coverage, and the description never explains what it is, what format it takes, or whether it is required (it is not). With low coverage the description is expected to compensate, and it does not.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Return a synthetic example') and adds a qualifier ('never counts as demand') that distinguishes it from the surrounding verify/audit/monitor siblings by signalling it produces placeholder data rather than real results. It does not name a specific alternative, but the tool's nature is clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
'never counts as demand' hints at a caveat/guardrail rather than an explicit when-to-use rule; it implies the tool is for demonstration or scaffolding and should not be relied on for real demand. No explicit condition selecting it over siblings is given, so usage is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
fact.extractCInspect
R/IV fact.extract — independent evidence-verification primitive for evidence. Completed paid execution returns an RVO plus signed R/IV Verification Receipt.
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | ||
| max_claims | No | ||
| request_id | Yes | Caller-generated idempotency key for this paid execution attempt. | |
| source_url | No |
Output Schema
| Name | Required | Description |
|---|---|---|
| cost | Yes | |
| jobId | Yes | |
| result | Yes | R/IV Verification Object with evidence, limitations, verdict and resultHash. |
| status | Yes | |
| receipt | Yes | |
| verdict | Yes | |
| requestId | Yes | |
| timestamps | Yes | |
| operationId | Yes | |
| schemaVersion | Yes | |
| operationVersion | Yes |
TDQS
C2.1/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It does disclose that execution is 'paid' and returns a signed Verification Receipt, which is useful, but it says nothing about permissions, side effects, failure handling, or what an 'RVO' is, leaving key behavior opaque.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
It is appropriately short and front-loads the purpose statement, but it is dense with undefined jargon ('R/IV', 'RVO') that consumes space without adding clarity for a reader or agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists so return values needn't be spelled out, but for a paid, 4-parameter tool with a rich sibling set, the description omits what the tool actually does, when to invoke it, and the meaning of its inputs. That is a significant completeness gap despite the output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 25%: request_id is documented, but text, max_claims, and source_url are not. The description mentions no parameters at all, so it fails to compensate for the coverage gap on a 4-parameter tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The name implies extracting facts, but the description instead calls it an 'independent evidence-verification primitive for evidence,' which muddles the actual action (extraction of claims from text). It never states what is extracted or how it differs from the many verify/check siblings (citation.verify, claim.check, number.verify), and 'for evidence' is circular.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no when-to-use guidance, no mention of when not to use it, and no routing to any of the numerous alternative verification tools. An agent cannot tell from this text why it would pick fact.extract over claim.check or citation.verify.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
investigation.runCInspect
R/IV investigation.run — independent evidence-verification primitive for investigation reporting. Completed paid execution returns an RVO plus signed R/IV Verification Receipt.
| Name | Required | Description | Default |
|---|---|---|---|
| scope | Yes | ||
| deadline | No | ||
| question | Yes | ||
| request_id | Yes | Caller-generated idempotency key for this paid execution attempt. | |
| public_urls | No |
Output Schema
| Name | Required | Description |
|---|---|---|
| cost | Yes | |
| jobId | Yes | |
| result | Yes | R/IV Verification Object with evidence, limitations, verdict and resultHash. |
| status | Yes | |
| receipt | Yes | |
| verdict | Yes | |
| requestId | Yes | |
| timestamps | Yes | |
| operationId | Yes | |
| schemaVersion | Yes | |
| operationVersion | Yes |
TDQS
C2.6/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, and it does disclose two meaningful traits: execution is paid and a completed run returns an RVO plus a signed Verification Receipt. It still omits auth requirements, latency/deadline behavior, failure modes, and how idempotency interacts with retries, so the disclosure is partial.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with little padding, but the opening clause largely restates the tool name and the remaining content is compressed into dense, undefined abbreviations. Front-loading is acceptable; information density per sentence is low given the jargon.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return values need not be detailed, but for a five-parameter paid execution tool with no annotations the description leaves too much open: what scope/question should contain, how deadline is honored, and what the paid-execution contract means in practice.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 20% (request_id), leaving question, scope, deadline, and public_urls essentially undocumented. The description adds no meaning for any of these parameters, so it fails to compensate for the coverage gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a resource ('investigation', 'evidence-verification') and casts it as an independent verification primitive for reporting, but leans on unexplained jargon ('R/IV', 'RVO'). It does not distinguish this tool from a large cluster of verification siblings (claim.check, citation.verify, evidence.bundle, contradiction.scan), so an agent cannot route reliably among them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no statement of when to use this versus the many alternative verification tools, no prerequisite conditions, and no exclusions. The only contextual hint is that execution is paid, which speaks to cost rather than selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
model.change.auditCInspect
R/IV model.change.audit — independent evidence-verification primitive for dependency risk. Completed paid execution returns an RVO plus signed R/IV Verification Receipt.
| Name | Required | Description | Default |
|---|---|---|---|
| current | Yes | ||
| baseline | Yes | ||
| workflow | Yes | ||
| request_id | Yes | Caller-generated idempotency key for this paid execution attempt. | |
| public_urls | No |
Output Schema
| Name | Required | Description |
|---|---|---|
| cost | Yes | |
| jobId | Yes | |
| result | Yes | R/IV Verification Object with evidence, limitations, verdict and resultHash. |
| status | Yes | |
| receipt | Yes | |
| verdict | Yes | |
| requestId | Yes | |
| timestamps | Yes | |
| operationId | Yes | |
| schemaVersion | Yes | |
| operationVersion | Yes |
TDQS
C2.2/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full disclosure burden. It usefully flags that execution is paid and yields an RVO plus a signed receipt, but says nothing about failure modes, idempotency behavior, required inputs' semantics, or what the audit actually evaluates. That is thin for a paid, mutation-adjacent operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences with no filler, and the purpose statement leads. However, the 'R/IV' prefix is internal jargon that spends opening-token real estate without informing the agent, and the brevity borders on under-specification for a 5-parameter tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return values needn't be spelled out, but the description still omits how the required workflow/baseline/current triple is composed and what the audit covers. For a tool with nested objects, 4 required params, and 20% schema coverage, it is incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 20%; only request_id is documented. The opaque nested 'baseline' and 'current' objects and the 10-50k-character 'workflow' string get no explanation in either schema or description, so the agent has no idea what shape they must take relative to each other.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description labels the tool as an 'independent evidence-verification primitive for dependency risk,' which hints at auditing model/dependency changes but never states a specific verb+resource pairing an agent can act on. It does not distinguish this from siblings such as dependency.monitor, dependency.map, ai.use.audit, or workflow.verify. The purpose is inferable but vague.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no when-to-use guidance, no when-not-to-use exclusions, and no named alternative among the many verification/audit siblings. The agent is left to guess whether this or dependency.monitor/ai.use.audit is the right call for a given change-verification need.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
number.verifyCInspect
R/IV number.verify — independent evidence-verification primitive for verification. Completed paid execution returns an RVO plus signed R/IV Verification Receipt.
| Name | Required | Description | Default |
|---|---|---|---|
| unit | No | ||
| as_of | No | ||
| claim | Yes | ||
| value | No | ||
| request_id | Yes | Caller-generated idempotency key for this paid execution attempt. | |
| public_urls | No |
Output Schema
| Name | Required | Description |
|---|---|---|
| cost | Yes | |
| jobId | Yes | |
| result | Yes | R/IV Verification Object with evidence, limitations, verdict and resultHash. |
| status | Yes | |
| receipt | Yes | |
| verdict | Yes | |
| requestId | Yes | |
| timestamps | Yes | |
| operationId | Yes | |
| schemaVersion | Yes | |
| operationVersion | Yes |
TDQS
C2.1/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full disclosure burden. It does add two useful facts — execution is paid and produces an RVO plus a signed R/IV Verification Receipt — but leaves out permissions/auth, failure and non-payment behavior, what 'RVO' means, whether it is idempotent (the schema notes request_id is an idempotency key but the description never mentions retry semantics), and any rate limits. Half the behavioral story is untold.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no padding, but the first sentence is spent on a redundant 'R/IV number.verify —' prefix and a circular self-description, so the front-loaded portion delivers little. It is short without being wasteful in length, only in payload.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return values need not be spelled out, but for a paid, idempotent, six-parameter verification primitive with zero annotations the description should at least establish scope (numeric claims), cost implications beyond 'paid', and how it differs from the sibling verify tools. Those gaps make it insufficient for correct invocation in a crowded toolset.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Six parameters exist and schema description coverage is only 17% (solely request_id), so the description must compensate and it does not — it never mentions claim, value, unit, as_of, or public_urls. The meaning of unit and as_of in a numeric-verification context is exactly the kind of thing an agent needs and cannot infer. Below the baseline because the coverage gap is unaddressed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description calls itself an 'independent evidence-verification primitive for verification,' which is circular and repeats the name rather than stating what it verifies. In a family with giants like citation.verify, quote.verify, transaction.verify, and claim.check, it never says the tool is scoped to numeric claims or what a 'number' verification produces. The only concrete content is the paid-execution/receipt clause, so purpose is largely restated, not explained.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no when-to-use, when-not-to-use, or alternative-tool guidance at all, despite at least a dozen sibling verify/check tools that an agent must choose between. The word 'independent' faintly implies it does its own evidence gathering, but nothing routes the agent to or away from citation.verify, claim.check, or source.verify. Effectively no guidance beyond the name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
policy.monitorCInspect
R/IV policy.monitor — independent evidence-verification primitive for monitoring. Completed paid execution returns an RVO plus signed R/IV Verification Receipt.
| Name | Required | Description | Default |
|---|---|---|---|
| target | Yes | ||
| cadence | No | daily | |
| request_id | Yes | Caller-generated idempotency key for this paid execution attempt. | |
| public_urls | No | ||
| materiality_rule | No |
Output Schema
| Name | Required | Description |
|---|---|---|
| cost | Yes | |
| jobId | Yes | |
| result | Yes | R/IV Verification Object with evidence, limitations, verdict and resultHash. |
| status | Yes | |
| receipt | Yes | |
| verdict | Yes | |
| requestId | Yes | |
| timestamps | Yes | |
| operationId | Yes | |
| schemaVersion | Yes | |
| operationVersion | Yes |
TDQS
C2.6/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, and it does add useful context: execution is a 'paid' run and a completed run returns an RVO plus a signed verification receipt. However, it omits permission/auth requirements, what cadence actually does, behavior on partial failure, and any rate or cost specifics beyond the word 'paid'.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
It is short and front-loads the purpose, so it is not wasteful in length. But it opens by repeating the tool name and spends its limited budget on opaque acronyms ('R/IV', 'RVO') that carry no decodable meaning for an outside caller.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return values need not be detailed. But for a 5-parameter, 2-required monitoring tool with 20% schema coverage, key inputs like target, cadence, and materiality_rule are unexplained, and the domain vocabulary is never defined, leaving the definition inadequate to invoke the tool confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 20% (just request_id is documented), yet the description explains none of the other parameters. 'target' (the primary required input), 'cadence', 'public_urls', and 'materiality_rule' receive no meaning here or in the schema, leaving the agent to guess at semantics and format.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names the resource (policy monitoring) and calls itself an 'independent evidence-verification primitive', but the actual operation is buried under undefined jargon ('R/IV', 'RVO'). It does not differentiate from the many sibling monitor tools (claim.monitor, vendor.monitor, evidence.monitor, dependency.monitor), so an agent cannot tell why it would pick this one.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no statement of when to use this tool versus any alternative. The crowded sibling set contains at least four other *.monitor tools with no routing guidance, and no prerequisites or exclusion conditions are given. 'For monitoring' merely restates the name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
pricing.quoteCInspect
Get public R/IV pricing and machine-payment routes without charging or authentication.
| Name | Required | Description | Default |
|---|---|---|---|
| capabilityId | No | ||
| capability_id | No |
TDQS
C2.9/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does disclose that the call is public, incurs no charge, and needs no auth. That is genuinely useful behavioral context, but it says nothing about return format, idempotency, or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence with no waste. It is terse but efficient; the terseness comes at the cost of completeness rather than verbosity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no annotations, no output schema, and two undocumented parameters, the description is too thin: it does not explain the parameters, the return values, or how to interpret pricing. It covers intent but not the operational detail an agent needs.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Both parameters (capabilityId and capability_id) have 0% schema description coverage, and the description provides no parameter semantics at all. It also ignores the odd duplicate camelCase/snake_case parameter pair, leaving the agent to guess which to supply.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('Get') and resource ('public R/IV pricing and machine-payment routes'), so an agent can tell what it retrieves. However, 'R/IV' is unexplained jargon and the description doesn't differentiate from any sibling, though no close sibling exists.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'without charging or authentication' signals the operation is safe and free to call, which is mild usage context. But there is no explicit when-to-use, prerequisite, or alternative routing guidance against the many sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
procurement.evidenceCInspect
R/IV procurement.evidence — independent evidence-verification primitive for enterprise assurance. Completed paid execution returns an RVO plus signed R/IV Verification Receipt.
| Name | Required | Description | Default |
|---|---|---|---|
| request_id | Yes | Caller-generated idempotency key for this paid execution attempt. | |
| public_urls | No | ||
| requirements | Yes | ||
| product_or_vendor | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
| cost | Yes | |
| jobId | Yes | |
| result | Yes | R/IV Verification Object with evidence, limitations, verdict and resultHash. |
| status | Yes | |
| receipt | Yes | |
| verdict | Yes | |
| requestId | Yes | |
| timestamps | Yes | |
| operationId | Yes | |
| schemaVersion | Yes | |
| operationVersion | Yes |
TDQS
C2.3/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It does disclose two useful traits beyond the schema: the execution is paid (a cost the agent must weigh) and the verification is 'independent'. However it says nothing about auth requirements, rate limits, failure modes, or side effects, leaving meaningful gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
It is short (two sentences) and not padded, but it is cryptic rather than front-loaded: the lead clause is meta-jargon ('R/IV ... primitive') instead of a plain statement of function, so brevity comes at the cost of clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return values needn't be re-explained, but with no annotations, three undocumented parameters, and undefined acronyms, the description is not complete enough for an agent to confidently invoke a paid verification tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 25% (just request_id documented) and the description adds no meaning for product_or_vendor, requirements, or public_urls. With low coverage the description was expected to compensate and it does not, though the schema does document the idempotency key well.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description labels itself a 'evidence-verification primitive' but never states a concrete verb+resource an agent can act on, and undefined jargon ('R/IV', 'RVO') obscures what it actually does. It also fails to differentiate itself from close siblings such as claim.check, source.verify, citation.verify, or provenance.receipt.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no statement of when to use this tool, when not to, or which sibling to prefer. The only hint of context is 'for enterprise assurance' and the mention of paid execution, neither of which routes the agent among the many verify/monitor siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
provenance.receiptCInspect
R/IV provenance.receipt — independent evidence-verification primitive for provenance. Completed paid execution returns an RVO plus signed R/IV Verification Receipt.
| Name | Required | Description | Default |
|---|---|---|---|
| request_id | Yes | Caller-generated idempotency key for this paid execution attempt. | |
| source_records | Yes | ||
| job_or_artifact | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
| cost | Yes | |
| jobId | Yes | |
| result | Yes | R/IV Verification Object with evidence, limitations, verdict and resultHash. |
| status | Yes | |
| receipt | Yes | |
| verdict | Yes | |
| requestId | Yes | |
| timestamps | Yes | |
| operationId | Yes | |
| schemaVersion | Yes | |
| operationVersion | Yes |
TDQS
C2.7/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, but it does disclose that execution is paid and that completion yields an RVO plus a signed receipt. It omits failure/error behavior, prerequisites, and whether runs are idempotent beyond the schema's request_id hint.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two compact sentences, front-loaded with the tool identity and the return behavior. Efficient sizing, though the dense jargon reduces immediate readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return values needn't be explained, but for a complex paid verification primitive with nested object inputs and two undocumented required parameters, the description should cover prerequisites, failure modes, and the trial alternative — none of which appear.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 33% — request_id is documented, but job_or_artifact and source_records (both required, including a nested object and a 200-item array) are undocumented in both schema and description. The description adds no meaning for these parameters, so the coverage gap is uncompensated.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific domain action (evidence verification producing a provenance receipt) and implies a paid-vs-trial distinction against provenance.receipt.trial. However, the unexplained acronyms 'R/IV' and 'RVO' leave the actual resource and output ambiguous, so an agent outside the domain cannot fully pin down what is verified or returned.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use guidance or exclusions are given. The phrase 'paid execution' faintly implies this is the paid counterpart to provenance.receipt.trial, but the description never states that relationship or when one should be chosen over the other.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
provenance.receipt.trialCInspect
Run one free signed R/IV provenance receipt trial. No payment or account required.
| Name | Required | Description | Default |
|---|---|---|---|
| input | Yes | ||
| trial_id | Yes |
TDQS
C2.4/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It discloses that the call is free, needs no account, and is limited to one trial, which is useful, but says nothing about what the receipt contains, whether the supplied input is persisted or signed, or what state the trial leaves behind. For a mutation-style operation with zero annotation coverage this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short, front-loaded sentences with no filler; the free/no-account constraint is stated immediately. The only cost is the unexplained "R/IV" token, which is concision at the expense of clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with a nested input object, a required identifier, no output schema, and no annotations, the description is far too thin. It should explain the trial_id, the expected input shape, and the trial lifecycle, none of which appear anywhere.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% for two required parameters. The description never mentions trial_id or input, so the agent gets no meaning for the 12-200 character identifier or the free-form nested input object beyond what the bare schema types imply.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description gives a verb ("Run") and a resource ("provenance receipt trial") and signals it is the free variant of provenance.receipt. However, "R/IV" is unexplained jargon, and the description never explicitly contrasts this trial with the sibling provenance.receipt, leaving the agent to infer the difference.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
"No payment or account required" hints at prerequisites but gives no when-to-use guidance: it never says when to choose this trial over provenance.receipt, whether the trial is one-per-identity, or what happens after the trial expires. No alternatives are named.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
quote.verifyDInspect
R/IV quote.verify — independent evidence-verification primitive for verification. Completed paid execution returns an RVO plus signed R/IV Verification Receipt.
| Name | Required | Description | Default |
|---|---|---|---|
| quote | Yes | ||
| context | No | ||
| request_id | Yes | Caller-generated idempotency key for this paid execution attempt. | |
| source_url | Yes | ||
| attribution | No |
Output Schema
| Name | Required | Description |
|---|---|---|
| cost | Yes | |
| jobId | Yes | |
| result | Yes | R/IV Verification Object with evidence, limitations, verdict and resultHash. |
| status | Yes | |
| receipt | Yes | |
| verdict | Yes | |
| requestId | Yes | |
| timestamps | Yes | |
| operationId | Yes | |
| schemaVersion | Yes | |
| operationVersion | Yes |
TDQS
D1.9/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations, so the description carries the full behavioral burden. It does mention 'completed paid execution returns an RVO plus signed R/IV Verification Receipt', signalling a payment/execution model, but leaves critical gaps: what an RVO is, whether retries are idempotent (only schema notes idempotency), and what happens on failure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, front-loaded with an identifier, but it's under-specified rather than tight; the 'R/IV' and 'RVO' jargon is unexplained and a later clause about receipts is buried.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite an output schema existing, five-parameter verification tool with no annotations, 20% schema coverage and no usage guidance is under-documented. Key operational facts (payment trigger, idempotency, error behavior, what counts as a verified quote) are absent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 20% (only request_id documented). The description explains no parameters: quote, source_url, context and attribution are undocumented in both description and schema, leaving agents guessing at format and purpose.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description labels the tool an 'independent evidence-verification primitive for verification' – tautological and vague. It doesn't say what it verifies (a quoted string against a source URL) or distinguish itself from siblings like citation.verify, fact.extract, or claim.check. The name 'quote.verify' implies the resource, but the prose adds little.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No when-to-use guidance at all. There are many adjacent verify/audit siblings (citation.verify, source.verify, number.verify, claim.check), and nothing here routes an agent to quote.verify over them.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
service.matchCInspect
Match a verification goal to the smallest R/IV capability without charging.
| Name | Required | Description | Default |
|---|---|---|---|
| goal | Yes |
TDQS
C2.6/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full disclosure burden. It hints at cost behavior ('without charging') and minimality ('smallest'), but says nothing about side effects, auth requirements, rate limits, or what a 'match' returns. For a tool with zero annotation coverage this is thin.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence with no filler, which is well-structured. It stays efficient, though the unexplained 'R/IV' abbreviation trades brevity for clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no annotations, no output schema, an undocumented single parameter, and undefined jargon, the description leaves an agent guessing about inputs, outputs, and behavior. For a matchmaking tool that presumably returns a selected capability, the omission of what comes back is significant.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There is one parameter ('goal') at 0% schema description coverage, so the schema contributes no meaning. The description supplies only that the goal is a 'verification goal', which marginally narrows the input but gives no format, constraints, or examples. Baseline-3 territory with a small nudge up from the one clarifying word, capped by the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a clear verb ('Match') and resource ('a verification goal to the smallest R/IV capability'), so the general action is discernible. However, 'R/IV capability' is undefined domain jargon, and the description does little to distinguish this tool from siblings like capabilities.list, control.check, or pricing.quote. An agent cannot confidently tell what a 'match' produces relative to those alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'without charging' faintly implies this should be used when cost avoidance matters (versus pricing.quote), but no explicit when-to-use, when-not-to-use, or alternative routing is given. Given ~35 sibling tools, the absence of any routing guidance is a real gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
source.snapshotCInspect
R/IV source.snapshot — independent evidence-verification primitive for provenance. Completed paid execution returns an RVO plus signed R/IV Verification Receipt.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | ||
| purpose | No | ||
| request_id | Yes | Caller-generated idempotency key for this paid execution attempt. | |
| capture_scope | No | text |
Output Schema
| Name | Required | Description |
|---|---|---|
| cost | Yes | |
| jobId | Yes | |
| result | Yes | R/IV Verification Object with evidence, limitations, verdict and resultHash. |
| status | Yes | |
| receipt | Yes | |
| verdict | Yes | |
| requestId | Yes | |
| timestamps | Yes | |
| operationId | Yes | |
| schemaVersion | Yes | |
| operationVersion | Yes |
TDQS
C2.6/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the full burden. It does disclose meaningful behavior — that this is a paid execution and that completion yields a signed Verification Receipt — which is real context beyond structured fields. However it says nothing about permissions, side effects, or the idempotency behavior implied by request_id.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no wasted filler and the tool name is front-loaded, which is good. But the heavy acronym load (R/IV, RVO) reduces scannability and the brevity comes at the cost of clarity rather than through efficiency.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return values need not be described. But with no annotations, 25% parameter coverage, and a cryptic two-sentence description, key information an agent needs — what the tool captures, when to choose it over source.verify, and what capture_scope controls — is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 25% (only request_id is documented), so the description must compensate for url, purpose, and capture_scope. It adds no parameter meaning at all — notably the capture_scope enum with its 'metadata/text/full_public_record' choices is left completely unexplained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a purpose ('independent evidence-verification primitive for provenance') and names the artifact produced, which is more than a tautology. But the operation is expressed in opaque jargon (R/IV, RVO) and it never clarifies what 'snapshot' actually does, nor distinguishes it from the close sibling source.verify. Purpose is present but vague.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no when-to-use guidance, no prerequisites, and no mention of alternatives such as source.verify or provenance.receipt. The agent is left to infer entirely when this tool applies versus its many verification siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
source.verifyCInspect
R/IV source.verify — independent evidence-verification primitive for verification. Completed paid execution returns an RVO plus signed R/IV Verification Receipt.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | ||
| context | No | ||
| request_id | Yes | Caller-generated idempotency key for this paid execution attempt. | |
| expected_identity | No |
Output Schema
| Name | Required | Description |
|---|---|---|
| cost | Yes | |
| jobId | Yes | |
| result | Yes | R/IV Verification Object with evidence, limitations, verdict and resultHash. |
| status | Yes | |
| receipt | Yes | |
| verdict | Yes | |
| requestId | Yes | |
| timestamps | Yes | |
| operationId | Yes | |
| schemaVersion | Yes | |
| operationVersion | Yes |
TDQS
C2.1/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It does disclose that execution is paid and returns an RVO plus a signed verification receipt, which is useful. But it omits what constitutes the verification, permission/auth requirements, cost, latency, idempotency behavior (beyond the schema's request_id note), and failure modes; "RVO" is undefined jargon.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
It is short (two sentences) and names the return artifacts up front. However the first sentence spends its length on circular self-description rather than payload information, so its brevity comes at the cost of substance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Four parameters at 25% coverage with no annotations leaves major gaps, and while an output schema exists (so return shape needn't be restated), the description still doesn't convey what verification the tool performs, what a caller must provide, or when it should be chosen over the numerous sibling verifiers.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 25% — just request_id is documented. The description adds nothing about url, context, or expected_identity, and never explains what a caller must supply to verify a source or how expected_identity constrains the result.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
"R/IV source.verify — independent evidence-verification primitive for verification" restates the tool name and then defines the activity circularly ("verification primitive for verification"). It never states what source-verification actually does or how it differs from the many sibling verifiers (citation.verify, claim.check, source.snapshot, data.flow.verify). Only the payout artifact (RVO + signed receipt) hints at a concrete function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no when-to-use, when-not-to-use, or alternative guidance at all, despite a family of near-identical sibling verification tools. The description implies it is an evidence-verification step but gives no trigger, prerequisite, or routing rule an agent could act on.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
system.statusBInspect
Read R/IV production system status.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
TDQS
B3.2/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. 'Read' implies a safe, read-only operation, but the description omits any details about authentication, rate limits, caching, freshness, or potential side effects, leaving key traits unstated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. It is appropriately sized for a zero-parameter status-check tool and gets straight to the point.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple zero-parameter status read, the description is minimally adequate but lacks context about what 'status' includes or what the return looks like. Since there is no output schema and no annotations, the agent has no additional structured guidance, making a bit more detail warranted.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so the schema provides no parameter semantics to supplement. The description appropriately avoids unnecessary parameter detail, though it could clarify the status format if no output schema existed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('Read') and resource ('R/IV production system status'), which is clear enough for an agent to know it retrieves status information. However, it does not differentiate itself from siblings like agent.monitor or policy.monitor, leaving the agent to infer the scope difference.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It lacks any explicit when-to-use, when-not-to-use, or prerequisite information, forcing the agent to guess its role among many monitoring and verification siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
timeline.reconcileCInspect
R/IV timeline.reconcile — independent evidence-verification primitive for retrieval reconstruction. Completed paid execution returns an RVO plus signed R/IV Verification Receipt.
| Name | Required | Description | Default |
|---|---|---|---|
| events | Yes | ||
| question | No | ||
| request_id | Yes | Caller-generated idempotency key for this paid execution attempt. | |
| default_timezone | No |
Output Schema
| Name | Required | Description |
|---|---|---|
| cost | Yes | |
| jobId | Yes | |
| result | Yes | R/IV Verification Object with evidence, limitations, verdict and resultHash. |
| status | Yes | |
| receipt | Yes | |
| verdict | Yes | |
| requestId | Yes | |
| timestamps | Yes | |
| operationId | Yes | |
| schemaVersion | Yes | |
| operationVersion | Yes |
TDQS
C2.7/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It usefully discloses that this is a paid execution returning a signed Verification Receipt, and 'Completed' implies non-completion states. However, it says nothing about auth, cost magnitude, failure behavior, or what 'independent' verification entails.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tight sentences, front-loaded with the tool name and the core primitive. Little waste, though the unexplained 'R/IV' prefix consumes space without adding clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 4-parameter, no-annotation execution tool, the description is thin: undefined acronyms, no parameter guidance, no precondition or cost details. The existing output schema covers return values, but the remaining behavioral and parameter gaps are not filled.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 25% (just request_id), so the description must compensate and does not. It gives no explanation of the events array shape, question, or default_timezone, and introduces undefined output terms (RVO, Receipt) in place of parameter meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names the resource (timeline) and frames the action as verification/reconciliation, but leans on undefined jargon ('R/IV', 'RVO', 'retrieval reconstruction') that never states plainly what the tool reconciles or returns. It does not differentiate itself from the many sibling verification tools (claim.check, citation.verify, contradiction.scan). Purpose is inferable but vague.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit when-to-use, when-not-to-use, or alternative routing, despite a crowded field of overlapping verification siblings. Only the phrase 'retrieval reconstruction' hints at context, leaving the agent to guess when this beats citation.verify or evidence.bundle.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
transaction.verifyCInspect
R/IV transaction.verify — independent evidence-verification primitive for verification. Completed paid execution returns an RVO plus signed R/IV Verification Receipt.
| Name | Required | Description | Default |
|---|---|---|---|
| request_id | Yes | Caller-generated idempotency key for this paid execution attempt. | |
| expected_amount | No | ||
| evidence_records | Yes | ||
| expected_currency | No | ||
| transaction_claim | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
| cost | Yes | |
| jobId | Yes | |
| result | Yes | R/IV Verification Object with evidence, limitations, verdict and resultHash. |
| status | Yes | |
| receipt | Yes | |
| verdict | Yes | |
| requestId | Yes | |
| timestamps | Yes | |
| operationId | Yes | |
| schemaVersion | Yes | |
| operationVersion | Yes |
TDQS
C2.4/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It usefully discloses that this is a paid execution that returns an RVO plus a signed R/IV Verification Receipt, which conveys cost and output form. However, it omits failure modes, auth/permission requirements, and side effects, which is thin for a mutation/payment-style primitive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, front-loaded with the tool name and the core action. Reasonably tight, though the phrase 'for verification' is redundant filler. No sprawl, but the terseness is partly under-specification rather than clean concision.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a complex, likely paid verification primitive with 5 parameters and only 20% schema coverage, and no annotations. Although an output schema exists (so return values needn't be explained), auth, cost, idempotency expectations, and parameter meanings are all missing, leaving the definition too thin for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 20% — just request_id is documented — so the description should compensate for the other four parameters, but it does not. It never explains transaction_claim, evidence_records, expected_amount, or expected_currency, leaving their semantics to be guessed. The vague word 'evidence' is the only hint toward evidence_records.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description restates the tool name (verify → 'verification primitive for verification'), which is essentially circular, though 'independent evidence-verification' adds a faint concept of evidence-based checking. It does not distinguish this tool from the many similar siblings such as agent.action.verify, data.flow.verify, workflow.verify, or claim.check. An agent cannot tell from the text why it would pick transaction.verify over the other verifiers.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no when-to-use guidance, no prerequisites, and no mention of alternatives despite ~34 verification-adjacent siblings. The reader is left to infer that this verifies transactions from the name alone. Nothing tells the agent how this differs from the other verify tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
vendor.diligenceCInspect
R/IV vendor.diligence — independent evidence-verification primitive for dependency risk. Completed paid execution returns an RVO plus signed R/IV Verification Receipt.
| Name | Required | Description | Default |
|---|---|---|---|
| scope | Yes | ||
| vendor | Yes | ||
| question | No | ||
| request_id | Yes | Caller-generated idempotency key for this paid execution attempt. | |
| public_urls | No |
Output Schema
| Name | Required | Description |
|---|---|---|
| cost | Yes | |
| jobId | Yes | |
| result | Yes | R/IV Verification Object with evidence, limitations, verdict and resultHash. |
| status | Yes | |
| receipt | Yes | |
| verdict | Yes | |
| requestId | Yes | |
| timestamps | Yes | |
| operationId | Yes | |
| schemaVersion | Yes | |
| operationVersion | Yes |
TDQS
C2.7/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It adds genuinely useful context that the tool is a 'paid execution' and that completion returns 'an RVO plus signed R/IV Verification Receipt,' which hints at cost and a verifiable output artifact. It still omits permission requirements, failure/refund behavior on unpaid attempts, and rate/limit characteristics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tight, front-loaded sentences with no padding; the core function is stated first and the return behavior second. The main weakness is that brevity comes at the cost of clarity due to unexplained acronyms rather than verbosity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 5-parameter, 3-required tool with multiple near-identical siblings and an output schema, the description is too thin. It does not explain the required vendor/scope/question inputs or differentiate behavior from vendor.monitor/dependency.map, leaving substantial ambiguity despite the output schema covering return values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 20% (only request_id is documented), so the description must compensate — but it says nothing about vendor, scope, question, or public_urls. The four undocumented parameters remain opaque, so the description does not fill the gap the schema leaves.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the tool as an 'independent evidence-verification primitive for dependency risk,' which conveys a verification function on a vendor/dependency subject. However, it leans heavily on undefined jargon ('R/IV', 'RVO', 'Verification Receipt') and never distinguishes its purpose from close siblings like vendor.monitor or dependency.map, so the agent cannot cleanly tell what unique job this tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no when-to-use guidance, no prerequisites, and no mention of alternatives such as vendor.monitor, dependency.map, or procurement.evidence. The agent is left to infer the routing decision entirely from the name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
vendor.monitorCInspect
R/IV vendor.monitor — independent evidence-verification primitive for monitoring. Completed paid execution returns an RVO plus signed R/IV Verification Receipt.
| Name | Required | Description | Default |
|---|---|---|---|
| target | Yes | ||
| cadence | No | daily | |
| request_id | Yes | Caller-generated idempotency key for this paid execution attempt. | |
| public_urls | No | ||
| materiality_rule | No |
Output Schema
| Name | Required | Description |
|---|---|---|
| cost | Yes | |
| jobId | Yes | |
| result | Yes | R/IV Verification Object with evidence, limitations, verdict and resultHash. |
| status | Yes | |
| receipt | Yes | |
| verdict | Yes | |
| requestId | Yes | |
| timestamps | Yes | |
| operationId | Yes | |
| schemaVersion | Yes | |
| operationVersion | Yes |
TDQS
C2.4/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, and it does disclose two meaningful traits: execution is paid, and a completed run returns an RVO plus a signed verification receipt. However it omits cost/pricing, whether 'cadence' triggers recurring charges, auth/permission requirements, and side effects of setting up monitoring, so the disclosure is partial.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tight sentences with the tool identity front-loaded and no filler. Its brevity is appropriate, though the compression is partly achieved through unexplained acronyms rather than clear language.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a five-parameter paid monitoring tool with no annotations, the description leaves critical gaps: parameters are unexplained, cost behavior is only implied, and undefined terms (RVO) are never clarified. An output schema exists so return values need not be described, but the input and behavioral context are far too thin.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 20% (only request_id is documented as an idempotency key), and the description compensates for none of it: target, cadence, public_urls, and materiality_rule are left with no explanation in either place. The prose adds no meaning the schema does not already carry.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description labels the tool an 'independent evidence-verification primitive for monitoring' but never states in plain language what it actually does to a vendor (e.g. monitor a vendor's public URLs for changes over time). It is saturated with undefined jargon ('R/IV', 'RVO', 'Verification Receipt') and gives no way to distinguish it from the many sibling monitors such as evidence.monitor, claim.monitor, or policy.monitor.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no when-to-use guidance, no exclusions, and no routing to alternatives despite a large sibling set that includes vendor.diligence and several other *.monitor tools. The only faint context is 'Completed paid execution', which hints at a paid workflow but does not tell the agent when this tool is the right choice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
workflow.verifyCInspect
R/IV workflow.verify — independent evidence-verification primitive for agent assurance. Completed paid execution returns an RVO plus signed R/IV Verification Receipt.
| Name | Required | Description | Default |
|---|---|---|---|
| workflow | Yes | ||
| request_id | Yes | Caller-generated idempotency key for this paid execution attempt. | |
| claimed_steps | Yes | ||
| evidence_records | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
| cost | Yes | |
| jobId | Yes | |
| result | Yes | R/IV Verification Object with evidence, limitations, verdict and resultHash. |
| status | Yes | |
| receipt | Yes | |
| verdict | Yes | |
| requestId | Yes | |
| timestamps | Yes | |
| operationId | Yes | |
| schemaVersion | Yes | |
| operationVersion | Yes |
TDQS
C2.6/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations at all, the description carries the full burden, and it does disclose two meaningful behaviors: the call is a 'paid execution' (a cost/payment gate) and a completed run yields a signed receipt artifact, implying cryptographic provenance. It does not say what happens on verification failure, whether calls are idempotent beyond the schema's request_id hint, or what the signing/authority model is.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences with no obvious padding, and the identification of the tool is front-loaded. The structure is acceptable, but the second sentence packs multiple undefined acronyms and product terms, so brevity comes at the cost of legibility rather than being efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so the receipt contents need not be described. But for a four-parameter, all-required verification primitive, the description omits the conceptual model (what a 'workflow' string contains, how claimed steps are checked against evidence, what failure looks like) and omits cost and precondition detail, leaving the agent unable to invoke it correctly with confidence.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 25% — just request_id is documented as an idempotency key — leaving workflow, claimed_steps, and evidence_records entirely undocumented in both schema and prose. The description mentions 'evidence-verification' but never explains the expected shape or semantics of evidence_records versus claimed_steps, so it fails to compensate for the coverage gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific operation ('evidence-verification') and states it returns an RVO plus a signed Verification Receipt, so the general purpose is inferable. However, it is saturated with undefined in-house jargon ('R/IV', 'RVO', 'agent assurance') and never states plainly what is being verified — the relationship between claimed_steps and evidence_records is never mentioned. It also gives no differentiation from siblings such as agent.action.verify, claim.check, or transaction.verify.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit when-to-use, when-not-to-use, or alternative-tool guidance. The phrase 'Completed paid execution' hints that the tool is billed and invoked only after execution, but that is not framed as guidance and no sibling is named as an alternative for related verification tasks.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
29 tool updates
- Changed
agent.action.verify1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "$id": "https://rdiv-production-runtime-production.up.railway.app/schemas/riv-machine-result-v2.json", + "$schema": "https://json-schema.org/draft/2020-12/schema", + "additionalProperties": true, + "description": "Schema of a completed R/IV machine execution. Cryptographic receipt integrity does not independently establish the truth of any underlying conclusion. Free trials may use a separate contract.", + "properties": { + "cost": { + "additionalProperties": true, + "properties": { + "amount": { + "minimum": 0, + "type": "number" + }, + "currency": { + "const": "USD" + } + }, + "required": [ + "currency", + "amount" + ], + "type": "object" + }, + "jobId": { + "minLength": 1, + "type": "string" + }, + "operationId": { + "minLength": 1, + "type": "string" + }, + "operationVersion": { + "minLength": 1, + "type": "string" + }, + "receipt": { + "additionalProperties": true, + "properties": { + "issuedAt": { + "format": "date-time", + "type": "string" + }, + "jobId": { + "type": "string" + }, + "operationId": { + "type": "string" + }, + "receiptId": { + "type": "string" + }, + "receiptVersion": { + "type": "string" + }, + "requestId": { + "type": "string" + }, + "resultHash": { + "pattern": "^[a-f0-9]{64}$", + "type": "string" + }, + "sha256": { + "pattern": "^[a-f0-9]{64}$", + "type": "string" + }, + "signature": { + "pattern": "^[a-f0-9]{64}$", + "type": "string" + } + }, + "required": [ + "receiptVersion", + "receiptId", + "jobId", + "requestId", + "operationId", + "resultHash", + "issuedAt", + "sha256", + "signature" + ], + "type": "object" + }, + "requestId": { + "minLength": 1, + "type": "string" + }, + "result": { + "additionalProperties": true, + "description": "R/IV Verification Object with evidence, limitations, verdict and resultHash.", + "properties": { + "limitations": { + "items": { + "type": "string" + }, + "type": "array" + }, + "operationId": { + "type": "string" + }, + "resultHash": { + "pattern": "^[a-f0-9]{64}$", + "type": "string" + }, + "verdict": { + "type": "string" + }, + "verificationId": { + "type": "string" + } + }, + "required": [ + "operationId", + "verificationId", + "verdict", + "limitations", + "resultHash" + ], + "type": "object" + }, + "schemaVersion": { + "minLength": 1, + "type": "string" + }, + "status": { + "const": "COMPLETED" + }, + "timestamps": { + "additionalProperties": true, + "properties": { + "completedAt": { + "format": "date-time", + "type": "string" + } + }, + "required": [ + "completedAt" + ], + "type": "object" + }, + "verdict": { + "minLength": 1, + "type": "string" + } + }, + "required": [ + "schemaVersion", + "requestId", + "jobId", + "operationId", + "operationVersion", + "status", + "verdict", + "result", + "receipt", + "cost", + "timestamps" + ], + "title": "R/IV Machine Verification Result v2 - authenticated paid execution", + "type": "object", + "x-riv-receipt-policy": { + "integrity": "server-side HMAC verification required for v1 receipts", + "meaning": "signed provenance and execution integrity; not evidence that an underlying claim is true" + }, + "x-riv-status": "public-contract-v2-live-machine-completed-only" +}
- Changed
agent.monitor1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "$id": "https://rdiv-production-runtime-production.up.railway.app/schemas/riv-machine-result-v2.json", + "$schema": "https://json-schema.org/draft/2020-12/schema", + "additionalProperties": true, + "description": "Schema of a completed R/IV machine execution. Cryptographic receipt integrity does not independently establish the truth of any underlying conclusion. Free trials may use a separate contract.", + "properties": { + "cost": { + "additionalProperties": true, + "properties": { + "amount": { + "minimum": 0, + "type": "number" + }, + "currency": { + "const": "USD" + } + }, + "required": [ + "currency", + "amount" + ], + "type": "object" + }, + "jobId": { + "minLength": 1, + "type": "string" + }, + "operationId": { + "minLength": 1, + "type": "string" + }, + "operationVersion": { + "minLength": 1, + "type": "string" + }, + "receipt": { + "additionalProperties": true, + "properties": { + "issuedAt": { + "format": "date-time", + "type": "string" + }, + "jobId": { + "type": "string" + }, + "operationId": { + "type": "string" + }, + "receiptId": { + "type": "string" + }, + "receiptVersion": { + "type": "string" + }, + "requestId": { + "type": "string" + }, + "resultHash": { + "pattern": "^[a-f0-9]{64}$", + "type": "string" + }, + "sha256": { + "pattern": "^[a-f0-9]{64}$", + "type": "string" + }, + "signature": { + "pattern": "^[a-f0-9]{64}$", + "type": "string" + } + }, + "required": [ + "receiptVersion", + "receiptId", + "jobId", + "requestId", + "operationId", + "resultHash", + "issuedAt", + "sha256", + "signature" + ], + "type": "object" + }, + "requestId": { + "minLength": 1, + "type": "string" + }, + "result": { + "additionalProperties": true, + "description": "R/IV Verification Object with evidence, limitations, verdict and resultHash.", + "properties": { + "limitations": { + "items": { + "type": "string" + }, + "type": "array" + }, + "operationId": { + "type": "string" + }, + "resultHash": { + "pattern": "^[a-f0-9]{64}$", + "type": "string" + }, + "verdict": { + "type": "string" + }, + "verificationId": { + "type": "string" + } + }, + "required": [ + "operationId", + "verificationId", + "verdict", + "limitations", + "resultHash" + ], + "type": "object" + }, + "schemaVersion": { + "minLength": 1, + "type": "string" + }, + "status": { + "const": "COMPLETED" + }, + "timestamps": { + "additionalProperties": true, + "properties": { + "completedAt": { + "format": "date-time", + "type": "string" + } + }, + "required": [ + "completedAt" + ], + "type": "object" + }, + "verdict": { + "minLength": 1, + "type": "string" + } + }, + "required": [ + "schemaVersion", + "requestId", + "jobId", + "operationId", + "operationVersion", + "status", + "verdict", + "result", + "receipt", + "cost", + "timestamps" + ], + "title": "R/IV Machine Verification Result v2 - authenticated paid execution", + "type": "object", + "x-riv-receipt-policy": { + "integrity": "server-side HMAC verification required for v1 receipts", + "meaning": "signed provenance and execution integrity; not evidence that an underlying claim is true" + }, + "x-riv-status": "public-contract-v2-live-machine-completed-only" +}
- Changed
ai.use.audit1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "$id": "https://rdiv-production-runtime-production.up.railway.app/schemas/riv-machine-result-v2.json", + "$schema": "https://json-schema.org/draft/2020-12/schema", + "additionalProperties": true, + "description": "Schema of a completed R/IV machine execution. Cryptographic receipt integrity does not independently establish the truth of any underlying conclusion. Free trials may use a separate contract.", + "properties": { + "cost": { + "additionalProperties": true, + "properties": { + "amount": { + "minimum": 0, + "type": "number" + }, + "currency": { + "const": "USD" + } + }, + "required": [ + "currency", + "amount" + ], + "type": "object" + }, + "jobId": { + "minLength": 1, + "type": "string" + }, + "operationId": { + "minLength": 1, + "type": "string" + }, + "operationVersion": { + "minLength": 1, + "type": "string" + }, + "receipt": { + "additionalProperties": true, + "properties": { + "issuedAt": { + "format": "date-time", + "type": "string" + }, + "jobId": { + "type": "string" + }, + "operationId": { + "type": "string" + }, + "receiptId": { + "type": "string" + }, + "receiptVersion": { + "type": "string" + }, + "requestId": { + "type": "string" + }, + "resultHash": { + "pattern": "^[a-f0-9]{64}$", + "type": "string" + }, + "sha256": { + "pattern": "^[a-f0-9]{64}$", + "type": "string" + }, + "signature": { + "pattern": "^[a-f0-9]{64}$", + "type": "string" + } + }, + "required": [ + "receiptVersion", + "receiptId", + "jobId", + "requestId", + "operationId", + "resultHash", + "issuedAt", + "sha256", + "signature" + ], + "type": "object" + }, + "requestId": { + "minLength": 1, + "type": "string" + }, + "result": { + "additionalProperties": true, + "description": "R/IV Verification Object with evidence, limitations, verdict and resultHash.", + "properties": { + "limitations": { + "items": { + "type": "string" + }, + "type": "array" + }, + "operationId": { + "type": "string" + }, + "resultHash": { + "pattern": "^[a-f0-9]{64}$", + "type": "string" + }, + "verdict": { + "type": "string" + }, + "verificationId": { + "type": "string" + } + }, + "required": [ + "operationId", + "verificationId", + "verdict", + "limitations", + "resultHash" + ], + "type": "object" + }, + "schemaVersion": { + "minLength": 1, + "type": "string" + }, + "status": { + "const": "COMPLETED" + }, + "timestamps": { + "additionalProperties": true, + "properties": { + "completedAt": { + "format": "date-time", + "type": "string" + } + }, + "required": [ + "completedAt" + ], + "type": "object" + }, + "verdict": { + "minLength": 1, + "type": "string" + } + }, + "required": [ + "schemaVersion", + "requestId", + "jobId", + "operationId", + "operationVersion", + "status", + "verdict", + "result", + "receipt", + "cost", + "timestamps" + ], + "title": "R/IV Machine Verification Result v2 - authenticated paid execution", + "type": "object", + "x-riv-receipt-policy": { + "integrity": "server-side HMAC verification required for v1 receipts", + "meaning": "signed provenance and execution integrity; not evidence that an underlying claim is true" + }, + "x-riv-status": "public-contract-v2-live-machine-completed-only" +}
- Changed
answer.audit1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "$id": "https://rdiv-production-runtime-production.up.railway.app/schemas/riv-machine-result-v2.json", + "$schema": "https://json-schema.org/draft/2020-12/schema", + "additionalProperties": true, + "description": "Schema of a completed R/IV machine execution. Cryptographic receipt integrity does not independently establish the truth of any underlying conclusion. Free trials may use a separate contract.", + "properties": { + "cost": { + "additionalProperties": true, + "properties": { + "amount": { + "minimum": 0, + "type": "number" + }, + "currency": { + "const": "USD" + } + }, + "required": [ + "currency", + "amount" + ], + "type": "object" + }, + "jobId": { + "minLength": 1, + "type": "string" + }, + "operationId": { + "minLength": 1, + "type": "string" + }, + "operationVersion": { + "minLength": 1, + "type": "string" + }, + "receipt": { + "additionalProperties": true, + "properties": { + "issuedAt": { + "format": "date-time", + "type": "string" + }, + "jobId": { + "type": "string" + }, + "operationId": { + "type": "string" + }, + "receiptId": { + "type": "string" + }, + "receiptVersion": { + "type": "string" + }, + "requestId": { + "type": "string" + }, + "resultHash": { + "pattern": "^[a-f0-9]{64}$", + "type": "string" + }, + "sha256": { + "pattern": "^[a-f0-9]{64}$", + "type": "string" + }, + "signature": { + "pattern": "^[a-f0-9]{64}$", + "type": "string" + } + }, + "required": [ + "receiptVersion", + "receiptId", + "jobId", + "requestId", + "operationId", + "resultHash", + "issuedAt", + "sha256", + "signature" + ], + "type": "object" + }, + "requestId": { + "minLength": 1, + "type": "string" + }, + "result": { + "additionalProperties": true, + "description": "R/IV Verification Object with evidence, limitations, verdict and resultHash.", + "properties": { + "limitations": { + "items": { + "type": "string" + }, + "type": "array" + }, + "operationId": { + "type": "string" + }, + "resultHash": { + "pattern": "^[a-f0-9]{64}$", + "type": "string" + }, + "verdict": { + "type": "string" + }, + "verificationId": { + "type": "string" + } + }, + "required": [ + "operationId", + "verificationId", + "verdict", + "limitations", + "resultHash" + ], + "type": "object" + }, + "schemaVersion": { + "minLength": 1, + "type": "string" + }, + "status": { + "const": "COMPLETED" + }, + "timestamps": { + "additionalProperties": true, + "properties": { + "completedAt": { + "format": "date-time", + "type": "string" + } + }, + "required": [ + "completedAt" + ], + "type": "object" + }, + "verdict": { + "minLength": 1, + "type": "string" + } + }, + "required": [ + "schemaVersion", + "requestId", + "jobId", + "operationId", + "operationVersion", + "status", + "verdict", + "result", + "receipt", + "cost", + "timestamps" + ], + "title": "R/IV Machine Verification Result v2 - authenticated paid execution", + "type": "object", + "x-riv-receipt-policy": { + "integrity": "server-side HMAC verification required for v1 receipts", + "meaning": "signed provenance and execution integrity; not evidence that an underlying claim is true" + }, + "x-riv-status": "public-contract-v2-live-machine-completed-only" +}
- Changed
citation.verify1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "$id": "https://rdiv-production-runtime-production.up.railway.app/schemas/riv-machine-result-v2.json", + "$schema": "https://json-schema.org/draft/2020-12/schema", + "additionalProperties": true, + "description": "Schema of a completed R/IV machine execution. Cryptographic receipt integrity does not independently establish the truth of any underlying conclusion. Free trials may use a separate contract.", + "properties": { + "cost": { + "additionalProperties": true, + "properties": { + "amount": { + "minimum": 0, + "type": "number" + }, + "currency": { + "const": "USD" + } + }, + "required": [ + "currency", + "amount" + ], + "type": "object" + }, + "jobId": { + "minLength": 1, + "type": "string" + }, + "operationId": { + "minLength": 1, + "type": "string" + }, + "operationVersion": { + "minLength": 1, + "type": "string" + }, + "receipt": { + "additionalProperties": true, + "properties": { + "issuedAt": { + "format": "date-time", + "type": "string" + }, + "jobId": { + "type": "string" + }, + "operationId": { + "type": "string" + }, + "receiptId": { + "type": "string" + }, + "receiptVersion": { + "type": "string" + }, + "requestId": { + "type": "string" + }, + "resultHash": { + "pattern": "^[a-f0-9]{64}$", + "type": "string" + }, + "sha256": { + "pattern": "^[a-f0-9]{64}$", + "type": "string" + }, + "signature": { + "pattern": "^[a-f0-9]{64}$", + "type": "string" + } + }, + "required": [ + "receiptVersion", + "receiptId", + "jobId", + "requestId", + "operationId", + "resultHash", + "issuedAt", + "sha256", + "signature" + ], + "type": "object" + }, + "requestId": { + "minLength": 1, + "type": "string" + }, + "result": { + "additionalProperties": true, + "description": "R/IV Verification Object with evidence, limitations, verdict and resultHash.", + "properties": { + "limitations": { + "items": { + "type": "string" + }, + "type": "array" + }, + "operationId": { + "type": "string" + }, + "resultHash": { + "pattern": "^[a-f0-9]{64}$", + "type": "string" + }, + "verdict": { + "type": "string" + }, + "verificationId": { + "type": "string" + } + }, + "required": [ + "operationId", + "verificationId", + "verdict", + "limitations", + "resultHash" + ], + "type": "object" + }, + "schemaVersion": { + "minLength": 1, + "type": "string" + }, + "status": { + "const": "COMPLETED" + }, + "timestamps": { + "additionalProperties": true, + "properties": { + "completedAt": { + "format": "date-time", + "type": "string" + } + }, + "required": [ + "completedAt" + ], + "type": "object" + }, + "verdict": { + "minLength": 1, + "type": "string" + } + }, + "required": [ + "schemaVersion", + "requestId", + "jobId", + "operationId", + "operationVersion", + "status", + "verdict", + "result", + "receipt", + "cost", + "timestamps" + ], + "title": "R/IV Machine Verification Result v2 - authenticated paid execution", + "type": "object", + "x-riv-receipt-policy": { + "integrity": "server-side HMAC verification required for v1 receipts", + "meaning": "signed provenance and execution integrity; not evidence that an underlying claim is true" + }, + "x-riv-status": "public-contract-v2-live-machine-completed-only" +}
- Changed
claim.check1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "$id": "https://rdiv-production-runtime-production.up.railway.app/schemas/riv-machine-result-v2.json", + "$schema": "https://json-schema.org/draft/2020-12/schema", + "additionalProperties": true, + "description": "Schema of a completed R/IV machine execution. Cryptographic receipt integrity does not independently establish the truth of any underlying conclusion. Free trials may use a separate contract.", + "properties": { + "cost": { + "additionalProperties": true, + "properties": { + "amount": { + "minimum": 0, + "type": "number" + }, + "currency": { + "const": "USD" + } + }, + "required": [ + "currency", + "amount" + ], + "type": "object" + }, + "jobId": { + "minLength": 1, + "type": "string" + }, + "operationId": { + "minLength": 1, + "type": "string" + }, + "operationVersion": { + "minLength": 1, + "type": "string" + }, + "receipt": { + "additionalProperties": true, + "properties": { + "issuedAt": { + "format": "date-time", + "type": "string" + }, + "jobId": { + "type": "string" + }, + "operationId": { + "type": "string" + }, + "receiptId": { + "type": "string" + }, + "receiptVersion": { + "type": "string" + }, + "requestId": { + "type": "string" + }, + "resultHash": { + "pattern": "^[a-f0-9]{64}$", + "type": "string" + }, + "sha256": { + "pattern": "^[a-f0-9]{64}$", + "type": "string" + }, + "signature": { + "pattern": "^[a-f0-9]{64}$", + "type": "string" + } + }, + "required": [ + "receiptVersion", + "receiptId", + "jobId", + "requestId", + "operationId", + "resultHash", + "issuedAt", + "sha256", + "signature" + ], + "type": "object" + }, + "requestId": { + "minLength": 1, + "type": "string" + }, + "result": { + "additionalProperties": true, + "description": "R/IV Verification Object with evidence, limitations, verdict and resultHash.", + "properties": { + "limitations": { + "items": { + "type": "string" + }, + "type": "array" + }, + "operationId": { + "type": "string" + }, + "resultHash": { + "pattern": "^[a-f0-9]{64}$", + "type": "string" + }, + "verdict": { + "type": "string" + }, + "verificationId": { + "type": "string" + } + }, + "required": [ + "operationId", + "verificationId", + "verdict", + "limitations", + "resultHash" + ], + "type": "object" + }, + "schemaVersion": { + "minLength": 1, + "type": "string" + }, + "status": { + "const": "COMPLETED" + }, + "timestamps": { + "additionalProperties": true, + "properties": { + "completedAt": { + "format": "date-time", + "type": "string" + } + }, + "required": [ + "completedAt" + ], + "type": "object" + }, + "verdict": { + "minLength": 1, + "type": "string" + } + }, + "required": [ + "schemaVersion", + "requestId", + "jobId", + "operationId", + "operationVersion", + "status", + "verdict", + "result", + "receipt", + "cost", + "timestamps" + ], + "title": "R/IV Machine Verification Result v2 - authenticated paid execution", + "type": "object", + "x-riv-receipt-policy": { + "integrity": "server-side HMAC verification required for v1 receipts", + "meaning": "signed provenance and execution integrity; not evidence that an underlying claim is true" + }, + "x-riv-status": "public-contract-v2-live-machine-completed-only" +}
- Changed
claim.monitor1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "$id": "https://rdiv-production-runtime-production.up.railway.app/schemas/riv-machine-result-v2.json", + "$schema": "https://json-schema.org/draft/2020-12/schema", + "additionalProperties": true, + "description": "Schema of a completed R/IV machine execution. Cryptographic receipt integrity does not independently establish the truth of any underlying conclusion. Free trials may use a separate contract.", + "properties": { + "cost": { + "additionalProperties": true, + "properties": { + "amount": { + "minimum": 0, + "type": "number" + }, + "currency": { + "const": "USD" + } + }, + "required": [ + "currency", + "amount" + ], + "type": "object" + }, + "jobId": { + "minLength": 1, + "type": "string" + }, + "operationId": { + "minLength": 1, + "type": "string" + }, + "operationVersion": { + "minLength": 1, + "type": "string" + }, + "receipt": { + "additionalProperties": true, + "properties": { + "issuedAt": { + "format": "date-time", + "type": "string" + }, + "jobId": { + "type": "string" + }, + "operationId": { + "type": "string" + }, + "receiptId": { + "type": "string" + }, + "receiptVersion": { + "type": "string" + }, + "requestId": { + "type": "string" + }, + "resultHash": { + "pattern": "^[a-f0-9]{64}$", + "type": "string" + }, + "sha256": { + "pattern": "^[a-f0-9]{64}$", + "type": "string" + }, + "signature": { + "pattern": "^[a-f0-9]{64}$", + "type": "string" + } + }, + "required": [ + "receiptVersion", + "receiptId", + "jobId", + "requestId", + "operationId", + "resultHash", + "issuedAt", + "sha256", + "signature" + ], + "type": "object" + }, + "requestId": { + "minLength": 1, + "type": "string" + }, + "result": { + "additionalProperties": true, + "description": "R/IV Verification Object with evidence, limitations, verdict and resultHash.", + "properties": { + "limitations": { + "items": { + "type": "string" + }, + "type": "array" + }, + "operationId": { + "type": "string" + }, + "resultHash": { + "pattern": "^[a-f0-9]{64}$", + "type": "string" + }, + "verdict": { + "type": "string" + }, + "verificationId": { + "type": "string" + } + }, + "required": [ + "operationId", + "verificationId", + "verdict", + "limitations", + "resultHash" + ], + "type": "object" + }, + "schemaVersion": { + "minLength": 1, + "type": "string" + }, + "status": { + "const": "COMPLETED" + }, + "timestamps": { + "additionalProperties": true, + "properties": { + "completedAt": { + "format": "date-time", + "type": "string" + } + }, + "required": [ + "completedAt" + ], + "type": "object" + }, + "verdict": { + "minLength": 1, + "type": "string" + } + }, + "required": [ + "schemaVersion", + "requestId", + "jobId", + "operationId", + "operationVersion", + "status", + "verdict", + "result", + "receipt", + "cost", + "timestamps" + ], + "title": "R/IV Machine Verification Result v2 - authenticated paid execution", + "type": "object", + "x-riv-receipt-policy": { + "integrity": "server-side HMAC verification required for v1 receipts", + "meaning": "signed provenance and execution integrity; not evidence that an underlying claim is true" + }, + "x-riv-status": "public-contract-v2-live-machine-completed-only" +}
- Changed
contradiction.scan1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "$id": "https://rdiv-production-runtime-production.up.railway.app/schemas/riv-machine-result-v2.json", + "$schema": "https://json-schema.org/draft/2020-12/schema", + "additionalProperties": true, + "description": "Schema of a completed R/IV machine execution. Cryptographic receipt integrity does not independently establish the truth of any underlying conclusion. Free trials may use a separate contract.", + "properties": { + "cost": { + "additionalProperties": true, + "properties": { + "amount": { + "minimum": 0, + "type": "number" + }, + "currency": { + "const": "USD" + } + }, + "required": [ + "currency", + "amount" + ], + "type": "object" + }, + "jobId": { + "minLength": 1, + "type": "string" + }, + "operationId": { + "minLength": 1, + "type": "string" + }, + "operationVersion": { + "minLength": 1, + "type": "string" + }, + "receipt": { + "additionalProperties": true, + "properties": { + "issuedAt": { + "format": "date-time", + "type": "string" + }, + "jobId": { + "type": "string" + }, + "operationId": { + "type": "string" + }, + "receiptId": { + "type": "string" + }, + "receiptVersion": { + "type": "string" + }, + "requestId": { + "type": "string" + }, + "resultHash": { + "pattern": "^[a-f0-9]{64}$", + "type": "string" + }, + "sha256": { + "pattern": "^[a-f0-9]{64}$", + "type": "string" + }, + "signature": { + "pattern": "^[a-f0-9]{64}$", + "type": "string" + } + }, + "required": [ + "receiptVersion", + "receiptId", + "jobId", + "requestId", + "operationId", + "resultHash", + "issuedAt", + "sha256", + "signature" + ], + "type": "object" + }, + "requestId": { + "minLength": 1, + "type": "string" + }, + "result": { + "additionalProperties": true, + "description": "R/IV Verification Object with evidence, limitations, verdict and resultHash.", + "properties": { + "limitations": { + "items": { + "type": "string" + }, + "type": "array" + }, + "operationId": { + "type": "string" + }, + "resultHash": { + "pattern": "^[a-f0-9]{64}$", + "type": "string" + }, + "verdict": { + "type": "string" + }, + "verificationId": { + "type": "string" + } + }, + "required": [ + "operationId", + "verificationId", + "verdict", + "limitations", + "resultHash" + ], + "type": "object" + }, + "schemaVersion": { + "minLength": 1, + "type": "string" + }, + "status": { + "const": "COMPLETED" + }, + "timestamps": { + "additionalProperties": true, + "properties": { + "completedAt": { + "format": "date-time", + "type": "string" + } + }, + "required": [ + "completedAt" + ], + "type": "object" + }, + "verdict": { + "minLength": 1, + "type": "string" + } + }, + "required": [ + "schemaVersion", + "requestId", + "jobId", + "operationId", + "operationVersion", + "status", + "verdict", + "result", + "receipt", + "cost", + "timestamps" + ], + "title": "R/IV Machine Verification Result v2 - authenticated paid execution", + "type": "object", + "x-riv-receipt-policy": { + "integrity": "server-side HMAC verification required for v1 receipts", + "meaning": "signed provenance and execution integrity; not evidence that an underlying claim is true" + }, + "x-riv-status": "public-contract-v2-live-machine-completed-only" +}
- Changed
control.check1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "$id": "https://rdiv-production-runtime-production.up.railway.app/schemas/riv-machine-result-v2.json", + "$schema": "https://json-schema.org/draft/2020-12/schema", + "additionalProperties": true, + "description": "Schema of a completed R/IV machine execution. Cryptographic receipt integrity does not independently establish the truth of any underlying conclusion. Free trials may use a separate contract.", + "properties": { + "cost": { + "additionalProperties": true, + "properties": { + "amount": { + "minimum": 0, + "type": "number" + }, + "currency": { + "const": "USD" + } + }, + "required": [ + "currency", + "amount" + ], + "type": "object" + }, + "jobId": { + "minLength": 1, + "type": "string" + }, + "operationId": { + "minLength": 1, + "type": "string" + }, + "operationVersion": { + "minLength": 1, + "type": "string" + }, + "receipt": { + "additionalProperties": true, + "properties": { + "issuedAt": { + "format": "date-time", + "type": "string" + }, + "jobId": { + "type": "string" + }, + "operationId": { + "type": "string" + }, + "receiptId": { + "type": "string" + }, + "receiptVersion": { + "type": "string" + }, + "requestId": { + "type": "string" + }, + "resultHash": { + "pattern": "^[a-f0-9]{64}$", + "type": "string" + }, + "sha256": { + "pattern": "^[a-f0-9]{64}$", + "type": "string" + }, + "signature": { + "pattern": "^[a-f0-9]{64}$", + "type": "string" + } + }, + "required": [ + "receiptVersion", + "receiptId", + "jobId", + "requestId", + "operationId", + "resultHash", + "issuedAt", + "sha256", + "signature" + ], + "type": "object" + }, + "requestId": { + "minLength": 1, + "type": "string" + }, + "result": { + "additionalProperties": true, + "description": "R/IV Verification Object with evidence, limitations, verdict and resultHash.", + "properties": { + "limitations": { + "items": { + "type": "string" + }, + "type": "array" + }, + "operationId": { + "type": "string" + }, + "resultHash": { + "pattern": "^[a-f0-9]{64}$", + "type": "string" + }, + "verdict": { + "type": "string" + }, + "verificationId": { + "type": "string" + } + }, + "required": [ + "operationId", + "verificationId", + "verdict", + "limitations", + "resultHash" + ], + "type": "object" + }, + "schemaVersion": { + "minLength": 1, + "type": "string" + }, + "status": { + "const": "COMPLETED" + }, + "timestamps": { + "additionalProperties": true, + "properties": { + "completedAt": { + "format": "date-time", + "type": "string" + } + }, + "required": [ + "completedAt" + ], + "type": "object" + }, + "verdict": { + "minLength": 1, + "type": "string" + } + }, + "required": [ + "schemaVersion", + "requestId", + "jobId", + "operationId", + "operationVersion", + "status", + "verdict", + "result", + "receipt", + "cost", + "timestamps" + ], + "title": "R/IV Machine Verification Result v2 - authenticated paid execution", + "type": "object", + "x-riv-receipt-policy": { + "integrity": "server-side HMAC verification required for v1 receipts", + "meaning": "signed provenance and execution integrity; not evidence that an underlying claim is true" + }, + "x-riv-status": "public-contract-v2-live-machine-completed-only" +}
- Changed
data.flow.verify1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "$id": "https://rdiv-production-runtime-production.up.railway.app/schemas/riv-machine-result-v2.json", + "$schema": "https://json-schema.org/draft/2020-12/schema", + "additionalProperties": true, + "description": "Schema of a completed R/IV machine execution. Cryptographic receipt integrity does not independently establish the truth of any underlying conclusion. Free trials may use a separate contract.", + "properties": { + "cost": { + "additionalProperties": true, + "properties": { + "amount": { + "minimum": 0, + "type": "number" + }, + "currency": { + "const": "USD" + } + }, + "required": [ + "currency", + "amount" + ], + "type": "object" + }, + "jobId": { + "minLength": 1, + "type": "string" + }, + "operationId": { + "minLength": 1, + "type": "string" + }, + "operationVersion": { + "minLength": 1, + "type": "string" + }, + "receipt": { + "additionalProperties": true, + "properties": { + "issuedAt": { + "format": "date-time", + "type": "string" + }, + "jobId": { + "type": "string" + }, + "operationId": { + "type": "string" + }, + "receiptId": { + "type": "string" + }, + "receiptVersion": { + "type": "string" + }, + "requestId": { + "type": "string" + }, + "resultHash": { + "pattern": "^[a-f0-9]{64}$", + "type": "string" + }, + "sha256": { + "pattern": "^[a-f0-9]{64}$", + "type": "string" + }, + "signature": { + "pattern": "^[a-f0-9]{64}$", + "type": "string" + } + }, + "required": [ + "receiptVersion", + "receiptId", + "jobId", + "requestId", + "operationId", + "resultHash", + "issuedAt", + "sha256", + "signature" + ], + "type": "object" + }, + "requestId": { + "minLength": 1, + "type": "string" + }, + "result": { + "additionalProperties": true, + "description": "R/IV Verification Object with evidence, limitations, verdict and resultHash.", + "properties": { + "limitations": { + "items": { + "type": "string" + }, + "type": "array" + }, + "operationId": { + "type": "string" + }, + "resultHash": { + "pattern": "^[a-f0-9]{64}$", + "type": "string" + }, + "verdict": { + "type": "string" + }, + "verificationId": { + "type": "string" + } + }, + "required": [ + "operationId", + "verificationId", + "verdict", + "limitations", + "resultHash" + ], + "type": "object" + }, + "schemaVersion": { + "minLength": 1, + "type": "string" + }, + "status": { + "const": "COMPLETED" + }, + "timestamps": { + "additionalProperties": true, + "properties": { + "completedAt": { + "format": "date-time", + "type": "string" + } + }, + "required": [ + "completedAt" + ], + "type": "object" + }, + "verdict": { + "minLength": 1, + "type": "string" + } + }, + "required": [ + "schemaVersion", + "requestId", + "jobId", + "operationId", + "operationVersion", + "status", + "verdict", + "result", + "receipt", + "cost", + "timestamps" + ], + "title": "R/IV Machine Verification Result v2 - authenticated paid execution", + "type": "object", + "x-riv-receipt-policy": { + "integrity": "server-side HMAC verification required for v1 receipts", + "meaning": "signed provenance and execution integrity; not evidence that an underlying claim is true" + }, + "x-riv-status": "public-contract-v2-live-machine-completed-only" +}
- Changed
dependency.map1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "$id": "https://rdiv-production-runtime-production.up.railway.app/schemas/riv-machine-result-v2.json", + "$schema": "https://json-schema.org/draft/2020-12/schema", + "additionalProperties": true, + "description": "Schema of a completed R/IV machine execution. Cryptographic receipt integrity does not independently establish the truth of any underlying conclusion. Free trials may use a separate contract.", + "properties": { + "cost": { + "additionalProperties": true, + "properties": { + "amount": { + "minimum": 0, + "type": "number" + }, + "currency": { + "const": "USD" + } + }, + "required": [ + "currency", + "amount" + ], + "type": "object" + }, + "jobId": { + "minLength": 1, + "type": "string" + }, + "operationId": { + "minLength": 1, + "type": "string" + }, + "operationVersion": { + "minLength": 1, + "type": "string" + }, + "receipt": { + "additionalProperties": true, + "properties": { + "issuedAt": { + "format": "date-time", + "type": "string" + }, + "jobId": { + "type": "string" + }, + "operationId": { + "type": "string" + }, + "receiptId": { + "type": "string" + }, + "receiptVersion": { + "type": "string" + }, + "requestId": { + "type": "string" + }, + "resultHash": { + "pattern": "^[a-f0-9]{64}$", + "type": "string" + }, + "sha256": { + "pattern": "^[a-f0-9]{64}$", + "type": "string" + }, + "signature": { + "pattern": "^[a-f0-9]{64}$", + "type": "string" + } + }, + "required": [ + "receiptVersion", + "receiptId", + "jobId", + "requestId", + "operationId", + "resultHash", + "issuedAt", + "sha256", + "signature" + ], + "type": "object" + }, + "requestId": { + "minLength": 1, + "type": "string" + }, + "result": { + "additionalProperties": true, + "description": "R/IV Verification Object with evidence, limitations, verdict and resultHash.", + "properties": { + "limitations": { + "items": { + "type": "string" + }, + "type": "array" + }, + "operationId": { + "type": "string" + }, + "resultHash": { + "pattern": "^[a-f0-9]{64}$", + "type": "string" + }, + "verdict": { + "type": "string" + }, + "verificationId": { + "type": "string" + } + }, + "required": [ + "operationId", + "verificationId", + "verdict", + "limitations", + "resultHash" + ], + "type": "object" + }, + "schemaVersion": { + "minLength": 1, + "type": "string" + }, + "status": { + "const": "COMPLETED" + }, + "timestamps": { + "additionalProperties": true, + "properties": { + "completedAt": { + "format": "date-time", + "type": "string" + } + }, + "required": [ + "completedAt" + ], + "type": "object" + }, + "verdict": { + "minLength": 1, + "type": "string" + } + }, + "required": [ + "schemaVersion", + "requestId", + "jobId", + "operationId", + "operationVersion", + "status", + "verdict", + "result", + "receipt", + "cost", + "timestamps" + ], + "title": "R/IV Machine Verification Result v2 - authenticated paid execution", + "type": "object", + "x-riv-receipt-policy": { + "integrity": "server-side HMAC verification required for v1 receipts", + "meaning": "signed provenance and execution integrity; not evidence that an underlying claim is true" + }, + "x-riv-status": "public-contract-v2-live-machine-completed-only" +}
- Changed
dependency.monitor1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "$id": "https://rdiv-production-runtime-production.up.railway.app/schemas/riv-machine-result-v2.json", + "$schema": "https://json-schema.org/draft/2020-12/schema", + "additionalProperties": true, + "description": "Schema of a completed R/IV machine execution. Cryptographic receipt integrity does not independently establish the truth of any underlying conclusion. Free trials may use a separate contract.", + "properties": { + "cost": { + "additionalProperties": true, + "properties": { + "amount": { + "minimum": 0, + "type": "number" + }, + "currency": { + "const": "USD" + } + }, + "required": [ + "currency", + "amount" + ], + "type": "object" + }, + "jobId": { + "minLength": 1, + "type": "string" + }, + "operationId": { + "minLength": 1, + "type": "string" + }, + "operationVersion": { + "minLength": 1, + "type": "string" + }, + "receipt": { + "additionalProperties": true, + "properties": { + "issuedAt": { + "format": "date-time", + "type": "string" + }, + "jobId": { + "type": "string" + }, + "operationId": { + "type": "string" + }, + "receiptId": { + "type": "string" + }, + "receiptVersion": { + "type": "string" + }, + "requestId": { + "type": "string" + }, + "resultHash": { + "pattern": "^[a-f0-9]{64}$", + "type": "string" + }, + "sha256": { + "pattern": "^[a-f0-9]{64}$", + "type": "string" + }, + "signature": { + "pattern": "^[a-f0-9]{64}$", + "type": "string" + } + }, + "required": [ + "receiptVersion", + "receiptId", + "jobId", + "requestId", + "operationId", + "resultHash", + "issuedAt", + "sha256", + "signature" + ], + "type": "object" + }, + "requestId": { + "minLength": 1, + "type": "string" + }, + "result": { + "additionalProperties": true, + "description": "R/IV Verification Object with evidence, limitations, verdict and resultHash.", + "properties": { + "limitations": { + "items": { + "type": "string" + }, + "type": "array" + }, + "operationId": { + "type": "string" + }, + "resultHash": { + "pattern": "^[a-f0-9]{64}$", + "type": "string" + }, + "verdict": { + "type": "string" + }, + "verificationId": { + "type": "string" + } + }, + "required": [ + "operationId", + "verificationId", + "verdict", + "limitations", + "resultHash" + ], + "type": "object" + }, + "schemaVersion": { + "minLength": 1, + "type": "string" + }, + "status": { + "const": "COMPLETED" + }, + "timestamps": { + "additionalProperties": true, + "properties": { + "completedAt": { + "format": "date-time", + "type": "string" + } + }, + "required": [ + "completedAt" + ], + "type": "object" + }, + "verdict": { + "minLength": 1, + "type": "string" + } + }, + "required": [ + "schemaVersion", + "requestId", + "jobId", + "operationId", + "operationVersion", + "status", + "verdict", + "result", + "receipt", + "cost", + "timestamps" + ], + "title": "R/IV Machine Verification Result v2 - authenticated paid execution", + "type": "object", + "x-riv-receipt-policy": { + "integrity": "server-side HMAC verification required for v1 receipts", + "meaning": "signed provenance and execution integrity; not evidence that an underlying claim is true" + }, + "x-riv-status": "public-contract-v2-live-machine-completed-only" +}
- Changed
evidence.bundle1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "$id": "https://rdiv-production-runtime-production.up.railway.app/schemas/riv-machine-result-v2.json", + "$schema": "https://json-schema.org/draft/2020-12/schema", + "additionalProperties": true, + "description": "Schema of a completed R/IV machine execution. Cryptographic receipt integrity does not independently establish the truth of any underlying conclusion. Free trials may use a separate contract.", + "properties": { + "cost": { + "additionalProperties": true, + "properties": { + "amount": { + "minimum": 0, + "type": "number" + }, + "currency": { + "const": "USD" + } + }, + "required": [ + "currency", + "amount" + ], + "type": "object" + }, + "jobId": { + "minLength": 1, + "type": "string" + }, + "operationId": { + "minLength": 1, + "type": "string" + }, + "operationVersion": { + "minLength": 1, + "type": "string" + }, + "receipt": { + "additionalProperties": true, + "properties": { + "issuedAt": { + "format": "date-time", + "type": "string" + }, + "jobId": { + "type": "string" + }, + "operationId": { + "type": "string" + }, + "receiptId": { + "type": "string" + }, + "receiptVersion": { + "type": "string" + }, + "requestId": { + "type": "string" + }, + "resultHash": { + "pattern": "^[a-f0-9]{64}$", + "type": "string" + }, + "sha256": { + "pattern": "^[a-f0-9]{64}$", + "type": "string" + }, + "signature": { + "pattern": "^[a-f0-9]{64}$", + "type": "string" + } + }, + "required": [ + "receiptVersion", + "receiptId", + "jobId", + "requestId", + "operationId", + "resultHash", + "issuedAt", + "sha256", + "signature" + ], + "type": "object" + }, + "requestId": { + "minLength": 1, + "type": "string" + }, + "result": { + "additionalProperties": true, + "description": "R/IV Verification Object with evidence, limitations, verdict and resultHash.", + "properties": { + "limitations": { + "items": { + "type": "string" + }, + "type": "array" + }, + "operationId": { + "type": "string" + }, + "resultHash": { + "pattern": "^[a-f0-9]{64}$", + "type": "string" + }, + "verdict": { + "type": "string" + }, + "verificationId": { + "type": "string" + } + }, + "required": [ + "operationId", + "verificationId", + "verdict", + "limitations", + "resultHash" + ], + "type": "object" + }, + "schemaVersion": { + "minLength": 1, + "type": "string" + }, + "status": { + "const": "COMPLETED" + }, + "timestamps": { + "additionalProperties": true, + "properties": { + "completedAt": { + "format": "date-time", + "type": "string" + } + }, + "required": [ + "completedAt" + ], + "type": "object" + }, + "verdict": { + "minLength": 1, + "type": "string" + } + }, + "required": [ + "schemaVersion", + "requestId", + "jobId", + "operationId", + "operationVersion", + "status", + "verdict", + "result", + "receipt", + "cost", + "timestamps" + ], + "title": "R/IV Machine Verification Result v2 - authenticated paid execution", + "type": "object", + "x-riv-receipt-policy": { + "integrity": "server-side HMAC verification required for v1 receipts", + "meaning": "signed provenance and execution integrity; not evidence that an underlying claim is true" + }, + "x-riv-status": "public-contract-v2-live-machine-completed-only" +}
- Changed
evidence.monitor1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "$id": "https://rdiv-production-runtime-production.up.railway.app/schemas/riv-machine-result-v2.json", + "$schema": "https://json-schema.org/draft/2020-12/schema", + "additionalProperties": true, + "description": "Schema of a completed R/IV machine execution. Cryptographic receipt integrity does not independently establish the truth of any underlying conclusion. Free trials may use a separate contract.", + "properties": { + "cost": { + "additionalProperties": true, + "properties": { + "amount": { + "minimum": 0, + "type": "number" + }, + "currency": { + "const": "USD" + } + }, + "required": [ + "currency", + "amount" + ], + "type": "object" + }, + "jobId": { + "minLength": 1, + "type": "string" + }, + "operationId": { + "minLength": 1, + "type": "string" + }, + "operationVersion": { + "minLength": 1, + "type": "string" + }, + "receipt": { + "additionalProperties": true, + "properties": { + "issuedAt": { + "format": "date-time", + "type": "string" + }, + "jobId": { + "type": "string" + }, + "operationId": { + "type": "string" + }, + "receiptId": { + "type": "string" + }, + "receiptVersion": { + "type": "string" + }, + "requestId": { + "type": "string" + }, + "resultHash": { + "pattern": "^[a-f0-9]{64}$", + "type": "string" + }, + "sha256": { + "pattern": "^[a-f0-9]{64}$", + "type": "string" + }, + "signature": { + "pattern": "^[a-f0-9]{64}$", + "type": "string" + } + }, + "required": [ + "receiptVersion", + "receiptId", + "jobId", + "requestId", + "operationId", + "resultHash", + "issuedAt", + "sha256", + "signature" + ], + "type": "object" + }, + "requestId": { + "minLength": 1, + "type": "string" + }, + "result": { + "additionalProperties": true, + "description": "R/IV Verification Object with evidence, limitations, verdict and resultHash.", + "properties": { + "limitations": { + "items": { + "type": "string" + }, + "type": "array" + }, + "operationId": { + "type": "string" + }, + "resultHash": { + "pattern": "^[a-f0-9]{64}$", + "type": "string" + }, + "verdict": { + "type": "string" + }, + "verificationId": { + "type": "string" + } + }, + "required": [ + "operationId", + "verificationId", + "verdict", + "limitations", + "resultHash" + ], + "type": "object" + }, + "schemaVersion": { + "minLength": 1, + "type": "string" + }, + "status": { + "const": "COMPLETED" + }, + "timestamps": { + "additionalProperties": true, + "properties": { + "completedAt": { + "format": "date-time", + "type": "string" + } + }, + "required": [ + "completedAt" + ], + "type": "object" + }, + "verdict": { + "minLength": 1, + "type": "string" + } + }, + "required": [ + "schemaVersion", + "requestId", + "jobId", + "operationId", + "operationVersion", + "status", + "verdict", + "result", + "receipt", + "cost", + "timestamps" + ], + "title": "R/IV Machine Verification Result v2 - authenticated paid execution", + "type": "object", + "x-riv-receipt-policy": { + "integrity": "server-side HMAC verification required for v1 receipts", + "meaning": "signed provenance and execution integrity; not evidence that an underlying claim is true" + }, + "x-riv-status": "public-contract-v2-live-machine-completed-only" +}
- Changed
fact.extract1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "$id": "https://rdiv-production-runtime-production.up.railway.app/schemas/riv-machine-result-v2.json", + "$schema": "https://json-schema.org/draft/2020-12/schema", + "additionalProperties": true, + "description": "Schema of a completed R/IV machine execution. Cryptographic receipt integrity does not independently establish the truth of any underlying conclusion. Free trials may use a separate contract.", + "properties": { + "cost": { + "additionalProperties": true, + "properties": { + "amount": { + "minimum": 0, + "type": "number" + }, + "currency": { + "const": "USD" + } + }, + "required": [ + "currency", + "amount" + ], + "type": "object" + }, + "jobId": { + "minLength": 1, + "type": "string" + }, + "operationId": { + "minLength": 1, + "type": "string" + }, + "operationVersion": { + "minLength": 1, + "type": "string" + }, + "receipt": { + "additionalProperties": true, + "properties": { + "issuedAt": { + "format": "date-time", + "type": "string" + }, + "jobId": { + "type": "string" + }, + "operationId": { + "type": "string" + }, + "receiptId": { + "type": "string" + }, + "receiptVersion": { + "type": "string" + }, + "requestId": { + "type": "string" + }, + "resultHash": { + "pattern": "^[a-f0-9]{64}$", + "type": "string" + }, + "sha256": { + "pattern": "^[a-f0-9]{64}$", + "type": "string" + }, + "signature": { + "pattern": "^[a-f0-9]{64}$", + "type": "string" + } + }, + "required": [ + "receiptVersion", + "receiptId", + "jobId", + "requestId", + "operationId", + "resultHash", + "issuedAt", + "sha256", + "signature" + ], + "type": "object" + }, + "requestId": { + "minLength": 1, + "type": "string" + }, + "result": { + "additionalProperties": true, + "description": "R/IV Verification Object with evidence, limitations, verdict and resultHash.", + "properties": { + "limitations": { + "items": { + "type": "string" + }, + "type": "array" + }, + "operationId": { + "type": "string" + }, + "resultHash": { + "pattern": "^[a-f0-9]{64}$", + "type": "string" + }, + "verdict": { + "type": "string" + }, + "verificationId": { + "type": "string" + } + }, + "required": [ + "operationId", + "verificationId", + "verdict", + "limitations", + "resultHash" + ], + "type": "object" + }, + "schemaVersion": { + "minLength": 1, + "type": "string" + }, + "status": { + "const": "COMPLETED" + }, + "timestamps": { + "additionalProperties": true, + "properties": { + "completedAt": { + "format": "date-time", + "type": "string" + } + }, + "required": [ + "completedAt" + ], + "type": "object" + }, + "verdict": { + "minLength": 1, + "type": "string" + } + }, + "required": [ + "schemaVersion", + "requestId", + "jobId", + "operationId", + "operationVersion", + "status", + "verdict", + "result", + "receipt", + "cost", + "timestamps" + ], + "title": "R/IV Machine Verification Result v2 - authenticated paid execution", + "type": "object", + "x-riv-receipt-policy": { + "integrity": "server-side HMAC verification required for v1 receipts", + "meaning": "signed provenance and execution integrity; not evidence that an underlying claim is true" + }, + "x-riv-status": "public-contract-v2-live-machine-completed-only" +}
- Changed
investigation.run1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "$id": "https://rdiv-production-runtime-production.up.railway.app/schemas/riv-machine-result-v2.json", + "$schema": "https://json-schema.org/draft/2020-12/schema", + "additionalProperties": true, + "description": "Schema of a completed R/IV machine execution. Cryptographic receipt integrity does not independently establish the truth of any underlying conclusion. Free trials may use a separate contract.", + "properties": { + "cost": { + "additionalProperties": true, + "properties": { + "amount": { + "minimum": 0, + "type": "number" + }, + "currency": { + "const": "USD" + } + }, + "required": [ + "currency", + "amount" + ], + "type": "object" + }, + "jobId": { + "minLength": 1, + "type": "string" + }, + "operationId": { + "minLength": 1, + "type": "string" + }, + "operationVersion": { + "minLength": 1, + "type": "string" + }, + "receipt": { + "additionalProperties": true, + "properties": { + "issuedAt": { + "format": "date-time", + "type": "string" + }, + "jobId": { + "type": "string" + }, + "operationId": { + "type": "string" + }, + "receiptId": { + "type": "string" + }, + "receiptVersion": { + "type": "string" + }, + "requestId": { + "type": "string" + }, + "resultHash": { + "pattern": "^[a-f0-9]{64}$", + "type": "string" + }, + "sha256": { + "pattern": "^[a-f0-9]{64}$", + "type": "string" + }, + "signature": { + "pattern": "^[a-f0-9]{64}$", + "type": "string" + } + }, + "required": [ + "receiptVersion", + "receiptId", + "jobId", + "requestId", + "operationId", + "resultHash", + "issuedAt", + "sha256", + "signature" + ], + "type": "object" + }, + "requestId": { + "minLength": 1, + "type": "string" + }, + "result": { + "additionalProperties": true, + "description": "R/IV Verification Object with evidence, limitations, verdict and resultHash.", + "properties": { + "limitations": { + "items": { + "type": "string" + }, + "type": "array" + }, + "operationId": { + "type": "string" + }, + "resultHash": { + "pattern": "^[a-f0-9]{64}$", + "type": "string" + }, + "verdict": { + "type": "string" + }, + "verificationId": { + "type": "string" + } + }, + "required": [ + "operationId", + "verificationId", + "verdict", + "limitations", + "resultHash" + ], + "type": "object" + }, + "schemaVersion": { + "minLength": 1, + "type": "string" + }, + "status": { + "const": "COMPLETED" + }, + "timestamps": { + "additionalProperties": true, + "properties": { + "completedAt": { + "format": "date-time", + "type": "string" + } + }, + "required": [ + "completedAt" + ], + "type": "object" + }, + "verdict": { + "minLength": 1, + "type": "string" + } + }, + "required": [ + "schemaVersion", + "requestId", + "jobId", + "operationId", + "operationVersion", + "status", + "verdict", + "result", + "receipt", + "cost", + "timestamps" + ], + "title": "R/IV Machine Verification Result v2 - authenticated paid execution", + "type": "object", + "x-riv-receipt-policy": { + "integrity": "server-side HMAC verification required for v1 receipts", + "meaning": "signed provenance and execution integrity; not evidence that an underlying claim is true" + }, + "x-riv-status": "public-contract-v2-live-machine-completed-only" +}
- Changed
model.change.audit1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "$id": "https://rdiv-production-runtime-production.up.railway.app/schemas/riv-machine-result-v2.json", + "$schema": "https://json-schema.org/draft/2020-12/schema", + "additionalProperties": true, + "description": "Schema of a completed R/IV machine execution. Cryptographic receipt integrity does not independently establish the truth of any underlying conclusion. Free trials may use a separate contract.", + "properties": { + "cost": { + "additionalProperties": true, + "properties": { + "amount": { + "minimum": 0, + "type": "number" + }, + "currency": { + "const": "USD" + } + }, + "required": [ + "currency", + "amount" + ], + "type": "object" + }, + "jobId": { + "minLength": 1, + "type": "string" + }, + "operationId": { + "minLength": 1, + "type": "string" + }, + "operationVersion": { + "minLength": 1, + "type": "string" + }, + "receipt": { + "additionalProperties": true, + "properties": { + "issuedAt": { + "format": "date-time", + "type": "string" + }, + "jobId": { + "type": "string" + }, + "operationId": { + "type": "string" + }, + "receiptId": { + "type": "string" + }, + "receiptVersion": { + "type": "string" + }, + "requestId": { + "type": "string" + }, + "resultHash": { + "pattern": "^[a-f0-9]{64}$", + "type": "string" + }, + "sha256": { + "pattern": "^[a-f0-9]{64}$", + "type": "string" + }, + "signature": { + "pattern": "^[a-f0-9]{64}$", + "type": "string" + } + }, + "required": [ + "receiptVersion", + "receiptId", + "jobId", + "requestId", + "operationId", + "resultHash", + "issuedAt", + "sha256", + "signature" + ], + "type": "object" + }, + "requestId": { + "minLength": 1, + "type": "string" + }, + "result": { + "additionalProperties": true, + "description": "R/IV Verification Object with evidence, limitations, verdict and resultHash.", + "properties": { + "limitations": { + "items": { + "type": "string" + }, + "type": "array" + }, + "operationId": { + "type": "string" + }, + "resultHash": { + "pattern": "^[a-f0-9]{64}$", + "type": "string" + }, + "verdict": { + "type": "string" + }, + "verificationId": { + "type": "string" + } + }, + "required": [ + "operationId", + "verificationId", + "verdict", + "limitations", + "resultHash" + ], + "type": "object" + }, + "schemaVersion": { + "minLength": 1, + "type": "string" + }, + "status": { + "const": "COMPLETED" + }, + "timestamps": { + "additionalProperties": true, + "properties": { + "completedAt": { + "format": "date-time", + "type": "string" + } + }, + "required": [ + "completedAt" + ], + "type": "object" + }, + "verdict": { + "minLength": 1, + "type": "string" + } + }, + "required": [ + "schemaVersion", + "requestId", + "jobId", + "operationId", + "operationVersion", + "status", + "verdict", + "result", + "receipt", + "cost", + "timestamps" + ], + "title": "R/IV Machine Verification Result v2 - authenticated paid execution", + "type": "object", + "x-riv-receipt-policy": { + "integrity": "server-side HMAC verification required for v1 receipts", + "meaning": "signed provenance and execution integrity; not evidence that an underlying claim is true" + }, + "x-riv-status": "public-contract-v2-live-machine-completed-only" +}
- Changed
number.verify1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "$id": "https://rdiv-production-runtime-production.up.railway.app/schemas/riv-machine-result-v2.json", + "$schema": "https://json-schema.org/draft/2020-12/schema", + "additionalProperties": true, + "description": "Schema of a completed R/IV machine execution. Cryptographic receipt integrity does not independently establish the truth of any underlying conclusion. Free trials may use a separate contract.", + "properties": { + "cost": { + "additionalProperties": true, + "properties": { + "amount": { + "minimum": 0, + "type": "number" + }, + "currency": { + "const": "USD" + } + }, + "required": [ + "currency", + "amount" + ], + "type": "object" + }, + "jobId": { + "minLength": 1, + "type": "string" + }, + "operationId": { + "minLength": 1, + "type": "string" + }, + "operationVersion": { + "minLength": 1, + "type": "string" + }, + "receipt": { + "additionalProperties": true, + "properties": { + "issuedAt": { + "format": "date-time", + "type": "string" + }, + "jobId": { + "type": "string" + }, + "operationId": { + "type": "string" + }, + "receiptId": { + "type": "string" + }, + "receiptVersion": { + "type": "string" + }, + "requestId": { + "type": "string" + }, + "resultHash": { + "pattern": "^[a-f0-9]{64}$", + "type": "string" + }, + "sha256": { + "pattern": "^[a-f0-9]{64}$", + "type": "string" + }, + "signature": { + "pattern": "^[a-f0-9]{64}$", + "type": "string" + } + }, + "required": [ + "receiptVersion", + "receiptId", + "jobId", + "requestId", + "operationId", + "resultHash", + "issuedAt", + "sha256", + "signature" + ], + "type": "object" + }, + "requestId": { + "minLength": 1, + "type": "string" + }, + "result": { + "additionalProperties": true, + "description": "R/IV Verification Object with evidence, limitations, verdict and resultHash.", + "properties": { + "limitations": { + "items": { + "type": "string" + }, + "type": "array" + }, + "operationId": { + "type": "string" + }, + "resultHash": { + "pattern": "^[a-f0-9]{64}$", + "type": "string" + }, + "verdict": { + "type": "string" + }, + "verificationId": { + "type": "string" + } + }, + "required": [ + "operationId", + "verificationId", + "verdict", + "limitations", + "resultHash" + ], + "type": "object" + }, + "schemaVersion": { + "minLength": 1, + "type": "string" + }, + "status": { + "const": "COMPLETED" + }, + "timestamps": { + "additionalProperties": true, + "properties": { + "completedAt": { + "format": "date-time", + "type": "string" + } + }, + "required": [ + "completedAt" + ], + "type": "object" + }, + "verdict": { + "minLength": 1, + "type": "string" + } + }, + "required": [ + "schemaVersion", + "requestId", + "jobId", + "operationId", + "operationVersion", + "status", + "verdict", + "result", + "receipt", + "cost", + "timestamps" + ], + "title": "R/IV Machine Verification Result v2 - authenticated paid execution", + "type": "object", + "x-riv-receipt-policy": { + "integrity": "server-side HMAC verification required for v1 receipts", + "meaning": "signed provenance and execution integrity; not evidence that an underlying claim is true" + }, + "x-riv-status": "public-contract-v2-live-machine-completed-only" +}
- Changed
policy.monitor1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "$id": "https://rdiv-production-runtime-production.up.railway.app/schemas/riv-machine-result-v2.json", + "$schema": "https://json-schema.org/draft/2020-12/schema", + "additionalProperties": true, + "description": "Schema of a completed R/IV machine execution. Cryptographic receipt integrity does not independently establish the truth of any underlying conclusion. Free trials may use a separate contract.", + "properties": { + "cost": { + "additionalProperties": true, + "properties": { + "amount": { + "minimum": 0, + "type": "number" + }, + "currency": { + "const": "USD" + } + }, + "required": [ + "currency", + "amount" + ], + "type": "object" + }, + "jobId": { + "minLength": 1, + "type": "string" + }, + "operationId": { + "minLength": 1, + "type": "string" + }, + "operationVersion": { + "minLength": 1, + "type": "string" + }, + "receipt": { + "additionalProperties": true, + "properties": { + "issuedAt": { + "format": "date-time", + "type": "string" + }, + "jobId": { + "type": "string" + }, + "operationId": { + "type": "string" + }, + "receiptId": { + "type": "string" + }, + "receiptVersion": { + "type": "string" + }, + "requestId": { + "type": "string" + }, + "resultHash": { + "pattern": "^[a-f0-9]{64}$", + "type": "string" + }, + "sha256": { + "pattern": "^[a-f0-9]{64}$", + "type": "string" + }, + "signature": { + "pattern": "^[a-f0-9]{64}$", + "type": "string" + } + }, + "required": [ + "receiptVersion", + "receiptId", + "jobId", + "requestId", + "operationId", + "resultHash", + "issuedAt", + "sha256", + "signature" + ], + "type": "object" + }, + "requestId": { + "minLength": 1, + "type": "string" + }, + "result": { + "additionalProperties": true, + "description": "R/IV Verification Object with evidence, limitations, verdict and resultHash.", + "properties": { + "limitations": { + "items": { + "type": "string" + }, + "type": "array" + }, + "operationId": { + "type": "string" + }, + "resultHash": { + "pattern": "^[a-f0-9]{64}$", + "type": "string" + }, + "verdict": { + "type": "string" + }, + "verificationId": { + "type": "string" + } + }, + "required": [ + "operationId", + "verificationId", + "verdict", + "limitations", + "resultHash" + ], + "type": "object" + }, + "schemaVersion": { + "minLength": 1, + "type": "string" + }, + "status": { + "const": "COMPLETED" + }, + "timestamps": { + "additionalProperties": true, + "properties": { + "completedAt": { + "format": "date-time", + "type": "string" + } + }, + "required": [ + "completedAt" + ], + "type": "object" + }, + "verdict": { + "minLength": 1, + "type": "string" + } + }, + "required": [ + "schemaVersion", + "requestId", + "jobId", + "operationId", + "operationVersion", + "status", + "verdict", + "result", + "receipt", + "cost", + "timestamps" + ], + "title": "R/IV Machine Verification Result v2 - authenticated paid execution", + "type": "object", + "x-riv-receipt-policy": { + "integrity": "server-side HMAC verification required for v1 receipts", + "meaning": "signed provenance and execution integrity; not evidence that an underlying claim is true" + }, + "x-riv-status": "public-contract-v2-live-machine-completed-only" +}
- Changed
procurement.evidence1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "$id": "https://rdiv-production-runtime-production.up.railway.app/schemas/riv-machine-result-v2.json", + "$schema": "https://json-schema.org/draft/2020-12/schema", + "additionalProperties": true, + "description": "Schema of a completed R/IV machine execution. Cryptographic receipt integrity does not independently establish the truth of any underlying conclusion. Free trials may use a separate contract.", + "properties": { + "cost": { + "additionalProperties": true, + "properties": { + "amount": { + "minimum": 0, + "type": "number" + }, + "currency": { + "const": "USD" + } + }, + "required": [ + "currency", + "amount" + ], + "type": "object" + }, + "jobId": { + "minLength": 1, + "type": "string" + }, + "operationId": { + "minLength": 1, + "type": "string" + }, + "operationVersion": { + "minLength": 1, + "type": "string" + }, + "receipt": { + "additionalProperties": true, + "properties": { + "issuedAt": { + "format": "date-time", + "type": "string" + }, + "jobId": { + "type": "string" + }, + "operationId": { + "type": "string" + }, + "receiptId": { + "type": "string" + }, + "receiptVersion": { + "type": "string" + }, + "requestId": { + "type": "string" + }, + "resultHash": { + "pattern": "^[a-f0-9]{64}$", + "type": "string" + }, + "sha256": { + "pattern": "^[a-f0-9]{64}$", + "type": "string" + }, + "signature": { + "pattern": "^[a-f0-9]{64}$", + "type": "string" + } + }, + "required": [ + "receiptVersion", + "receiptId", + "jobId", + "requestId", + "operationId", + "resultHash", + "issuedAt", + "sha256", + "signature" + ], + "type": "object" + }, + "requestId": { + "minLength": 1, + "type": "string" + }, + "result": { + "additionalProperties": true, + "description": "R/IV Verification Object with evidence, limitations, verdict and resultHash.", + "properties": { + "limitations": { + "items": { + "type": "string" + }, + "type": "array" + }, + "operationId": { + "type": "string" + }, + "resultHash": { + "pattern": "^[a-f0-9]{64}$", + "type": "string" + }, + "verdict": { + "type": "string" + }, + "verificationId": { + "type": "string" + } + }, + "required": [ + "operationId", + "verificationId", + "verdict", + "limitations", + "resultHash" + ], + "type": "object" + }, + "schemaVersion": { + "minLength": 1, + "type": "string" + }, + "status": { + "const": "COMPLETED" + }, + "timestamps": { + "additionalProperties": true, + "properties": { + "completedAt": { + "format": "date-time", + "type": "string" + } + }, + "required": [ + "completedAt" + ], + "type": "object" + }, + "verdict": { + "minLength": 1, + "type": "string" + } + }, + "required": [ + "schemaVersion", + "requestId", + "jobId", + "operationId", + "operationVersion", + "status", + "verdict", + "result", + "receipt", + "cost", + "timestamps" + ], + "title": "R/IV Machine Verification Result v2 - authenticated paid execution", + "type": "object", + "x-riv-receipt-policy": { + "integrity": "server-side HMAC verification required for v1 receipts", + "meaning": "signed provenance and execution integrity; not evidence that an underlying claim is true" + }, + "x-riv-status": "public-contract-v2-live-machine-completed-only" +}
- Changed
provenance.receipt1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "$id": "https://rdiv-production-runtime-production.up.railway.app/schemas/riv-machine-result-v2.json", + "$schema": "https://json-schema.org/draft/2020-12/schema", + "additionalProperties": true, + "description": "Schema of a completed R/IV machine execution. Cryptographic receipt integrity does not independently establish the truth of any underlying conclusion. Free trials may use a separate contract.", + "properties": { + "cost": { + "additionalProperties": true, + "properties": { + "amount": { + "minimum": 0, + "type": "number" + }, + "currency": { + "const": "USD" + } + }, + "required": [ + "currency", + "amount" + ], + "type": "object" + }, + "jobId": { + "minLength": 1, + "type": "string" + }, + "operationId": { + "minLength": 1, + "type": "string" + }, + "operationVersion": { + "minLength": 1, + "type": "string" + }, + "receipt": { + "additionalProperties": true, + "properties": { + "issuedAt": { + "format": "date-time", + "type": "string" + }, + "jobId": { + "type": "string" + }, + "operationId": { + "type": "string" + }, + "receiptId": { + "type": "string" + }, + "receiptVersion": { + "type": "string" + }, + "requestId": { + "type": "string" + }, + "resultHash": { + "pattern": "^[a-f0-9]{64}$", + "type": "string" + }, + "sha256": { + "pattern": "^[a-f0-9]{64}$", + "type": "string" + }, + "signature": { + "pattern": "^[a-f0-9]{64}$", + "type": "string" + } + }, + "required": [ + "receiptVersion", + "receiptId", + "jobId", + "requestId", + "operationId", + "resultHash", + "issuedAt", + "sha256", + "signature" + ], + "type": "object" + }, + "requestId": { + "minLength": 1, + "type": "string" + }, + "result": { + "additionalProperties": true, + "description": "R/IV Verification Object with evidence, limitations, verdict and resultHash.", + "properties": { + "limitations": { + "items": { + "type": "string" + }, + "type": "array" + }, + "operationId": { + "type": "string" + }, + "resultHash": { + "pattern": "^[a-f0-9]{64}$", + "type": "string" + }, + "verdict": { + "type": "string" + }, + "verificationId": { + "type": "string" + } + }, + "required": [ + "operationId", + "verificationId", + "verdict", + "limitations", + "resultHash" + ], + "type": "object" + }, + "schemaVersion": { + "minLength": 1, + "type": "string" + }, + "status": { + "const": "COMPLETED" + }, + "timestamps": { + "additionalProperties": true, + "properties": { + "completedAt": { + "format": "date-time", + "type": "string" + } + }, + "required": [ + "completedAt" + ], + "type": "object" + }, + "verdict": { + "minLength": 1, + "type": "string" + } + }, + "required": [ + "schemaVersion", + "requestId", + "jobId", + "operationId", + "operationVersion", + "status", + "verdict", + "result", + "receipt", + "cost", + "timestamps" + ], + "title": "R/IV Machine Verification Result v2 - authenticated paid execution", + "type": "object", + "x-riv-receipt-policy": { + "integrity": "server-side HMAC verification required for v1 receipts", + "meaning": "signed provenance and execution integrity; not evidence that an underlying claim is true" + }, + "x-riv-status": "public-contract-v2-live-machine-completed-only" +}
- Changed
quote.verify1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "$id": "https://rdiv-production-runtime-production.up.railway.app/schemas/riv-machine-result-v2.json", + "$schema": "https://json-schema.org/draft/2020-12/schema", + "additionalProperties": true, + "description": "Schema of a completed R/IV machine execution. Cryptographic receipt integrity does not independently establish the truth of any underlying conclusion. Free trials may use a separate contract.", + "properties": { + "cost": { + "additionalProperties": true, + "properties": { + "amount": { + "minimum": 0, + "type": "number" + }, + "currency": { + "const": "USD" + } + }, + "required": [ + "currency", + "amount" + ], + "type": "object" + }, + "jobId": { + "minLength": 1, + "type": "string" + }, + "operationId": { + "minLength": 1, + "type": "string" + }, + "operationVersion": { + "minLength": 1, + "type": "string" + }, + "receipt": { + "additionalProperties": true, + "properties": { + "issuedAt": { + "format": "date-time", + "type": "string" + }, + "jobId": { + "type": "string" + }, + "operationId": { + "type": "string" + }, + "receiptId": { + "type": "string" + }, + "receiptVersion": { + "type": "string" + }, + "requestId": { + "type": "string" + }, + "resultHash": { + "pattern": "^[a-f0-9]{64}$", + "type": "string" + }, + "sha256": { + "pattern": "^[a-f0-9]{64}$", + "type": "string" + }, + "signature": { + "pattern": "^[a-f0-9]{64}$", + "type": "string" + } + }, + "required": [ + "receiptVersion", + "receiptId", + "jobId", + "requestId", + "operationId", + "resultHash", + "issuedAt", + "sha256", + "signature" + ], + "type": "object" + }, + "requestId": { + "minLength": 1, + "type": "string" + }, + "result": { + "additionalProperties": true, + "description": "R/IV Verification Object with evidence, limitations, verdict and resultHash.", + "properties": { + "limitations": { + "items": { + "type": "string" + }, + "type": "array" + }, + "operationId": { + "type": "string" + }, + "resultHash": { + "pattern": "^[a-f0-9]{64}$", + "type": "string" + }, + "verdict": { + "type": "string" + }, + "verificationId": { + "type": "string" + } + }, + "required": [ + "operationId", + "verificationId", + "verdict", + "limitations", + "resultHash" + ], + "type": "object" + }, + "schemaVersion": { + "minLength": 1, + "type": "string" + }, + "status": { + "const": "COMPLETED" + }, + "timestamps": { + "additionalProperties": true, + "properties": { + "completedAt": { + "format": "date-time", + "type": "string" + } + }, + "required": [ + "completedAt" + ], + "type": "object" + }, + "verdict": { + "minLength": 1, + "type": "string" + } + }, + "required": [ + "schemaVersion", + "requestId", + "jobId", + "operationId", + "operationVersion", + "status", + "verdict", + "result", + "receipt", + "cost", + "timestamps" + ], + "title": "R/IV Machine Verification Result v2 - authenticated paid execution", + "type": "object", + "x-riv-receipt-policy": { + "integrity": "server-side HMAC verification required for v1 receipts", + "meaning": "signed provenance and execution integrity; not evidence that an underlying claim is true" + }, + "x-riv-status": "public-contract-v2-live-machine-completed-only" +}
- Changed
source.snapshot1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "$id": "https://rdiv-production-runtime-production.up.railway.app/schemas/riv-machine-result-v2.json", + "$schema": "https://json-schema.org/draft/2020-12/schema", + "additionalProperties": true, + "description": "Schema of a completed R/IV machine execution. Cryptographic receipt integrity does not independently establish the truth of any underlying conclusion. Free trials may use a separate contract.", + "properties": { + "cost": { + "additionalProperties": true, + "properties": { + "amount": { + "minimum": 0, + "type": "number" + }, + "currency": { + "const": "USD" + } + }, + "required": [ + "currency", + "amount" + ], + "type": "object" + }, + "jobId": { + "minLength": 1, + "type": "string" + }, + "operationId": { + "minLength": 1, + "type": "string" + }, + "operationVersion": { + "minLength": 1, + "type": "string" + }, + "receipt": { + "additionalProperties": true, + "properties": { + "issuedAt": { + "format": "date-time", + "type": "string" + }, + "jobId": { + "type": "string" + }, + "operationId": { + "type": "string" + }, + "receiptId": { + "type": "string" + }, + "receiptVersion": { + "type": "string" + }, + "requestId": { + "type": "string" + }, + "resultHash": { + "pattern": "^[a-f0-9]{64}$", + "type": "string" + }, + "sha256": { + "pattern": "^[a-f0-9]{64}$", + "type": "string" + }, + "signature": { + "pattern": "^[a-f0-9]{64}$", + "type": "string" + } + }, + "required": [ + "receiptVersion", + "receiptId", + "jobId", + "requestId", + "operationId", + "resultHash", + "issuedAt", + "sha256", + "signature" + ], + "type": "object" + }, + "requestId": { + "minLength": 1, + "type": "string" + }, + "result": { + "additionalProperties": true, + "description": "R/IV Verification Object with evidence, limitations, verdict and resultHash.", + "properties": { + "limitations": { + "items": { + "type": "string" + }, + "type": "array" + }, + "operationId": { + "type": "string" + }, + "resultHash": { + "pattern": "^[a-f0-9]{64}$", + "type": "string" + }, + "verdict": { + "type": "string" + }, + "verificationId": { + "type": "string" + } + }, + "required": [ + "operationId", + "verificationId", + "verdict", + "limitations", + "resultHash" + ], + "type": "object" + }, + "schemaVersion": { + "minLength": 1, + "type": "string" + }, + "status": { + "const": "COMPLETED" + }, + "timestamps": { + "additionalProperties": true, + "properties": { + "completedAt": { + "format": "date-time", + "type": "string" + } + }, + "required": [ + "completedAt" + ], + "type": "object" + }, + "verdict": { + "minLength": 1, + "type": "string" + } + }, + "required": [ + "schemaVersion", + "requestId", + "jobId", + "operationId", + "operationVersion", + "status", + "verdict", + "result", + "receipt", + "cost", + "timestamps" + ], + "title": "R/IV Machine Verification Result v2 - authenticated paid execution", + "type": "object", + "x-riv-receipt-policy": { + "integrity": "server-side HMAC verification required for v1 receipts", + "meaning": "signed provenance and execution integrity; not evidence that an underlying claim is true" + }, + "x-riv-status": "public-contract-v2-live-machine-completed-only" +}
- Changed
source.verify1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "$id": "https://rdiv-production-runtime-production.up.railway.app/schemas/riv-machine-result-v2.json", + "$schema": "https://json-schema.org/draft/2020-12/schema", + "additionalProperties": true, + "description": "Schema of a completed R/IV machine execution. Cryptographic receipt integrity does not independently establish the truth of any underlying conclusion. Free trials may use a separate contract.", + "properties": { + "cost": { + "additionalProperties": true, + "properties": { + "amount": { + "minimum": 0, + "type": "number" + }, + "currency": { + "const": "USD" + } + }, + "required": [ + "currency", + "amount" + ], + "type": "object" + }, + "jobId": { + "minLength": 1, + "type": "string" + }, + "operationId": { + "minLength": 1, + "type": "string" + }, + "operationVersion": { + "minLength": 1, + "type": "string" + }, + "receipt": { + "additionalProperties": true, + "properties": { + "issuedAt": { + "format": "date-time", + "type": "string" + }, + "jobId": { + "type": "string" + }, + "operationId": { + "type": "string" + }, + "receiptId": { + "type": "string" + }, + "receiptVersion": { + "type": "string" + }, + "requestId": { + "type": "string" + }, + "resultHash": { + "pattern": "^[a-f0-9]{64}$", + "type": "string" + }, + "sha256": { + "pattern": "^[a-f0-9]{64}$", + "type": "string" + }, + "signature": { + "pattern": "^[a-f0-9]{64}$", + "type": "string" + } + }, + "required": [ + "receiptVersion", + "receiptId", + "jobId", + "requestId", + "operationId", + "resultHash", + "issuedAt", + "sha256", + "signature" + ], + "type": "object" + }, + "requestId": { + "minLength": 1, + "type": "string" + }, + "result": { + "additionalProperties": true, + "description": "R/IV Verification Object with evidence, limitations, verdict and resultHash.", + "properties": { + "limitations": { + "items": { + "type": "string" + }, + "type": "array" + }, + "operationId": { + "type": "string" + }, + "resultHash": { + "pattern": "^[a-f0-9]{64}$", + "type": "string" + }, + "verdict": { + "type": "string" + }, + "verificationId": { + "type": "string" + } + }, + "required": [ + "operationId", + "verificationId", + "verdict", + "limitations", + "resultHash" + ], + "type": "object" + }, + "schemaVersion": { + "minLength": 1, + "type": "string" + }, + "status": { + "const": "COMPLETED" + }, + "timestamps": { + "additionalProperties": true, + "properties": { + "completedAt": { + "format": "date-time", + "type": "string" + } + }, + "required": [ + "completedAt" + ], + "type": "object" + }, + "verdict": { + "minLength": 1, + "type": "string" + } + }, + "required": [ + "schemaVersion", + "requestId", + "jobId", + "operationId", + "operationVersion", + "status", + "verdict", + "result", + "receipt", + "cost", + "timestamps" + ], + "title": "R/IV Machine Verification Result v2 - authenticated paid execution", + "type": "object", + "x-riv-receipt-policy": { + "integrity": "server-side HMAC verification required for v1 receipts", + "meaning": "signed provenance and execution integrity; not evidence that an underlying claim is true" + }, + "x-riv-status": "public-contract-v2-live-machine-completed-only" +}
- Changed
timeline.reconcile1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "$id": "https://rdiv-production-runtime-production.up.railway.app/schemas/riv-machine-result-v2.json", + "$schema": "https://json-schema.org/draft/2020-12/schema", + "additionalProperties": true, + "description": "Schema of a completed R/IV machine execution. Cryptographic receipt integrity does not independently establish the truth of any underlying conclusion. Free trials may use a separate contract.", + "properties": { + "cost": { + "additionalProperties": true, + "properties": { + "amount": { + "minimum": 0, + "type": "number" + }, + "currency": { + "const": "USD" + } + }, + "required": [ + "currency", + "amount" + ], + "type": "object" + }, + "jobId": { + "minLength": 1, + "type": "string" + }, + "operationId": { + "minLength": 1, + "type": "string" + }, + "operationVersion": { + "minLength": 1, + "type": "string" + }, + "receipt": { + "additionalProperties": true, + "properties": { + "issuedAt": { + "format": "date-time", + "type": "string" + }, + "jobId": { + "type": "string" + }, + "operationId": { + "type": "string" + }, + "receiptId": { + "type": "string" + }, + "receiptVersion": { + "type": "string" + }, + "requestId": { + "type": "string" + }, + "resultHash": { + "pattern": "^[a-f0-9]{64}$", + "type": "string" + }, + "sha256": { + "pattern": "^[a-f0-9]{64}$", + "type": "string" + }, + "signature": { + "pattern": "^[a-f0-9]{64}$", + "type": "string" + } + }, + "required": [ + "receiptVersion", + "receiptId", + "jobId", + "requestId", + "operationId", + "resultHash", + "issuedAt", + "sha256", + "signature" + ], + "type": "object" + }, + "requestId": { + "minLength": 1, + "type": "string" + }, + "result": { + "additionalProperties": true, + "description": "R/IV Verification Object with evidence, limitations, verdict and resultHash.", + "properties": { + "limitations": { + "items": { + "type": "string" + }, + "type": "array" + }, + "operationId": { + "type": "string" + }, + "resultHash": { + "pattern": "^[a-f0-9]{64}$", + "type": "string" + }, + "verdict": { + "type": "string" + }, + "verificationId": { + "type": "string" + } + }, + "required": [ + "operationId", + "verificationId", + "verdict", + "limitations", + "resultHash" + ], + "type": "object" + }, + "schemaVersion": { + "minLength": 1, + "type": "string" + }, + "status": { + "const": "COMPLETED" + }, + "timestamps": { + "additionalProperties": true, + "properties": { + "completedAt": { + "format": "date-time", + "type": "string" + } + }, + "required": [ + "completedAt" + ], + "type": "object" + }, + "verdict": { + "minLength": 1, + "type": "string" + } + }, + "required": [ + "schemaVersion", + "requestId", + "jobId", + "operationId", + "operationVersion", + "status", + "verdict", + "result", + "receipt", + "cost", + "timestamps" + ], + "title": "R/IV Machine Verification Result v2 - authenticated paid execution", + "type": "object", + "x-riv-receipt-policy": { + "integrity": "server-side HMAC verification required for v1 receipts", + "meaning": "signed provenance and execution integrity; not evidence that an underlying claim is true" + }, + "x-riv-status": "public-contract-v2-live-machine-completed-only" +}
- Changed
transaction.verify1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "$id": "https://rdiv-production-runtime-production.up.railway.app/schemas/riv-machine-result-v2.json", + "$schema": "https://json-schema.org/draft/2020-12/schema", + "additionalProperties": true, + "description": "Schema of a completed R/IV machine execution. Cryptographic receipt integrity does not independently establish the truth of any underlying conclusion. Free trials may use a separate contract.", + "properties": { + "cost": { + "additionalProperties": true, + "properties": { + "amount": { + "minimum": 0, + "type": "number" + }, + "currency": { + "const": "USD" + } + }, + "required": [ + "currency", + "amount" + ], + "type": "object" + }, + "jobId": { + "minLength": 1, + "type": "string" + }, + "operationId": { + "minLength": 1, + "type": "string" + }, + "operationVersion": { + "minLength": 1, + "type": "string" + }, + "receipt": { + "additionalProperties": true, + "properties": { + "issuedAt": { + "format": "date-time", + "type": "string" + }, + "jobId": { + "type": "string" + }, + "operationId": { + "type": "string" + }, + "receiptId": { + "type": "string" + }, + "receiptVersion": { + "type": "string" + }, + "requestId": { + "type": "string" + }, + "resultHash": { + "pattern": "^[a-f0-9]{64}$", + "type": "string" + }, + "sha256": { + "pattern": "^[a-f0-9]{64}$", + "type": "string" + }, + "signature": { + "pattern": "^[a-f0-9]{64}$", + "type": "string" + } + }, + "required": [ + "receiptVersion", + "receiptId", + "jobId", + "requestId", + "operationId", + "resultHash", + "issuedAt", + "sha256", + "signature" + ], + "type": "object" + }, + "requestId": { + "minLength": 1, + "type": "string" + }, + "result": { + "additionalProperties": true, + "description": "R/IV Verification Object with evidence, limitations, verdict and resultHash.", + "properties": { + "limitations": { + "items": { + "type": "string" + }, + "type": "array" + }, + "operationId": { + "type": "string" + }, + "resultHash": { + "pattern": "^[a-f0-9]{64}$", + "type": "string" + }, + "verdict": { + "type": "string" + }, + "verificationId": { + "type": "string" + } + }, + "required": [ + "operationId", + "verificationId", + "verdict", + "limitations", + "resultHash" + ], + "type": "object" + }, + "schemaVersion": { + "minLength": 1, + "type": "string" + }, + "status": { + "const": "COMPLETED" + }, + "timestamps": { + "additionalProperties": true, + "properties": { + "completedAt": { + "format": "date-time", + "type": "string" + } + }, + "required": [ + "completedAt" + ], + "type": "object" + }, + "verdict": { + "minLength": 1, + "type": "string" + } + }, + "required": [ + "schemaVersion", + "requestId", + "jobId", + "operationId", + "operationVersion", + "status", + "verdict", + "result", + "receipt", + "cost", + "timestamps" + ], + "title": "R/IV Machine Verification Result v2 - authenticated paid execution", + "type": "object", + "x-riv-receipt-policy": { + "integrity": "server-side HMAC verification required for v1 receipts", + "meaning": "signed provenance and execution integrity; not evidence that an underlying claim is true" + }, + "x-riv-status": "public-contract-v2-live-machine-completed-only" +}
- Changed
vendor.diligence1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "$id": "https://rdiv-production-runtime-production.up.railway.app/schemas/riv-machine-result-v2.json", + "$schema": "https://json-schema.org/draft/2020-12/schema", + "additionalProperties": true, + "description": "Schema of a completed R/IV machine execution. Cryptographic receipt integrity does not independently establish the truth of any underlying conclusion. Free trials may use a separate contract.", + "properties": { + "cost": { + "additionalProperties": true, + "properties": { + "amount": { + "minimum": 0, + "type": "number" + }, + "currency": { + "const": "USD" + } + }, + "required": [ + "currency", + "amount" + ], + "type": "object" + }, + "jobId": { + "minLength": 1, + "type": "string" + }, + "operationId": { + "minLength": 1, + "type": "string" + }, + "operationVersion": { + "minLength": 1, + "type": "string" + }, + "receipt": { + "additionalProperties": true, + "properties": { + "issuedAt": { + "format": "date-time", + "type": "string" + }, + "jobId": { + "type": "string" + }, + "operationId": { + "type": "string" + }, + "receiptId": { + "type": "string" + }, + "receiptVersion": { + "type": "string" + }, + "requestId": { + "type": "string" + }, + "resultHash": { + "pattern": "^[a-f0-9]{64}$", + "type": "string" + }, + "sha256": { + "pattern": "^[a-f0-9]{64}$", + "type": "string" + }, + "signature": { + "pattern": "^[a-f0-9]{64}$", + "type": "string" + } + }, + "required": [ + "receiptVersion", + "receiptId", + "jobId", + "requestId", + "operationId", + "resultHash", + "issuedAt", + "sha256", + "signature" + ], + "type": "object" + }, + "requestId": { + "minLength": 1, + "type": "string" + }, + "result": { + "additionalProperties": true, + "description": "R/IV Verification Object with evidence, limitations, verdict and resultHash.", + "properties": { + "limitations": { + "items": { + "type": "string" + }, + "type": "array" + }, + "operationId": { + "type": "string" + }, + "resultHash": { + "pattern": "^[a-f0-9]{64}$", + "type": "string" + }, + "verdict": { + "type": "string" + }, + "verificationId": { + "type": "string" + } + }, + "required": [ + "operationId", + "verificationId", + "verdict", + "limitations", + "resultHash" + ], + "type": "object" + }, + "schemaVersion": { + "minLength": 1, + "type": "string" + }, + "status": { + "const": "COMPLETED" + }, + "timestamps": { + "additionalProperties": true, + "properties": { + "completedAt": { + "format": "date-time", + "type": "string" + } + }, + "required": [ + "completedAt" + ], + "type": "object" + }, + "verdict": { + "minLength": 1, + "type": "string" + } + }, + "required": [ + "schemaVersion", + "requestId", + "jobId", + "operationId", + "operationVersion", + "status", + "verdict", + "result", + "receipt", + "cost", + "timestamps" + ], + "title": "R/IV Machine Verification Result v2 - authenticated paid execution", + "type": "object", + "x-riv-receipt-policy": { + "integrity": "server-side HMAC verification required for v1 receipts", + "meaning": "signed provenance and execution integrity; not evidence that an underlying claim is true" + }, + "x-riv-status": "public-contract-v2-live-machine-completed-only" +}
- Changed
vendor.monitor1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "$id": "https://rdiv-production-runtime-production.up.railway.app/schemas/riv-machine-result-v2.json", + "$schema": "https://json-schema.org/draft/2020-12/schema", + "additionalProperties": true, + "description": "Schema of a completed R/IV machine execution. Cryptographic receipt integrity does not independently establish the truth of any underlying conclusion. Free trials may use a separate contract.", + "properties": { + "cost": { + "additionalProperties": true, + "properties": { + "amount": { + "minimum": 0, + "type": "number" + }, + "currency": { + "const": "USD" + } + }, + "required": [ + "currency", + "amount" + ], + "type": "object" + }, + "jobId": { + "minLength": 1, + "type": "string" + }, + "operationId": { + "minLength": 1, + "type": "string" + }, + "operationVersion": { + "minLength": 1, + "type": "string" + }, + "receipt": { + "additionalProperties": true, + "properties": { + "issuedAt": { + "format": "date-time", + "type": "string" + }, + "jobId": { + "type": "string" + }, + "operationId": { + "type": "string" + }, + "receiptId": { + "type": "string" + }, + "receiptVersion": { + "type": "string" + }, + "requestId": { + "type": "string" + }, + "resultHash": { + "pattern": "^[a-f0-9]{64}$", + "type": "string" + }, + "sha256": { + "pattern": "^[a-f0-9]{64}$", + "type": "string" + }, + "signature": { + "pattern": "^[a-f0-9]{64}$", + "type": "string" + } + }, + "required": [ + "receiptVersion", + "receiptId", + "jobId", + "requestId", + "operationId", + "resultHash", + "issuedAt", + "sha256", + "signature" + ], + "type": "object" + }, + "requestId": { + "minLength": 1, + "type": "string" + }, + "result": { + "additionalProperties": true, + "description": "R/IV Verification Object with evidence, limitations, verdict and resultHash.", + "properties": { + "limitations": { + "items": { + "type": "string" + }, + "type": "array" + }, + "operationId": { + "type": "string" + }, + "resultHash": { + "pattern": "^[a-f0-9]{64}$", + "type": "string" + }, + "verdict": { + "type": "string" + }, + "verificationId": { + "type": "string" + } + }, + "required": [ + "operationId", + "verificationId", + "verdict", + "limitations", + "resultHash" + ], + "type": "object" + }, + "schemaVersion": { + "minLength": 1, + "type": "string" + }, + "status": { + "const": "COMPLETED" + }, + "timestamps": { + "additionalProperties": true, + "properties": { + "completedAt": { + "format": "date-time", + "type": "string" + } + }, + "required": [ + "completedAt" + ], + "type": "object" + }, + "verdict": { + "minLength": 1, + "type": "string" + } + }, + "required": [ + "schemaVersion", + "requestId", + "jobId", + "operationId", + "operationVersion", + "status", + "verdict", + "result", + "receipt", + "cost", + "timestamps" + ], + "title": "R/IV Machine Verification Result v2 - authenticated paid execution", + "type": "object", + "x-riv-receipt-policy": { + "integrity": "server-side HMAC verification required for v1 receipts", + "meaning": "signed provenance and execution integrity; not evidence that an underlying claim is true" + }, + "x-riv-status": "public-contract-v2-live-machine-completed-only" +}
- Changed
workflow.verify1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "$id": "https://rdiv-production-runtime-production.up.railway.app/schemas/riv-machine-result-v2.json", + "$schema": "https://json-schema.org/draft/2020-12/schema", + "additionalProperties": true, + "description": "Schema of a completed R/IV machine execution. Cryptographic receipt integrity does not independently establish the truth of any underlying conclusion. Free trials may use a separate contract.", + "properties": { + "cost": { + "additionalProperties": true, + "properties": { + "amount": { + "minimum": 0, + "type": "number" + }, + "currency": { + "const": "USD" + } + }, + "required": [ + "currency", + "amount" + ], + "type": "object" + }, + "jobId": { + "minLength": 1, + "type": "string" + }, + "operationId": { + "minLength": 1, + "type": "string" + }, + "operationVersion": { + "minLength": 1, + "type": "string" + }, + "receipt": { + "additionalProperties": true, + "properties": { + "issuedAt": { + "format": "date-time", + "type": "string" + }, + "jobId": { + "type": "string" + }, + "operationId": { + "type": "string" + }, + "receiptId": { + "type": "string" + }, + "receiptVersion": { + "type": "string" + }, + "requestId": { + "type": "string" + }, + "resultHash": { + "pattern": "^[a-f0-9]{64}$", + "type": "string" + }, + "sha256": { + "pattern": "^[a-f0-9]{64}$", + "type": "string" + }, + "signature": { + "pattern": "^[a-f0-9]{64}$", + "type": "string" + } + }, + "required": [ + "receiptVersion", + "receiptId", + "jobId", + "requestId", + "operationId", + "resultHash", + "issuedAt", + "sha256", + "signature" + ], + "type": "object" + }, + "requestId": { + "minLength": 1, + "type": "string" + }, + "result": { + "additionalProperties": true, + "description": "R/IV Verification Object with evidence, limitations, verdict and resultHash.", + "properties": { + "limitations": { + "items": { + "type": "string" + }, + "type": "array" + }, + "operationId": { + "type": "string" + }, + "resultHash": { + "pattern": "^[a-f0-9]{64}$", + "type": "string" + }, + "verdict": { + "type": "string" + }, + "verificationId": { + "type": "string" + } + }, + "required": [ + "operationId", + "verificationId", + "verdict", + "limitations", + "resultHash" + ], + "type": "object" + }, + "schemaVersion": { + "minLength": 1, + "type": "string" + }, + "status": { + "const": "COMPLETED" + }, + "timestamps": { + "additionalProperties": true, + "properties": { + "completedAt": { + "format": "date-time", + "type": "string" + } + }, + "required": [ + "completedAt" + ], + "type": "object" + }, + "verdict": { + "minLength": 1, + "type": "string" + } + }, + "required": [ + "schemaVersion", + "requestId", + "jobId", + "operationId", + "operationVersion", + "status", + "verdict", + "result", + "receipt", + "cost", + "timestamps" + ], + "title": "R/IV Machine Verification Result v2 - authenticated paid execution", + "type": "object", + "x-riv-receipt-policy": { + "integrity": "server-side HMAC verification required for v1 receipts", + "meaning": "signed provenance and execution integrity; not evidence that an underlying claim is true" + }, + "x-riv-status": "public-contract-v2-live-machine-completed-only" +}
29 tool updates
- Changed
agent.action.verify3 fields changed- added
Input schema / additionalPropertiesAdded value: +false - added
Input schema / propertiesAdded value: +{ + "claimed_action": { + "maxLength": 10000, + "minLength": 3, + "type": "string" + }, + "evidence_records": { + "items": { + "type": "object" + }, + "maxItems": 100, + "minItems": 1, + "type": "array" + }, + "request_id": { + "description": "Caller-generated idempotency key for this paid execution attempt.", + "maxLength": 200, + "minLength": 8, + "type": "string" + }, + "target": { + "maxLength": 2048, + "type": "string" + } +} - added
Input schema / requiredAdded value: +[ + "claimed_action", + "evidence_records", + "request_id" +]
- Changed
agent.monitor3 fields changed- added
Input schema / additionalPropertiesAdded value: +false - added
Input schema / propertiesAdded value: +{ + "cadence": { + "default": "daily", + "enum": [ + "daily", + "weekly" + ] + }, + "materiality_rule": { + "maxLength": 10000, + "type": "string" + }, + "public_urls": { + "items": { + "format": "uri", + "type": "string" + }, + "maxItems": 50, + "type": "array" + }, + "request_id": { + "description": "Caller-generated idempotency key for this paid execution attempt.", + "maxLength": 200, + "minLength": 8, + "type": "string" + }, + "target": { + "maxLength": 20000, + "minLength": 3, + "type": "string" + } +} - added
Input schema / requiredAdded value: +[ + "target", + "request_id" +]
- Changed
ai.use.audit3 fields changed- added
Input schema / additionalPropertiesAdded value: +false - added
Input schema / propertiesAdded value: +{ + "public_urls": { + "items": { + "format": "uri", + "type": "string" + }, + "maxItems": 100, + "type": "array" + }, + "questions": { + "items": { + "maxLength": 5000, + "type": "string" + }, + "maxItems": 50, + "type": "array" + }, + "request_id": { + "description": "Caller-generated idempotency key for this paid execution attempt.", + "maxLength": 200, + "minLength": 8, + "type": "string" + }, + "scope": { + "maxLength": 20000, + "minLength": 3, + "type": "string" + }, + "workflow_description": { + "maxLength": 50000, + "minLength": 10, + "type": "string" + } +} - added
Input schema / requiredAdded value: +[ + "workflow_description", + "scope", + "request_id" +]
- Changed
answer.audit3 fields changed- added
Input schema / additionalPropertiesAdded value: +false - added
Input schema / propertiesAdded value: +{ + "answer": { + "maxLength": 100000, + "minLength": 10, + "type": "string" + }, + "public_urls": { + "items": { + "format": "uri", + "type": "string" + }, + "maxItems": 50, + "type": "array" + }, + "request_id": { + "description": "Caller-generated idempotency key for this paid execution attempt.", + "maxLength": 200, + "minLength": 8, + "type": "string" + }, + "strictness": { + "default": "standard", + "enum": [ + "standard", + "high" + ] + } +} - added
Input schema / requiredAdded value: +[ + "answer", + "request_id" +]
- Changed
citation.verify3 fields changed- added
Input schema / additionalPropertiesAdded value: +false - added
Input schema / propertiesAdded value: +{ + "citation_url": { + "format": "uri", + "type": "string" + }, + "claim": { + "maxLength": 10000, + "minLength": 3, + "type": "string" + }, + "quoted_or_cited_text": { + "maxLength": 20000, + "type": "string" + }, + "request_id": { + "description": "Caller-generated idempotency key for this paid execution attempt.", + "maxLength": 200, + "minLength": 8, + "type": "string" + } +} - added
Input schema / requiredAdded value: +[ + "claim", + "citation_url", + "request_id" +]
- Changed
claim.check3 fields changed- added
Input schema / additionalPropertiesAdded value: +false - added
Input schema / propertiesAdded value: +{ + "claim": { + "maxLength": 10000, + "minLength": 3, + "type": "string" + }, + "context": { + "maxLength": 20000, + "type": "string" + }, + "public_urls": { + "items": { + "format": "uri", + "type": "string" + }, + "maxItems": 20, + "type": "array" + }, + "request_id": { + "description": "Caller-generated idempotency key for this paid execution attempt.", + "maxLength": 200, + "minLength": 8, + "type": "string" + } +} - added
Input schema / requiredAdded value: +[ + "claim", + "request_id" +]
- Changed
claim.monitor3 fields changed- added
Input schema / additionalPropertiesAdded value: +false - added
Input schema / propertiesAdded value: +{ + "cadence": { + "default": "daily", + "enum": [ + "daily", + "weekly" + ] + }, + "materiality_rule": { + "maxLength": 10000, + "type": "string" + }, + "public_urls": { + "items": { + "format": "uri", + "type": "string" + }, + "maxItems": 50, + "type": "array" + }, + "request_id": { + "description": "Caller-generated idempotency key for this paid execution attempt.", + "maxLength": 200, + "minLength": 8, + "type": "string" + }, + "target": { + "maxLength": 20000, + "minLength": 3, + "type": "string" + } +} - added
Input schema / requiredAdded value: +[ + "target", + "request_id" +]
- Changed
contradiction.scan3 fields changed- added
Input schema / additionalPropertiesAdded value: +false - added
Input schema / propertiesAdded value: +{ + "items": { + "items": { + "oneOf": [ + { + "minLength": 1, + "type": "string" + }, + { + "type": "object" + } + ] + }, + "maxItems": 30, + "minItems": 2, + "type": "array" + }, + "question": { + "maxLength": 10000, + "type": "string" + }, + "request_id": { + "description": "Caller-generated idempotency key for this paid execution attempt.", + "maxLength": 200, + "minLength": 8, + "type": "string" + } +} - added
Input schema / requiredAdded value: +[ + "items", + "request_id" +]
- Changed
control.check3 fields changed- added
Input schema / additionalPropertiesAdded value: +false - added
Input schema / propertiesAdded value: +{ + "control_claim": { + "maxLength": 10000, + "minLength": 3, + "type": "string" + }, + "control_type": { + "enum": [ + "human_review", + "logging", + "retention", + "authorization", + "data_isolation", + "fallback", + "other" + ] + }, + "evidence_records": { + "items": { + "type": "object" + }, + "maxItems": 100, + "minItems": 1, + "type": "array" + }, + "request_id": { + "description": "Caller-generated idempotency key for this paid execution attempt.", + "maxLength": 200, + "minLength": 8, + "type": "string" + } +} - added
Input schema / requiredAdded value: +[ + "control_claim", + "evidence_records", + "request_id" +]
- Changed
data.flow.verify3 fields changed- added
Input schema / additionalPropertiesAdded value: +false - added
Input schema / propertiesAdded value: +{ + "evidence_records": { + "items": { + "type": "object" + }, + "maxItems": 200, + "type": "array" + }, + "flow_description": { + "maxLength": 50000, + "minLength": 10, + "type": "string" + }, + "public_urls": { + "items": { + "format": "uri", + "type": "string" + }, + "maxItems": 50, + "type": "array" + }, + "request_id": { + "description": "Caller-generated idempotency key for this paid execution attempt.", + "maxLength": 200, + "minLength": 8, + "type": "string" + } +} - added
Input schema / requiredAdded value: +[ + "flow_description", + "request_id" +]
- Changed
dependency.map3 fields changed- added
Input schema / additionalPropertiesAdded value: +false - added
Input schema / propertiesAdded value: +{ + "public_urls": { + "items": { + "format": "uri", + "type": "string" + }, + "maxItems": 50, + "type": "array" + }, + "request_id": { + "description": "Caller-generated idempotency key for this paid execution attempt.", + "maxLength": 200, + "minLength": 8, + "type": "string" + }, + "workflow_description": { + "maxLength": 50000, + "minLength": 10, + "type": "string" + } +} - added
Input schema / requiredAdded value: +[ + "workflow_description", + "request_id" +]
- Changed
dependency.monitor3 fields changed- added
Input schema / additionalPropertiesAdded value: +false - added
Input schema / propertiesAdded value: +{ + "cadence": { + "default": "daily", + "enum": [ + "daily", + "weekly" + ] + }, + "materiality_rule": { + "maxLength": 10000, + "type": "string" + }, + "public_urls": { + "items": { + "format": "uri", + "type": "string" + }, + "maxItems": 50, + "type": "array" + }, + "request_id": { + "description": "Caller-generated idempotency key for this paid execution attempt.", + "maxLength": 200, + "minLength": 8, + "type": "string" + }, + "target": { + "maxLength": 20000, + "minLength": 3, + "type": "string" + } +} - added
Input schema / requiredAdded value: +[ + "target", + "request_id" +]
- Changed
evidence.bundle3 fields changed- added
Input schema / additionalPropertiesAdded value: +false - added
Input schema / propertiesAdded value: +{ + "context": { + "maxLength": 50000, + "type": "string" + }, + "public_urls": { + "items": { + "format": "uri", + "type": "string" + }, + "maxItems": 50, + "type": "array" + }, + "question": { + "maxLength": 10000, + "minLength": 3, + "type": "string" + }, + "request_id": { + "description": "Caller-generated idempotency key for this paid execution attempt.", + "maxLength": 200, + "minLength": 8, + "type": "string" + } +} - added
Input schema / requiredAdded value: +[ + "question", + "request_id" +]
- Changed
evidence.monitor3 fields changed- added
Input schema / additionalPropertiesAdded value: +false - added
Input schema / propertiesAdded value: +{ + "cadence": { + "enum": [ + "daily", + "weekly" + ] + }, + "monitor_type": { + "enum": [ + "claim", + "source", + "entity", + "dependency" + ] + }, + "public_urls": { + "items": { + "format": "uri", + "type": "string" + }, + "maxItems": 20, + "type": "array" + }, + "request_id": { + "description": "Caller-generated idempotency key for this paid execution attempt.", + "maxLength": 200, + "minLength": 8, + "type": "string" + }, + "target": { + "maxLength": 10000, + "minLength": 3, + "type": "string" + } +} - added
Input schema / requiredAdded value: +[ + "target", + "monitor_type", + "cadence", + "request_id" +]
- Changed
fact.extract3 fields changed- added
Input schema / additionalPropertiesAdded value: +false - added
Input schema / propertiesAdded value: +{ + "max_claims": { + "default": 50, + "maximum": 200, + "minimum": 1, + "type": "integer" + }, + "request_id": { + "description": "Caller-generated idempotency key for this paid execution attempt.", + "maxLength": 200, + "minLength": 8, + "type": "string" + }, + "source_url": { + "format": "uri", + "type": "string" + }, + "text": { + "maxLength": 100000, + "minLength": 10, + "type": "string" + } +} - added
Input schema / requiredAdded value: +[ + "text", + "request_id" +]
- Changed
investigation.run3 fields changed- added
Input schema / additionalPropertiesAdded value: +false - added
Input schema / propertiesAdded value: +{ + "deadline": { + "maxLength": 200, + "type": "string" + }, + "public_urls": { + "items": { + "format": "uri", + "type": "string" + }, + "maxItems": 100, + "type": "array" + }, + "question": { + "maxLength": 10000, + "minLength": 3, + "type": "string" + }, + "request_id": { + "description": "Caller-generated idempotency key for this paid execution attempt.", + "maxLength": 200, + "minLength": 8, + "type": "string" + }, + "scope": { + "maxLength": 20000, + "minLength": 3, + "type": "string" + } +} - added
Input schema / requiredAdded value: +[ + "question", + "scope", + "request_id" +]
- Changed
model.change.audit3 fields changed- added
Input schema / additionalPropertiesAdded value: +false - added
Input schema / propertiesAdded value: +{ + "baseline": { + "type": "object" + }, + "current": { + "type": "object" + }, + "public_urls": { + "items": { + "format": "uri", + "type": "string" + }, + "maxItems": 50, + "type": "array" + }, + "request_id": { + "description": "Caller-generated idempotency key for this paid execution attempt.", + "maxLength": 200, + "minLength": 8, + "type": "string" + }, + "workflow": { + "maxLength": 50000, + "minLength": 10, + "type": "string" + } +} - added
Input schema / requiredAdded value: +[ + "workflow", + "baseline", + "current", + "request_id" +]
- Changed
number.verify3 fields changed- added
Input schema / additionalPropertiesAdded value: +false - added
Input schema / propertiesAdded value: +{ + "as_of": { + "maxLength": 200, + "type": "string" + }, + "claim": { + "maxLength": 10000, + "minLength": 1, + "type": "string" + }, + "public_urls": { + "items": { + "format": "uri", + "type": "string" + }, + "maxItems": 20, + "type": "array" + }, + "request_id": { + "description": "Caller-generated idempotency key for this paid execution attempt.", + "maxLength": 200, + "minLength": 8, + "type": "string" + }, + "unit": { + "maxLength": 100, + "type": "string" + }, + "value": { + "type": [ + "number", + "string" + ] + } +} - added
Input schema / requiredAdded value: +[ + "claim", + "request_id" +]
- Changed
policy.monitor3 fields changed- added
Input schema / additionalPropertiesAdded value: +false - added
Input schema / propertiesAdded value: +{ + "cadence": { + "default": "daily", + "enum": [ + "daily", + "weekly" + ] + }, + "materiality_rule": { + "maxLength": 10000, + "type": "string" + }, + "public_urls": { + "items": { + "format": "uri", + "type": "string" + }, + "maxItems": 50, + "type": "array" + }, + "request_id": { + "description": "Caller-generated idempotency key for this paid execution attempt.", + "maxLength": 200, + "minLength": 8, + "type": "string" + }, + "target": { + "maxLength": 20000, + "minLength": 3, + "type": "string" + } +} - added
Input schema / requiredAdded value: +[ + "target", + "request_id" +]
- Changed
procurement.evidence3 fields changed- added
Input schema / additionalPropertiesAdded value: +false - added
Input schema / propertiesAdded value: +{ + "product_or_vendor": { + "maxLength": 1000, + "minLength": 1, + "type": "string" + }, + "public_urls": { + "items": { + "format": "uri", + "type": "string" + }, + "maxItems": 100, + "type": "array" + }, + "request_id": { + "description": "Caller-generated idempotency key for this paid execution attempt.", + "maxLength": 200, + "minLength": 8, + "type": "string" + }, + "requirements": { + "items": { + "maxLength": 5000, + "type": "string" + }, + "maxItems": 100, + "minItems": 1, + "type": "array" + } +} - added
Input schema / requiredAdded value: +[ + "product_or_vendor", + "requirements", + "request_id" +]
- Changed
provenance.receipt3 fields changed- added
Input schema / additionalPropertiesAdded value: +false - added
Input schema / propertiesAdded value: +{ + "job_or_artifact": { + "type": "object" + }, + "request_id": { + "description": "Caller-generated idempotency key for this paid execution attempt.", + "maxLength": 200, + "minLength": 8, + "type": "string" + }, + "source_records": { + "items": { + "type": "object" + }, + "maxItems": 200, + "type": "array" + } +} - added
Input schema / requiredAdded value: +[ + "job_or_artifact", + "source_records", + "request_id" +]
- Changed
quote.verify3 fields changed- added
Input schema / additionalPropertiesAdded value: +false - added
Input schema / propertiesAdded value: +{ + "attribution": { + "maxLength": 5000, + "type": "string" + }, + "context": { + "maxLength": 20000, + "type": "string" + }, + "quote": { + "maxLength": 20000, + "minLength": 1, + "type": "string" + }, + "request_id": { + "description": "Caller-generated idempotency key for this paid execution attempt.", + "maxLength": 200, + "minLength": 8, + "type": "string" + }, + "source_url": { + "format": "uri", + "type": "string" + } +} - added
Input schema / requiredAdded value: +[ + "quote", + "source_url", + "request_id" +]
- Changed
source.snapshot3 fields changed- added
Input schema / additionalPropertiesAdded value: +false - added
Input schema / propertiesAdded value: +{ + "capture_scope": { + "default": "text", + "enum": [ + "metadata", + "text", + "full_public_record" + ] + }, + "purpose": { + "maxLength": 5000, + "type": "string" + }, + "request_id": { + "description": "Caller-generated idempotency key for this paid execution attempt.", + "maxLength": 200, + "minLength": 8, + "type": "string" + }, + "url": { + "format": "uri", + "type": "string" + } +} - added
Input schema / requiredAdded value: +[ + "url", + "request_id" +]
- Changed
source.verify3 fields changed- added
Input schema / additionalPropertiesAdded value: +false - added
Input schema / propertiesAdded value: +{ + "context": { + "maxLength": 20000, + "type": "string" + }, + "expected_identity": { + "maxLength": 5000, + "type": "string" + }, + "request_id": { + "description": "Caller-generated idempotency key for this paid execution attempt.", + "maxLength": 200, + "minLength": 8, + "type": "string" + }, + "url": { + "format": "uri", + "type": "string" + } +} - added
Input schema / requiredAdded value: +[ + "url", + "request_id" +]
- Changed
timeline.reconcile3 fields changed- added
Input schema / additionalPropertiesAdded value: +false - added
Input schema / propertiesAdded value: +{ + "default_timezone": { + "maxLength": 100, + "type": "string" + }, + "events": { + "items": { + "type": "object" + }, + "maxItems": 200, + "minItems": 2, + "type": "array" + }, + "question": { + "maxLength": 10000, + "type": "string" + }, + "request_id": { + "description": "Caller-generated idempotency key for this paid execution attempt.", + "maxLength": 200, + "minLength": 8, + "type": "string" + } +} - added
Input schema / requiredAdded value: +[ + "events", + "request_id" +]
- Changed
transaction.verify3 fields changed- added
Input schema / additionalPropertiesAdded value: +false - added
Input schema / propertiesAdded value: +{ + "evidence_records": { + "items": { + "type": "object" + }, + "maxItems": 100, + "minItems": 1, + "type": "array" + }, + "expected_amount": { + "type": [ + "number", + "null" + ] + }, + "expected_currency": { + "maxLength": 10, + "type": [ + "string", + "null" + ] + }, + "request_id": { + "description": "Caller-generated idempotency key for this paid execution attempt.", + "maxLength": 200, + "minLength": 8, + "type": "string" + }, + "transaction_claim": { + "maxLength": 10000, + "minLength": 3, + "type": "string" + } +} - added
Input schema / requiredAdded value: +[ + "transaction_claim", + "evidence_records", + "request_id" +]
- Changed
vendor.diligence3 fields changed- added
Input schema / additionalPropertiesAdded value: +false - added
Input schema / propertiesAdded value: +{ + "public_urls": { + "items": { + "format": "uri", + "type": "string" + }, + "maxItems": 100, + "type": "array" + }, + "question": { + "maxLength": 10000, + "type": "string" + }, + "request_id": { + "description": "Caller-generated idempotency key for this paid execution attempt.", + "maxLength": 200, + "minLength": 8, + "type": "string" + }, + "scope": { + "maxLength": 20000, + "minLength": 3, + "type": "string" + }, + "vendor": { + "maxLength": 1000, + "minLength": 1, + "type": "string" + } +} - added
Input schema / requiredAdded value: +[ + "vendor", + "scope", + "request_id" +]
- Changed
vendor.monitor3 fields changed- added
Input schema / additionalPropertiesAdded value: +false - added
Input schema / propertiesAdded value: +{ + "cadence": { + "default": "daily", + "enum": [ + "daily", + "weekly" + ] + }, + "materiality_rule": { + "maxLength": 10000, + "type": "string" + }, + "public_urls": { + "items": { + "format": "uri", + "type": "string" + }, + "maxItems": 50, + "type": "array" + }, + "request_id": { + "description": "Caller-generated idempotency key for this paid execution attempt.", + "maxLength": 200, + "minLength": 8, + "type": "string" + }, + "target": { + "maxLength": 20000, + "minLength": 3, + "type": "string" + } +} - added
Input schema / requiredAdded value: +[ + "target", + "request_id" +]
- Changed
workflow.verify3 fields changed- added
Input schema / additionalPropertiesAdded value: +false - added
Input schema / propertiesAdded value: +{ + "claimed_steps": { + "items": { + "type": "object" + }, + "maxItems": 100, + "minItems": 1, + "type": "array" + }, + "evidence_records": { + "items": { + "type": "object" + }, + "maxItems": 200, + "minItems": 1, + "type": "array" + }, + "request_id": { + "description": "Caller-generated idempotency key for this paid execution attempt.", + "maxLength": 200, + "minLength": 8, + "type": "string" + }, + "workflow": { + "maxLength": 50000, + "minLength": 10, + "type": "string" + } +} - added
Input schema / requiredAdded value: +[ + "workflow", + "claimed_steps", + "evidence_records", + "request_id" +]
6 tool updates
- Changed
capabilities.list1 field changed- added
Input schema / additionalPropertiesAdded value: +false
- Changed
example.get2 fields changed- added
Input schema / additionalPropertiesAdded value: +true - added
Input schema / propertiesAdded value: +{ + "capabilityId": { + "type": "string" + } +}
- Changed
pricing.quote2 fields changed- added
Input schema / additionalPropertiesAdded value: +false - added
Input schema / propertiesAdded value: +{ + "capabilityId": { + "type": "string" + }, + "capability_id": { + "type": "string" + } +}
- Added
provenance.receipt.trial - Changed
service.match3 fields changed- added
Input schema / additionalPropertiesAdded value: +false - added
Input schema / propertiesAdded value: +{ + "goal": { + "type": "string" + } +} - added
Input schema / requiredAdded value: +[ + "goal" +]
- Changed
system.status1 field changed- added
Input schema / additionalPropertiesAdded value: +false
34 tool updates
- First observed
agent.action.verify - First observed
agent.monitor - First observed
ai.use.audit - First observed
answer.audit - First observed
capabilities.list - First observed
citation.verify - First observed
claim.check - First observed
claim.monitor - First observed
contradiction.scan - First observed
control.check - First observed
data.flow.verify - First observed
dependency.map - First observed
dependency.monitor - First observed
evidence.bundle - First observed
evidence.monitor - First observed
example.get - First observed
fact.extract - First observed
investigation.run - First observed
model.change.audit - First observed
number.verify - First observed
policy.monitor - First observed
pricing.quote - First observed
procurement.evidence - First observed
provenance.receipt - First observed
quote.verify - First observed
service.match - First observed
source.snapshot - First observed
source.verify - First observed
system.status - First observed
timeline.reconcile - First observed
transaction.verify - First observed
vendor.diligence - First observed
vendor.monitor - First observed
workflow.verify
Related MCP Connectors
Free buyer-side outcome verification and provider comparison for supplied agent receipts.
Verify a company, figure or citation before you rely on it. Card or crypto; signed receipt.
Verified brand claims with receipts for agent commerce. Ranking is never paid; the engine is open.
Before an agent pays, get a verdict and a keepable receipt. Not insurance. Not custody.
Related MCP Servers
- AlicenseNot gradedqualityBmaintenanceEnables agents to verify factual claims against hosted web search with provenance-tracked evidence, tiered pricing, and signed receipts. Offers quick, standard, deep, and research-grade verification through paid MCP tools.MIT
- AlicenseNot gradedqualityAmaintenanceEnables AI agents to obtain structured, source-backed real-world evidence with provenance, freshness, conflicts, support levels, coverage, unresolved dependencies, and reusable integrity-checked receipts, including French company verification and beta import assessment.Apache 2.0
- AlicenseNot gradedqualityBmaintenanceTrust layer for agent work: verify the artifact an AI agent produced, meter what the run actually cost, and keep the agent inside its mandate. Signed receipts verify offline. 20 checks/day free, then 0.005 USDC per call or $49 per environment per month. Locales: en, hi.MIT
Try in Browser
Context Every Agent Can ShareAgents share what they learn, hand off work, and keep it when you switch models. Start with 5 GB free.fulcradynamics.comAd
Glama MCP Gateway
Add one secure layer between your agents and this server.