← Documentation

EVIDIQ Rubric

Payment for work implies acceptance, and acceptance is usually one person's opinion — which is exactly what neither side can verify later. Rubric turns it into a verdict against a spec both sides agreed on before the work started, computed the same way every time by anyone holding the same bytes.

Quickstart

Connect the Streamable HTTP MCP endpoint, then preflight for free before paying.

claude mcp add --transport http evidiq-rubric https://mcp.evidiq.dev/rubric/mcp

Or probe the public pricing discovery endpoint:

curl -s https://mcp.evidiq.dev/rubric/x402

Prefer a Skill file? Fetch the agent-readable EVIDIQ Rubric Skill:

curl -s https://mcp.evidiq.dev/rubric/skill.md

What Rubric is for

The acceptance spec

A spec is JSON — no expressions, no code, no hidden regex. It is versioned, and an unknown version is refused rather than guessed at.

{
  "specVersion": "1.0",
  "deliverable": { "kind": "markdown" },
  "criteria": [
    { "id": "has-summary", "severity": "blocker",
      "type": "requiredSection", "section": "Summary", "minWords": 40 },
    { "id": "cites-sources", "severity": "blocker", "type": "minCitations", "count": 2 },
    { "id": "no-placeholder", "severity": "blocker",
      "type": "forbiddenPhrase", "phrases": ["TODO", "lorem ipsum", "as an AI"] },
    { "id": "length", "severity": "high", "type": "wordCount", "min": 300, "max": 1200 },
    { "id": "numbers-grounded", "severity": "high",
      "type": "numbersGrounded", "tolerance": 0.001 }
  ]
}

The verdict rules are fixed and published, not tuned per call: any failing blocker is BLOCK; otherwise any failing high is REVIEW; everything passing is PASS. A criterion that cannot be evaluated is INCONCLUSIVE, is excluded from a pass, and forces at least REVIEW.

Ten MCP tools

Paid checks

• check_schema — Validate a structured deliverable against a JSON Schema; every violation is reported by path, with the expected and actual type. (0.005 USDT0)
• verify_grounding — Check that every quoted span, number and date is supported by the sources supplied with the deliverable; unsupported spans come back with offsets. (0.01 USDT0)
• check_acceptance — Evaluate a deliverable against an acceptance spec and return PASS, REVIEW, BLOCK or REFUSED with the per-criterion results that decided it. (0.015 USDT0)
• diff_deliverable — Compare a revision against the previous version and the spec: which criteria flipped, and what changed between them. (0.02 USDT0)
• attest_acceptance — Bind the spec digest, deliverable digest and verdict into one EIP-191 signed attestation, and anchor the digest. (0.03 USDT0)

Free preflight and verification

• rubric_capabilities — Spec DSL version, criterion catalogue with severities, supported deliverable kinds, limits, full pricing, and the names of all ten tools. (free)
• validate_spec — Parse-check the spec and the deliverable and return counts by severity — refusing exactly what a paid check would refuse. (free)
• estimate_cost — Price one tool, or the whole table when none is named. (free)
• verify_rubric_report — Recompute the digest and verify the EIP-191 signature offline. (free)
• get_artifact — Retrieve a stored report or attestation by id, within its in-memory TTL. (free)

Recommended workflow

Settlement happens before a paid tool runs, so a spec the engine would refuse is still a paid call. Preflight for free first.

1. Call rubric_capabilities for the DSL version, criterion types, limits and prices.
2. Call validate_spec — it refuses exactly what a paid check refuses, including a spec with no criteria.
3. Call estimate_cost for the intended tool.
4. Run check_acceptance, adding check_schema or verify_grounding where the spec needs them.
5. If a counterparty needs proof, call attest_acceptance and hand over the report.
6. Verify offline with verify_rubric_report, and re-fetch with get_artifact while its TTL lasts.

What a verdict proves, and what it does not

It proves that this exact deliverable, under this spec version and this rule set version, produced these criterion results and this verdict — recomputable by anyone with the same bytes. It does not prove the work is correct, useful, or complete in a sense the spec did not encode. A PASS means the spec's criteria were met, no more. And absence of support for a claim is not evidence that the claim is false.

{
  "verdict": "PASS",
  "verdictReason": "All criteria passed.",
  "counts": { "pass": 3, "fail": 0, "inconclusive": 0 },
  "criteria": [
    { "id": "has-summary", "type": "requiredSection", "severity": "blocker", "status": "PASS" }
  ],
  "integrity": { "algorithm": "SHA-256", "digest": "...", "signature": "0x...", "signer": "0x8a3c7524..." }
}

x402 pricing

Payments use x402 v2 exact scheme with USDT0 (6 decimals) on X Layer (eip155:196). Verification and settlement run through the official OKX Onchain OS Payment SDK (@okxweb3/x402-core and @okxweb3/x402-evm). The OKX facilitator verifies each authorization and settles it on X Layer before any check runs.

Licensing

EVIDIQ owns and licenses its original Rubric code under MIT. Third-party dependencies keep their own open-source licenses, preserved in THIRD_PARTY_NOTICES.md.

← Back to docs