diff --git a/docs/claimantmodel/CoreModel.md b/docs/claimantmodel/CoreModel.md
index 294afb2a94..22ea9ec659 100644
--- a/docs/claimantmodel/CoreModel.md
+++ b/docs/claimantmodel/CoreModel.md
@@ -1,59 +1,74 @@
# Claimant Model
-This paper introduces an intuitive, standalone model for a common scenario where one party needs to perform an action which is reasonable only if a claim made by another party is true. The Claimant Model allows formally verifiable constructs to be bound to a messy reality.
+The Claimant Model provides a framework for analyzing trust in systems. It helps map formal cryptographic or verifiable constructs to real-world scenarios where one party needs to rely on information provided by another.
-## Model
+## Core Roles
-*This model describes roles, not actors. In a concrete deployment of this model, the same actor may play multiple roles, or multiple actors may need to work together to cover a role.*
+*Note: This model describes **roles**, not specific actors. In practice, a single actor might play multiple roles, or multiple actors might share a single role.*
-There is a **Claimant** that makes a **Claim** that is relied upon by a **Believer** as a precondition to take an action they would not have taken if the claim was false. Claims are represented by signed **Statements**. The veracity of a Claim can be verified by a **Claim Verifier**, who will notify a **Claim Arbiter** of any false Claims.
+The model defines five key roles:
-## Example: Certification Claims
+* **Claimant**: The party that makes a **Claim**.
+* **Claim**: A falsifiable logical statement made by the Claimant.
+* **Statement**: The concrete data (usually signed) that represents the Claim.
+* **Believer**: The party that relies on the Claim to take an action. They would not take this action if the Claim were false.
+* **Claim Verifier**: The party that checks whether the Claim is actually true.
+* **Claim Arbiter**: The party that handles disputes and takes action if a false Claim is discovered.
-As a concrete example of the Claimant Model in action, we'll model one of the core claims made by [Certificate Authorities](https://en.wikipedia.org/wiki/Certificate_authority) (CAs).
-A CA should create and sign a Certificate, *only at the request of the Domain Owner*.
-A user's web browser receives this cert when attempting to establish a secure connection to a domain, and proceeds with the connection only if it was signed by a CA that the Browser Vendor has blessed.
-In the event of a CA issuing bad certificates, the Browser Vendor can protect their users by removing the CA from the blessed set.
-The only party which can verify that a certificate was issued under authorization is the Domain Owner.
+## Example: Certificate Transparency
-
-- ClaimCERT
-- "I, ${CA}, am authorized to certify $pubKey for $domain"
-- StatementCERT
-- X.509 Certificate
-- ClaimantCERT
-- Certificate Authority
-- BelieverCERT
-- Web Browser
-- VerifierCERT
-- Domain Owner
-- ArbiterCERT
-- Browser Vendor
-
+To see the model in action, consider how it applies to web security and Certificate Authorities (CAs).
-The Browser has sufficient trust in the CA to employ a strategy of [Trust But Verify](#trust-but-verify), however this model alone does not provide a mechanism to ensure that any StatementCERT relied on by BelieverCERT can be discovered by VerifierCERT. This is why Certificate Transparency was created; to allow verifiers to discover all of the certificates that have been believed.
-Using Logs to provide this discoverability is described in [Claimant Model: Logs](Logs.md).
+* **Background**: A CA signs a digital certificate for a domain. A web browser trusts this certificate to establish a secure connection.
+* **The Tension**: A CA should only issue a certificate if the domain owner requests it. If a CA issues a certificate maliciously or by mistake, the browser relies on a false claim.
-
+Here is how we map this to the Claimant Model roles for this specific domain:
-# Claim Requirements
-* The Statement for any claim must be signed by the Claimant to ensure that it is immutable and non-repudiable.
-* It must be possible to generate the Claim from the Statement without any additional context.
-* Claims must be [falsifiable](https://en.wikipedia.org/wiki/Falsifiability).
-
-## Compound Claims
-When the Claim is composed of multiple subclaims, the Verifier role must be covered by actors that can verify all components of the Claim.
+* **Cert Claim**: *"I, [CA Name], am authorized to certify [Public Key] for [Domain]."*
+* **Cert Statement**: The X.509 Certificate itself.
+* **Cert Claimant**: The Certificate Authority.
+* **Cert Believer**: The Web Browser (which connects based on the cert).
+* **Cert Verifier**: The Domain Owner (the only one who knows if they requested the cert).
+* **Cert Arbiter**: The Browser Vendor (who can remove the CA from the trusted set if they misbehave).
-For example, imagine a ClaimantPRIME that provides BelieverPRIME with an integer covered by ClaimPRIME: *"This is prime, and is uniquely issued to $believerID"*. This is a compound Claim: verification would need to confirm 1) the primality of the integer, and 2) that no other Believer had been issued the same value.
+> [!NOTE]
+> **Notation Note:** In complex systems, we often apply the Claimant Model at multiple layers (e.g., the certificate layer and the log layer). To distinguish roles at different layers, we use descriptive prefixes (like **Cert** Claimant or **Log** Claimant). An alternative way of formatting this in older versions of this documentation was using superscripts (e.g., ClaimantCERT), but this was deprecated in favor of straight text for accessibility and readability.
-# Believer Strategies
-## Trust But Verify
-If the Believer has sufficient trust to believe the Claimant for some action, Trust But Verify allows the Believer to take the Claim on face value, and perform the action before the Claim Verifier verifies this Claim. This system requires all Claims trusted by the Believer to be discovered by a Verifier, and this is what is meant by transparency. Such systems generally include a Claim Arbiter that closes the feedback loop by notifying Believers of bad Claimants, and of new Claimants that can be trusted.
+In this example, the Browser has sufficient trust in the CA to employ a "**Trust But Verify**" strategy. However, the model above doesn't guarantee that the **Cert Verifier** (Domain Owner) will ever *see* the certificate that the **Cert Believer** relied on. This gap is why Certificate Transparency was created—to make all issued certificates discoverable.
-## Verify Before Use
-If the Believer does not have sufficient trust in the Claimant to perform an action without verifying the claim, then the Believer must wait until the claim is verified. It is attractive to imagine that the veracity of a Claim starts UNKNOWN and then is verified to be either TRUE or FALSE, and this will hold for all time. Reality isn't as kind as this, and the veracity of claims is best considered a degree of confidence that can be very volatile as new data points are brought to light. Believers need to determine what degree of confidence they require before proceeding with an action. The role of the Arbiter is less critical in this strategy, but they can still be included to prevent bad Claimants from wasting other actor's time.
+(For details on how logs fill this gap, see [Claimant Model: Logs](Logs.md)).
+
+## Claim Requirements
+
+For the model to work effectively, Claims and Statements must meet certain criteria:
+* **Signed Statements**: The Statement for any claim must be signed by the Claimant to ensure it is immutable and non-repudiable.
+* **Self-Contained**: It must be possible to extract the Claim from the Statement without needing additional context.
+* **Falsifiable**: Claims must be able to be proven false.
+
+### Compound Claims
+
+Sometimes a Claim is composed of multiple sub-claims. In these cases, the Verifier role must be covered by actors that can verify all components of the Claim.
+
+*Example:* Imagine a **Prime Claimant** that provides a **Prime Believer** with an integer covered by a **Prime Claim**: *"This integer is prime, and it is uniquely issued to [Believer ID]."* This is a compound claim because verification requires checking two different things:
+1. Is the integer actually prime?
+2. Has this integer been issued to anyone else?
+
+## Believer Strategies
+
+How a Believer acts on a Claim depends on their level of trust. There are two primary strategies:
+
+### 1. Trust But Verify
+If the Believer has sufficient trust in the Claimant, they may take the Claim at face value and act on it *before* it is verified. This is how Certificate Transparency works.
+* **Requirement**: This strategy requires all Claims to be discoverable by Verifiers so that accountability is possible after the fact.
+* **Role of Arbiter**: Critical here to penalize bad Claimants and protect future Believers.
+
+### 2. Verify Before Use
+If the Believer does not have sufficient trust, they must wait until the Claim is verified before acting.
+* **Nuance**: Reality is messy, and "verified" often means reaching a certain level of confidence rather than absolute certainty. The Believer must decide what degree of confidence they require.
+* **Role of Arbiter**: Less critical for blocking actions, but still useful for penalizing bad Claimants to save others' time.
## Discussion
-A Believer can be flexible about which strategy they employ. For example: Trust But Verify might be reasonable for a low-stakes action based on a Claim from a Claimant with a good reputation; allowing the action to be taken without blocking. As the potential loss involved in the action increases, the Believer will demand increased trust in the Claimant and/or a higher degree of verification. Some systems may also provide other incentives, such as some promise of compensation from the arbitration process (e.g. FSCS).
+
+A Believer can be flexible. They might use "Trust But Verify" for low-stakes actions or highly reputable Claimants, but switch to "Verify Before Use" as the risk increases.
diff --git a/docs/claimantmodel/Logs.md b/docs/claimantmodel/Logs.md
index 912b050088..ab76f97a99 100644
--- a/docs/claimantmodel/Logs.md
+++ b/docs/claimantmodel/Logs.md
@@ -1,90 +1,115 @@
# Claimant Model: Logs
-This doc presents a model for transparent ecosystems built around logs. This doc requires understanding the core [Claimant Model](CoreModel.md).
+This document applies the Claimant Model to transparent ecosystems built around logs. It requires an understanding of the core [Claimant Model](CoreModel.md).
-Log Transparency as described here should be applied to situations where the Claimant Model has already been established for the domain claims. It does not cover situations where you “just want to write to a log”.
+Log Transparency should be used when you have already established a Claimant Model for your specific domain (e.g., Certificate Transparency) and need a way to ensure that claims are discoverable. It is not for situations where you "just want to write to a log."
## Purpose of Log Transparency
-**The main purpose of transparency built around logs is *discoverability of Claims***.
-
-A Claim is discoverable if it can be found by the Verifier without information being passed to them by the Believer. This property is essential when Believers are employing Trust But Verify and the identity of all Verifiers does not form part of the Believer’s [TCB](https://en.wikipedia.org/wiki/Trusted_computing_base).
-
-More formally: *Any claim believed by any honest Believer must be eventually verified by an honest Verifier*.
-
-Another way to conceptualize this is that Logs provide a verifiable transport mechanism to ensure that any Claim that a Believer relies on will be eventually discovered by the Verifier.
-
-# Model
-Log Transparency is another application of the Claimant Model to solve a transport problem in what we will refer to as SystemDOMAIN; it provides a mechanism for all StatementDOMAIN relied upon by BelieverDOMAIN to be discovered by VerifierDOMAIN.
-
-## SystemLOG
-
-A log operator maintains an append-only list of StatementDOMAIN, and presents all clients with the same list.
-The log produces and signs checkpoints to commit to the state of the list as it grows, and committments to data to by a checkpoint should be cryptographically verifiable.
-A StatementDOMAIN should only be believed once its inclusion in the log has been verified.
-Clients of the log should verify that any new checkpoints they receive are consistent with any previous checkpoint that they have relied on, and checkpoints can be shared amongst clients to detect any inconsistencies in the list of data being presented.
-
-
-- ClaimLOG
-- "I make available a globally consistent, append-only list of StatementDOMAIN"
-- StatementLOG
-- Log Checkpoint
-- ClaimantLOG
-- Claim Log
-- BelieverLOG
-- BelieverDOMAIN and VerifierDOMAIN
-- VerifierLOG
-- Log Verifier
-- ArbiterLOG
-- Log Arbiter
-
-
-### Artifacts
-
-- Log Checkpoint (aka STH)
-- a signed statement by the Claim Log which declares the number of Claims in the log, and represents a verifiable commitment to the contents of the log.
- The signature on a Checkpoint states nothing about the veracity of any ClaimDOMAIN, but asserts that:
-
-- This Checkpoint is consistent with all earlier Checkpoints; and
-- All StatementDOMAIN committed to by this Checkpoint are immutable and discoverable
-
-
-
-
-### Roles
-
-- Claim Log (ClaimantLog)
-- maintains the log, appends well-formed Statements, and periodically produces Checkpoints. All Statements must be made available to VerifierDOMAIN, and commitments made available to all roles.
-- Log Verifier (VerifierLog)
-- watches a Claim Log, verifying that all Checkpoints seen by this verifier are consistent (i.e. represent a single lineage of the Log). Effectively verifies inclusion for all leaves that Checkpoints commit to. Note that this role is only concerned with the commitments to the Claims, not the Claims themselves.
-- Log Arbiter (ArbiterLog)
-- acts upon evidence of Claim Log misbehaviour (e.g. distrusts it, publishes the evidence so others can make their own decisions). Any actor can appeal to this entity if logs misbehave. Example situations where a report will be investigated:
-
-- Log Verifier appeals with proof of inconsistent Checkpoints
-- Claim Writer appeals if the Log won’t accept valid Claims
-- Believer appeals if the log is not available with sufficient uptime
-
-This mechanism doesn’t always require proof, e.g. you can’t prove that a log was not serving inclusion proofs to you. It will probably contain human judgement.
-- Checkpoint Witness
-- any party that shares a Checkpoint they have seen. Sharing Checkpoints provides a mechanism to allow them to be more broadly checked for consistency. Only entries committed to by a Checkpoint obtainable from a different security domain than the Log are tamper-evident, and third party Witnesses support this resilience. This role does not map to a role in SystemLOG, but supports VerifierLOG.
-
-
-- Claim Writer
-- writes Claims to the Log. This role doesn’t map to a role in the Claimant Model, but someone has to do it. In many systems this will be the Claimant, but it could also be the Believer, or another third party.
-
-### Relationship Graph
-This shows which roles must know about the actors playing the other roles before any of the machinery starts moving. For example, the Believer must know about the Claimant ahead of time because they need to have some basis on which to trust a Claim and verify its authenticity.
+**The main purpose of transparency built around logs is the *discoverability of Claims*.**
+
+A Claim is discoverable if the Verifier can find it without relying on the Believer to pass it to them. This property is essential when Believers use a "Trust But Verify" strategy and cannot guarantee they will report every claim they see.
+
+More formally: *Any claim believed by any honest Believer must be eventually verified by an honest Verifier.*
+
+In other words, Logs provide a verifiable transport mechanism to ensure that any Claim a Believer relies on will eventually be discovered by the Verifier.
+
+# The Model
+
+Log Transparency applies the Claimant Model to solve a transport problem in the **Domain System** (the application layer, like certificates). It ensures that all **Domain Statements** relied upon by a **Domain Believer** can be discovered by the **Domain Verifier**.
+
+## The Log System
+
+In this layer, the Log itself becomes the system we are modeling:
+
+* **Log Claim**: *"I make available a globally consistent, append-only list of Domain Statements."*
+* **Log Statement**: The Log Checkpoint (signed by the log).
+* **Log Claimant**: The Claim Log (operator).
+* **Log Believer**: Both the **Domain Believer** and the **Domain Verifier**.
+* **Log Verifier**: The Log Verifier (watches for consistency).
+* **Log Arbiter**: The Log Arbiter (handles disputes).
+
+### Key Artifacts
-Believer, Claimant, Claim Verifier, and Claimant Arbiter are all for SystemDOMAIN.
+* **Log Checkpoint (aka STH)**: A signed statement by the **Log Claimant** declaring the number of entries in the log and committing to its contents. The signature does not verify the *veracity* of the domain claims; it only asserts that:
+ * This Checkpoint is consistent with all earlier Checkpoints.
+ * All Domain Statements committed to by this Checkpoint are immutable and discoverable.
-
+### Roles in the Log System
-
+* **Log Operator (Log Claimant)**: Maintains the log, appends valid Statements, and periodically produces Checkpoints. All Statements must be made available to Domain Verifiers.
+* **Log Verifier**: This role ensures the integrity and availability of the log. It encompasses two primary responsibilities that are often handled by different actors:
+ 1. **Consistency Verification**: Ensuring that all Checkpoints represent a single, append-only lineage. In practice, this is often performed by independent **Witnesses** (see [C2SP Witness](http://c2sp.org/tlog-witness) and the [Witness Network](https://witness-network.org/)) who verify checkpoints without necessarily downloading the full log contents.
+ 2. **Data Availability**: Confirming that all Domain Statements committed to by the checkpoints are actually available. This is performed by actors who download the full log, or by using auditing tools like Tessera's [fsck](https://github.com/transparency-dev/tessera/tree/main/cmd/fsck).
+
+ *Note: Remember that the Log Verifier is a role, not an actor; it is common for multiple distinct actors to share this responsibility to cover both jobs.*
+* **Log Arbiter**: Acts on evidence of log misbehavior (e.g., presenting inconsistent checkpoints or denying service).
+* **Claim Writer**: The party that writes claims to the log. This might be the Domain Claimant, the Domain Believer, or a third party.
+
+### Relationship Graph
+
+This shows which roles must know about each other before the system can operate.
+
+```mermaid
+graph TD
+ subgraph "Domain System"
+ DB[Domain Believer]
+ DC[Domain Claimant]
+ DV[Domain Verifier]
+ DA[Domain Arbiter]
+ end
+
+ subgraph "Log System"
+ LO[Log Operator]
+ LV[Log Verifier]
+ LA[Log Arbiter]
+ W[Witness]
+ end
+
+ %% Relationships
+ DB -->|Trusts & Relies on| DC
+ DV -->|Verifies claims of| DC
+ DV -->|Reports false claims to| DA
+ DA -->|Notifies of bad actors| DB
+
+ %% Log interactions
+ DC -->|Submits statements to| LO
+ DB -->|Verifies proofs bound to| LO
+ DV -->|Consumes full log to discover claims| LO
+
+ W -->|Verifies consistency of| LO
+ LV -->|Reports log misbehavior to| LA
+
+ %% Role Overlap
+ DV -. Acts as .-> LV
+ W -. Acts as .-> LV
+```
+
+> [!NOTE]
+> **Witness Behavior:** While the diagram shows the Log Verifier role reporting misbehavior to the Arbiter, independent **Witnesses** often operate passively. They verify consistency and sign checkpoints that are correct, but if they encounter an inconsistent checkpoint, they simply refuse to sign it. The absence of a quorum of witness signatures is what signals that the log may be compromised, rather than an active report being filed.
+
+# Appendix
-# Interesting Edge Cases
## Transitive Signing
-The signature on each individual StatementDOMAIN can be omitted if both of the following hold:
-* ClaimantDOMAIN and ClaimantLOG are the same actor; and
-* Every actor that is BelieverDOMAIN is also BelieverLOG
-The signature on the Checkpoint effectively transitively signs each of the Claims within the log. This is what the [Go SumDB](https://blog.golang.org/module-mirror-launch) does. The Claim here is “*I, ${SumDB}, commit to $hash as the checksum for $module at $version*”. This is falsifiable; correct behaviour can be verified by confirming that no two entries committed to by the log have the same module & version, but different checksums.
+The signature on each individual **Domain Statement** can be omitted if both of the following hold:
+1. The **Domain Claimant** and the **Log Claimant** are the same actor.
+2. Every actor that is a **Domain Believer** is also a **Log Believer**.
+
+In this case, the signature on the Checkpoint transitively signs each of the Claims within the log. This is how the [Go SumDB](https://blog.golang.org/module-mirror-launch) works. The claim is: *"I, SumDB, commit to [Hash] as the checksum for [Module] at [Version]."* This is falsifiable because correctness can be verified by confirming that no two entries have the same module and version but different checksums.
+
+## Practical Deployment & Proof Distribution
+
+While the Claimant Model describes abstract roles, the security and privacy of a real-world system depend heavily on how **Domain Believers** obtain and verify proofs.
+
+There are two primary patterns for distributing inclusion proofs:
+
+### 1. Online Lookup
+In this model, the Believer receives a statement and queries the Log Operator directly to fetch a proof of inclusion.
+* **How it works**: The Believer asks the log: "Is this entry included, and what is the current checkpoint?"
+* **Trade-offs**: This is simple to implement but introduces privacy leaks (the log operator learns what the believer is looking up) and requires the log to be highly available to handle lookup traffic from all believers.
+
+### 2. Offline Inclusion Proofs (Bundled)
+This is the more modern and prevalent pattern. Instead of the Believer fetching proofs, the **Domain Claimant** (or a submitter) logs the entry, fetches the proof, and bundles it directly with the object being distributed.
+* **How it works**: The Believer is given the data and an offline proof (see the [C2SP tlog-proof spec](https://c2sp.org/tlog-proof)). The Believer verifies the log's signature on the checkpoint (and potentially witness signatures) and checks the Merkle proof locally.
+* **Impact**: This moves transparency towards a **richer signature scheme**. A valid claim is no longer just a cryptographic signature from a key; it is a signature *plus* a verifiable proof that the signature was made public in a consistent log. This eliminates privacy leaks to the log and removes the log from the critical path of verification.
diff --git a/docs/claimantmodel/Maps.md b/docs/claimantmodel/Maps.md
index 6c76c35c4b..34f393c75f 100644
--- a/docs/claimantmodel/Maps.md
+++ b/docs/claimantmodel/Maps.md
@@ -1,102 +1,64 @@
# Claimant Model: Maps
-This doc presents a model for transparent ecosystems built around key value maps.
-This doc requires understanding the core [Claimant Model](CoreModel.md), and it is recommended that [Claimant Model: Logs](Logs.md) is also read first.
+This document applies the Claimant Model to transparent ecosystems built around **Verifiable Maps**. In this context, these maps take the form of **Claim Subject Maps (CSMs)**, where the keys are the "Claim Subjects" (the specific entity a claim is about).
+
+The intended user of this kind of map is the **Domain Verifier**. While logs provide discoverability by allowing a verifier to read all entries sequentially, maps allow a verifier to efficiently look up only the specific subjects they care about.
+
+In fact, a verifiable map built on top of an append-only log is the primary expected deployment model for these systems, combining the auditability of logs with the efficiency of maps.
+
+This document requires an understanding of the core [Claimant Model](CoreModel.md) and is best read after [Claimant Model: Logs](Logs.md).
## Groundwork: Discoverability
-A Claim is discoverable if it can be found by the Claim Verifier without information being passed to them by the Believer.
-The Log Claimant Model states that the purpose of Log Transparency is to enable discoverability of Claims.
-To understand whether this statement applies to Maps, we need to understand what it is about Logs that enables discoverability.
+A Claim is discoverable if the Claim Verifier can find it without relying on the Believer to pass it to them.
-A Log can be thought of as a Map where the key is the leaf index, and new entries need to be written into the next available leaf.
-Maps and Logs both have a single root hash which precisely commits to key/value data, and given this root hash and a key, there is only one verifiable value for the point lookup.
-The key difference (pun intended) is that in Maps the writer gets to choose any arbitrary key, where in Logs the key is the next available sequence number.
+The purpose of Log Transparency is to enable discoverability of Claims. To understand whether this applies to Maps, we need to look at how they differ from Logs:
-A Log Checkpoint commits to a range of keys by stating the tree size.
-Tree size is the only input required to generate all keys for a log, and it is this property of key enumerability that makes Claim discoverability simple; given a Log Checkpoint, a Verifier can discover all Claims by requesting all entries from [0..treeSize).
-Thus, providing the Verifier is getting recent Checkpoints and is seeing Checkpoints consistent with the Believer, each and every Claim will be discovered in time.
-While simple, this is not efficient, especially for Verifiers interested in a tiny subset of Claims.
+* **Logs**: Can be thought of as a Map where the key is the leaf index. The writer cannot choose the key; it is the next available sequence number. This makes enumeration easy: given a tree size, a Verifier can discover all Claims by requesting all entries from `0` to `treeSize`. This makes discoverability simple but inefficient for large datasets if you only care about a few entries.
+* **Maps**: The writer gets to choose arbitrary keys. A Verifier cannot guess all keys from a Map Checkpoint alone, so they cannot discover all claims by enumeration.
-Map keys cannot be generated/discovered from a Map Checkpoint, consequently Maps do not allow for efficient discoverability through key enumeration.
-However, if the expected location for Claims in a Map is precisely understood ahead of time by the Believer and Verifier, Maps can provide Claim discoverability.
+However, if the expected location for Claims in a Map is precisely understood ahead of time by both the Believer and Verifier, Maps can provide efficient discoverability.
## Claim Subject Maps (CSMs)
### New Terms
-
-- Claim Subject
-- the entity to which a Claim relates (also referred to as ‘Subject’, for brevity)
-
-- Mog
-- a Map where the values are Logs
-
-- Claim Subject Map/Mog (CSM)
-- this is a Map keyed by the Claim Subject. For Mogs, the value is a Log of Claims, for Maps the value is a single Claim. In either case, the Claims keyed under a Subject must relate to the Subject.
-
+* **Claim Subject**: The entity to which a Claim relates (e.g., a domain name in a certificate).
+* **Mog**: A Map where the values are Logs (Map + Log).
+* **Claim Subject Map/Mog (CSM)**: A Map keyed by the Claim Subject. The value is either a single Claim (for Maps) or a Log of Claims (for Mogs). Crucially, the claims keyed under a Subject must relate to that Subject.
### Introduction
-CSMs allow for more efficient discoverability of Claims, particularly in ecosystems where there are many independent Claim Verifiers with distinct Claim Subjects.
-Claim Verifiers can become somewhat ignorant and selfish, looking after only their own Subjects and trusting others to look after their own.
-The trade-off for this is the risk that any Claims placed in the map at locations the Verifier does not expect will not be discovered by the Verifier.
-This risk can be eliminated with careful design of Claim Subjects and how they are extracted from Claims.
+CSMs allow for more efficient discoverability of Claims, particularly when there are many independent Claim Verifiers interested in distinct Subjects (e.g., different domain owners).
+
+Verifiers can look after only their own Subjects, trusting others to do the same. The risk is that any Claims placed at locations the Verifier does not expect will not be discovered. This risk can be eliminated with careful design of Claim Subjects.
### Requirements
To use a CSM for discoverability, these properties must hold:
- 1. Claim Subjects can be derived from only the Claim. Examples (Claim Subjects in bold):
- * Certificate Transparency: the Claim (cert) contains the **domain(s)** the certificate is for
- * Go SumDB: the Claim contains the **module name**
- 2. Claim Subjects must be keyed only under their canonical form
- 3. Claim Verifiers must have a complete set of all Claim Subjects they will verify
-
-#### Canonicalization & Discoverability
-
-A canonical form gives a single location in the map for a Claim Subject. This means that all users looking up Claims related to this see the same value. If there are multiple locations that users can look in, then it’s possible that Believers can be convinced of Claim inclusion in the data structure, but Verifiers are looking elsewhere. This means the Claims are not discoverable, and this undermines the core transparency goal.
-
-The spec for canonicalization should be precise and unambiguous so that it can be implemented in precisely the same way on all clients. Any discrepancy in implementation is a vector for presenting different Claims to different actors. This type of issue is insidious because the data structure verification would pass, giving a false sense of confidence. An attacker could effectively use this to provide a split-view without all the pains required to maintain root commitments that could not be reconciled.
-
-Non-canonical forms are not uniquely a problem for maps. Having ambiguous forms could be a problem for Claim Verifiers in the Log Claimant model too, but there Verifiers have the raw Subject and can canonicalize it, or query for substrings/prefixes, etc.
-
-### Map Functions (deriving Claim Subjects from a Claim)
+1. **Derivable Subjects**: Claim Subjects must be derived from the Claim itself (e.g., extracting the domain from a cert).
+2. **Canonical Forms**: Claim Subjects must be keyed only under their canonical form to avoid split-view attacks where users look in different places for the same thing.
+3. **Known Subjects**: Claim Verifiers must know the complete set of Subjects they intend to verify.
-Using a CSM is simplest in the case where there is a single Subject for every Claim. However, in the general case there are multiple Claim Subjects entailed by a Claim. This apparently minor difference has a large impact on the amount of work required in order to maintain discoverability.
+### Map Functions
-```
-mapFn(Claim) []ClaimSubject
-```
+We use a map function to derive Subjects from a Claim: `mapFn(Claim) []ClaimSubject`.
-We’ll use the signature above when describing how Subjects are derived from Claims. For a Believer to trust that a given Claim is discoverable, they must check that the Claim is committed to under all Subjects returned by mapFn.
+For a Believer to trust that a Claim is discoverable, they must check that the Claim is committed to under *all* Subjects returned by `mapFn`. For example, a certificate for `*.foo.example.co.uk` might entail subjects like `foo.example.co.uk`, `example.co.uk`, etc. The Verifier must check the locations they expect.
-The reasoning behind this is best understood through example. If we look at the Subjects entailed by a Certificate for `*.foo.example.co.uk` we might derive:
- * `foo.example.co.uk.`
- * `example.co.uk.`
- * `co.uk.`
- * `uk.`
- * `.`
+## CSM in the Claimant Model
-This set of Subjects must have a non-empty intersection with the set of subjects that the Domain Owner is expecting. If this Domain Owner does not have any subdomains and expects to be checking only `example.co.uk.` then a believer convinced only of the inclusion of `foo.example.co.uk.` and no others will have trusted a Claim which cannot be discovered.
+If the map is constructed from a Claim Log (a Log-Backed Map), we can model it as:
-This example also highlights that mapFn should not return too many Subjects. While the empty domain `.` may be derived from all Claims, doing so entails a map key which is effectively committing to all entries that would have been in the log. If this is the only mechanism that permits discoverability then a log should have been chosen instead of a map.
+* **CSM Claim**: *"Applying the map function to the logged data committed to by [Log Checkpoint] results in the map with [Root Hash]."*
+* **CSM Statement**: Map Checkpoint (sometimes called Signed Map Root or SMR).
+* **CSM Claimant**: The CSM Operator.
+* **CSM Believer**: Both the **Domain Believer** and the **Domain Verifier**.
+* **CSM Verifier**: A Verifier with the power to compute the map from the log (verifying the map construction).
+* **CSM Arbiter**: The CSM Arbiter (likely the same as the Log Arbiter).
-### CSM in the Claimant Model
-#### Log-Backed Maps & Mogs
+### Optimization: Verifiable Index (VIndex)
-If the map is constructed from a Claim Log then we have the following:
+When deploying a map built on top of a log, a potential inefficiency arises if the map duplicates the full data of the claims already stored in the log.
-
-- ClaimCSM
-- "Applying $mapFn to the logged data committed to by $LogCheckpoint results in the map with $rootHash"
-- StatementCSM
-- Map Checkpoint (sometimes SMR, or Signed Map Root)
-- ClaimantCSM
-- CSM Operator
-- BelieverCSM
-- BelieverDOMAIN and VerifierDOMAIN
-- VerifierCSM
-- A VerifierLOG,DOMAIN with the power to compute the map
-- ArbiterCSM
-- CSM Arbiter, possibly the same as ArbiterLOG
-
+The [Verifiable Index (VIndex)](https://github.com/transparency-dev/incubator/tree/main/vindex) is an optimization designed to solve this. Instead of repeating the full log entries or claims in the map values, the VIndex map simply stores **pointers** (the sequence numbers or indices) back to the location of the claim in the original log. This keeps the map small and efficient while maintaining full discoverability and verifiability.
diff --git a/docs/claimantmodel/cmrels.png b/docs/claimantmodel/cmrels.png
deleted file mode 100644
index b8d83ef81f..0000000000
Binary files a/docs/claimantmodel/cmrels.png and /dev/null differ