{
  "schema_version": "1.3",
  "url": "https://trustbutveri.fyi/explorer/?mechanisms=M-0007,M-0002&ready=R2",
  "data_generated": "2026-10-09",
  "definitions": {
    "methodology": "https://trustbutveri.fyi/about/methodology/",
    "readiness": "https://trustbutveri.fyi/about/readiness/",
    "filters": [
      {
        "id": "prover",
        "label": "Prover",
        "question": "How far can the party being checked be trusted?",
        "options": [
          {
            "value": "cooperative",
            "label": "Cooperative"
          },
          {
            "value": "semi-trusted",
            "label": "Semi-trusted"
          },
          {
            "value": "adversarial",
            "label": "Adversarial"
          }
        ],
        "rule": "Keeps mechanisms whose threat model holds against at least this prover. Adversarial is the strongest assumption.",
        "about": "The prover is the party being checked. Semi-trusted designs rely on part of its stack: usually the chip vendor's hardware root of trust, its firmware or counters, or its supply-chain records. Adversarial designs aim to hold even if it cheats wherever the checks allow, within their stated assumptions."
      },
      {
        "id": "onsite",
        "label": "Verifier devices on site",
        "question": "May the verifier install its own hardware at the prover's sites?",
        "options": [
          {
            "value": "no",
            "label": "Not allowed"
          }
        ],
        "rule": "\"Not allowed\" removes mechanisms that need a retrofit device, such as a network tap or a sealed sensor.",
        "about": "Some mechanisms need a device the verifier owns or trusts at the prover's facility, such as a network tap, a bandwidth limiter or a sealed sensor. Choose Not allowed when the setting rules that out. Inspectors are not covered."
      },
      {
        "id": "coop",
        "label": "Prover cooperation",
        "question": "How much must the prover take part?",
        "options": [
          {
            "value": "partial",
            "label": "Partial at most"
          },
          {
            "value": "none",
            "label": "Not required"
          }
        ],
        "rule": "\"Partial at most\" removes mechanisms that need the prover's active participation. \"Not required\" keeps only those that work without it.",
        "about": "Required: the prover takes part, for example by logging requests, producing proofs or opening records. Partial: some access, such as installing a device. Not required: works from outside, such as satellite imagery."
      },
      {
        "id": "chips",
        "label": "Chips",
        "question": "May the proposal depend on new chip designs?",
        "options": [
          {
            "value": "existing",
            "label": "Existing chips only"
          }
        ],
        "rule": "\"Existing chips only\" removes mechanisms that need changes to future chip designs.",
        "about": "New chip features take years to reach a deployed fleet and cover only chips made after they ship. Mechanisms that use shipping features, such as trusted execution environments or performance counters, stay."
      },
      {
        "id": "ready",
        "label": "Minimum development status",
        "question": "Development status",
        "options": [
          {
            "value": "R1",
            "label": "Proposed"
          },
          {
            "value": "R2",
            "label": "Research demonstration"
          },
          {
            "value": "R3",
            "label": "Operational use"
          },
          {
            "value": "R4",
            "label": "Legacy independent-evaluation filter",
            "legacy": true
          }
        ],
        "rule": "Keeps mechanisms whose readiness level is at least this one.",
        "about": "A level describes the public evidence for a mechanism's stated use, not its cost or feasibility. R3 can still have open critical flaws."
      },
      {
        "id": "tested",
        "label": "Attack testing",
        "question": "How hard has each mechanism been attacked in public?",
        "options": [
          {
            "value": "analysis",
            "label": "Published analysis"
          },
          {
            "value": "red-teamed",
            "label": "Red-teamed"
          },
          {
            "value": "independent-red-team",
            "label": "Independent red-team"
          }
        ],
        "rule": "Keeps mechanisms whose strongest published attack testing is at least this.",
        "about": "The strongest published attempt to break the mechanism for its verification use: a security analysis, red-teaming by its developers or collaborators, or a red team independent of them."
      },
      {
        "id": "hide",
        "label": "Keep hidden from the verifier",
        "question": "What must the verifier never see?",
        "options": [
          {
            "value": "weights",
            "label": "Model weights"
          },
          {
            "value": "io",
            "label": "Inputs and outputs"
          },
          {
            "value": "training",
            "label": "Training data"
          }
        ],
        "rule": "Removes mechanisms that show the asset to the verifier. Conditional or unspecified exposure stays with a note and needs checking against the privacy requirement.",
        "about": "Model weights: the checked model's parameters. Inputs and outputs: the requests a deployed model serves and its responses. Training data: what a model was trained on. Each mechanism's exposure is the editors' reading of its record: shown, depends on the design (kept, with a note), hidden, not involved, or unspecified for a selected implementation. Code and configuration are not covered yet."
      }
    ],
    "exposure": "For model weights, inputs and outputs, and training data. This is the editors' reading of each mechanism's record (its threat model, how it works and its limitations), not a field of the record. Shown: the verifier sees it. Depends: on the design or variant, or the verifier sees only samples. Hidden: the verifier sees only commitments, hashes, proofs or results. Not involved: the record does not handle it. Unspecified: the selected implementation has no asset-specific assessment here.",
    "claim_status": {
      "addressed": "A mechanism in the proposal is aimed at this claim and is not excluded by the filters.",
      "partly-addressed": "Only supporting mechanisms, or mechanisms aimed at it that the filters exclude.",
      "unaddressed": "No mechanism in the proposal addresses this claim."
    },
    "finding_classification": {
      "failure": {
        "label": "Known failures",
        "singular": "Known failure",
        "anchor": "known-flaws"
      },
      "scope-limitation": {
        "label": "Scope limitations",
        "singular": "Scope limitation",
        "anchor": "scope-limitations"
      },
      "open-question": {
        "label": "Open questions",
        "singular": "Open question",
        "anchor": "open-questions"
      }
    },
    "finding_scope": "Evidence scope describes where a finding was demonstrated; it does not establish applicability to every implementation in the mechanism family.",
    "claim_finding_scope": "open_critical_findings names active failures on the assessed records; open_critical_context names conditional family failures whose implementation applicability is unassessed.",
    "legacy_status": "The status field retains covered/partial/none for compatibility. It names claim links, never successful verification. Use claim_status and status_label for presentation."
  },
  "filters": {
    "prover": "",
    "onsite": "",
    "coop": "",
    "chips": "",
    "ready": "R2",
    "tested": "",
    "hide": []
  },
  "mechanisms_passing_filters": 15,
  "claims": [],
  "mechanisms": [
    {
      "id": "M-0007",
      "title": "Proofs of useful work for capacity accounting",
      "url": "https://trustbutveri.fyi/mechanisms/proofs-of-useful-work/",
      "assessment_record": {
        "id": "M-0007",
        "title": "Proofs of useful work for capacity accounting",
        "url": "https://trustbutveri.fyi/mechanisms/proofs-of-useful-work/"
      },
      "finding_counts": {
        "failure": 1,
        "scope_limitation": 1,
        "open_question": 1,
        "open_failures": {
          "critical": 0,
          "significant": 1,
          "minor": 0
        }
      },
      "selected_implementation": null,
      "readiness": {
        "level": "R1",
        "scope": "bounding the spare capacity of declared hardware that could run training",
        "confidence": "low",
        "evidence": [
          "S-1102",
          "S-0005",
          "S-1609",
          "S-1105",
          "S-1107"
        ]
      },
      "development_status": {
        "code": "R1",
        "label": "Proposed",
        "short": "Proposed",
        "rank": 1,
        "legacy_code": "R1"
      },
      "security_evidence": {
        "attack_testing": {
          "status": "analysis",
          "label": "Published security analysis",
          "kind": "analysis"
        },
        "independent_evaluation": {
          "status": "unassessed"
        },
        "formal_proof": {
          "status": "unassessed"
        },
        "deployment_assurance": {
          "status": "unassessed"
        },
        "legacy_evaluation_code": null,
        "scoped_findings": [
          {
            "n": 3,
            "severity": "significant",
            "status": "open",
            "evidence_scope": "unassessed",
            "sources": [
              "S-1105"
            ]
          }
        ],
        "open_failures": {
          "critical": 0,
          "significant": 1,
          "minor": 0
        }
      },
      "assessed_properties": {
        "threat_model": "adversarial",
        "hardware_requirement": "none",
        "prover_cooperation": "required",
        "adversarial_evaluation": "analysis"
      },
      "claims": [],
      "exposure": {
        "weights": "partial",
        "io": "partial",
        "training": "none",
        "note": "Checking a sampled tile of a matrix multiplication reveals that tile, which may hold model or input data; the authors suggest a zero-knowledge proof when the matrices must stay private."
      },
      "family_finding_context": [],
      "filter_issues": [
        {
          "filter": "ready",
          "level": "exclude",
          "short": "development: Proposed",
          "text": "Development status: Proposed. Minimum: Research demonstration."
        }
      ]
    },
    {
      "id": "M-0002",
      "title": "Deterministic and bit-exact inference",
      "url": "https://trustbutveri.fyi/mechanisms/deterministic-inference/",
      "assessment_record": {
        "id": "M-0002",
        "title": "Deterministic and bit-exact inference",
        "url": "https://trustbutveri.fyi/mechanisms/deterministic-inference/"
      },
      "finding_counts": {
        "failure": 0,
        "scope_limitation": 2,
        "open_question": 0,
        "open_failures": {
          "critical": 0,
          "significant": 0,
          "minor": 0
        }
      },
      "selected_implementation": null,
      "readiness": {
        "level": "R3",
        "scope": "reproducing open-model inference from receipts in Gensyn's information-market service",
        "confidence": "low",
        "evidence": [
          "S-0020",
          "S-1009",
          "S-1010",
          "S-1012",
          "S-1013",
          "S-1812",
          "S-3021",
          "S-3022",
          "S-3023",
          "S-0075"
        ]
      },
      "development_status": {
        "code": "R3",
        "label": "Operational use",
        "short": "Operational use",
        "rank": 3,
        "legacy_code": "R3"
      },
      "security_evidence": {
        "attack_testing": {
          "status": "analysis",
          "label": "Published security analysis",
          "kind": "analysis"
        },
        "independent_evaluation": {
          "status": "unassessed"
        },
        "formal_proof": {
          "status": "unassessed"
        },
        "deployment_assurance": {
          "status": "unassessed"
        },
        "legacy_evaluation_code": null,
        "scoped_findings": [],
        "open_failures": {
          "critical": 0,
          "significant": 0,
          "minor": 0
        }
      },
      "assessed_properties": {
        "threat_model": "adversarial",
        "hardware_requirement": "none",
        "prover_cooperation": "required",
        "adversarial_evaluation": "analysis"
      },
      "claims": [],
      "exposure": {
        "weights": "partial",
        "io": "partial",
        "training": "none",
        "note": "Exact replay needs the weights, configuration and replayed requests inside the recomputation environment. What the verifier sees depends on whether that environment keeps them confidential.",
        "sources": [
          "S-0018",
          "S-0020"
        ]
      },
      "family_finding_context": [],
      "filter_issues": []
    }
  ],
  "strengths": {
    "covered": [],
    "production": [
      "M-0002"
    ],
    "operationalUse": [
      "M-0002"
    ],
    "adversarial": [
      "M-0002"
    ],
    "noNewHardware": [
      "M-0002"
    ],
    "mitigated": [],
    "notCounted": [
      "M-0007"
    ]
  },
  "properties": {
    "covered": [],
    "production": [
      "M-0002"
    ],
    "operationalUse": [
      "M-0002"
    ],
    "adversarial": [
      "M-0002"
    ],
    "noNewHardware": [
      "M-0002"
    ],
    "mitigated": [],
    "notCounted": [
      "M-0007"
    ]
  },
  "attack_testing": [
    {
      "id": "M-0007",
      "record": "M-0007",
      "evaluation": "analysis",
      "in_setting": false
    },
    {
      "id": "M-0002",
      "record": "M-0002",
      "evaluation": "analysis",
      "in_setting": true
    }
  ],
  "selected_implementations": {},
  "weaknesses": {
    "gaps": [],
    "excluded": [
      {
        "id": "M-0007",
        "issues": [
          {
            "filter": "ready",
            "level": "exclude",
            "short": "development: Proposed",
            "text": "Development status: Proposed. Minimum: Research demonstration."
          }
        ]
      }
    ],
    "unlinked": [],
    "critical": [],
    "significant": [
      {
        "mech": "M-0007",
        "n": 3,
        "historical": false,
        "title": "Known shortcuts let a miner claim somewhat more work than it did",
        "classification": "failure",
        "kind": "theoretical-argument",
        "severity": "significant",
        "status": "open",
        "evidence_scope": null,
        "scope_note": null,
        "related_finding": null,
        "description": "Pearl's specification lists known mining speedups: crafted inputs, precision shortcuts, seed grinding, work reuse, and faster kernels or hardware. A policy check caps the summands a miner may skip at one-sixteenth of those in a tile. For capacity bounding, any gap between work proven and work possible leaves spare capacity.",
        "response": null,
        "sources": [
          "S-1105"
        ]
      }
    ],
    "criticalMechanisms": [],
    "significantMechanisms": [
      "M-0007"
    ],
    "familyContext": [],
    "scopeLimitations": [
      {
        "mech": "M-0007",
        "n": 1,
        "historical": false,
        "title": "Proves that work was done, not that no capacity remains",
        "classification": "scope-limitation",
        "kind": "theoretical-argument",
        "severity": "significant",
        "status": "open",
        "evidence_scope": null,
        "scope_note": null,
        "related_finding": null,
        "description": "Proof-of-work accounting bounds unmonitored compute only relative to an estimate of what the actor has. Attestable states that the verifier \"needs a credible estimate of the compute available\" to the actor, and that a proof \"cannot discover a datacenter that was never declared\".",
        "response": null,
        "sources": [
          "S-1102"
        ],
        "helps": [
          {
            "by": "M-0019",
            "how": "A registry of chips is one basis for the estimate of available compute that the flaw's source says the verifier needs."
          },
          {
            "by": "M-0020",
            "how": "Looks for data centres that were never declared, which a proof cannot discover."
          }
        ]
      },
      {
        "mech": "M-0002",
        "n": 1,
        "historical": false,
        "title": "Some kernels remain genuinely nondeterministic",
        "classification": "scope-limitation",
        "kind": "open-question",
        "severity": "minor",
        "status": "open",
        "evidence_scope": null,
        "scope_note": null,
        "related_finding": null,
        "description": "The bit-exact work separates kernels that are deterministic but not batch-invariant from truly nondeterministic ones that use atomic functions. Some integer de-quantization kernels use atomic additions and remain nondeterministic, so exact replay needs backends that avoid them.",
        "response": null,
        "sources": [
          "S-0020"
        ]
      },
      {
        "mech": "M-0002",
        "n": 2,
        "historical": false,
        "title": "Cross-hardware replay relies on reverse-engineered, closed behaviour",
        "classification": "scope-limitation",
        "kind": "open-question",
        "severity": "significant",
        "status": "open",
        "evidence_scope": null,
        "scope_note": null,
        "related_finding": null,
        "description": "Emulating one GPU's rounding on another requires reverse-engineering tensor-core arithmetic and modelling proprietary kernel choices. Hawkeye covers a subset of NVIDIA architectures and states that attention and other higher-level operations need further reverse engineering. For the bit-exact emulator, a proprietary Hopper kernel family is an open edge case.",
        "response": null,
        "sources": [
          "S-1010",
          "S-0020"
        ]
      }
    ],
    "openQuestions": [
      {
        "mech": "M-0007",
        "n": 2,
        "historical": false,
        "title": "Security rests on new hardness assumptions",
        "classification": "open-question",
        "kind": "open-question",
        "severity": "significant",
        "status": "open",
        "evidence_scope": null,
        "scope_note": null,
        "related_finding": null,
        "description": "Komargodski and Weinstein base security on hardness assumptions about batches of low-rank random linear equations, and list PoUW \"from more standard or well-studied assumptions\" as an open problem. Pearl's floating-point variant introduces a further \"quantized-subspace hardness\" assumption.",
        "response": null,
        "sources": [
          "S-1609",
          "S-1105"
        ]
      }
    ],
    "minor": 0,
    "minorFindings": [],
    "minorBy": [],
    "notDemonstrated": [
      "M-0007"
    ],
    "newChip": []
  },
  "findings": [
    {
      "mech": "M-0007",
      "record": "M-0007",
      "n": 1,
      "historical": false,
      "title": "Proves that work was done, not that no capacity remains",
      "classification": "scope-limitation",
      "kind": "theoretical-argument",
      "severity": "significant",
      "status": "open",
      "evidence_scope": null,
      "scope_note": null,
      "related_finding": null,
      "description": "Proof-of-work accounting bounds unmonitored compute only relative to an estimate of what the actor has. Attestable states that the verifier \"needs a credible estimate of the compute available\" to the actor, and that a proof \"cannot discover a datacenter that was never declared\".",
      "response": null,
      "sources": [
        "S-1102"
      ],
      "helps": [
        {
          "by": "M-0019",
          "how": "A registry of chips is one basis for the estimate of available compute that the flaw's source says the verifier needs."
        },
        {
          "by": "M-0020",
          "how": "Looks for data centres that were never declared, which a proof cannot discover."
        }
      ]
    },
    {
      "mech": "M-0007",
      "record": "M-0007",
      "n": 2,
      "historical": false,
      "title": "Security rests on new hardness assumptions",
      "classification": "open-question",
      "kind": "open-question",
      "severity": "significant",
      "status": "open",
      "evidence_scope": null,
      "scope_note": null,
      "related_finding": null,
      "description": "Komargodski and Weinstein base security on hardness assumptions about batches of low-rank random linear equations, and list PoUW \"from more standard or well-studied assumptions\" as an open problem. Pearl's floating-point variant introduces a further \"quantized-subspace hardness\" assumption.",
      "response": null,
      "sources": [
        "S-1609",
        "S-1105"
      ]
    },
    {
      "mech": "M-0007",
      "record": "M-0007",
      "n": 3,
      "historical": false,
      "title": "Known shortcuts let a miner claim somewhat more work than it did",
      "classification": "failure",
      "kind": "theoretical-argument",
      "severity": "significant",
      "status": "open",
      "evidence_scope": null,
      "scope_note": null,
      "related_finding": null,
      "description": "Pearl's specification lists known mining speedups: crafted inputs, precision shortcuts, seed grinding, work reuse, and faster kernels or hardware. A policy check caps the summands a miner may skip at one-sixteenth of those in a tile. For capacity bounding, any gap between work proven and work possible leaves spare capacity.",
      "response": null,
      "sources": [
        "S-1105"
      ]
    },
    {
      "mech": "M-0002",
      "record": "M-0002",
      "n": 1,
      "historical": false,
      "title": "Some kernels remain genuinely nondeterministic",
      "classification": "scope-limitation",
      "kind": "open-question",
      "severity": "minor",
      "status": "open",
      "evidence_scope": null,
      "scope_note": null,
      "related_finding": null,
      "description": "The bit-exact work separates kernels that are deterministic but not batch-invariant from truly nondeterministic ones that use atomic functions. Some integer de-quantization kernels use atomic additions and remain nondeterministic, so exact replay needs backends that avoid them.",
      "response": null,
      "sources": [
        "S-0020"
      ]
    },
    {
      "mech": "M-0002",
      "record": "M-0002",
      "n": 2,
      "historical": false,
      "title": "Cross-hardware replay relies on reverse-engineered, closed behaviour",
      "classification": "scope-limitation",
      "kind": "open-question",
      "severity": "significant",
      "status": "open",
      "evidence_scope": null,
      "scope_note": null,
      "related_finding": null,
      "description": "Emulating one GPU's rounding on another requires reverse-engineering tensor-core arithmetic and modelling proprietary kernel choices. Hawkeye covers a subset of NVIDIA architectures and states that attention and other higher-level operations need further reverse engineering. For the bit-exact emulator, a proprietary Hopper kernel family is an open edge case.",
      "response": null,
      "sources": [
        "S-1010",
        "S-0020"
      ]
    }
  ],
  "possible_additions": [],
  "goal": null,
  "design": null,
  "dependencies": {
    "prerequisites": [],
    "shared": [],
    "blockers": [
      {
        "mech": "M-0007",
        "n": 1,
        "historical": false,
        "text": "Bounding spare capacity needs a credible estimate of the compute available to the actor, including third-party access.",
        "theme": "capacity-bounds",
        "blocked_by": null,
        "sources": [
          "S-1102"
        ],
        "inProposal": null
      },
      {
        "mech": "M-0007",
        "n": 2,
        "historical": false,
        "text": "Proofs of work cannot find facilities that were never declared.",
        "theme": "coverage-hidden-compute",
        "blocked_by": null,
        "sources": [
          "S-1102"
        ],
        "inProposal": null
      },
      {
        "mech": "M-0007",
        "n": 3,
        "historical": false,
        "text": "As of September 2026 no implementation, demonstration or independent evaluation of proofs of work for capacity bounding has been published.",
        "theme": "adversarial-validation",
        "blocked_by": null,
        "sources": [],
        "inProposal": null
      },
      {
        "mech": "M-0002",
        "n": 1,
        "historical": false,
        "text": "Batch-invariant kernels cost throughput: in Thinking Machines' Qwen3-8B test, an improved deterministic build took 42 s against 26 s for vLLM's default, and SGLang reports an average 34.35% slowdown on its FlashInfer and FlashAttention 3 backends.",
        "theme": "performance-compatibility",
        "blocked_by": null,
        "sources": [
          "S-1009",
          "S-1012"
        ],
        "inProposal": null
      },
      {
        "mech": "M-0002",
        "n": 2,
        "historical": false,
        "text": "Coverage is incomplete: the bit-exact emulator targets dense blocks on NVIDIA GPUs and excludes mixture-of-experts inference and training, and vLLM's batch-invariant mode is in beta, with open work on AMD hardware and speculative decoding.",
        "theme": "performance-compatibility",
        "blocked_by": null,
        "sources": [
          "S-0020",
          "S-1013",
          "S-1814"
        ],
        "inProposal": null
      },
      {
        "mech": "M-0002",
        "n": 3,
        "historical": false,
        "text": "Amodo's status page for the AI 2040 verification plan rates a reproducible inference stack for that plan as 'not started'.",
        "theme": "performance-compatibility",
        "blocked_by": null,
        "sources": [
          "S-1008"
        ],
        "inProposal": null
      },
      {
        "mech": "M-0002",
        "n": 4,
        "historical": false,
        "text": "Exact replay requires the prover to disclose weights, software versions, parallelism and batch sizes to whoever recomputes.",
        "theme": "privacy-leakage",
        "blocked_by": null,
        "sources": [
          "S-0020",
          "S-0018"
        ],
        "inProposal": null
      }
    ]
  },
  "exposure": {
    "weights": {
      "shown": [],
      "partial": [
        "M-0007",
        "M-0002"
      ],
      "hidden": [],
      "none": [],
      "unknown": []
    },
    "io": {
      "shown": [],
      "partial": [
        "M-0007",
        "M-0002"
      ],
      "hidden": [],
      "none": [],
      "unknown": []
    },
    "training": {
      "shown": [],
      "partial": [],
      "hidden": [],
      "none": [
        "M-0007",
        "M-0002"
      ],
      "unknown": []
    }
  },
  "implementations": [
    {
      "mechanism": "M-0007",
      "selected": null,
      "implementations": [
        {
          "id": "I-0004",
          "title": "Pearl proof-of-useful-work blockchain",
          "url": "https://trustbutveri.fyi/implementations/pearl-proof-of-useful-work/"
        }
      ]
    },
    {
      "mechanism": "M-0002",
      "selected": null,
      "implementations": [
        {
          "id": "I-0016",
          "title": "Batch-invariant inference kernels (Thinking Machines)",
          "url": "https://trustbutveri.fyi/implementations/batch-invariant-inference-kernels/"
        },
        {
          "id": "I-0015",
          "title": "Verde and RepOps (Gensyn)",
          "url": "https://trustbutveri.fyi/implementations/gensyn-verde-repops/"
        },
        {
          "id": "I-0012",
          "title": "Low-trust AI compute verification system overview",
          "url": "https://trustbutveri.fyi/implementations/low-trust-compute-verification-system-overview/"
        }
      ]
    }
  ],
  "sources": [
    {
      "id": "S-1102",
      "title": "Pacing AI Requires Proof",
      "authors": "Attestable",
      "year": 2026,
      "url": "https://attestable.com/blog/pacing-ai-requires-proof",
      "path": "/sources/attestable-pacing-ai-requires-proof/"
    },
    {
      "id": "S-0005",
      "title": "Mechanisms to Verify International Agreements About AI Development",
      "authors": "A. Scher & L. Thiergart",
      "year": 2025,
      "url": "https://arxiv.org/abs/2506.15867",
      "path": "/sources/scher-mechanisms-verify-ai-agreements/"
    },
    {
      "id": "S-1609",
      "title": "Proofs of Useful Work from Arbitrary Matrix Multiplication",
      "authors": "I. Komargodski & O. Weinstein",
      "year": 2025,
      "url": "https://arxiv.org/abs/2504.09971",
      "path": "/sources/komargodski-proofs-useful-work-matrix-multiplication/"
    },
    {
      "id": "S-1105",
      "title": "Pearl Floating Point Scheme Specification",
      "authors": "Pearl Research Team",
      "year": 2026,
      "url": "https://pearlresearch.ai/Pearl_Whitepaper.pdf",
      "path": "/sources/pearl-floating-point-scheme-specification/"
    },
    {
      "id": "S-1107",
      "title": "pearl: Monorepo for the Pearl network",
      "authors": "Pearl Research Labs",
      "year": 2026,
      "url": "https://github.com/pearl-research-labs/pearl",
      "path": "/sources/pearl-network-monorepo/"
    },
    {
      "id": "S-0020",
      "title": "Bit-Exact AI Inference Verification Without Performance Tradeoffs",
      "authors": "N. Cankaya",
      "year": 2026,
      "url": "https://arxiv.org/abs/2606.00279",
      "path": "/sources/cankaya-bit-exact-inference-verification/"
    },
    {
      "id": "S-1009",
      "title": "Defeating Nondeterminism in LLM Inference",
      "authors": "H. He & Thinking Machines Lab",
      "year": 2025,
      "url": "https://thinkingmachines.ai/blog/defeating-nondeterminism-in-llm-inference/",
      "path": "/sources/he-defeating-nondeterminism-llm-inference/"
    },
    {
      "id": "S-1010",
      "title": "Hawkeye: Reproducing GPU-Level Non-Determinism",
      "authors": "E. Badash et al.",
      "year": 2026,
      "url": "https://proceedings.mlsys.org/paper_files/paper/2026/hash/e217c271a57c365a246b0ad39e668ba8-Abstract-Conference.html",
      "path": "/sources/badash-hawkeye/"
    },
    {
      "id": "S-1012",
      "title": "Towards Deterministic Inference in SGLang and Reproducible RL Training",
      "authors": "The SGLang Team",
      "year": 2025,
      "url": "https://www.lmsys.org/blog/2025-09-22-sglang-deterministic/",
      "path": "/sources/sglang-deterministic-inference/"
    },
    {
      "id": "S-1013",
      "title": "Batch Invariance (vLLM documentation)",
      "authors": "vLLM project",
      "year": 2026,
      "url": "https://github.com/vllm-project/vllm/blob/main/docs/features/batch_invariance.md",
      "path": "/sources/vllm-batch-invariance-docs/"
    },
    {
      "id": "S-1812",
      "title": "gensyn-ai/ree: Gensyn Reproducible Execution Environment (GitHub repository)",
      "authors": "Gensyn",
      "year": 2026,
      "url": "https://github.com/gensyn-ai/ree",
      "path": "/sources/gensyn-ree-code/"
    },
    {
      "id": "S-3021",
      "title": "EigenCloud Brings Verifiable AI to Mass Market with EigenAI and EigenCompute Launches",
      "authors": "EigenCloud",
      "year": 2025,
      "url": "https://www.eigenlabs.org/blog/eigencloud-brings-verifiable-ai-to-mass-market-with-eigenai-and-eigencompute-launches/",
      "path": "/sources/eigencloud-eigenai-launch/"
    },
    {
      "id": "S-3022",
      "title": "Building Delphi: Pricing, Settlement, and Agentic Trading",
      "authors": "D. Jedamski",
      "year": 2026,
      "url": "https://www.gensyn.ai/blog/building-delphi-pricing-settlement-and-agentic-trading",
      "path": "/sources/gensyn-building-delphi/"
    },
    {
      "id": "S-3023",
      "title": "Reproducible Execution Environment (REE) (Gensyn documentation)",
      "authors": "Gensyn",
      "year": 2026,
      "url": "https://docs.gensyn.ai/tech",
      "path": "/sources/gensyn-ree-docs/"
    },
    {
      "id": "S-0075",
      "title": "What is Delphi? (Delphi documentation)",
      "authors": "Gensyn",
      "year": 2026,
      "url": "https://docs.delphi.fyi/",
      "path": "/sources/gensyn-delphi-documentation/"
    },
    {
      "id": "S-0018",
      "title": "A System Overview for Near-Term, Low-Trust AI Compute Verification",
      "authors": "N. Cankaya",
      "year": 2026,
      "url": "https://intelligence.org/wp-content/uploads/2026/06/A-system-overview-for-near-term-low-trust-AI-compute-verification.pdf",
      "path": "/sources/cankaya-system-overview-low-trust-compute-verification/"
    },
    {
      "id": "S-1814",
      "title": "[Feature]: Batch Invariant Feature and Performance Optimization (vLLM issue #27433)",
      "authors": "vLLM project contributors",
      "year": 2025,
      "url": "https://github.com/vllm-project/vllm/issues/27433",
      "path": "/sources/vllm-batch-invariance-tracking-issue/"
    },
    {
      "id": "S-1008",
      "title": "AI 2040 Plan A — Verification SITREP",
      "authors": "Amodo Design",
      "year": 2026,
      "url": "https://amododesign.com/ai-verification/plan-a-sitrep/",
      "path": "/sources/amodo-plan-a-verification-sitrep/"
    }
  ]
}