Verification workspace

What you can check

The workspace checks relationships retained from the HTML snapshot you supply. It distinguishes a value that belongs to your entity from a value that merely appears somewhere on the page. It also surfaces compatible declarations that disagree.

These examples explain the behavior. They are not live receipts or a general accuracy benchmark.

Make your first check

1. Sign in and open the workspace. Choose an example or start with your own HTML.
2. Enter the exact entity, such as Atlas. A name does not assign every value on the page to that entity.
3. For each field, choose an output name, the source property, and a value type. For this example, use price for both names and Number for the type.
4. Use an optional entity override for a field that belongs to another entity. To check an answer you already have, enable Check proposed values and enter one JSON object containing exactly your output field names. Incorrect values are refused rather than corrected.
5. Supply a reference URL and paste the source snapshot. The URL is a reference you provide; the workspace does not contact it.
6. Select Verify snapshot. Read the whole-result decision, then select each field to inspect its supporting or competing passages.

<p>Atlas costs 25; Boreal costs 99</p>

The supported contract uses explicit, flat fields with text, number, or boolean values. Arbitrary prose, aliases, complex layouts, and nested data can fall outside the supported relationships. Missing evidence is not permission to infer an answer.

Set context deliberately

Open Context and source policy when currency, period, unit, version, variant, or source channel matters. Known different currencies, periods or variants can describe different claims even when amounts are equal. Without enough context to distinguish them, the result can be uncertain rather than conflicting.

Variant support requires an explicit Variant label in the same supported price record, such as a table row. It does not infer variants from SKU, size, color, aliases or arbitrary prose. An unsupported qualifier or nested proposed value is refused with an explanation.

Selecting only body text or only metadata narrows the claim being checked. It does not establish that the selected declaration is more truthful. Excluding content marked hidden checks explicit static HTML declarations; it does not establish what a browser actually displays.

Numeric interpretation is deliberately narrow. Comma-formatted numbers and unsupported conversions can be refused. A dollar symbol is not guessed to mean USD. Make the source and requested context explicit.

Read the field decisions

Supported

The retained relationship supports the requested value within the stated entity, property, and context, with no detected compatible contradiction.

Conflicting

Comparable declarations for the same claim disagree. Inspect both passages and resolve the source or requested context before acting.

Uncertain

Context is ambiguous, conversion is unsafe, or known missing or truncated evidence prevents a decision.

Missing evidence

No adequate supported relationship was found. This does not establish that the requested fact is false.

Unsupported

The request or candidate does not meet the supported contract or does not match the evidence.

If any requested field is unresolved, the whole-result data is withheld. A supported individual field remains a scoped decision; it does not make the entire request accepted.

The check can recover evidence outside its initial selection window when that evidence is already retained from your snapshot. It cannot recover content absent from the HTML. There is no automatic web fetch, rendering, or model fallback in this mode.

Inspect the source

Select a field to see its entity, context, source channel, and relevant passages. The displayed fragments come from the supplied HTML and are shown as text. A structural fragment may include an enclosing declaration, so read its context as well as the displayed value.

Passage limits and truncation are disclosed. A snapshot hash identifies the supplied bytes; it does not authenticate where they came from. The source URL, live freshness, publisher truth, and rendered visibility remain unverified.

Save, review, and return

Each completed run has one execution ID across its decision, source evidence, receipt, and account-private history. Reopen a run from history to inspect the same saved result. Inputs, results, and review notes are encrypted at rest, and snapshot content remains available for seven days.

If you supplied proposed values, they remain visible separately from the accepted answer and are covered by the signature, including when the proposal is refused. Changing or removing them invalidates the receipt.

Flag a wrong accepted value, missed support, missed conflict, or another issue. Describe the field and what the source actually establishes. Feedback is saved for investigation; it does not automatically change the verification rules or become a validated improvement.

Download the signed result when you need to retain a packet. Follow the evidence packet guide to verify it using independently obtained issuer keys. A valid signature establishes packet integrity and issuer-key possession, not source authenticity or semantic truth.

Pilot limits

• Up to 20 runs per account in a rolling 24-hour period, with two active runs at once and shared service capacity limits.
• Up to 20 flat fields and 200,000 UTF-8 bytes of supplied HTML per request.
• Seven days of account-private snapshot history.
• No extraction credits charged for this supplied-snapshot mode.

These are bounded pilot limits, separate from the existing extraction plans and their credit allowances. A supported snapshot result is not a general semantic-accuracy certification.

Check and recover from an agent

The operator-enabled agent pilot adds contrie_check_fields and contrie_verification. Use them only when your connection lists them. They use the same account-private workspace and pilot limits. A Contrie OAuth connection needs no additional API key; bearer REST and headless clients can use a key.

Start with HTML your client already holds. The URL describes the snapshot and is never fetched. contrie_read returns reduced markdown, so its output is not a substitute for the original HTML. Create a fresh UUID v4 for each new submission and keep it with the exact input.

{
  "idempotencyKey": "331cbfac-28bc-478d-ade8-ab4be2dbdfbf",
  "source": {
    "url": "https://example.com/plans",
    "html": "<p>Atlas costs 25; Boreal costs 99</p>"
  },
  "contract": {
    "version": 1,
    "fields": {
      "price": { "entity": "Atlas", "property": "price", "type": "number", "normalization": "number" }
    }
  },
  "proposedData": { "price": 99 }
}

The example checks an incorrect proposal. Inspect run.state, then run.result.status, data, and each field decision. A completed check can withhold all data; that is a useful result, not a failed tool call. isError indicates an operational or input error. The service does not silently repair your proposal.

Use explicit normalization: number for numeric text. Conversion is deliberately narrow: a source value containing currency or period prose can remain uncertain even when a person understands it. Qualifiers constrain the required relationship; they do not make arbitrary text parseable. Keep the original snapshot and inspect the refusal.

After a lost response, reuse the identical input and UUID. When you have an execution ID, call contrie_verification {"executionId":"…"}. Call it with {} to list recent runs, then pass before from nextCursor for another page. Do not combine the cursor with an execution ID. Open dashboardUrl while signed into the same account to inspect or download the saved result.

Bearer REST provides POST /api/v1/verification/runs with the same body except idempotencyKey goes in the Idempotency-Key header; GET lists runs and GET /api/v1/verification/runs/:id recovers one. Browser cookies alone do not authorize these routes. Completed submissions return 201, matching replays 200, running submissions 202, changed-input retries 409, expired retry records 410, and capacity limits 429. A 503 can include an execution ID: recover it before starting new work.

Snapshot payloads remain available for seven days; content-free retry identities remain for 30 days. Recovery uses no extraction credits, including when the account has none left. Human review notes can be read with the run; these tools cannot write or invent human labels. A signed result establishes integrity, not authenticity, freshness, completeness or factual truth.

Choose the right verification path

Verification workspace

Use the signed-in workspace to inspect explicit entity and context relationships in supplied snapshots. This guide describes that bounded mode.

Verify API

Use the existing API to check whether value text occurs in a source. Text presence does not establish that a value belongs to the claimed entity or field.

Evidence verification

Verify the signature of a saved result. For a supplied snapshot, asking to refetch does not fetch the reference URL; source comparison is reported unavailable.

The workspace and its optional agent tools do not replace the legacy extraction acceptance rules. contrie_verify continues to check text presence. Use the MCP guide to connect and inspect available tools.