The SOP Framework: Orchestrating the Evidence Chain
Accurate resolution depends not only on how questions are defined, but also on how evidence is sourced. In practice, many oracle failures arise from data source drift: changes in availability, interpretation, freshness, or trustworthiness of inputs over time.
Cournot treats data requirements as a first-class protocol responsibility rather than an implicit assumption. Each resolution specifies explicit constraints on evidence collection, including:
Authoritative sources permitted for resolution,
Verifiable retrieval methods with cryptographic receipts,
Freshness windows defining acceptable temporal bounds,
Conflict resolution rules for handling inconsistent or competing evidence.
By formalizing these requirements, Cournot reduces unpredictability in AI reasoning, minimizes disputes caused by shifting data assumptions, and lowers verification costs by narrowing the evidence set. Explicit data requirements ensure that all parties: resolvers, verifiers, and challengers, evaluate outcomes against the same evidentiary ground truth.
The Proof of Reasoning workflow is enforced by a Role-Based SOP, ensuring that every resolution undergoes three mandatory verification stages:

Stage 1: Proof of Authenticity (The Collector Role)
SOP Action: The Collector Agent is responsible for the "Input" phase. The Collector retrieves real-world evidence strictly according to the predefined data requirements associated with the resolution. Only evidence that satisfies the authoritative source list, freshness constraints, and verifiable retrieval criteria is admitted into the reasoning process. Each evidence item is accompanied by a cryptographic receipt, ensuring provenance and replayability.
Technology: zkTLS (Zero-Knowledge Transport Layer Security).
Mechanism: When fetching data (e.g., a tweet or a sports score), the Collector generates a ZK-proof confirming the data originated from the specific server (e.g.,
twitter.com) via a secure TLS session. While zkTLS provides the gold standard for verification, the protocol supports a tiered verification model to accommodate long-tail data sources that may lack modern TLS infrastructure.Tokenomics: The Collector stakes $COUR on the Source Integrity. If the zkTLS proof is invalid, their stake is slashed.
Stage 2: Proof of Logic (The Auditor Role)
SOP Action: The Auditor Agent is responsible for the "Processing" phase. The Auditor performs structured reasoning exclusively over:
the committed PromptSpec (semantic contract), and
the verified evidence set produced by the Collector.
Reasoning traces are constrained to reference only admissible evidence and must adhere to the logical rules defined by the semantic specification. This prevents out-of-scope inference, hallucinated inputs, or post-hoc reinterpretation.
Technology: DSPy-Optimized Chain-of-Thought.
Mechanism: The Auditor generates a Merkle-ized Reasoning Trace — a cryptographic tree structure of the step-by-step log (e.g., Search -> Verify -> Deduce). Only the Reasoning Merkle Root is anchored on-chain, allowing for granular, gas-efficient auditing where specific logical fallacies can be proven via a simple Merkle Branch.
Tokenomics: The Auditor stakes $COUR on the Logical Coherence. If the reasoning contains fallacies (e.g., concluding "Yes" despite contradictory evidence in the trace), they are penalized.
Stage 3: Proof of Determinism (The Judge Role)
SOP Action: The Judge Agent is responsible for the "Output" phase. The Judge maps the reasoning outcome deterministically to the final verdict schema defined in the PromptSpec. The verdict space is closed and predefined, ensuring that resolution outputs are predictable, bounded, and machine-verifiable.
Technology: Neuro-Symbolic Constraints (Outlines/Logit Locking).
Mechanism: The Judge enforces strict schema compliance (e.g., mapping the conclusion to
Enum: {YES, NO, INVALID}). It filters out ambiguity to ensure the smart contract can execute settlement without error.Tokenomics: The Judge stakes network token on Schema Compliance, ensuring the final payload is machine-readable.
Last updated

