Verified Truth — Research Landscape Map

Document: VERIFIED_TRUTH_RESEARCH_LANDSCAPE.md Version: 1.0 Date: 2026-06-26 Owner: Maxim Geller Status: Deliverable A of six requested in Mikhail Goman's scientific review Companion to: VERIFIED_TRUTH_REFERENCES.md (Deliverable E — structured bibliography)

Preface

This document is the narrative survey of the intellectual fields the Verified Truth Ecosystem operates within. Where the Reference Bibliography (Deliverable E) lists individual sources with structured fields, this document tells the story of each field: where it began, how it developed, what its current state is, what its open problems are, and where Verified Truth fits within it.

The eight categories correspond to the priority list in Mikhail Goman's review:

1. Provenance Standards
2. Formal Verification and Temporal Logic
3. Security Certification
4. Distributed Ledgers and Oracles
5. Supply Chain Provenance
6. Digital Identity and Trust Services
7. Academic Knowledge Provenance
8. Theoretical Foundations (Speech Acts, Event Sourcing)

For each category, the structure is:

• Origins and intellectual founding — the founding work, who did it, when, and what they were trying to solve
• Development arc — the main lines that grew from the founding work
• Current state of the field — what is mature, what is in use, what is being deployed today
• Open problems — what the field has not yet solved and is actively working on
• How Verified Truth engages — what we build on, what we adapt, what we deliberately diverge from
• Calibrated honest note — what we have not yet engaged with in this field

The goal is not to write the definitive history of each field. The goal is to make it visible that we know our place in each field and to invite the reader to verify our positioning.

1. Provenance Standards

1.1 Origins

The intellectual problem of data provenance — knowing where a piece of information came from and how it was derived — predates digital computing. Archivists have practiced it for centuries; scientists from Mendel onward have kept laboratory notebooks for it; the discipline of paleography catalogs the provenance of manuscripts.

The computational treatment of provenance has its modern roots in two distinct traditions. The first is database lineage, traceable to the work of Cui and Widom at Stanford in the late 1990s, who studied how to attribute query results to specific input tuples. The second is workflow provenance in scientific computing, which arose in the early 2000s with systems like Kepler (UC Davis), Taverna (Manchester), and VisTrails (Utah) — each tracking how scientific results were produced through chains of computational steps.

These traditions converged in the late 2000s when the W3C Provenance Working Group, chartered in 2009, set out to create a shared interoperability framework. The group included researchers from databases, semantic web, scientific computing, and digital preservation communities, and its mandate was to produce a vocabulary that would let provenance metadata flow between systems that had previously been incompatible.

1.2 Development arc

The W3C effort produced the PROV family of recommendations in April 2013:

• PROV-DM (the data model) defines three core classes (Entity, Activity, Agent) and their relations (wasGeneratedBy, used, wasAttributedTo, actedOnBehalfOf, wasDerivedFrom, and others)
• PROV-O provides an OWL2 ontology expression for RDF-based systems
• PROV-N specifies a human-readable notation
• PROV-Constraints defines integrity constraints on valid provenance graphs
• PROV-AQ addresses access and query of provenance information

After the 2013 recommendation, the PROV family has been extended for specific domains:

• PROV-DfA (Data for Action) for human action sequences
• ProvONE for scientific workflows
• PROV-ML for machine learning pipelines
• CWL-Prov for Common Workflow Language

Specific implementations have appeared in scientific workflow systems (Taverna, Pegasus, Galaxy), in cloud platforms (Apache Atlas), in research data infrastructures (CrossRef Event Data, RO-Crate), and in regulatory compliance contexts (several GDPR-oriented provenance frameworks).

1.3 Current state

PROV is the de facto standard vocabulary for representing data provenance in the academic and standards-body community. It is widely understood, has multiple mature implementations, and is taught in graduate data management courses.

In industrial practice, however, PROV adoption is uneven. Cloud platforms tend to use vendor-specific lineage formats (Apache Atlas, Snowflake's data lineage, AWS Lake Formation). Open source projects sometimes adopt PROV-compatible structures (OpenLineage being a recent example for data-engineering pipelines) but more often invent their own vocabularies.

This pattern — strong academic standardisation, fragmented industrial adoption — is characteristic of the field.

1.4 Open problems

Several questions remain genuinely unsolved:

• Cross-system provenance interoperability at scale. When a data artifact moves through fifteen different systems (data lake → ETL → warehouse → ML training → inference → dashboard), the provenance metadata typically fragments. Stitching the chain back together is hard, and no widely deployed solution exists.
• Privacy-preserving provenance. Detailed provenance graphs can leak sensitive information about source data, internal processes, or relationships. The GDPR compatibility of fine-grained provenance is an open research area.
• Provenance for AI/ML systems. The training-data-to-model-to-output chain is fundamentally hard to capture in PROV vocabulary. Model cards, data sheets for datasets, and the emerging EU AI Act requirements gesture at this but have not converged.
• Trust in provenance metadata itself. PROV describes provenance; it does not natively address whether the provenance metadata is itself trustworthy. Some domains (cryptographic timestamping, sealed audit logs) address this, but the integration is ad hoc.

1.5 How Verified Truth engages

The Verified Truth substrate is conceptually compatible with PROV at the level of entity/activity/agent decomposition. A Verified Event maps naturally to a PROV Activity that generates new Entities via an Agent. The framework could export PROV-compatible RDF if downstream consumers required it.

What the framework adds on top of PROV:

• Approval semantics. PROV has no concept of "approved" or "rejected" — only descriptive lineage. The framework adds explicit approval predicates with authority requirements.
• Canonical state. PROV describes what happened; the framework adds the notion of canonical state that has been formally sealed and is the basis for further action.
• Audit-grade integrity. PROV is a metadata vocabulary; the framework treats the provenance log itself as append-only and integrity-protected at the substrate level.
• Domain-uniform application. PROV is general but each domain implements it differently. The framework applies one vocabulary across agreements, objects, and scientific knowledge.

What the framework does not try to replace:

• PROV's interoperability mission. The framework can export PROV-formatted provenance for downstream consumers. We do not propose a competing standard.
• Domain-specific provenance extensions. Healthcare (HL7 FHIR Provenance), supply chain (GS1 EPCIS), and research data (RO-Crate) have their own conventions. The framework can integrate with these as adapter layers rather than displacing them.

1.6 Honest note

The PROV family is the area we have engaged with most directly in this field. Adjacent areas we have not engaged with at sufficient depth include:

• The literature on inference of provenance from operational logs (when systems do not natively track provenance, can you reconstruct it?). This is an active research area we have not surveyed.
• Provenance in distributed systems under network partitions and Byzantine actors. Lampson, Lamport, and others have worked on related problems; we have not engaged with this literature specifically through a provenance lens.
• The digital preservation community's work on long-term provenance preservation (OAIS reference model, ISO 14721) is adjacent to our 120-year retention target and deserves engagement we have not yet done.

2. Formal Verification and Temporal Logic

2.1 Origins

The intellectual founding of formal program verification is conventionally dated to Robert Floyd's 1967 paper "Assigning Meanings to Programs" (Proc. Symposia in Applied Mathematics, Vol. XIX, pages 19–32, American Mathematical Society). Floyd introduced the idea of attaching inductive assertions to program flowcharts: a precondition before each statement, a postcondition after, with the requirement that local proofs at each step compose into a global correctness proof.

Tony Hoare's 1969 paper "An Axiomatic Basis for Computer Programming" (Communications of the ACM, Vol. 12, No. 10, pages 576–580) formalised this approach as an axiomatic semantics. Hoare introduced the triple notation P{S}Q (today usually written {P}S{Q}), where P is a precondition, S a program statement, and Q a postcondition. The notation and the inference rules associated with it became known as Hoare Logic, and the field of program verification was effectively founded.

Two extensions deepened the foundation in the 1970s:

• Edsger Dijkstra's 1976 book A Discipline of Programming introduced weakest precondition semantics, providing a method for systematically deriving correct programs from specifications rather than just verifying them after the fact.
• Amir Pnueli's 1977 paper "The Temporal Logic of Programs" (FOCS 1977, pages 46–57) introduced linear temporal logic (LTL) to computer science. Pnueli's insight was that Hoare-style logic could reason about terminating sequential programs but was inadequate for reactive systems — programs whose normal mode is non-terminating interaction with an environment (operating systems, network protocols, control systems). Temporal logic added operators for "always", "eventually", "until" that could express liveness and fairness properties Hoare logic could not.

Pnueli received the 1996 Turing Award for this contribution. The 5,800+ citations to the 1977 paper are unusual for a theoretical computer science work.

2.2 Development arc

Through the late 1970s and 1980s, the field developed along three main lines:

Temporal logic theory. Manna and Pnueli systematised the use of temporal logic for verification in their two-volume work The Temporal Verification of Reactive Systems (Springer, 1995). Branching-time variants (CTL — Clarke and Emerson) and unified frameworks (CTL* — Emerson and Halpern) emerged. The classification of safety properties ("nothing bad ever happens") versus liveness properties ("something good eventually happens") became canonical.

Model checking. Clarke and Emerson at Carnegie Mellon, Sifakis at IMAG/Grenoble, and others developed algorithms for automatically verifying that a finite-state model satisfies a temporal logic formula. The major insight was that for finite-state systems, you could exhaustively check all reachable states rather than constructing a proof. Clarke, Emerson, and Sifakis shared the 2007 Turing Award for this work. Tools like SMV (Symbolic Model Verifier), SPIN, and later NuSMV brought model checking to practical use.

Proof assistants. Inspired by the LCF approach (Edinburgh, late 1970s), interactive theorem provers developed: Coq (INRIA, 1984+) based on the Calculus of Inductive Constructions, Isabelle (Cambridge / TU Munich, 1986+) on higher-order logic, ACL2 (Boyer-Moore tradition), and HOL. These tools allowed mathematical proofs to be machine-checked, with a small trusted kernel verifying every step.

2.3 Current state

By the mid-2020s, formal verification has reached production scale for high-assurance domains:

Industrial adoption of TLA+. Amazon Web Services published in 2014 their use of TLA+ for verifying distributed protocols in S3, DynamoDB, and the Elastic Block Store. Microsoft uses TLA+ in Azure. Intel verified cache coherence protocols. The pattern: TLA+ catches design bugs that would be undiscoverable in code review and prohibitively expensive to find in production.

CompCert. Xavier Leroy's verified C compiler (CompCert, INRIA, formally verified in Coq, with the main results published in 2009 in the Journal of Automated Reasoning and elsewhere) demonstrated that an optimising compiler can carry a machine-checked proof that its output matches the source semantics. CompCert is used in safety-critical embedded systems, particularly avionics.

seL4. The seL4 microkernel (NICTA/Data61 in Australia) was the first general-purpose OS kernel with a complete machine-checked functional correctness proof from C to specification, with the main paper "seL4: formal verification of an operating-system kernel" in Communications of the ACM 53(6), pages 107–115, June 2010 (DOI 10.1145/1743546.1743574). Subsequent work extended the proof down to the assembly level on RISC-V (2021).

Smaller-scale tools. SAT and SMT solvers (Z3 from Microsoft Research, CVC4/CVC5, Yices) underpin a wide range of verification tools. Bounded model checkers, abstract interpretation frameworks (Astrée at École Normale Supérieure / AbsInt), and runtime verification frameworks have become production tools in their respective domains.

2.4 Open problems

Despite the maturation, the field has genuine open problems:

• Scaling formal verification to large systems. seL4 is 8,700 lines of C; a modern web application is several orders of magnitude larger. Verification cost grows with system size. Compositional verification techniques are an active research area.
• Specification correctness. A verified system is verified against a specification. If the specification is wrong, the verification certifies nothing useful. The "specification gap" — bridging informal requirements to formal specifications — remains hard.
• Verification of probabilistic and learning systems. Statistical and ML-based systems do not have the discrete state spaces classical verification handles well. Probabilistic model checking and verification of neural networks are active areas with substantial open work.
• Automation versus expressiveness. Model checking is automatic but limited to finite state. Proof assistants are expressive but require expert human guidance. The middle ground (SMT-based deductive verification) is improving but not yet fully automated for rich properties.

2.5 How Verified Truth engages

The relation between Verified Truth and formal verification is conceptual rather than direct.

• TLA+ as a potential hardening target. The EquiWork canonical state machine — a finite graph with explicit transitions — is exactly the kind of system TLA+ verifies well. A future hardening sprint could specify the lifecycle in TLA+ and check that no state path lets AI emit an approval predicate, that no path skips a required signature, that the audit log invariants hold. This is on the roadmap as a future quality investment, not currently implemented.
• Coq or Isabelle as code-correctness option. If the implementation of the protocol composition needed to be formally verified (rather than just heavily tested), the seL4 / CompCert approach using a proof assistant could apply. This is realistic only for the core protocol kernel, not the application layer.
• Conceptual influence. The discipline of separating invariants (properties that always hold) from temporal properties (properties about sequences over time) has shaped how we think about what the framework guarantees.

What the framework does not do:

• It does not prove that what happened in production was correct. Formal verification proves designs; the framework records what actually occurred under (potentially verified) designs.
• It does not replace testing. Formal proof and runtime testing have different strengths; we use the latter for now.

2.6 Honest note

Foundational works (Floyd 1967, Hoare 1969, Pnueli 1977, Lamport 1994) are read and referenced. Secondary literature we have engaged with less:

• The full development of CTL/CTL* branching time logics and their algorithmic verification.
• Separation logic (Reynolds 2002), which addresses pointers and shared mutable state — relevant if we ever formally verify our memory model.
• Refinement in the Z and B specification languages, which is closely related to how Verified Truth's lifecycle could be modelled.
• Industrial case studies from AWS's TLA+ adoption beyond the published overviews.

These are gaps. Engagement is on the path forward, not yet achieved.

3. Security Certification

3.1 Origins

Formal IT security certification has its roots in the Orange Book — properly the Trusted Computer System Evaluation Criteria (TCSEC) published by the US Department of Defense in 1983 and revised in 1985 as DoD 5200.28-STD. The Orange Book defined assurance classes (D, C1, C2, B1, B2, B3, A1) for evaluating the security of computer systems, primarily for government use.

In parallel, European nations developed national criteria (the UK's ITSEC, Germany's IT Sicherheitskriterien, France's Catalogue de Critères) in the late 1980s, leading to harmonisation as the European Information Technology Security Evaluation Criteria (ITSEC) in 1991.

The fragmentation of the US (TCSEC), European (ITSEC), and Canadian (CTCPEC) frameworks created an obvious need for international harmonisation. The Common Criteria initiative began in 1993 and produced CC v1.0 in 1996 and the corresponding ISO/IEC 15408 in 1999. Subsequent revisions through 2005, 2008, 2009, and the current 2022 revision deepened the framework.

3.2 Development arc

The Common Criteria framework is structured around three documents that work together:

• Protection Profile (PP). Written by a user community (often a government or industry consortium). States what security properties a class of products must have, in implementation-independent terms.
• Security Target (ST). Written by a vendor for a specific product. Identifies the Target of Evaluation (TOE), states what security properties the product has, and explains how the product meets a Protection Profile (if one is claimed).
• Evaluation report. Produced by an accredited evaluation laboratory (CEM — Common Evaluation Methodology). Certifies whether the ST is correctly implemented by the TOE.

The Evaluation Assurance Levels (EAL 1 through 7) combine functional and assurance requirements into reusable packages. EAL1 ("functionally tested") is the lightest; EAL7 ("formally verified design and tested") is the most rigorous. Most commercial certifications target EAL4 ("methodically designed, tested, and reviewed").

The Common Criteria Recognition Arrangement (CCRA), signed in 1998 and expanded since, provides international mutual recognition: a certification issued by an accredited body in one CCRA member country is recognised by others (with some limitations).

3.3 Current state

Common Criteria certifications are routine for commercial security products: smartcards, hardware security modules, network firewalls, operating systems, database management systems, identity providers. Certifications appear in tender requirements for government procurements in CCRA countries.

The framework is mature but not static. Recent revisions added Protection Profiles for cloud services, biometric authentication, IoT devices. The "Collaborative Protection Profile" (cPP) approach — Protection Profiles agreed jointly by user communities and vendors before product-level certification — has tried to make the process more responsive.

3.4 Open problems and critiques

The Common Criteria framework has consistent critics. The most-cited critiques include:

• Lab game dynamics. Vendors and evaluation laboratories develop relationships that can affect the rigor of evaluation. The market for evaluations is small enough that price competition between labs creates pressure to interpret requirements loosely.
• Slow and expensive. Months to years per certification, costs running into hundreds of thousands of dollars or more. Not viable for rapidly iterating software products.
• Static. A certification certifies a specific product version. Subsequent updates require recertification. Misconfiguration in deployment voids the assurance: the standard itself notes that "misconfiguration or improper management of a product does not guarantee a certain level of security."
• Scope limited to IT products. Common Criteria does not address agreements, ownership chains, physical goods provenance, or scientific knowledge — only IT product security claims.
• Misalignment with modern continuous deployment. A product released through continuous integration with daily updates does not fit the Common Criteria model of a fixed version under evaluation.

Modern alternatives partially fill the gap: continuous compliance monitoring (CSPM tools, FedRAMP continuous monitoring), software bills of materials (SBOM, CycloneDX, SPDX), security attestation frameworks (SLSA from Google's Open Source Security Foundation), and the EU Cyber Resilience Act (in force 2024) take different approaches to the same underlying need.

3.5 How Verified Truth engages

The structural insight of Common Criteria — separating the claim, the claim's implementer, the evidence, and the evaluator into distinct roles held by different parties — is one of the most important architectural inspirations for the Verified Truth framework. The four-role decomposition (PP author / ST author / TOE / evaluator) maps to the framework's separation of declaration / evidence / approval / canonical state.

What the framework borrows:

• Role separation as architectural commitment. Different parties hold different responsibilities. No single party is both subject and evaluator.
• Reusable templates. Protection Profiles are a precedent for the framework's agreement type templates (software contract, service contract, goods contract, etc.).
• Mutual recognition pattern. The CCRA's idea that one jurisdiction's evaluation can be recognised by another influences how we think about cross-jurisdictional Verified Truth records.

What the framework does differently:

• Continuous event stream rather than static certification. A Verified Truth record is not a once-and-done certificate; it is an ongoing chain of events.
• Lightweight per event. No accredited laboratory is required for each event. The framework produces evidence the way a Common Criteria evaluator produces certifications, but at a per-event scale.
• Multi-domain scope. Common Criteria is IT-only. The framework applies the architectural insight to agreements, physical objects, and scientific knowledge.

The framework does not try to replace Common Criteria. A product seeking high-assurance IT security certification should still pursue Common Criteria. The framework operates in domains and at scales Common Criteria does not address.

3.6 Honest note

The Common Criteria standards are read at the level of architectural principles. Areas we have not engaged at depth:

• Specific Protection Profiles for individual product categories (we know they exist, we have not studied them).
• The lab evaluation methodology in detail (CEM — Common Evaluation Methodology).
• National scheme variations between CCRA members (BSI in Germany, NIAP in the US, etc.).
• The cyclical critique literature in academic security venues (Anderson, Murdoch, and others have published critiques of CC's effectiveness).

4. Distributed Ledgers and Oracles

4.1 Origins

The intellectual foundations of distributed ledgers go back to Leslie Lamport's work on distributed consensus in the 1980s — "The Byzantine Generals Problem" (1982, with Shostak and Pease) and "Paxos" (1989, published in 1998). These works addressed how distributed nodes could agree on a single value despite some nodes being faulty or malicious.

For nearly two decades, this work remained theoretical or applied to closed systems (database replication, distributed coordination). The conceptual breakthrough that made public distributed ledgers practical was Bitcoin, introduced by Satoshi Nakamoto in 2008 and launched in January 2009. Bitcoin's key innovation was Proof of Work — using computational cost to make Sybil attacks economically infeasible — which allowed permissionless distributed consensus without trusted parties.

Ethereum, launched in 2015 by Vitalik Buterin and others, generalised Bitcoin's approach to programmable state transitions: smart contracts. Ethereum's Turing-complete virtual machine made it possible to build complex applications on a distributed ledger.

The immediate problem this raised was the oracle problem: smart contracts are deterministic and isolated. They cannot directly access external data (weather, asset prices, sports results, identity verification, real-world events). Without external data, smart contracts can only operate on data already on-chain — a serious limitation for most real-world applications.

4.2 Development arc

The oracle problem spawned a substantial research and engineering literature. Early solutions used trusted single-source oracles (which reintroduced single points of failure, defeating the decentralisation argument). A series of attempts (Augur, Reality.eth, others) explored game-theoretic and crowdsourced oracles.

Chainlink (whitepaper by Ellis, Juels, and Nazarov in 2017; mainnet 2019) is the most-deployed decentralised oracle network. Chainlink uses multiple independent node operators that each retrieve data from multiple sources; the aggregated result is delivered on-chain with cryptoeconomic guarantees (nodes stake LINK tokens that can be slashed for incorrect data). The Chainlink architecture includes:

• Price Feeds for financial data
• Verifiable Random Function (VRF) for trustworthy on-chain randomness
• Automation (formerly Keepers) for triggered smart contract execution
• CCIP (Cross-Chain Interoperability Protocol) for cross-blockchain messaging
• Proof of Reserve attestations

Alternative oracle networks have emerged: Band Protocol, API3, Pyth Network, RedStone. Each makes different trade-offs between decentralisation, latency, and economic model.

DECO (Decentralized Oracles for TLS), published in 2020 by Zhang, Maram, Malvai, Goldfeder, and Juels at Cornell (USENIX Security 2020), introduced zero-knowledge proofs of TLS-secured web data. A DECO oracle can prove that specific data was retrieved from a specific TLS-secured website at a specific moment, without requiring the website's cooperation. This addresses a previously unsolved aspect of the oracle problem.

4.3 Current state

By 2026, the distributed ledger ecosystem has differentiated into multiple distinct layers:

• Base layer ledgers (Bitcoin, Ethereum, Solana, others). Mature.
• Layer 2 scaling solutions (Optimistic Rollups, ZK Rollups, sidechains). Maturing.
• Oracles (Chainlink dominant; alternatives in specific niches). Mature for price feeds; less mature for arbitrary data.
• Cross-chain interoperability (CCIP, LayerZero, Wormhole, IBC). Active development; security incidents have demonstrated remaining challenges.
• Permissioned blockchains (Hyperledger Fabric, R3 Corda) for enterprise consortia. Different design space, mature for industrial use.

Chainlink in particular has become infrastructure: it secures more than 70% of the DeFi ecosystem's price feeds. CCIP has been adopted by major financial institutions exploring tokenisation (SWIFT, ANZ, BNY Mellon among the announced participants).

4.4 Open problems

• Oracle MEV. Maximum Extractable Value (MEV) opportunities exist when oracle updates can be front-run by sophisticated actors. Multiple research lines address this.
• Decentralisation versus cost. Truly decentralised oracles with high node counts are expensive to operate. The economic model that sustains them is delicate.
• Cross-chain security. Bridges have been the most-targeted attack surface in the blockchain ecosystem (Ronin, Wormhole, Nomad incidents collectively cost over $2 billion). Better security models are an active research frontier.
• Privacy-preserving oracles. DECO and related zero-knowledge approaches are early; widespread adoption is not yet mature.
• Real-world asset (RWA) tokenisation. Bringing physical assets on-chain with legally meaningful guarantees about the off-chain reality is the focus of significant effort but the trust model is unsettled.

4.5 How Verified Truth engages

The Verified Truth framework treats distributed ledgers as one possible substrate component, not as the foundation of the architecture. Specifically:

• EquiWork uses Ethereum-compatible signature primitives (EIP-712) and may use on-chain anchoring for cross-party settlement, but the framework's core (predicate vocabulary, authority model, audit chain) does not require a blockchain.
• Chainlink as infrastructure for adapters. When EquiWork needs to bring off-chain evidence on-chain in a high-stakes scenario, Chainlink's data feeds or DECO-style attestations are realistic candidates. We do not currently use them but they are in scope for future evidence adapter work.
• Cross-chain (CCIP) for multi-jurisdiction settlement. If Verified Truth records need to settle across multiple chains (e.g., agreement signed on Ethereum, payment released on a different chain), CCIP is the leading candidate.

The framework's relation to blockchain is compositional. We are not a blockchain project. We use blockchain primitives where they solve a problem better than alternatives, and not otherwise.

What we do not claim:

• We do not claim that blockchain immutability solves verification problems. It solves non-repudiation of records; it does not solve correctness of records, which is the actual problem.
• We do not claim that decentralisation is essential. Verified Truth is verifiable by third parties through cryptographic evidence, which is different from decentralised across nodes.

4.6 Honest note

We have engaged with the oracle problem space conceptually. Areas where engagement is shallower:

• Specific cryptoeconomic mechanism design of competing oracle networks (Band, API3, Pyth) — read at the whitepaper level, not synthesised.
• MEV literature in detail. We know MEV exists and matters; we have not engaged with the academic MEV research deeply.
• Cross-chain security incident post-mortems. The Ronin and Wormhole hack post-mortems contain important lessons we have not systematically learned.
• Real-world asset tokenisation case studies. This is the area of distributed ledger activity most adjacent to CAP, and we have engaged less than we should have given that adjacency.

5. Supply Chain Provenance

5.1 Origins

Supply chain traceability as a formalised discipline begins in the 1990s with the rise of barcode-based tracking and the standardisation of identifier schemes by GS1 (then known as EAN International, formed from the merger of the European Article Numbering Association and the Uniform Code Council). The Global Trade Item Number (GTIN), the Serial Shipping Container Code (SSCC), and the Global Location Number (GLN) — all part of the GS1 system — became the backbone of modern supply chain identification.

The motivation was largely commercial: efficient retail checkout, inventory management, logistics optimisation. The motivation for verified provenance came later, driven by three forces:

1. Food safety scares (BSE in the UK in the 1990s, melamine in Chinese milk in 2008, the European horsemeat scandal in 2013) made consumers and regulators demand traceable food supply chains.
2. Pharmaceutical counterfeiting prompted regulations (the US DSCSA from 2013, the EU FMD from 2019) requiring serialised tracking of prescription drugs.
3. Luxury goods anti-counterfeiting drove the development of provenance systems for high-value items (art, watches, wine, handbags).

5.2 Development arc

The supply chain provenance space has developed along three tracks:

Identifier standardisation. GS1 evolved its identifier schemes to include serialisation (each item gets a unique serial number, not just a product class identifier). GS1 EPCIS (Electronic Product Code Information Services) defined how serialised events should be exchanged. GS1 Digital Link (v1.1.1 current; 2027 global sunrise for 2D barcodes at retail) encodes GTIN, batch, serial, expiry into web-addressable URIs — supporting both POS scanning and consumer smartphone lookup.

Industrial blockchain platforms. The mid-2010s saw the emergence of permissioned blockchain platforms designed for multi-party industrial use:

• IBM Food Trust (general availability 2018, built on Hyperledger Fabric) is the most-deployed, with members including Walmart, Carrefour, Nestlé, Unilever, Dole, Tyson Foods. Walmart's famous demonstration — tracing mangoes from farm to shelf in 2.2 seconds versus 6+ days using paper records — established the value proposition.
• Oracle Blockchain Platform powers aerospace applications such as Honeywell's GoDirect Trade marketplace for used aircraft parts.
• VeChain focuses on supply chain provenance with public-blockchain transparency.

Regulatory frameworks. Industry-specific regulations drive specific tracing requirements:

• DSCSA (Drug Supply Chain Security Act, US, 2013, with phased implementation through November 2023) requires interoperable electronic tracing of prescription drug movements.
• EU FMD (Falsified Medicines Directive, in effect 2019) requires serialisation and verification of prescription drugs across the EU.
• EU Battery Regulation (2023) introduces battery passports with sustainability and provenance data.
• EU Digital Product Passport (Eco-design for Sustainable Products Regulation, 2024) extends product passports to many product categories.

5.3 Current state

Supply chain provenance is mature for specific verticals and uneven across others.

• Pharmaceuticals. DSCSA and EU FMD are in force. Serialisation is implemented. Cross-supply-chain verification works at the wholesale level. Consumer-facing verification (a patient scanning a drug box) is uneven.
• Food. IBM Food Trust and similar systems operate in major retailers' supply chains. Less mature outside the major retailers' supplier networks.
• Luxury goods. Provenance platforms exist (Aura Blockchain Consortium for LVMH, Prada, Cartier; Arianee for various brands; LuxChain). Adoption is brand-specific.
• Industrial parts. GoDirect Trade and similar platforms in aerospace. Adoption uneven outside high-value parts.
• Wine. The vertical most analogous to CAP's first commercial target. Various provenance projects exist (eProvenance, Authentic Vision, Selinko). None has established as a market standard.

5.4 Open problems

• The physical-digital binding problem. A barcode, RFID tag, or NFC chip can be removed from one object and attached to another. The integrity of the binding between the digital record and the physical object is the harder half of supply chain provenance, less solved than the digital tracking half. Approaches range from holographic seals to DNA marking for art conservation to physical unclonable functions (PUFs).
• Multi-tier visibility. A typical supply chain has 5-10 tiers between raw material and end consumer. Most provenance systems cover one or a few tiers; end-to-end visibility is rare.
• Cross-vertical interoperability. A bottle of wine is also a packaged food, also a consumer product, also a luxury good. Each vertical has its own provenance system. Interoperability between them is a research and standards-body problem.
• Consumer-facing usability. Consumers scanning QR codes at retail expect instant, intelligible information. Many existing provenance systems produce technical output that is unintelligible to non-experts.
• Trust in the input. All blockchain-based provenance systems trust the data that is recorded; the blockchain prevents tampering after recording, not at recording. This is widely acknowledged but no general solution exists.

5.5 How Verified Truth engages

CAP (Cartulary Inc, planned as a separate Delaware C-Corp licensing CAP primitives from EquiWork) is the framework's engagement with supply chain provenance. The architectural posture is:

• Compose with GS1. CAP can use GS1 Digital Link as one identity input among others. No reinvention of identifier schemes.
• Compose with HL7 FHIR for pharmaceuticals, with industry standards for other verticals. Each vertical has its conventions; CAP adapter layers integrate with them.
• Add the agreement-formation layer. Existing supply chain provenance starts at the warehouse door of the producing organisation. CAP also records the agreements that produced the goods — the contributor relationships, the licensing terms, the technology transfer, the IP. This is what distinguishes CAP from IBM Food Trust style systems.
• Add the human approval semantics. Existing systems log logistics events; CAP records the human approvals associated with each meaningful state transition.

The first commercial wedge is wine via Tasting & Toasting (T&T), with first pilot conversation underway with Stara Winna Góra in Poland. The choice of wine as first vertical is deliberate: wine has high per-unit value, complex provenance (vineyard → winemaker → bottling → distributor → retailer → consumer), strong existing identification practices, and consumers willing to pay for verified provenance. It is also small enough that a startup can engage seriously with first partners rather than being absorbed into a large incumbent's stack.

What CAP does not try to do:

• It does not solve the physical-digital binding problem. We compose with existing solutions (holographic seals, NFC tags, etc.) per partner choice.
• It does not solve cross-vertical universal interoperability. The architecture supports multiple verticals from a single substrate, but each vertical requires real per-vertical integration work.

5.6 Honest note

Engagement gaps in this category:

• DSCSA implementation details. We know the regulation; we have not read implementation guides.
• Specific luxury provenance platforms (Aura, Arianee). Read at a high level; not deeply.
• The technical literature on physical-unclonable functions for object identity binding.
• The wine-industry-specific literature on existing provenance practices (Bordeaux classifications, AOC/PDO frameworks, organic certifications). For T&T to be credible in the wine vertical, this engagement is owed.

6. Digital Identity and Trust Services

6.1 Origins

The intellectual prehistory of digital identity is a sequence of approaches each addressing the limitations of its predecessor.

PGP / Web of Trust (Phil Zimmermann, 1991) introduced peer-issued cryptographic identity certificates with a decentralised trust graph. Anyone could sign anyone else's key; trust derived from the chain of signatures.

X.509 PKI (the X.509 standard dates to 1988; widespread deployment from the late 1990s) introduced hierarchical certificate authorities. Trust came from a small set of root CAs whose certificates were preinstalled in browsers and operating systems.

SAML (Security Assertion Markup Language, OASIS standard 2002) and OAuth/OIDC (2007 onwards) introduced federated identity: a user authenticates with an identity provider (Google, Microsoft, etc.) and the identity provider issues assertions to relying parties.

The self-sovereign identity (SSI) movement emerged around 2014, motivated by the recognition that federated identity centralises power in a small number of large identity providers. SSI proponents argued that users should hold their own credentials and present them as needed without an intermediary.

6.2 Development arc

The SSI movement produced two W3C standards that have become the technical backbone of the modern decentralised identity ecosystem:

• W3C Decentralized Identifiers (DIDs) v1.0 (W3C Recommendation 2022; v1.1 Candidate Recommendation 2026) defines a URI format did:method:identifier and the associated DID Documents containing public keys and verification methods. Multiple methods exist (did:key, did:web, did:ion, did:ethr, did:btcr, others) with varying maturity.
• W3C Verifiable Credentials (VCs) Data Model v2.0 (W3C Recommendation 2025) defines a data model for cryptographically signed claims with three roles: issuer, holder, verifier. The model supports selective disclosure for privacy.

In parallel, the EU developed eIDAS (Regulation EU 910/2014, in force 2014), establishing three levels of electronic signature (Simple, Advanced, Qualified) with the Qualified Electronic Signature (QES) having legal equivalence to handwritten signatures across the EU. The supporting framework includes Qualified Trust Service Providers (QTSPs) — accredited entities authorised to issue qualified certificates.

eIDAS 2.0 (Regulation EU 2024/1183) revised the framework in 2024 to introduce:

• The EU Digital Identity Wallet (EUDI Wallet) — a member-state-provided wallet that EU citizens use to manage qualified identity credentials.
• Qualified Electronic Attestations of Attributes (QEAAs) — verifiable claims about user attributes (age, address, qualifications, etc.).
• Convergence with W3C VC and DID standards.

6.3 Current state

The landscape in 2026 is layered:

• Federated identity (Google, Microsoft, Apple, Facebook OIDC providers) remains dominant for consumer authentication.
• Enterprise federated identity (SAML 2.0, OIDC) is the default for B2B SSO.
• PKI for server authentication (TLS certificates, Let's Encrypt) is universal infrastructure.
• W3C DID/VC standards are deployed in pilots and production for specific use cases: verified academic credentials (Blockcerts, Open Badges), professional licensing, supply chain attestations.
• eIDAS QES is widely used in EU government and regulated industry signing flows.
• eIDAS 2.0 EUDI Wallet rollout is phased through 2026-2030; large-scale pilots are active.

The relationship between W3C SSI standards and eIDAS 2.0 is converging: the EUDI Wallet supports W3C VC data formats; the underlying cryptographic primitives are shared.

6.4 Open problems

• Revocation. When a credential needs to be revoked, how does a verifier learn? Multiple approaches exist (certificate revocation lists, OCSP, status list 2021, BLS-aggregated revocation) but no clean answer.
• Recovery. If a user loses their wallet's private keys, what is the recovery story? Several social recovery and multi-factor approaches exist; none is universally adopted.
• Linkability. Privacy demands that a credential used across multiple verifiers cannot be correlated. Zero-knowledge proof techniques (BBS+ signatures, selective disclosure JWT) help but are not yet mainstream.
• Trust framework interoperability. Different jurisdictions have different trust frameworks (eIDAS in EU, NIST 800-63 in US, GovTech in Singapore). Cross-trust-framework recognition is still a manual mapping problem.
• Usability. End users find managing cryptographic credentials hard. The user experience problem is genuinely unsolved at scale.

6.5 How Verified Truth engages

Identity is necessary but not sufficient for the Verified Truth framework. The framework assumes good identity primitives and builds the event-and-approval layer above them.

• EquiWork currently uses EIP-712 signatures (a public Ethereum standard) as the identity primitive for binding agreement payloads. The signer's address is the canonical identity.
• Integration with eIDAS QES for EU-legal-weight signatures is a future option. The framework's architecture allows multiple signature primitives to be plugged in.
• W3C VC and DID are realistic future identity layer integrations. The framework's actor model can be expressed in DID syntax; signed claims can be wrapped in VC data structures.

What the framework adds above the identity layer:

• Continuous lifecycle of identity-bearing events. Identity standards prove "who signed this at moment T"; the framework records the chain of "what happened next" beyond that moment.
• Approval composition. Identity standards verify individual claims; the framework composes multiple approvals into canonical state transitions.
• Authority levels above raw signatures. A signature proves a key was used; the framework adds the layer of "and that key holder is authorised for this kind of approval in this context."

What the framework does not try to do:

• It does not propose a new identity standard. We compose with what exists.
• It does not address recovery, revocation, or linkability problems in identity. Those are problems for the identity layer to solve.

6.6 Honest note

Identity is the field where we engage most through integration rather than direct research. Areas of shallower engagement:

• The W3C VC v2.0 cryptography suites in detail (Data Integrity, BBS+, SD-JWT). We know they exist; we have not implemented or stress-tested.
• The eIDAS 2.0 trust framework specifics (rules for qualified trust service providers, the EUDI Wallet implementation requirements).
• Privacy-preserving identity literature (anonymous credentials, U-Prove, Idemix and its descendants).
• The trust-framework literature comparing eIDAS, NIST 800-63, OIX, and similar frameworks.

7. Academic Knowledge Provenance

7.1 Origins

The provenance of scientific knowledge has been a concern of universities, learned societies, and publishers since the seventeenth century — the founding of the Royal Society of London (1660), the Philosophical Transactions of the Royal Society (1665), and the conventions of attribution and peer review that grew up around them.

The modern computational treatment begins with bibliographic databases in the 1960s-1970s (Medline 1971, Chemical Abstracts going digital, Web of Science). The capacity to search the scholarly record was the first transformation.

The internet era brought the second transformation: the ability to cite with persistent links. The Digital Object Identifier (DOI) system, launched by the International DOI Foundation in 1998 and standardised as ISO 26324 (currently 2022 revision), provides persistent identifiers for digital objects (papers, datasets, books, preprints, grants). Crossref, founded in 2000, became the largest DOI registrar for scholarly publications.

The third transformation came with identifiers for people and organisations:

• ORCID (Open Researcher and Contributor ID), launched in 2012, provides persistent identifiers for individual researchers. 16-digit format (e.g., 0000-0002-1825-0097). Now exceeds 24 million records.
• DataCite, founded in 2009, became the major DOI registrar for research data. 92+ million records.
• ROR (Research Organization Registry), launched in 2019, provides open identifiers for research organisations, displacing fragmented previous systems (Funder ID, Ringgold, GRID).

7.2 Development arc

The persistent identifier infrastructure became the substrate for several developments:

Auto-population of researcher profiles. When a publisher registers a DOI for a new paper with author ORCID iDs, Crossref pushes the update to ORCID. The researcher's profile stays current automatically without manual data entry. Similar flows exist for datasets via DataCite.

Open citation graphs. The Initiative for Open Citations (I4OC) and subsequent efforts opened the citation links Crossref maintains. By the mid-2020s, the open scholarly citation graph contained over 2 billion citations and was queryable through APIs.

OpenAlex (OurResearch, launched 2022), the successor to Microsoft Academic Graph, aggregates approximately 240 million scholarly works from Crossref, ORCID, DataCite, and additional sources into a single open queryable graph. It is becoming the de facto research provenance API.

Research data management. A parallel infrastructure developed for research data: Dataverse (Harvard), Figshare, Zenodo (CERN/OpenAIRE), Dryad. These repositories assign DOIs to datasets and preserve them long-term.

Electronic laboratory notebooks (ELNs) and laboratory information management systems (LIMS) emerged as commercial products (Benchling, LabArchives, eLabFTW, sciNote). They digitise the historical paper laboratory notebook.

The FAIR Data Principles (Wilkinson et al., "The FAIR Guiding Principles for scientific data management and stewardship", Scientific Data 3:160018, 2016) — Findable, Accessible, Interoperable, Reusable — became the dominant framework for thinking about research data infrastructure. FAIR is a set of fifteen aspirational principles, not a standard; it has been adopted by funders (NIH, Horizon Europe, ANR) as policy requirements.

7.3 Current state

The modern scholarly information infrastructure has solved some problems and not others.

Solved (more or less):

• Identifying papers, datasets, researchers, and organisations with persistent identifiers.
• Citation graphs queryable at scale.
• Open metadata for the bulk of the scholarly record.
• Automated currency of researcher profiles.

Partially solved:

• Research data preservation (FAIR principles are aspirational; uneven implementation).
• Electronic laboratory notebooks (commercial products exist; uptake is uneven, especially outside well-funded research areas).
• Cross-platform research workflows (some tools interoperate; many do not).

Not solved:

• The reproducibility crisis in many fields (psychology, biomedical research, materials science). Even well-documented papers often cannot be reproduced.
• Negative results preservation. Failed experiments are rarely published or preserved. The community knows what works; it does not systematically know what does not.
• Supervisory and mentorship lineage. PhD advisor relationships, postdoc training chains, the propagation of methods between laboratories — none of this is structurally captured.
• Laboratory equipment provenance. Which centrifuge was used, when calibrated, by whom — almost never linked to the research outputs it produced.
• Industrial application chains. When fundamental research becomes commercial technology, the chain is invisible in current scholarly infrastructure.

7.4 Open problems

Beyond the gaps listed above, active research questions include:

• Reproducibility as a first-class research output. Several efforts (registered reports, preregistration, reproducibility studies) are trying to give reproducibility the status of original research.
• Provenance of AI-generated scientific content. As AI tools enter the research workflow (writing, hypothesis generation, image analysis), distinguishing AI contributions becomes important but is underspecified.
• Long-term preservation. Funders typically require ten years of preservation. The scientific record needs longer. The 100+ year preservation problem is being worked on (digital preservation community, OAIS reference model ISO 14721, Internet Archive, Software Heritage) but is not solved.
• Connections between scientific output and policy or industrial application. Funders increasingly want to see this chain; current infrastructure does not natively capture it.

7.5 How Verified Truth engages

The Scientific Knowledge Passport is the framework's engagement with this space. The current state is concept + one illustrative case study (Professor Mikhail Goman, drawn from his publicly available academic record at De Montfort University, ResearchGate, Google Scholar, and SUPRA project documentation; built strictly from public sources).

The Scientific Knowledge Passport architecture:

• Builds on ORCID as the identity foundation for researchers.
• Builds on DOI / Crossref / DataCite for publication and dataset identifiers.
• Builds on ROR for institutional affiliation.
• Builds on FAIR principles for data management practices it integrates with.
• Adds the layers above the published surface: research evolution between publications (the years of work that produced a paper), experimental evidence (datasets, simulations, failed runs), laboratory equipment provenance, supervisory and mentorship lineage, industrial application chains.

The key architectural commitment is that the Scientific Knowledge Passport assumes existing infrastructure works. We do not replace ORCID. We do not create a competing DOI scheme. We compose with what exists and add the layers it does not address.

What the Scientific Knowledge Passport does not try to do:

• It does not solve the reproducibility crisis. It can record what was done; whether the science was right is a question for science, not infrastructure.
• It does not replace lab notebooks (ELNs) or LIMS systems. It composes with them as evidence sources.
• It does not propose a new scholarly publishing model. It records what scholars do under whatever publishing model they participate in.

The current status of the Scientific Knowledge Passport is CONCEPT plus the Goman case study. No production deployment exists. A real pilot with a research institution is the next step. We do not claim to have built this; we claim to have specified an architecture that we propose works.

7.6 Honest note

This is the field where Verified Truth's claims are most aspirational. Specific gaps in engagement:

• The reproducibility crisis literature in detail (Open Science Collaboration 2015 in psychology; Begley & Ellis 2012 in cancer biology; Munafò et al. 2017 on the manifesto for reproducible science).
• Digital preservation standards in detail (OAIS reference model ISO 14721; PREMIS; Software Heritage protocol).
• Specific ELN and LIMS systems (Benchling, LabArchives, eLabFTW) at implementation level.
• Russian-language academic provenance practices. Given the founder's bilingual context and the TsAGI/Russian academic tradition, this gap is particularly notable.
• The science of science literature (Wang & Barabási, The Science of Science, 2021) which addresses many of the problems the Scientific Knowledge Passport tries to address from a research perspective.

8. Theoretical Foundations — Speech Acts and Event Sourcing

8.1 Speech act theory: origins

The intellectual founding of speech act theory is conventionally placed with J.L. Austin's William James Lectures at Harvard in 1955, published posthumously in 1962 as How to Do Things with Words (Oxford University Press). Austin's central insight was that some utterances do not describe states of the world (constatives) but perform actions in saying them (performatives). When a person says "I do" in a marriage ceremony, "I promise to pay you tomorrow", "I name this ship the Queen Elizabeth", or "I sentence you to ten years" — they are doing something by speaking, not describing something.

Austin classified speech acts into three layers:

• Locutionary act — the act of saying something with definite sense and reference
• Illocutionary act — what the speaker does in saying (asserting, asking, ordering, promising, naming, sentencing)
• Perlocutionary act — the effect produced by saying (persuading, alarming, convincing, deterring)

The conditions under which a performative succeeds — felicity conditions — were Austin's central technical contribution. A performative is infelicitous (does not succeed) if conditions are not met: the speaker lacks authority (a layperson cannot sentence someone), the formula is not followed correctly, the participants are inappropriate, the context is wrong.

John Searle systematised Austin's framework in his 1969 book Speech Acts: An Essay in the Philosophy of Language (Cambridge University Press), providing a more rigorous taxonomy and analysis. Searle classified illocutionary acts into five categories: assertives (committing to truth), directives (attempting to get the hearer to do something), commissives (committing the speaker to a future action), expressives (expressing psychological states), and declaratives (changing reality by declaring it changed).

8.2 Speech act theory: development arc

Through the 1970s and 1980s, speech act theory was developed in multiple directions:

• Philosophical refinement by Searle himself (Expression and Meaning, 1979; Intentionality, 1983; The Construction of Social Reality, 1995), and by critics (Habermas, Derrida's "Signature Event Context", 1972).
• Linguistic application in pragmatics: Grice's cooperative principle, Sperber and Wilson's relevance theory.
• Computational linguistics, where speech acts became central to dialogue systems and conversational AI from the 1970s onward.
• Legal theory, where the performative/constative distinction provided a framework for understanding contractual language, judicial pronouncements, and legislative acts.

The legal application is particularly relevant to Verified Truth. Contracts are performative utterances par excellence: "I agree" does not describe an agreement; it creates one. The signing of a contract is a declarative speech act in Searle's taxonomy. The felicity conditions of contract formation (capacity, consideration, mutual assent, legality of object) parallel the felicity conditions Austin and Searle analysed at a philosophical level.

8.3 Event sourcing: origins

Event sourcing as a software architecture pattern has informal origins in financial accounting (ledger entries, never edited, always appended) and in distributed systems research. Its codification as a software design pattern is associated with Greg Young in the mid-2000s; Martin Fowler's 2005 article "Event Sourcing" on his website (https://martinfowler.com/eaaDev/EventSourcing.html) is one of the early systematic treatments.

The core idea is to store the changes to state rather than the current state itself. Any current view of the system is computed by replaying the changes from the beginning (or from a snapshot, for performance). The pattern is the operational dual of accounting's debit-credit discipline.

8.4 Event sourcing: development arc

Event sourcing developed alongside Command Query Responsibility Segregation (CQRS) and Domain-Driven Design (DDD) in the 2000s and 2010s. The community around these patterns produced substantial implementation literature: books by Vaughn Vernon, Adam Dymitruk, Alberto Brandolini's EventStorming methodology, and frameworks (EventStore, Axon, Kafka with event log retention, AWS EventBridge).

By the mid-2020s, event sourcing is a mature software pattern with mainstream adoption in financial systems, e-commerce platforms, audit-heavy enterprise software, and increasingly in regulatory-compliance-oriented systems.

8.5 Current state of these foundations

Speech act theory is a mature philosophical and linguistic framework. It is widely taught, has substantial primary and secondary literature, and is regularly applied in dialogue system design, legal theory, and political philosophy. It has not produced an executable system specification language directly; it has shaped how others think about the relationship between language, action, and social reality.

Event sourcing is a mature software pattern with active community development. Its conceptual foundations are settled; the engineering trade-offs are well-understood. Open problems include performance at very large scale, schema evolution, and the challenge of operating event-sourced systems alongside CRUD systems.

8.6 Open problems

For speech act theory in computational systems:

• Bridging from philosophical speech act theory to executable contract specifications. Languages like DAML (Digital Asset Markup Language) gesture at this; the bridge is not formalised.
• Multi-agent felicity conditions. When AI agents participate alongside human actors, the felicity conditions for AI-issued speech acts are an open question that the EU AI Act, Section F of our Claims Discipline, and active academic literature all touch.
• Cross-cultural and cross-jurisdictional speech act semantics. The performative force of words varies across legal systems; computational systems that operate across jurisdictions must handle this variation.

For event sourcing:

• Hybrid CRUD/event-sourced architectures. Most production systems use event sourcing for some bounded contexts and CRUD elsewhere. The interfaces between these are not standardised.
• Schema evolution at scale. When event schemas change, replaying old events against new code paths is nontrivial. Multiple approaches exist; none is universally adopted.

8.7 How Verified Truth engages

Verified Truth engages with both foundations at the conceptual level.

From speech act theory, we adopt:

• The performative/constative distinction. Verified Events are performative — recording an event is not describing it; it constitutes it as part of the record.
• The felicity conditions framework. The framework's separation of declaration, evidence, analysis, verification, approval, and canonical state can be read as making explicit what Austin and Searle treated as felicity conditions for contracts: who had authority, what evidence supported the act, whether the procedure was followed.
• Searle's category of declaratives as the most relevant illocutionary category for the framework's canonical state transitions. When a qualified human authority approves a Verified Event, the act declares the state changed — it does not describe a change that happened independently.

From event sourcing, we adopt:

• Append-only event storage as architectural commitment. State derives from events; events are never edited.
• Bounded contexts (from the broader DDD tradition that surrounds event sourcing). Different domains (agreements, objects, knowledge) are bounded contexts that share the same architectural skeleton but have their own vocabularies.
• Replay-based view construction. Current views of any state are derivable from the event chain. This is what makes verification possible: any third party can replay the chain and confirm the state.

What the framework adds:

• Both philosophical foundations are general; the framework operationalises them for specific domains (agreements, objects, knowledge) with specific authority requirements and evidence types.
• Speech act theory does not include an audit chain or cryptographic integrity primitives; event sourcing as a software pattern does not include philosophical justification or authority semantics. The framework composes both.

What the framework does not try to do:

• It does not advance speech act theory philosophically. It applies a mature philosophical framework to a particular engineering problem.
• It does not advance event sourcing as a software pattern. It uses a mature pattern.

8.8 Honest note

These foundations are read at the primary source level (Austin 1962, Searle 1969 for speech acts; Fowler's writing for event sourcing) but the secondary literature is engaged with less deeply.

• The legal-philosophical literature applying speech act theory to contracts and constitutions (Reidenberg, Hildebrandt, Schauer, others) is read at the citation level, not synthesised.
• The dialogue systems literature applying speech act theory to conversational AI from the 1970s onward.
• The CQRS and Domain-Driven Design literature beyond Fowler's foundational pieces.
• EventStorming as a methodology (Brandolini's Introducing EventStorming) which is the practical operationalisation of event sourcing in design workshops.

These gaps are part of why this document is v1.0. A v2.0 would deepen each.

Closing

What this document does

This map gives a reviewer the conceptual geography of the fields the Verified Truth Ecosystem operates within. For each field, the reviewer can:

• Trace where the field came from (founding work, key contributors)
• Understand the current state (mature standards, active deployments)
• See what is still open (research questions, unsolved problems)
• Locate where Verified Truth fits (what we borrow, what we add, what we do not do)
• Identify our gaps (what we have not yet engaged with)

What this document does not do

This map does not exhaustively cover any single field. Each of the eight categories is the subject of multi-decade research traditions, hundreds of important papers, and ongoing development. The treatment here is calibrated to give a sophisticated reviewer the entry points and our current position. A reviewer who already knows a field will find the treatment of that field thin; a reviewer who does not will find it useful as orientation.

Version and revision

• Version 1.0 (2026-06-26). First narrative landscape map.
• A v2.0 would deepen the secondary literature engagement in each category. The honest notes in each section identify the specific gaps.
• The structured complement to this document is the Reference Bibliography at truth.equiwork.io/research/references, which lists individual sources with structured fields.

Companion documents

• truth.equiwork.io/research/references — Reference Bibliography (Deliverable E)
• VERIFIED_TRUTH_COMPARISON_MATRIX.docx — Comparison Matrix (Deliverable B)
• truth.equiwork.io/research/whats-new — Seven structural moves against prior art (Deliverable C)
• truth.equiwork.io/research/claims-discipline — Status-tagged claim inventory (Deliverable D)
• RESPONSE_TO_SCIENTIFIC_REVIEWER.md — Reviewer Response Memo (Deliverable F, private)
• truth.equiwork.io — Public portal (English)
• truth.equiwork.io/ru/ — Public portal (Russian)

Status of the six deliverables

This document is Deliverable A of six requested in Mikhail Goman's scientific review. All six are now complete:

• ✅ A — Research Landscape Map (this document) · truth.equiwork.io/research/landscape
• ✅ B — Comparison Matrix · VERIFIED_TRUTH_COMPARISON_MATRIX.docx
• ✅ C — What Is New Here? · truth.equiwork.io/research/whats-new
• ✅ D — Claims Discipline · truth.equiwork.io/research/claims-discipline
• ✅ E — Reference Bibliography · truth.equiwork.io/research/references
• ✅ F — Reviewer Response Memo (private correspondence to the reviewer)

Acknowledgement

This document exists because Mikhail Goman's review insisted that strong claims about a field require visible engagement with the field's prior art. The eight categories surveyed here are the fields the Verified Truth Ecosystem makes claims about. The treatment is honest about depth: where engagement is solid, the section names the primary sources and engages with them; where engagement is shallow, the honest notes at the end of each section name what is missing.

The map is incomplete because no map of eight interlocking research fields can be complete in 50 KB of text. The mapping itself is the point: a reviewer who reads this knows where to look next.