{
  "schema_version": "1.3",
  "url": "https://trustbutveri.fyi/explorer/?mechanisms=M-0007,M-0022&tested=red-teamed",
  "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": "",
    "tested": "red-teamed",
    "hide": []
  },
  "mechanisms_passing_filters": 7,
  "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": "tested",
          "level": "exclude",
          "short": "attack testing: analysis",
          "text": "Attack testing is analysis; the filter asks for at least red-teamed."
        }
      ]
    },
    {
      "id": "M-0022",
      "title": "Side-channel suppression for isolated facilities",
      "url": "https://trustbutveri.fyi/mechanisms/side-channel-suppression/",
      "assessment_record": {
        "id": "M-0022",
        "title": "Side-channel suppression for isolated facilities",
        "url": "https://trustbutveri.fyi/mechanisms/side-channel-suppression/"
      },
      "finding_counts": {
        "failure": 0,
        "scope_limitation": 1,
        "open_question": 2,
        "open_failures": {
          "critical": 0,
          "significant": 0,
          "minor": 0
        }
      },
      "selected_implementation": null,
      "readiness": {
        "level": "R1",
        "scope": "bounding physical covert channels out of a verified enclosure",
        "confidence": "medium",
        "evidence": [
          "S-0038"
        ]
      },
      "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": [],
        "open_failures": {
          "critical": 0,
          "significant": 0,
          "minor": 0
        }
      },
      "assessed_properties": {
        "threat_model": "adversarial",
        "hardware_requirement": "retrofit-device",
        "prover_cooperation": "partial",
        "adversarial_evaluation": "analysis"
      },
      "claims": [],
      "exposure": {
        "weights": "none",
        "io": "none",
        "training": "none",
        "note": "Shields and filters a facility; it does not handle model data."
      },
      "family_finding_context": [],
      "filter_issues": [
        {
          "filter": "tested",
          "level": "exclude",
          "short": "attack testing: analysis",
          "text": "Attack testing is analysis; the filter asks for at least red-teamed."
        }
      ]
    }
  ],
  "strengths": {
    "covered": [],
    "production": [],
    "operationalUse": [],
    "adversarial": [],
    "noNewHardware": [],
    "mitigated": [],
    "notCounted": [
      "M-0007",
      "M-0022"
    ]
  },
  "properties": {
    "covered": [],
    "production": [],
    "operationalUse": [],
    "adversarial": [],
    "noNewHardware": [],
    "mitigated": [],
    "notCounted": [
      "M-0007",
      "M-0022"
    ]
  },
  "attack_testing": [
    {
      "id": "M-0007",
      "record": "M-0007",
      "evaluation": "analysis",
      "in_setting": false
    },
    {
      "id": "M-0022",
      "record": "M-0022",
      "evaluation": "analysis",
      "in_setting": false
    }
  ],
  "selected_implementations": {},
  "weaknesses": {
    "gaps": [],
    "excluded": [
      {
        "id": "M-0007",
        "issues": [
          {
            "filter": "tested",
            "level": "exclude",
            "short": "attack testing: analysis",
            "text": "Attack testing is analysis; the filter asks for at least red-teamed."
          }
        ]
      },
      {
        "id": "M-0022",
        "issues": [
          {
            "filter": "tested",
            "level": "exclude",
            "short": "attack testing: analysis",
            "text": "Attack testing is analysis; the filter asks for at least red-teamed."
          }
        ]
      }
    ],
    "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-0022",
        "n": 2,
        "historical": false,
        "title": "Openings for airflow, power and optics weaken shielding",
        "classification": "scope-limitation",
        "kind": "theoretical-argument",
        "severity": "significant",
        "status": "open",
        "evidence_scope": null,
        "scope_note": null,
        "related_finding": null,
        "description": "Cankaya notes that keeping attenuation high while passing high-power airflow, cabling and optical links adds complexity beyond existing shielded-enclosure specifications.",
        "response": null,
        "sources": [
          "S-0038"
        ]
      }
    ],
    "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"
        ]
      },
      {
        "mech": "M-0022",
        "n": 1,
        "historical": false,
        "title": "Supply-chain implants may evade inspection",
        "classification": "open-question",
        "kind": "theoretical-argument",
        "severity": "significant",
        "status": "open",
        "evidence_scope": null,
        "scope_note": null,
        "related_finding": null,
        "description": "Cankaya identifies malicious hardware embedded deep in purchased components as a residual risk that visual inspection and disassembly may not catch. He notes that radiographic examination under high-security standards could mitigate it.",
        "response": null,
        "sources": [
          "S-0038"
        ]
      },
      {
        "mech": "M-0022",
        "n": 3,
        "historical": false,
        "title": "Inspection assumptions may not hold",
        "classification": "open-question",
        "kind": "open-question",
        "severity": "significant",
        "status": "open",
        "evidence_scope": null,
        "scope_note": null,
        "related_finding": null,
        "description": "The design's statistical argument assumes that visual or disassembly inspection catches every flaw that is present in a sampled unit. Cankaya is unsure whether destructive teardowns are defence-dominant or offence-dominant.",
        "response": null,
        "sources": [
          "S-0038"
        ]
      }
    ],
    "minor": 0,
    "minorFindings": [],
    "minorBy": [],
    "notDemonstrated": [
      "M-0007",
      "M-0022"
    ],
    "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-0022",
      "record": "M-0022",
      "n": 1,
      "historical": false,
      "title": "Supply-chain implants may evade inspection",
      "classification": "open-question",
      "kind": "theoretical-argument",
      "severity": "significant",
      "status": "open",
      "evidence_scope": null,
      "scope_note": null,
      "related_finding": null,
      "description": "Cankaya identifies malicious hardware embedded deep in purchased components as a residual risk that visual inspection and disassembly may not catch. He notes that radiographic examination under high-security standards could mitigate it.",
      "response": null,
      "sources": [
        "S-0038"
      ]
    },
    {
      "mech": "M-0022",
      "record": "M-0022",
      "n": 2,
      "historical": false,
      "title": "Openings for airflow, power and optics weaken shielding",
      "classification": "scope-limitation",
      "kind": "theoretical-argument",
      "severity": "significant",
      "status": "open",
      "evidence_scope": null,
      "scope_note": null,
      "related_finding": null,
      "description": "Cankaya notes that keeping attenuation high while passing high-power airflow, cabling and optical links adds complexity beyond existing shielded-enclosure specifications.",
      "response": null,
      "sources": [
        "S-0038"
      ]
    },
    {
      "mech": "M-0022",
      "record": "M-0022",
      "n": 3,
      "historical": false,
      "title": "Inspection assumptions may not hold",
      "classification": "open-question",
      "kind": "open-question",
      "severity": "significant",
      "status": "open",
      "evidence_scope": null,
      "scope_note": null,
      "related_finding": null,
      "description": "The design's statistical argument assumes that visual or disassembly inspection catches every flaw that is present in a sampled unit. Cankaya is unsure whether destructive teardowns are defence-dominant or offence-dominant.",
      "response": null,
      "sources": [
        "S-0038"
      ]
    }
  ],
  "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-0022",
        "n": 1,
        "historical": false,
        "text": "No prototype or red-team exists; the design is a first-pass viability study.",
        "theme": "adversarial-validation",
        "blocked_by": null,
        "sources": [
          "S-0038"
        ],
        "inProposal": null
      },
      {
        "mech": "M-0022",
        "n": 2,
        "historical": false,
        "text": "Volume costs of TEMPEST-grade power-line filters are uncertain, because existing products are mostly made to order.",
        "theme": "performance-compatibility",
        "blocked_by": null,
        "sources": [
          "S-0038"
        ],
        "inProposal": null
      }
    ]
  },
  "exposure": {
    "weights": {
      "shown": [],
      "partial": [
        "M-0007"
      ],
      "hidden": [],
      "none": [
        "M-0022"
      ],
      "unknown": []
    },
    "io": {
      "shown": [],
      "partial": [
        "M-0007"
      ],
      "hidden": [],
      "none": [
        "M-0022"
      ],
      "unknown": []
    },
    "training": {
      "shown": [],
      "partial": [],
      "hidden": [],
      "none": [
        "M-0007",
        "M-0022"
      ],
      "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-0022",
      "selected": null,
      "implementations": [
        {
          "id": "I-0011",
          "title": "AI 2040 inference-only verification stack",
          "url": "https://trustbutveri.fyi/implementations/ai-2040-inference-only-verification-plan/"
        },
        {
          "id": "I-0012",
          "title": "Low-trust AI compute verification system overview",
          "url": "https://trustbutveri.fyi/implementations/low-trust-compute-verification-system-overview/"
        },
        {
          "id": "I-0010",
          "title": "RAND secure inference data center (SIDC) design",
          "url": "https://trustbutveri.fyi/implementations/rand-secure-inference-data-centers/"
        }
      ]
    }
  ],
  "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-0038",
      "title": "Suppressing Side Channels in an Untrusted Data Center via Retrofitted Defenses",
      "authors": "N. Cankaya",
      "year": 2026,
      "url": "https://techgov.intelligence.org/blog/suppressing-side-channels-in-an-untrusted-data-center-via-retrofitted-defenses",
      "path": "/sources/cankaya-suppressing-side-channels/"
    }
  ]
}