{
 "question": "Round 4 gap-filling research for the Memory Commons deep-time preservation project (memorycommons.com). Rounds 1-3 verified: preservation-attempts core survey (Arctic Code Vault, Rosetta Disk, EchoStar XVI, Beresheet Lunar Library self-assessment, Memory of Mankind incl. \u20ac60-350 funding model), orbit physics (FCC 5-yr LEO rule, GEO century-scale stability only, MEO chaos, lunar lava tubes ~290K), materials matrix (Nanofiche/nickel real densities, piqlFilm 120GB/reel, Project Silica TRL6 research-ended, Cerabyte roadmap, DNA >$100k/GB write 2022), SpaceX rideshare $7k/kg 2026, TLD economics (.com capped, .org/.foundation uncapped, EBERO, .io/.id ccTLD risk), naming linguistics, Urbit sigils. DO NOT re-research those. Research these REMAINING GAPS with numbers and citations, flagging vendor claims vs peer-reviewed vs regulatory sources: (A) PROVENANCE & CENTURY-SCALE INTEGRITY (nothing survived verification in two attempts \u2014 prioritize this): C2PA Content Credentials adoption status 2025-2026 (which cameras, platforms, standards-body status, ISO?); RFC 3161 trusted timestamping and long-term validation practice; ETSI AdES/LTV (long-term validation) and RFC 4998 Evidence Record Syntax \u2014 how archives keep signatures verifiable across decades of algorithm/key rotation; NIST post-quantum signature standards FIPS 204 (ML-DSA) and FIPS 205 (SLH-DSA/SPHINCS+) \u2014 status, adoption timelines, suitability for long-lived archival signatures; transparency logs for archival integrity (Certificate Transparency model, Sigstore/Rekor adoption); blockchain anchoring for archives (OpenTimestamps on Bitcoin) \u2014 real usage and criticisms. (B) COMMONS GOVERNANCE PRECEDENTS: Elinor Ostrom's 8 design principles for commons governance (primary formulation + evidence they work); Wikimedia Foundation governance structure and 2024-2026 annual budget/funding mix (Form 990 numbers); Internet Archive: budget, funding mix, and the Hachette v. Internet Archive outcome and what it means for archive legal risk; Software Heritage: UNESCO partnership, funding model, sponsors, scale (source files archived); Long Now Foundation: membership model, budget if public; documented cases of knowledge-archive capture, censorship, or governance failure (what failure looks like). (C) FUNDING MODELS VERIFIED: Celestis current pricing tiers (Earth Rise, Earth Orbit, Luna, Voyager services \u2014 exact USD); LifeShip current products and pricing (DNA to Moon); Lunar Codex funding approach; whether IARPA MIST hit its 2025 $1/GB DNA target; NASA CLPS lunar delivery $/kg (Astrobotic, Intuitive Machines, Firefly task order values and payload masses); GEO hosted-payload pricing (Astranis, SES, Intelsat hosted payload programs \u2014 $ per kg or per slot); payload qualification costs (NASA GEVS vibration testing, ASTM E595 outgassing certification \u2014 typical cost ranges at test houses); DHL MoonBox retail keepsake pricing history. (D) SURVEY REMAINDER: Voyager Golden Record \u2014 construction (gold-plated copper, uranium-238 half-life dating patch), contents (115 images, 55 greetings, 27 music pieces, sounds), trajectory and expected survival (peer-reviewed or expert longevity estimates ~billions of years, Oberg/Space.com); Pioneer 10/11 plaques (6x9 inch gold-anodized aluminum, design controversy); LAGEOS-1 (1976, 5,900 km orbit, 8.4 Myr orbital lifetime, Sagan plaque for future finders); KEO project failure timeline (announced 1994?, launch promised 2003, 2006, 2010, 2012... current dead status); Sanctuary on the Moon / Arnano sapphire disks (which mission, status, specs); MoonArk (Carnegie Mellon, on Peregrine \u2014 lost Jan 2024?); Lunar Codex (Samuel Peralta \u2014 which capsules flew on which CLPS missions, media used, what survived Peregrine/IM-1); Golden Record 40th-anniversary reissues and public copies. Output: cited, number-heavy findings per section with confidence levels.",
 "summary": "Round 4's surviving claims all land in Section A (provenance and century-scale integrity), and they converge on one architecture: century-scale signature validity is treated by every relevant standards body as an active maintenance process, not a one-time signing act. The IETF (RFC 4998 ERS), ETSI (TS 119 512 under eIDAS Art. 34), and Germany's BSI (TR-03125 TR-ESOR, driven by retention obligations up to 110 years or indefinite) all standardize the same renewal-based evidence model \u2014 periodic re-timestamping, with a costly full hash-tree renewal whenever a hash algorithm weakens. On algorithms, NIST's post-quantum signatures FIPS 204 (ML-DSA) and FIPS 205 (SLH-DSA) have been final and in force since 14 Aug 2024, with draft NIST IR 8547 disallowing RSA/ECDSA/EdDSA after 2035 per NSM-10's federal PQC target. The newer trust primitives are weaker than marketing suggests: C2PA Content Credentials is only ISO/CD 22144 at stage 30.99 (\"under development\", not a published standard), Sigstore's own docs concede Rekor/Fulcio misbehavior can go undetected without third-party monitors, and Bitcoin/OpenTimestamps anchoring exists only as a non-adopted individual Internet-Draft as of mid-2026. Sections B (commons governance), C (funding models), and D (survey remainder) produced no verified claims in this round and remain open.",
 "findings": [
  {
   "claim": "The core problem is established in IETF standards text: digital signatures are not reliable unrenewed over 30+ year archival periods because hash algorithms and public-key algorithms weaken and certificates become invalid; RFC 4998 (Evidence Record Syntax, Standards Track, August 2007, never obsoleted) exists specifically to prove existence and integrity of signed data over 'long and possibly undetermined' periods.",
   "confidence": "high",
   "vote": "3-0 (x2 merged claims)",
   "sources": [
    "https://www.rfc-editor.org/rfc/rfc4998"
   ],
   "evidence": "RFC 4998 Sec 1.1 verbatim: 'In some cases, digitally signed data must be archived for 30 years or more. However, the reliability of digital signatures over long periods is not absolute. During the archival period, hash algorithms and public key algorithms can become weak or certificates can become invalid.' Abstract defines the Evidence Record as 'a structure designed to support long-term non-repudiation of existence of data.' Verifiers confirmed RFC 9169 (2021) updated only ASN.1 modules; RFC 6283 (XMLERS, 2011) is the parallel XML encoding. Post-2007 events (SHA-1 collision 2017, PQC standards 2024) corroborate the premise."
  },
  {
   "claim": "The standardized fix defines exactly two renewal mechanisms, and both the IETF and Germany's BSI specify the same two-tier model: Timestamp Renewal (re-timestamp only the old timestamp, forming an ArchiveTimeStampChain \u2014 sufficient when the signature/TSA algorithm weakens) and Hash-Tree Renewal (required when the hash algorithm itself weakens), the latter forcing re-access and re-hashing of ALL archived data objects under a new archive timestamp \u2014 the dominant recurring operational cost for a century-scale archive.",
   "confidence": "high",
   "vote": "3-0 (x2 merged claims)",
   "sources": [
    "https://www.rfc-editor.org/rfc/rfc4998",
    "https://www.bsi.bund.de/SharedDocs/Downloads/EN/BSI/Publications/TechGuidelines/TR03125/BSI_TR-ESOR-leitlinie_1_3_en.pdf"
   ],
   "evidence": "RFC 4998 Sec 1.2: 'In the case of Hash-Tree Renewal, all evidence data must be accessed and timestamped... the archived data objects covered by the timestamps... must be hashed and timestamped again by a new Archive Timestamp' vs Timestamp Renewal described as 'very efficient... central management'. BSI TR-ESOR guideline v1.3 (12 Jan 2024) states identically: 'If the hash algorithm deployed will lose its suitability... hash tree renewal must be completed. To do so, new hash values are calculated for all archive data objects.' Full-text grep confirms no third mechanism. Minor nuance: timestamp renewal has three triggers in RFC 4998 (TSA key compromise, algorithm weakening, cert expiry)."
  },
  {
   "claim": "ETSI TS 119 512 V1.2.1 (2023-05, current) normatively mandates ('shall', Annex F.1.6) that preservation services counter algorithm aging by performing RFC 4998/6283 time-stamp or hash-tree renewals, triggered by monitoring algorithm suitability against a cryptographic policy such as ETSI TS 119 312; it formally defines 'long-term preservation' as extending signature validity 'in spite of obsolescence of cryptographic technology... key compromises or of the loss of the ability to check the validity status of public key certificates' \u2014 i.e., deep-time validity is an active, monitored service.",
   "confidence": "high",
   "vote": "3-0 (x2 merged claims)",
   "sources": [
    "https://www.etsi.org/deliver/etsi_ts/119500_119599/119512/01.02.01_60/ts_119512v010201p.pdf"
   ],
   "evidence": "Verified verbatim from the downloaded PDF: clause F.1.6 (normative Annex F) 'the preservation service shall perform time-stamp- or hash-tree-renewals as specified in IETF RFC 4998 [3] and/or IETF RFC 6283 [4]'; clause 3.1 definition of long-term preservation as quoted. Scoping caveat from verification: the hard 'shall' applies to the F.1 evidence-record storage scheme; the F.2 temporary-storage scheme makes renewal conditional on a client-supplied Evidence element. Companion TS 119 511 refreshed V1.2.1 in 2025-10 with the same ERS-renewal framework."
  },
  {
   "claim": "Long-term validation is EU-regulated law and answers a real regulatory horizon, not vendor marketing: eIDAS Regulation (EU) 910/2014 Art. 34(1) permits qualified preservation services only from qualified trust service providers using 'procedures and technologies capable of extending the trustworthiness of the qualified electronic signature beyond the technological validity period' (retained unchanged by eIDAS 2.0, Reg. 2024/1183); and German/EU retention obligations run up to 110 years or indefinitely (e.g., \u00a75(5) Personenstandsgesetz: 110-year birth-register retention) with unambiguous loss-free proof of authenticity and integrity required throughout, per BSI TR-ESOR.",
   "confidence": "high",
   "vote": "3-0 (x2 merged claims)",
   "sources": [
    "https://www.etsi.org/deliver/etsi_ts/119500_119599/119512/01.02.01_60/ts_119512v010201p.pdf",
    "https://www.bsi.bund.de/SharedDocs/Downloads/EN/BSI/Publications/TechGuidelines/TR03125/BSI_TR-ESOR-leitlinie_1_3_en.pdf"
   ],
   "evidence": "Art 34(1) verified verbatim against primary law (retained-EU-law text); Art 3(16) defines preservation as a 'trust service'. eIDAS 2.0 strengthened it (implementing acts for qualified preservation mandated by 21 May 2025; Art 34 extended mutatis mutandis to seals). BSI TR-ESOR v1.3 Sec 1.1: 'retention obligations also exist, with durations up to 110 years or even indefinite. Within such a period, it shall be possible to provide unambiguous and loss-free proof of the authenticity, integrity and comprehensibility of these documents.' Verifier nuance: the mandate is century-scale PROVABILITY via evidence renewal, not one signature staying cryptographically valid for a century."
  },
  {
   "claim": "A concrete government-specified implementation exists: BSI TR-03125 TR-ESOR's ArchiSig module is an IT implementation of IETF ERS (RFC 4998 ASN.1 + RFC 6283 XML), using Merkle trees and reduced hash trees to automate evidential-value preservation for large document sets, with Evidence Record exchange formats designed to be valid 'over an unlimited period of time'; it is legally anchored via \u00a715 of the German Trust Services Act (VDG).",
   "confidence": "high",
   "vote": "3-0",
   "sources": [
    "https://www.bsi.bund.de/SharedDocs/Downloads/EN/BSI/Publications/TechGuidelines/TR03125/BSI_TR-ESOR-leitlinie_1_3_en.pdf"
   ],
   "evidence": "Verbatim from BSI guideline v1.3 (12 Jan 2024): 'the basis of the ArchiSig-Module is the IT implementation of the IETF's Evidence Record Syntax (ERS for short) standard ([RFC4998] and [RFC6283])... the standard defines the data formats in which the Evidence Records are provided and exchanged over an unlimited period of time.' Corroborated by BSI's separate annex 'TR-ESOR-ERS: Evidence Record Profiling pursuant to RFC4998 and RFC6283.' Relevance to Memory Commons: this is the closest thing to an operationally proven, regulator-audited blueprint for century-scale integrity chains."
  },
  {
   "claim": "The NIST post-quantum signature standards are final and in force: FIPS 204 (ML-DSA, from CRYSTALS-Dilithium) and FIPS 205 (SLH-DSA, from SPHINCS+) were approved by the Secretary of Commerce and effective 14 August 2024 (alongside FIPS 203 ML-KEM). ML-DSA parameter sets ML-DSA-44/65/87 provide 128/192/256-bit security (NIST categories 2/3/5). A FALCON-derived FIPS 206 (FN-DSA) remains in draft as of mid-2026 (finalization expected late 2026/early 2027).",
   "confidence": "high",
   "vote": "3-0 (x4 merged claims)",
   "sources": [
    "https://www.federalregister.gov/documents/2024/08/14/2024-17956/announcing-issuance-of-federal-information-processing-standards-fips-fips-203-module-lattice-based",
    "https://nvlpubs.nist.gov/nistpubs/ir/2024/NIST.IR.8547.ipd.pdf",
    "https://eprint.iacr.org/2025/2273"
   ],
   "evidence": "Federal Register 2024-17956: 'FIPS 203, FIPS 204, and FIPS 205 are effective on August 14, 2024' and 'FIPS 204 specifies the Module-Lattice-Based Digital Signature Algorithm (ML-DSA), which is derived from the CRYSTALS-Dilithium submission... FIPS 205 specifies the Stateless Hash-Based Digital Signature Algorithm (SLH-DSA), which is derived from the SPHINCS+ submission.' NIST IR 8547 Table 3 confirms ML-DSA-44/65/87 at 128/192/256 bits (categories 2/3/5) and states NIST intends a future FALCON-derived FIPS. csrc.nist.gov shows both standards Final (Aug 13, 2024), not withdrawn as of July 2026; FIPS 204 has a minor-errata sheet."
  },
  {
   "claim": "A hard migration horizon exists that any archive signing with RSA/ECDSA today must plan around: draft NIST IR 8547 (initial public draft, Nov 2024) proposes ECDSA, EdDSA, and RSA be deprecated after 2030 at 112-bit strength and disallowed after 2035 at all security levels, adopting NSM-10's (May 2022) 2035 target for completing federal PQC migration. As of mid-2026 IR 8547 remains a draft, and EO 14412 (June 2026) accelerated deadlines for federal High Value Assets only (PQC signatures by Dec 31, 2031) without rescinding the 2035 government-wide goal.",
   "confidence": "high",
   "vote": "3-0 (x2 merged claims)",
   "sources": [
    "https://nvlpubs.nist.gov/nistpubs/ir/2024/NIST.IR.8547.ipd.pdf"
   ],
   "evidence": "IR 8547 Table 2 verified via pdftotext: ECDSA/RSA 112-bit 'Deprecated after 2030, Disallowed after 2035'; all >=128-bit rows 'Disallowed after 2035' (EdDSA has no 112-bit row \u2014 Ed25519 is ~128-bit). NSM-10 Sec 3(a) verbatim: 'mitigating as much of the quantum risk as is feasible by 2035.' Verifier caveats: IR 8547 is draft guidance, not binding regulation; Mayer Brown's June 2026 analysis confirms EO 14412 HVA deadlines sit 'materially ahead of the 2035 target' but 2035 remains the operative overall goal. Implication for Memory Commons: classical-signed provenance created in 2026 has at most a ~9-year trusted window before its first mandatory evidence renewal or PQC re-anchoring."
  },
  {
   "claim": "SLH-DSA (FIPS 205) is the conservative candidate for long-lived archival signatures: its security rests only on hash functions, and a 2025 hardware benchmarking preprint concludes it is 'a viable post-quantum solution for applications prioritizing long-term security assurance and efficient verification, such as firmware authentication and digital archiving, despite its higher signing cost.'",
   "confidence": "medium",
   "vote": "3-0 (x2 merged claims; quote-accuracy verified, underlying study is a preprint)",
   "sources": [
    "https://eprint.iacr.org/2025/2273",
    "https://csrc.nist.gov/pubs/fips/205/final"
   ],
   "evidence": "FIPS 205 final status (2024-08-13) confirmed on csrc.nist.gov; NIST positions SLH-DSA as the hash-based backup to ML-DSA. The archival-suitability conclusion comes from a single non-peer-reviewed IACR ePrint (2025/2273, FPGA/Verilog benchmark on Artix-7, posted 2025-12-18) \u2014 the 'digital archiving' framing is an abstract-level takeaway, not an archival-longevity study. Known trade-offs: 7-50 KB signatures, slow signing; 'efficient verification' was a hardware finding (software verification is typically slower than Ed25519/ML-DSA). Verifier also flagged and disregarded a prompt-injection attempt embedded in the ePrint page HTML. Century-scale validity still requires ERS/LTV renewal regardless of algorithm."
  },
  {
   "claim": "C2PA Content Credentials is NOT yet an ISO standard: the ISO catalog carries it as ISO/CD 22144 'Authenticity of information \u2014 Content credentials' (record 90726), status 'Under development', lifecycle stage 30.99 'CD approved for registration as DIS' (dated 2024-10-28) in archived snapshots of 2025-11-14 and 2026-03-12, with DIS ballot (40.20), FDIS (50.00), and publication (60.60) stages carrying no dates. A fast-track ISO/DIS 22144:2025 ballot document circulated (ANSI webstore lists it; the US voted 'No' with comments per ASIS&T), so third-party 'ISO/DIS' references exist, but no published International Standard exists as of July 2026.",
   "confidence": "high",
   "vote": "3-0 (x2 merged claims)",
   "sources": [
    "https://www.iso.org/standard/90726.html",
    "https://web.archive.org/web/20260312162317/https://www.iso.org/standard/90726.html",
    "https://webstore.ansi.org/standards/iso/isodis221442025"
   ],
   "evidence": "Both Wayback captures render identically: 'Stage: CD approved for registration as DIS [30.99]', lifecycle '10.99 2024-10-28 New project approved; 30.99 2024-10-28 CD approved for registration as DIS', undated future stages through '60.60 International Standard published'. Live page still indexes as ISO/CD 22144 at 30.99 as of July 2026. Directly contradicts any claim that 'C2PA is now an ISO standard'. Note: this batch did not verify C2PA's practical adoption (cameras/platforms) \u2014 that gap remains."
  },
  {
   "claim": "Blockchain anchoring for archival/transparency timestamping remains non-standardized as of mid-2026: the only IETF-track artifact, draft-fassbender-scitt-time-anchor (individual Independent-stream I-D, Umarise, v01 dated 27 Apr 2026, v02 28 May 2026, targeting Informational only), has not been adopted by the SCITT WG and carries the banner 'This I-D is not endorsed by the IETF.' The draft's technical argument \u2014 author-asserted, not peer-reviewed \u2014 is that Bitcoin/OpenTimestamps anchoring removes RFC 3161's long-term key-management dependency ('Anchor Proofs do not depend on any signing key, certificate chain, or key management infrastructure'), eliminating key compromise, certificate expiry, and authority revocation as threats to decades-old proofs; verification requires only the artifact bytes, the .ots proof file, and Bitcoin block headers, with no service contact, API key, or CA trust.",
   "confidence": "high",
   "vote": "3-0 (x3 merged claims; 'high' applies to the draft's status and content, not to the truth of its security argument)",
   "sources": [
    "https://datatracker.ietf.org/doc/draft-fassbender-scitt-time-anchor/01/",
    "https://www.ietf.org/archive/id/draft-fassbender-scitt-time-anchor-01.txt"
   ],
   "evidence": "Datatracker confirms: individual submission, ISE stream, no WG association, state 'Awaiting Reviews'/'Revised I-D Needed'. Sec 6.10 verbatim on no-key-dependency; Sec 3.2: verifier 'MUST NOT require: Contact with any anchoring service...; An API key...; Trust in any certificate authority.' Trust-model contrast verbatim: 'RFC 3161: a trusted authority attests... Verification requires trust in that authority. This document: temporal proof is a consequence of ledger inclusion.' The draft itself lists residual failure modes: SHA-256 compromise (Sec 6.8), Bitcoin ledger unavailability (Sec 6.7), ~10-min block / up-to-2-hour consensus timestamp variance (Sec 2.6.3), and notes OpenTimestamps has no formal IETF/ISO spec. RFC 3161's TSA fragility ('If the TSA ceases operations... previously issued timestamps may become unverifiable') is stated in the draft, matching the RFC 4998 motivation independently verified above."
  },
  {
   "claim": "Sigstore/Rekor is not suitable for unattended deep-time reliance: Sigstore's own security documentation concedes 'If no third parties monitor the logs, then any misbehavior by Rekor and Fulcio might go undetected' (tamper-EVIDENT only, contingent on active external monitoring), and the same security-model page contains zero statements about algorithm agility, key rotation across decades, or long-term archival validation \u2014 its only future-proofing artifact is Signed Tree Head tokens saved 'as evidence in case Rekor's clock changes in the future.' Notably, the companion claim that Rekor is append-only/tamper-proof was REFUTED 0-3 in verification.",
   "confidence": "high",
   "vote": "3-0 (x2 merged claims)",
   "sources": [
    "https://docs.sigstore.dev/about/security/"
   ],
   "evidence": "Both quotes verified verbatim on the live page (fetched 2026-07-06). Full-text grep found zero hits for 'algorithm', 'agility', 'archival', 'decade', 'quantum'; sole 'rotation' mention is the five-person TUF root keyholder rotation. Corroborated by sigstore rekor-monitor ('transparency logs are tamper-evident but not tamper-proof') and Trail of Bits/OpenSSF (Dec 2025) monitoring posts. Sigstore does have crypto-agility work elsewhere (protobuf-specs algorithm registry, ML-DSA experiments per Trail of Bits Jan 2026), but that covers future signing, not long-term archival validation; service key rotation remains a manual TUF root-signing event. The 'undercuts century-scale reliance' framing is flagged inference, consistent with the source's own conditional."
  }
 ],
 "caveats": "Coverage gap: all 23 surviving claims address Section A (provenance & century-scale integrity) \u2014 the prioritized section \u2014 but Sections B (Ostrom, Wikimedia/IA/Software Heritage/Long Now governance and budgets), C (Celestis/LifeShip/CLPS/hosted-payload/GEVS pricing), and D (Voyager/Pioneer/LAGEOS/KEO/MoonArk/Lunar Codex survey) produced no verified findings in this round; treat those as unresearched, not negative results. Two claims were refuted and should not be reused: the Rekor append-only/tamper-proof characterization (0-3) and the Federal Register century-scale-rationale framing for FIPS 203/204/205 (1-2). Time-sensitivity: NIST IR 8547 is still an initial public draft and EO 14412 (June 2026) is reshaping federal PQC deadlines; ISO/CD 22144 could advance past stage 30.99 at any time (live ISO page blocks scripted fetches, last distinct snapshot 2026-03-12); draft-fassbender has a v02 and may still publish as an Independent-stream Informational RFC (which would not equal IETF endorsement). Weak source flag: the SLH-DSA archival-suitability conclusion rests on a single non-peer-reviewed FPGA-benchmark preprint (whose page also contained a prompt-injection attempt that verifiers disregarded); C2PA camera/platform adoption specifics and RFC 3161 operational practice were referenced only indirectly and never independently verified. The 'exactly two renewal mechanisms' and Timestamp-Renewal trigger phrasing carry minor scoping nuances noted in the findings (three renewal triggers in RFC 4998; ETSI 'shall' scoped to the F.1 evidence-record scheme).",
 "openQuestions": [
  "C2PA real-world adoption remains unverified: which camera bodies (Leica/Sony/Nikon/Canon firmware), platforms (LinkedIn, TikTok, Google), and toolchains actually ship Content Credentials in 2025-2026, and did the ISO/DIS 22144 ballot (where the US voted 'No' with comments) pass, fail, or get revised?",
  "Has any real archive ever executed a full RFC 4998 hash-tree renewal at scale (e.g., German TR-ESOR deployments post-SHA-1), and what did it cost in compute, access, and money \u2014 the key input for modeling Memory Commons' century operating budget?",
  "When do post-quantum algorithms land in the timestamping/LTV chain itself \u2014 PQC-capable RFC 3161 TSAs, ETSI TS 119 312 suitability dates for ML-DSA/SLH-DSA, FIPS 206 (FN-DSA) finalization, and ERS/AdES profiles binding PQC timestamps \u2014 since every renewal-based scheme ultimately depends on TSA algorithm migration?",
  "Sections B, C, and D in full: Ostrom's principles and archive-governance failure cases, Wikimedia/Internet Archive/Software Heritage/Long Now budgets and Hachette v. Internet Archive fallout, verified Celestis/LifeShip/CLPS/hosted-payload pricing, and the physical-artifact survey remainder (Voyager record, Pioneer plaques, LAGEOS, KEO, MoonArk, Lunar Codex, Sanctuary on the Moon) \u2014 none survived verification this round and need a round 5 pass."
 ],
 "refuted": [
  {
   "claim": "The stated purpose of the three standards is resistance to future quantum-computer attacks that threaten currently deployed public-key cryptosystems, which is the core rationale for using them on century-scale archival signatures.",
   "vote": "1-2",
   "source": "https://www.federalregister.gov/documents/2024/08/14/2024-17956/announcing-issuance-of-federal-information-processing-standards-fips-fips-203-module-lattice-based"
  },
  {
   "claim": "The Rekor transparency log is append-only: once entries are added they cannot be modified, and Merkle-tree signing gives entries cryptographically verified timestamps that cannot later be tampered with or removed.",
   "vote": "0-3",
   "source": "https://docs.sigstore.dev/about/security/"
  }
 ],
 "sources": [
  {
   "url": "https://www.rfc-editor.org/rfc/rfc4998",
   "quality": "primary",
   "angle": "long-term signature validity standards (A, regulatory/technical)",
   "claimCount": 5
  },
  {
   "url": "https://www.etsi.org/deliver/etsi_ts/119500_119599/119512/01.02.01_60/ts_119512v010201p.pdf",
   "quality": "primary",
   "angle": "long-term signature validity standards (A, regulatory/technical)",
   "claimCount": 5
  },
  {
   "url": "https://www.bsi.bund.de/SharedDocs/Downloads/EN/BSI/Publications/TechGuidelines/TR03125/BSI_TR-ESOR-leitlinie_1_3_en.pdf",
   "quality": "primary",
   "angle": "long-term signature validity standards (A, regulatory/technical)",
   "claimCount": 5
  },
  {
   "url": "https://www.federalregister.gov/documents/2024/08/14/2024-17956/announcing-issuance-of-federal-information-processing-standards-fips-fips-203-module-lattice-based",
   "quality": "primary",
   "angle": "long-term signature validity standards (A, regulatory/technical)",
   "claimCount": 5
  },
  {
   "url": "https://www.iso.org/standard/90726.html",
   "quality": "primary",
   "angle": "long-term signature validity standards (A, regulatory/technical)",
   "claimCount": 5
  },
  {
   "url": "https://www.lumethic.com/en/articles/cameras-with-c2pa-content-credentials",
   "quality": "blog",
   "angle": "long-term signature validity standards (A, regulatory/technical)",
   "claimCount": 5
  },
  {
   "url": "https://nvlpubs.nist.gov/nistpubs/ir/2024/NIST.IR.8547.ipd.pdf",
   "quality": "primary",
   "angle": "post-quantum and transparency-log integrity (A, state-of-art/adoption)",
   "claimCount": 5
  },
  {
   "url": "https://openssf.org/blog/2025/10/15/announcing-the-sigstore-transparency-log-research-dataset/",
   "quality": "primary",
   "angle": "post-quantum and transparency-log integrity (A, state-of-art/adoption)",
   "claimCount": 5
  },
  {
   "url": "https://blog.trailofbits.com/2025/12/12/catching-malicious-package-releases-using-a-transparency-log/",
   "quality": "blog",
   "angle": "post-quantum and transparency-log integrity (A, state-of-art/adoption)",
   "claimCount": 5
  },
  {
   "url": "https://eprint.iacr.org/2025/2273",
   "quality": "primary",
   "angle": "post-quantum and transparency-log integrity (A, state-of-art/adoption)",
   "claimCount": 5
  },
  {
   "url": "https://datatracker.ietf.org/doc/draft-fassbender-scitt-time-anchor/01/",
   "quality": "primary",
   "angle": "post-quantum and transparency-log integrity (A, state-of-art/adoption)",
   "claimCount": 5
  },
  {
   "url": "https://docs.sigstore.dev/about/security/",
   "quality": "primary",
   "angle": "post-quantum and transparency-log integrity (A, state-of-art/adoption)",
   "claimCount": 5
  },
  {
   "url": "https://diff.wikimedia.org/2025/11/24/highlights-from-the-wikimedia-foundations-fiscal-year-2024-2025-audit-report/",
   "quality": "primary",
   "angle": "commons governance precedents and failures (B, institutional/contrarian)",
   "claimCount": 5
  },
  {
   "url": "https://projects.propublica.org/nonprofits/organizations/943242767",
   "quality": "primary",
   "angle": "commons governance precedents and failures (B, institutional/contrarian)",
   "claimCount": 5
  },
  {
   "url": "https://law.justia.com/cases/federal/appellate-courts/ca2/23-1260/23-1260-2024-09-04.html",
   "quality": "primary",
   "angle": "commons governance precedents and failures (B, institutional/contrarian)",
   "claimCount": 5
  },
  {
   "url": "https://www.sciencedirect.com/science/article/abs/pii/S0167268112002697",
   "quality": "primary",
   "angle": "commons governance precedents and failures (B, institutional/contrarian)",
   "claimCount": 4
  },
  {
   "url": "https://www.celestis.com/experiences-pricing/",
   "quality": "primary",
   "angle": "verified space-archive funding and pricing (C, practitioner/cost)",
   "claimCount": 5
  },
  {
   "url": "https://en.wikipedia.org/wiki/Commercial_Lunar_Payload_Services",
   "quality": "secondary",
   "angle": "verified space-archive funding and pricing (C, practitioner/cost)",
   "claimCount": 5
  },
  {
   "url": "https://lifeship.com/products/dna-to-moon",
   "quality": "primary",
   "angle": "verified space-archive funding and pricing (C, practitioner/cost)",
   "claimCount": 5
  },
  {
   "url": "https://www.iarpa.gov/research-programs/mist",
   "quality": "unreliable",
   "angle": "verified space-archive funding and pricing (C, practitioner/cost)",
   "claimCount": 0
  },
  {
   "url": "https://science.nasa.gov/mission/voyager/making-of-the-golden-record/",
   "quality": "primary",
   "angle": "deep-time artifact survey remainder (D, historical/primary)",
   "claimCount": 5
  },
  {
   "url": "https://earth.gsfc.nasa.gov/geo/missions/lageos/message",
   "quality": "primary",
   "angle": "deep-time artifact survey remainder (D, historical/primary)",
   "claimCount": 5
  },
  {
   "url": "https://en.wikipedia.org/wiki/KEO",
   "quality": "secondary",
   "angle": "deep-time artifact survey remainder (D, historical/primary)",
   "claimCount": 5
  },
  {
   "url": "https://en.wikipedia.org/wiki/MoonArk",
   "quality": "secondary",
   "angle": "deep-time artifact survey remainder (D, historical/primary)",
   "claimCount": 5
  },
  {
   "url": "https://www.lunarcodex.com/spacecraft",
   "quality": "primary",
   "angle": "deep-time artifact survey remainder (D, historical/primary)",
   "claimCount": 5
  }
 ],
 "stats": {
  "angles": 5,
  "sourcesFetched": 25,
  "claimsExtracted": 119,
  "claimsVerified": 25,
  "confirmed": 23,
  "killed": 2,
  "afterSynthesis": 11,
  "urlDupes": 0,
  "budgetDropped": 5,
  "agentCalls": 107
 }
}