RFC: Extending OVS to Non-Numerical/Textual Claims (OVS-T)

[OpenVeracity]

Problem Statement: The Limits of Pure Arithmetic

Currently, the Open Veracity Standard (OVS) excels at validating deterministic, numerical claims against structured datasets (e.g., matching a job creation slogan to a parsed CSV file from a national statistics bureau).

However, political rhetoric frequently weaponizes non-numerical, text-based sources. Slogans often rely on the mischaracterization or outright fabrication of legal texts, treaties, supreme court rulings, or legislative bills (e.g., "Section 4 of the new treaty surrenders our national sovereignty").

To prevent politicians from using these documents as "lamp-posts to lean on rather than illumination," we need a deterministic way to extend OVS to textual and legal claims without introducing subjective human fact-checking or unreliable AI models.

Proposed Solution: The OVS-T (Textual) Extension

We propose an architectural extension that treats textual documents exactly like datasets—forcing lexical and structural anchoring against a strict domain whitelist of public legislative portals.

Proposed Schema Structure (textual.json)

Instead of tracking sums and columns, the metadata payload handles cryptographic text verification:

{
  "@context": "[https://openveracity.org/schemas/v1/textual.json](https://openveracity.org/schemas/v1/textual.json)",
  "@type": "VerificationClaim",
  "claimReviewed": "Section 12 of Bill C-11 grants the Minister total oversight.",
  "ovsExtensions": {
    "textualProof": {
      "documentSource": "[https://lovdata.no/dokument/NL/lov/2026-06-15-42](https://lovdata.no/dokument/NL/lov/2026-06-15-42)", 
      "documentHash": "e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855", 
      "structuralAnchor": {
        "section": "12",
        "paragraph": "2",
        "expectedText": "The Minister shall maintain regulatory oversight over..."
      }
    }
  }
}

Automated Runtime Validation Logic

When a client script or user-script encounters an OVS-T tag, it executes three checks:

1. Integrity Match: Download the source from the whitelisted domain and verify its SHA-256 hash against documentHash to ensure the text hasn't been modified or swapped.
2. Structural Isolation: Navigate the DOM/text structure of the verified document using the structuralAnchor variables.
3. Lexical String Matching: Verify that expectedText exists verbatim within that structural node, and that the user-facing claimReviewed accurately reflects it.

Open Questions for the Community

• What are the most reliable, canonical domain targets for legislative text repositories internationally (e.g., Eur-Lex for the EU, Congress.gov for the US)?
• How do we gracefully handle minor typographical string discrepancies (e.g., whitespace rendering, encoding differences between PDF and HTML) without throwing false validation errors?

We welcome feedback, schema refinements, and proof-of-concept parsing ideas from the community.