AI Dispatch
API & DataSubmit
The wirereportOct 13, 2026

The Trust Gap, Vol. 11

Two thirds of this index's published values restate their own source. We measured what that does to our trust-gap finding: it cannot reach 77.62% of it, because a trust gap is a finding of absence. It reaches 74.51% of the scores that give an agent credit.

# The Trust Gap, Vol. 11

## Our own index has a defect in two thirds of its published values. We measured what it does to the trust-gap finding, and the answer is: almost nothing — because a trust gap is a finding of absence, and absence is the one thing a misread quote cannot manufacture.

**aidispatch.news index report — 2026-10-12. All figures queried live; the queries are in Appendix A.**

---

Last week two of this index's own audit processes converged, independently, on the same number: roughly two thirds of every published field value in this database is byte-identical to the quote it cites. The extractor copied a span out of a source document, filed it as the answer to a question, and never performed the second step — deciding what the span *meant*.

That is a serious defect, and it is ours. A hand-audit put the resulting semantic-error rate at 43% on a candidate sample and 22% on a sample of live published `high_risk_domains` values. On an index whose entire claim is per-field evidence, "two thirds of our values restate their own source" is the kind of finding that would end most research products' credibility if a competitor found it first.

So this volume does what MIT's AI Agent Index did when it published "227 of our 1,350 data points lack public information": it reports the defect in its own numbers, exactly, and then measures precisely which of our published claims it threatens and which it does not.

The result is an asymmetry we did not expect and did not design for:

> **Of the 648 published trust gaps this index asserts, 503 (77.62%) rest on no present evidence at all — every rubric-mapped field reads `no_public_information`. 29 (4.48%) touch a copied value. The copy-paste defect is structurally incapable of reaching three quarters of our headline finding, because that finding is a finding of absence, and absence is observed, not interpreted.** > > **Of the 357 published scores that give an entity *credit* — a 2 or a 3 on any dimension — 266 (74.51%) touch a copied value. The defect is concentrated almost entirely in the verdicts that say an agent is doing something right.**

Both halves matter. The first says our central claim is more robust than last week's headline rate implies. The second says our "this one is fine" verdicts are badly exposed, and that the true number of trust gaps in this index is more likely to be *higher* than 648 than lower. We report both, and we prefer neither.

---

## 1. The census, reported exactly

MIT reports its own coverage as a fraction. Here is ours, computed from first principles rather than counted off a dashboard.

The index holds **3,220 entities**: 811 published (777 agents, 34 vendors), 2,407 candidates, 2 archived. The field catalogue holds **63 fields** — 45 applying to both entity types, 14 to agents only, 4 to vendors only. An agent therefore has 59 applicable fields and a vendor 49, giving

777 × 59 + 34 × 49 = 45,843 + 1,666 = 47,509 applicable data points

across the published index. Every one of those 47,509 slots is in exactly one of three states:

| State | Count | Share | |---|---:|---:| | **Present** — a value, a quote, a source URL, a timestamp | 13,129 | 27.63% | | **`no_public_information`** — we looked and the source does not say | 31,835 | 67.01% | | **Never assessed** — nobody has looked | 2,545 | 5.36% | | **No public evidence either way** (the two together) | **34,380** | **72.36%** |

Vol. 10 reported 72.56% on 47,204 slots. This week is **72.36% on 47,509** — a 0.20pp improvement, which is the ninth consecutive volume in which this number has sat within half a point of 72%.

We state the `never assessed` row separately on purpose. It is not a finding about the world; it is a finding about us. **1,834 of those 2,545 unlooked-at slots (72.06%) are assurance fields**, which means the assurance layer — the thing this index exists to measure — is also the ground we have left least examined.

**Against our own thesis, for the eighth consecutive volume: `assurance` is not the emptiest category in the index.**

| Category | Slots | Present | Present % | |---|---:|---:|---:| | models | 4,662 | 833 | **17.87%** | | assurance | 16,356 | 2,947 | **18.02%** | | safety | 6,488 | 1,315 | 20.27% | | ecosystem | 4,798 | 1,496 | 31.18% | | impact | 4,866 | 1,825 | 37.51% | | agency | 4,662 | 1,758 | 37.71% | | practicality | 5,677 | 2,955 | 52.05% |

`models` is emptier than `assurance`, by 0.15pp. It has been emptier, or within a point, every time we have looked. The honest reading remains: agents disclose very little about anything load-bearing, and our assurance-specific thesis is not distinguishable from general disclosure poverty on this measure alone. The thing that *is* distinguishable is in §6, where the six risk-transfer fields are examined one value at a time.

---

## 2. The defect, measured in our own published values

The instrument is a view, `uninterpreted_field_values`, that returns every published present value whose `value_text` equals its own `quote` after whitespace and case normalisation.

**8,762 of 13,135 published present values (66.71%) are copies.**

By category:

| Category | Published present | Copies | Rate | |---|---:|---:|---:| | safety | 1,315 | 913 | **69.43%** | | assurance | 2,947 | 1,990 | **67.53%** | | ecosystem | 1,498 | 1,003 | 66.96% | | **all** | **13,135** | **8,762** | **66.71%** | | impact | 1,825 | 1,213 | 66.47% | | agency | 1,761 | 1,165 | 66.16% | | practicality | 2,955 | 1,942 | 65.72% | | models | 834 | 536 | 64.27% |

The spread is 5.2 points from best to worst. **The defect is uniform.** It is not concentrated in hard fields or in one crawler's output — it is what the extraction step did everywhere, for a period, to everything. `safety` being worst and `models` best has no obvious mechanism and we assert none.

There is a measurement caveat that matters, because a prior internal run nearly published a four-dimension "decline" that was an instrument artifact. "Uninterpreted" has two defensible definitions: normalised equality (the view's, used throughout this report) and raw byte equality. They differ by about 50 rows, which is **more than this index's entire editorial output in a typical day**. Any reported *change* in this metric smaller than a few hundred rows is measuring the query, not the index. We therefore report the dated stock with the instrument named, and in §4 a trend against a documented baseline large enough to survive the ambiguity.

---

## 3. The headline: what the defect can and cannot reach

This is the analysis this volume exists for.

Every score in this index maps, through a published table (`rubric_dimension_fields`), to a specific set of field keys. For each of the 1,878 resolved scores on published entities we classified the evidence actually underneath it: are the mapped fields present and interpreted, present and copied, or absent altogether?

Two definitions, both load-bearing and both published at `/methodology`:

- A **trust gap** is a *judged* score of 0 or 1. A machine score (`scored_by = 'spark-verifier'`) of 0–1 is **not** a trust gap; it means nobody has read the evidence against the rubric yet. Machine scores are capped at 2 pending review, so a 3 is always judged. - Trust gaps are the rows that carry a commercial link on the public site. They are the index's monetised output, so they are the rows that have to be right.

| Band | Author | Scores | Absence only | Touches a copy | Fully interpreted | % touching a copy | |---|---|---:|---:|---:|---:|---:| | **0–1 (gap)** | **judged** | **648** | **503** | **29** | **116** | **4.48%** | | 0–1 (gap) | machine | 872 | 0 | 685 | 187 | 78.56% | | **2–3 (credit)** | **judged** | **83** | **1** | **19** | **63** | **22.89%** | | 2–3 (credit) | machine | 275 | 0 | 247 | 28 | 89.82% |

Read the first row first. **503 of the 648 published trust gaps rest on observed absence** — every field the dimension reads says `no_public_information`. There is no quote to misread, because there is no quote. A further 116 rest on present values that are genuinely interpreted. **29 of 648 (4.48%) touch a copied value at all.**

The mechanism is not luck and it is worth stating plainly, because it is the strongest structural argument this index has: **a trust gap is overwhelmingly a statement that a company has published nothing about runtime limits, audit records, certification, outcome-based payment, or insurance. That statement is made true or false by the absence of text, not by the interpretation of text.** The copy-paste defect is a defect of interpretation. It cannot manufacture an absence.

By dimension, the robustness is not uniform:

| Dimension | Judged gaps | Absence only | Touches a copy | Fully interpreted | |---|---:|---:|---:|---:| | `insurance_indemnity` | 139 | **135 (97.12%)** | **0** | 4 | | `outcome_settlement` | 133 | 121 (90.98%) | 2 | 10 | | `compliance` | 142 | 94 (66.20%) | 9 | 39 | | `audit_trail` | 131 | 93 (70.99%) | 6 | 32 | | `runtime_governance` | 103 | 60 (58.25%) | **12 (11.65%)** | 31 |

**The dimension this index's commercial thesis rests on hardest — `insurance_indemnity` — is the one the defect cannot touch at all. Zero of its 139 judged gaps involve a copied value, and 135 of 139 are pure absence.** `runtime_governance` is the weakest at 11.65%, for the obvious reason: it is the assurance dimension agents actually write marketing copy about, so there is text to copy and misread.

A second fact from the same table, which no prior volume has reported: **`insurance_indemnity` carries 141 published scores and every single one is human-judged.** The machine scorer has never written a row on it. The reason is mechanical — the automated scorer writes only on an evidenced-present hit, and the four fields this dimension reads (`insurance_available`, `insurance_carriers`, `coverage_limits`, `indemnification`) are present on **12 of 811 published entities**. The dimension with the least data is the only one that has been entirely hand-read.

---

## 4. Where it undercuts us, stated as plainly as the part that helps

Now the second row and the fourth.

**Of the 357 published scores of 2 or 3 — the scores that credit an entity with doing something right — 266 (74.51%) rest on at least one copied value.** Among the 275 machine-written ones it is 89.82%. Among the 83 judged ones it is 22.89%, which is better by a factor of four and still means roughly one in five of our human-made positive verdicts rests on a span nobody interpreted.

Combine that with the hand-audited error rates on copied values — 43% on a candidate sample, 22% on a live published sample — and the direction of the bias is unambiguous. A copied span filed as evidence of runtime governance is more likely to be marketing language about safety, or a certification badge, or a testimonial, than it is to be an enforced spend limit. **A meaningful share of this index's 2s are probably 1s or 0s. The number of real trust gaps is more likely above 648 than below it.**

This is the finding that cuts against our commercial interest in the opposite way from the one people expect. We are not at risk of having overstated the gap. We are at risk of having *understated* it, by giving credit on evidence that was never read — and every such case is an entity whose profile currently tells a reader it is better governed than our own evidence supports.

There is a third of the table worth naming for completeness: the machine's 872 gap-band scores, 78.56% of which touch a copy. Those are not published as trust gaps and carry no commercial link, which is exactly why the rule exists. The site's refusal to call a machine 0–1 a trust gap — a rule that looked conservative to the point of fussiness when it was written — turns out to be the single decision protecting the index from its own worst-contaminated layer. **1,147 of 1,878 published scores are machine-written, 932 of them touch a copy, and not one of them is a published finding.**

---

## 5. The defect's shape in time — and why "it stopped" is not reassurance

A rate tells you how bad the corpus is. It does not tell you whether the problem is live. So we asked when these 8,762 rows were created.

| Week beginning | Published copies created | |---|---:| | 2026-07-27 | **8,678** | | 2026-08-03 | 44 | | 2026-08-10 | 39 | | 2026-08-17 | 1 | | every week since | **0** |

**99.0% of the published backlog was written in a single week — the index's first — and index-wide the newest copy in the entire database was created 2026-08-22. Exactly one row has entered the backlog since.**

It would be convenient to read that as a fix. It is not, and the record is explicit about why. Migration `0047`, which installed a trigger that now rejects any write whose value is its own quote, documents the inflow's end precisely: the last extractor copy was written **2026-08-12 10:28 UTC — "the moment the extractor stopped."** The copies stopped because the writer stopped, seven weeks before the guard that would have stopped them shipped on 2026-10-08.

So the honest statement is three parts, and all three are needed:

1. **The defect is a frozen stock, not a live leak.** No value has been copied into this index in 51 days. 2. **Nothing was fixed to achieve that.** The extraction step that skipped interpretation was never corrected; the process running it went down. 3. **A latch is now in place.** `assert_value_is_interpreted` is enabled (`tgenabled = 'O'`, verified this run) and fires on insert and on any update that changes the value or the quote. Whoever revives the extractor will be told on the first write that interpretation is required, rather than by an audit three weeks later.

The remediation itself is editorial, one row against one document, and cannot be done in bulk by anybody — which brings us to the first trend measurement this metric has ever had.

### The trend, against a documented baseline

Nightly deltas on this metric are worthless: the two defensible instruments differ by more rows than a day of editorial work produces. But migration `0047` recorded a hand-checked baseline on **2026-09-01**: published present rows **12,637**, of which **9,510 (75.3%) copies**.

Forty-one days later, same instrument, same scope:

| | 2026-09-01 | 2026-10-12 | Change | |---|---:|---:|---:| | Published present values | 12,637 | 13,135 | +498 | | …copies | 9,510 | 8,762 | **−748** | | …interpreted | 3,127 | 4,373 | **+1,246** | | Copy rate | **75.26%** | **66.71%** | **−8.55pp** |

The arithmetic closes: +1,246 interpreted = 748 rows remediated + 498 net new present values. **748 published copies have been read against their sources and rewritten in 41 days — 18.2 rows a day.**

That is real and nobody had measured it. It is also the number that sets expectations honestly: at the observed rate — arithmetic on the two figures above, not a forecast — the remaining 8,762 published copies represent on the order of **480 days** of work. This defect will not be cleared by the process that is currently clearing it. It needs either a different method or a decision that some fields do not need remediating.

One caveat, stated rather than smoothed: the published set is not the same 811 entities it was on 09-01 — entities were promoted and demoted in between — so a small part of both movements is composition rather than work. The direction and the order of magnitude are not in doubt; the third significant figure is.

---

## 6. Risk transfer: 807 of 811, and what the 25 values actually say

The flagship question, asked the same way every volume: **of published entities, how many have no public evidence that insurance is available?**

**807 of 811 (99.51%).** Four entities carry a present `insurance_available` value; 804 carry an explicit `no_public_information`; 3 have never been assessed.

Vol. 10 reported 800 of 806 (99.26%). **This got worse, and not because the index grew.** `insurance_available` fell from 6 present values to 4. §7 is about why.

Widened to all six risk-transfer fields — `insurance_available`, `insurance_carriers`, `coverage_limits`, `liability_cap`, `indemnification`, `own_liability_cover` — **792 of 811 (97.66%) have nothing present on any of them.**

The six rarest of the 45 shared fields in the entire catalogue are, for the eighth consecutive volume, exactly these six: `coverage_limits` 1, `own_liability_cover` 1, `insurance_carriers` 3, `insurance_available` 4, `indemnification` 8, `liability_cap` 8.

Counting those 25 values overstates what they contain. We read all 25 against their stored quotes. Here is what they are.

**`insurance_available` — 4 values, 3 distinct products, 0 agents with cover in force.** Two are insurance vendors describing their own products (`armilla-ai`, `munich-re-aisure`). The other two are the same product filed twice — `elevenagents` and `elevenlabs-agents`, both citing the identical evidence row, **the eighth consecutive volume in which this index has published one voice-agent platform as two entities on its most important field.** Its own stored value is explicit about what it is:

> "ElevenAgents is also the first agent platform eligible for AI insurance through AIUC, once certified."

Eligible, once certified. **Of 777 published agents, exactly one distinct product has any insurance_available value at all, and that value describes conditional eligibility rather than cover in force. No published agent in this index discloses insurance cover in force from a named carrier. Eleventh consecutive volume.**

**`insurance_carriers` — 3 values, 0 of them about an agent.** `armilla-ai` names the Lloyd's market ("Armilla Insurance Services is a Coverholder at Lloyd's"); `coalition` names Allianz's "A+ rated capacity" behind its own enterprise cyber product. The third, `munich-re-aisure`, names Mosaic as a partner — and the stored value says so against itself: the capture "does not itself state which carrier bears the risk." A strict reading of this field is 2, not 3. We report both readings and prefer neither; this is the same referential class Vols. 9 and 10 named.

**`coverage_limits` — 1 value, and it is not agent cover.** `coalition`: "Up to $100K additional Funds Transfer Fraud coverage" — a cyber sub-limit, conditional on the policyholder also buying security awareness training.

**`indemnification` — 8 values, 3 genuine.** This is where counting misleads most. Read individually: - **Three are real vendor-to-customer indemnities.** `conversica` ("Conversica shall indemnify, defend, and hold harmless Customer…" against third-party IP claims), `gemini-code-assist` (Google's IP indemnification policy), `richpanel` (DPA indemnity for third-party claims). - **Two run the opposite way.** `alttextlab`: "You agree to indemnify and hold harmless AltTextLab.com…" `chatgpt-for-tinder-and-bumble`: "By using the extension, you agree to indemnify its creator from any liability." These are the *customer* indemnifying the *vendor* — filed in a field that asks whether the vendor indemnifies the customer. Both stored values describe the inversion correctly, to the Fact-Checker's credit, but a reader scanning for a populated indemnification field sees a populated field. - **One is marketing with no clause at all.** `agentcard`: "The legal responsibility sits with us, not you." - **One asserts a clause without any of its terms.** `augment-code`: "…backed by an indemnification clause in our terms." - **One is a warranty product, not an indemnity of our subject.** `munich-re-aisure`: aiSure-backed warranties "enable you to indemnify your clients."

**`liability_cap` — 8 values, 3 actual caps.** Three state a cap: `conversica` (twelve months of fees), `taletok` (six months of fees), and `nofireai` — a published Observability vendor whose own terms read:

> "IN NO EVENT WILL THE TOTAL LIABILITY OF THE NOFIRE AI PARTIES TO YOU … EXCEED, IN THE AGGREGATE, $100.00."

Three more are cross-references to a document we never captured — `fathom`, `mailkite` and `stackmint` all say liability is limited *per the main agreement*, which is a pointer, not a term. And two are not caps at all but total disclaimers: `alttextlab` ("We are not liable for any damages arising from your use of the Service") and `9bot`.

**`own_liability_cover` — 1 value**, `edwin-ai`, whose parent's trust centre states "Has cyber insurance." That is the vendor's own balance-sheet protection, which is not risk transfer to its customers.

So the hand-read bottom line, which is harder than any count:

> **Of 811 published entities, 3 (0.37%) carry evidence of a vendor-to-customer indemnity. Zero carry evidence of insurance cover in force on the agent. The one entity that discloses a specific dollar cap on its own liability is an assurance vendor, and the figure is one hundred dollars.**

That last fact deserves saying in the plainest possible terms, because it is the sharpest single illustration this index holds of why the assurance layer needs measuring: **a company selling AI observability caps its total aggregate liability to its customers at $100.00.** It was handed to our wire desk a week ago and has not yet run.

---

## 7. The reversal nobody flagged

`insurance_available` fell from 6 present values to 4 this week. We traced it.

On **2026-10-09 at 08:29 UTC**, in a single transaction, `spark-extractor` re-read three published entities and flipped `insurance_available` from `present` to `no_public_information` on all three: **`vouch`** (an insurance vendor), **`coalition`** (an insurance vendor), and `rentahuman-workman-rent`. The values and quotes were cleared to null.

Two of this index's four published insurance vendors no longer carry any public evidence, from their own pages, that insurance is available.

Three things about that, in order of importance.

**First, it may well be correct.** Both pages are live commercial sites that get rewritten. An extractor re-reading `coalition`'s homepage and not finding a sentence that answers "is insurance available for AI agents" is a plausible and even expected outcome, and absence is a finding we publish proudly. We are not asserting the downgrade is wrong.

**Second, nothing reviewed it.** A machine process cleared a human-relevant value on a published page in an unattended run, and the only reason it is in this report is that we were counting the field for other reasons. Vol. 10 flagged exactly this blind spot: an in-place downgrade moves only `updated_at`, which the `score_freshness` instrument does not read, so no instrument in this index escalates it.

**Third, it has left a published score standing on nothing.** `vouch`'s `insurance_indemnity` scorecard (id 4) is a judged **1**, written 2026-07-30 by the Fact-Checker. All four fields that dimension reads now say `no_public_information`, every one of them downgraded after the score was written. The score is still directionally right — 1 is a trust gap, and a vendor with no present evidence is a gap — so unlike the `gptme` case Vol. 10 found, no reader is being misled. But the score no longer rests on the evidence it was written from, and nobody was told.

Last week this index reported a gain in risk-transfer coverage driven by the promotion of `vouch` and `munich-re-aisure`. Part of that gain has since been reversed in place, by a machine, silently. **Reported here because a weekly report that only ever shows its own numbers improving is marketing.**

---

## 8. The gap by dimension, and the ceiling nobody reaches

For the record, since the question "how many score 0 or 1 on each dimension" is the one readers ask:

| Dimension | Scored pairs | At 0–1 | Judged gaps | Machine 0–1 (not gaps) | 0 | 1 | 2 | 3 | |---|---:|---:|---:|---:|---:|---:|---:|---:| | `runtime_governance` | 528 | 336 | 103 | 233 | 50 | 286 | 192 | 0 | | `audit_trail` | 485 | 455 | 131 | 324 | 92 | 363 | 29 | **1** | | `compliance` | 475 | 359 | 142 | 217 | 106 | 253 | 116 | 0 | | `outcome_settlement` | 249 | 231 | 133 | 98 | 124 | 107 | 18 | 0 | | `insurance_indemnity` | 141 | 139 | 139 | 0 | 135 | 4 | 2 | 0 | | **total** | **1,878** | **1,520** | **648** | **872** | **507** | **1,013** | **357** | **1** |

`insurance_indemnity` is the extreme: **139 of its 141 scored pairs (98.58%) are at 0–1, and 135 are flat zeros.** `runtime_governance` is the mildest at 63.64%, which is consistent with §3 — it is the one dimension where agents publish something.

**One published score of 3 exists across 811 entities and five dimensions** (`proofchain` / `audit_trail`, judged 2026-08-24). A rubric whose top band is reached once in 1,878 opportunities is either measuring a market with no top-band behaviour or is mis-calibrated. We cannot distinguish those from inside the index, and this report asserts neither. Second volume raising it.

And the coverage caveat that bounds everything above: **177 of 811 published entities (21.82%) carry any human-judged dimension at all.** The other 634 have only machine completeness scores, which are not findings. So the published trust gap describes just over a fifth of the index.

One more observation from that same cut, reported because it is striking and because we cannot tell which way it points: **of the 177 published entities that have been read against the rubric by a person, 177 carry at least one trust gap.** Not one entity has survived a human reading gap-free. That is either the market being uniformly ungoverned, or the rubric being unpassable, or the Fact-Checker having triaged toward entities likely to show gaps. All three are live hypotheses; the data cannot separate them.

---

## 9. Citation freshness: sixth consecutive volume at exactly the speed of the clock

Every present value cites a quote from a dated capture. `citation_freshness` re-diffs each cited quote against the newest capture of its own URL.

| | Vol. 10 | Vol. 11 | |---|---:|---:| | Never re-fetched | 37.69% | **31.30%** | | Stale (published) | 1,842 | **2,449** | | Stale rate on judgeable recaptures | 22.81% | **27.43%** | | Entities with ≥1 stale citation | 275 (34.12%) | **349 (43.03%)** | | Median cited-capture age | 64.7d | **71.7d** | | Median newest-available capture | 25.6d | **18.8d** |

**64.7 → 71.7 days is 7.0 days of decay over a 7.0-day week. Sixth consecutive volume at exactly the speed of the clock.** Nothing in this index re-points an evidence row at a fresher capture of the same URL; the detector was fixed in Vol. 6 and the gate made two-directional in Vol. 7, but the propagation step has never been built, so cited evidence ages at precisely one day per day.

**One thing improved and it reverses last week's worry.** Vol. 10 reported the newest-available median aging in step (18.5d → 25.6d) and concluded the gap was no longer closable by re-pointing, because fresher captures had stopped arriving. That has reversed: **the newest available capture is now 18.8 days old, 6.8 days fresher than last week.** The crawl is delivering again. The re-pointable gap between what we cite (71.7d) and what we hold (18.8d) is **52.9 days** — and it is once again closable by a propagation step nobody has written.

The stale count rising 1,842 → 2,449 is the arithmetic consequence of the same two facts: more pages re-fetched means more opportunities for a diff to fail. 2,449 published failures fall on **363 URLs**, which is the shape of the worklist: work it by page, not by field.

`superseded_quote_flags` holds 4,011 rows and **zero have been adjudicated. Sixth consecutive volume.**

---

## 10. The gate, both ends

The index runs a promotion gate it does not apply retroactively, so it can be pointed at the published set as an audit.

**472 of 811 published entities (58.20%) would not pass our own promotion gate today** — Vol. 7 48.23%, Vol. 8 50.88%, Vol. 9 53.23%, Vol. 10 51.61%. Last week's improvement did not hold, and the cause is §9: stale citations are the dominant blocker and they accrue with the calendar.

Blockers on the published set: stale citations **333**, fewer than 12 present fields **174**, below the publication floor **13**, no scored dimension **2**, capture disclaims affiliation **8**, name too generic **5**, entity name absent from its own captures **5**. Advisory, not blocking: single-source **625 (77.07%)**. Mean present fields **16.20**, mean distinct sources **1.27**.

At the candidate end: **1 of 2,407 candidates is promotion-ready** — `scidraw-org` (entity 1603, 13 present fields, 1 scored dimension, identity verified, single-source advisory only). This is the **first non-zero reading in six volumes**, and it is one entity, so it is a handoff rather than a trend. 103 are evidence-ready, 236 clear the publication floor, 1,016 carry `identity_verdict = unchecked`, 2,344 of 2,407 (97.38%) are single-source, mean 4.04 present fields.

The structural reason the candidate queue produces nobody was established independently last night and we do not re-derive it: 52 evidence-ready candidates clear every field threshold and carry **zero** fields the trust-gap rubric can read, so no scorer can propose the one dimension the publication floor requires. That is a disagreement between the rubric and the floor about what "publishable" means, and it needs an editorial decision, not a crawl.

---

## 11. The wedge, probed harder than before

Prior volumes have reported that **0 of the combined competitor listings carry insurance or liability data**, which is the one claim that has held every sweep. This volume widened the probe deliberately, to try to break it: name, description and category searched for `insur|indemnif|liabilit|underwrit|lloyd|coverage limit`.

**It returned 13 hits — 12 on aiagentsdirectory, 1 on theaiagentindex — and we read all 13.**

Every one is an agent sold *to* the insurance industry, not an agent carrying cover. `Kolena Insurance AI` ("accelerate underwriting, claims & RFP processing"), `MyPolicyReview.ai` ("analysis of insurance policies to identify coverage gaps"), `Cara` ("an AI CSR … for insurance agencies, brokerages, and MGAs"), `Voxworks`, `Xaver`, `MiA`, `vBots AI`, `RAW@AI`, `Insurance AI`, `Kay AI`, `Temperstack`, `SEF Agent Reliability Pack`, and `Persado`. Insurance as a vertical market, in all 13 cases.

**Zero of 3,573 competitor listings disclose whether the agent itself can be insured, indemnified, or audited. The wedge claim holds under a probe designed to break it** — which is a better-founded version of the claim than "the probe returns 0," and we will use this wording from here.

Competitor state, with the freshness caveat that matters: **theaiagentindex 408 listed, swept today (2026-10-12)**; **aiagentsdirectory 3,155 listed, corpus last seen 2026-09-29 — 13 days stale.** That stale leg is 88.5% of the still-listed wedge denominator. The claim is true on the fresh half and 13 days old on the other; we report the shape, not the number alone, and we did not re-measure it forward.

Our own coverage of the wedge remains thinner than our coverage of the contested ground. The four published insurance vendors average **13.5 present fields** against 16.20 index-wide, and 3 of 4 pass our gate. The Observability tier — 14 vendors across two subtype spellings, mean 17.1 and 24.0 fields — is better covered than the insurance tier, and it is the tier aiagentsdirectory has listed 25-deep since July. `Observability` (13) and `observability` (1) are still two subtype strings for one category, fourth volume.

---

## 12. Instrument state, checked before anything crawl-derived was quoted

Per standing rule, `job_heartbeats` was read first. **It still cannot answer the question it exists for.** Five of nine registered jobs return `is_stalled = null` with `last_success_at = null`: `crawl_sources`, `extract_pending`, both competitor syncs, and `demote_below_floor` — every job that runs on the local pipeline box. The four `pg_cron` jobs are healthy, youngest success 2026-10-12 20:05 UTC. **Third consecutive volume reporting that nothing escalates a `null`**, and a `null` on a registered job is a louder signal than a `true`.

The cause was diagnosed last night and is not a cloud-side problem: the run-logging code merged 2026-10-06 has written zero rows for any pipeline job, most likely because that machine is running a checkout from before the merge. It needs one command at the box.

Read directly instead, and reported separately because conflating them is how a partial recovery gets called "fixed":

- **Crawl: alive today.** Newest `raw_documents` row 2026-10-12 19:15 UTC, roughly an hour before this run. 21,442 documents. - **Extraction: 3 days behind.** Newest `evidence.retrieved_at` 2026-10-09 16:11 UTC. - **Editorial: 1,811 `entity_fields` rows touched in the last 7 days.**

Standing diagnostics: `entity_identity_drift` **3** rows (routed to the Fact-Checker, not acted on here, per the view's own rule); `score_authority_conflicts` **57** (40 published); `false_absence_flags` **2,662**; `change_queue` **5,125** pending; `published_floor_breaches` **14**; `superseded_quote_flags` **4,011**, zero adjudicated.

---

## 13. What this volume does not claim

- **Autonomy versus accountability: tenth deferral, re-measured rather than assumed.** `autonomy_level` is present on 92 of 777 published agents and holds **82 distinct free-text values across those 92 rows.** There is no scale to correlate an audit-trail score against. Any coefficient we published would describe our extraction, not the market. - **Model concentration risk:** same blocker, same reason. - **The assurance landscape map:** 34 published vendors, 4 of them insurance. Enough to list, not enough to map without padding. Unchanged from Vols. 5–10. - **Whether the three 10-09 insurance downgrades are correct.** We traced them and report them. Reading the current pages and deciding is the Fact-Checker's call, not ours. - **Whether the 43% / 22% hand-audited error rates generalise** to the 8,762-row backlog. They are two samples, read by one role, and the only figures in this database that measure wrongness rather than shape. We use them directionally in §4 and assert no index-wide error count. - **Citation integrity versus MIT's:** still never measured. Cloud roles cannot reach `aiagentindex.mit.edu`. We should stop making the comparison rhetorically until somebody measures it. - **Extraction throughput:** `evidence` still has no insertion timestamp, so "is evidence being written" is not answerable from that table. Not computed; asserted nowhere.

---

## Appendix A — reproduction

Every figure above comes from one of these. Run against Supabase project `invsbcblyrjsvmygulcz`, 2026-10-12, 20:30–21:30 UTC.

**A1 — entity census** ```sql select status, entity_type, count(*) from entities group by 1,2 order by 1,2; ```

**A2 — field catalogue applicability** ```sql select applies_to, category, count(*) from field_catalog group by 1,2 order by 1,2; ```

**A3 — the 47,509-slot census (§1)** ```sql with pub as (select id, entity_type from entities where status='published'), app as ( select p.id as entity_id, f.field_key, f.category from pub p join field_catalog f on f.applies_to='both' or f.applies_to=p.entity_type) select (select count(*) from app) as applicable_slots, count(*) filter (where ef.value_status='present') as present, count(*) filter (where ef.value_status='no_public_information') as no_public_information, count(*) filter (where ef.id is null) as never_assessed from app a left join entity_fields ef on ef.entity_id=a.entity_id and ef.field_key=a.field_key; ```

**A4 — completeness by category (§1)** ```sql with pub as (select id, entity_type from entities where status='published'), app as (select p.id as entity_id, f.field_key, f.category from pub p join field_catalog f on f.applies_to='both' or f.applies_to=p.entity_type) select a.category, count(*) as slots, count(*) filter (where ef.value_status='present') as present, round(100.0*count(*) filter (where ef.value_status='present')/count(*),2) as present_pct, count(*) filter (where ef.id is null) as never_assessed from app a left join entity_fields ef on ef.entity_id=a.entity_id and ef.field_key=a.field_key group by 1 order by present_pct; ```

**A5 — copy rate overall and by category (§2)** ```sql with pub_present as ( select ef.id, f.category from entity_fields ef join entities e on e.id=ef.entity_id and e.status='published' join field_catalog f on f.field_key=ef.field_key where ef.value_status='present') select 'ALL' as category, count(*) as published_present, count(u.entity_field_id) as uninterpreted, round(100.0*count(u.entity_field_id)/count(*),2) as pct from pub_present p left join uninterpreted_field_values u on u.entity_field_id=p.id union all select p.category, count(*), count(u.entity_field_id), round(100.0*count(u.entity_field_id)/count(*),2) from pub_present p left join uninterpreted_field_values u on u.entity_field_id=p.id group by p.category order by pct desc; ```

**A6 — score distribution and judged/machine split (§3, §8)** ```sql select count(*) as resolved_published_scores, count(*) filter (where is_judged) as judged, count(*) filter (where not is_judged) as machine, count(*) filter (where is_trust_gap) as trust_gaps, count(*) filter (where score=0) as s0, count(*) filter (where score=1) as s1, count(*) filter (where score=2) as s2, count(*) filter (where score=3) as s3 from scorecards_resolved where entity_status='published'; ```

**A7 — THE HEADLINE: evidence basis by band and author (§3, §4)** ```sql with scored as ( select sr.scorecard_id, sr.entity_id, sr.dimension, sr.score, sr.is_judged from scorecards_resolved sr where sr.entity_status='published'), mapped as ( select s.scorecard_id, count(ef.id) filter (where ef.value_status='present') as present_fields, count(u.entity_field_id) as uninterpreted_present from scored s join rubric_dimension_fields rdf on rdf.dimension=s.dimension left join entity_fields ef on ef.entity_id=s.entity_id and ef.field_key=rdf.field_key left join uninterpreted_field_values u on u.entity_field_id=ef.id group by 1) select case when s.score<=1 then '0-1 (gap band)' else '2-3 (credit band)' end as band, case when s.is_judged then 'judged' else 'machine' end as who, count(*) as scores, count(*) filter (where m.present_fields=0) as absence_only, count(*) filter (where m.present_fields>0 and m.uninterpreted_present>0) as any_uninterpreted, count(*) filter (where m.present_fields>0 and m.uninterpreted_present=0) as fully_interpreted, round(100.0*count(*) filter (where m.present_fields>0 and m.uninterpreted_present>0)/count(*),2) as pct_any_uninterpreted from scored s join mapped m using (scorecard_id) group by 1,2 order by 1,2; ```

**A8 — evidence basis of judged gaps, by dimension (§3)** ```sql with scored as (select sr.scorecard_id, sr.entity_id, sr.dimension from scorecards_resolved sr where sr.entity_status='published' and sr.is_trust_gap), mapped as (select s.scorecard_id, count(ef.id) filter (where ef.value_status='present') as present_fields, count(u.entity_field_id) as uninterp from scored s join rubric_dimension_fields rdf on rdf.dimension=s.dimension left join entity_fields ef on ef.entity_id=s.entity_id and ef.field_key=rdf.field_key left join uninterpreted_field_values u on u.entity_field_id=ef.id group by 1) select s.dimension, count(*) as judged_gaps, count(*) filter (where m.present_fields=0) as absence_only, count(*) filter (where m.present_fields>0 and m.uninterp>0) as touches_uninterpreted, count(*) filter (where m.present_fields>0 and m.uninterp=0) as fully_interpreted from scored s join mapped m using (scorecard_id) group by 1 order by 1; ```

**A9 — per-dimension score distribution (§8)** ```sql select dimension, count(*) as scored_pairs, count(*) filter (where score<=1) as at_0_or_1, count(*) filter (where score<=1 and is_judged) as judged_trust_gap, count(*) filter (where score<=1 and not is_judged) as machine_0_1_not_a_gap, count(*) filter (where score=0) as s0, count(*) filter (where score=1) as s1, count(*) filter (where score=2) as s2, count(*) filter (where score=3) as s3 from scorecards_resolved where entity_status='published' group by 1 order by 1; ```

**A10 — judged entity coverage (§8)** ```sql select (select count(*) from entities where status='published') as published, count(distinct entity_id) filter (where is_judged) as entities_with_judged, count(distinct entity_id) filter (where is_trust_gap) as entities_with_judged_gap from scorecards_resolved where entity_status='published'; ```

**A11 — when the backlog was written (§5)** ```sql select date_trunc('week', created_at)::date as week, count(*) from uninterpreted_field_values where entity_status='published' group by 1 order by 1 desc; ```

**A12 — the backlog index-wide, and the guard (§5)** ```sql select count(*) as all_uninterpreted, max(created_at)::date as newest_created, count(*) filter (where created_at >= '2026-08-22') as created_since, count(*) filter (where entity_status='published') as published_subset from uninterpreted_field_values;

select tgname, tgenabled from pg_trigger where tgname='entity_fields_value_is_interpreted'; ```

**A13 — insurance absence headline (§6)** ```sql with pub as (select id from entities where status='published') select (select count(*) from pub) as published, count(*) filter (where ia.value_status='present') as has_present, (select count(*) from pub) - count(*) filter (where ia.value_status='present') as no_public_evidence, count(*) filter (where ia.value_status='no_public_information') as explicit_npi, count(*) filter (where ia.id is null) as never_assessed from pub p left join entity_fields ia on ia.entity_id=p.id and ia.field_key='insurance_available'; ```

**A14 — widened to all six risk-transfer fields (§6)** ```sql with pub as (select id from entities where status='published'), rt as (select * from entity_fields where field_key in ('insurance_available','insurance_carriers','coverage_limits', 'liability_cap','indemnification','own_liability_cover')) select (select count(*) from pub) as published, count(distinct p.id) filter (where rt.value_status='present') as any_present, (select count(*) from pub) - count(distinct p.id) filter (where rt.value_status='present') as none_present from pub p left join rt on rt.entity_id=p.id; ```

**A15 — rarest assurance fields (§6)** ```sql select f.field_key, f.applies_to, count(ef.id) filter (where ef.value_status='present') as present, count(ef.id) filter (where ef.value_status='no_public_information') as npi from field_catalog f left join entity_fields ef on ef.field_key=f.field_key and ef.entity_id in (select id from entities where status='published') where f.category='assurance' group by 1,2 order by present, f.field_key; ```

**A16 — every risk-transfer value read individually (§6)** ```sql select e.slug, e.entity_type, ef.field_key, ef.value_text, ef.quote, ef.evidence_id, ev.source_url, cf.freshness, cf.confidence from entity_fields ef join entities e on e.id=ef.entity_id join evidence ev on ev.id=ef.evidence_id left join citation_freshness cf on cf.entity_id=ef.entity_id and cf.field_key=ef.field_key where e.status='published' and ef.value_status='present' and ef.field_key in ('insurance_available','insurance_carriers','coverage_limits', 'liability_cap','indemnification','own_liability_cover') order by ef.field_key, e.slug; ```

**A17 — the 2026-10-09 downgrades (§7)** ```sql select e.slug, e.status, ef.field_key, ef.value_status, ef.value_text, ef.extracted_by, ef.updated_at from entity_fields ef join entities e on e.id=ef.entity_id where ef.field_key in ('insurance_available','insurance_carriers','coverage_limits', 'liability_cap','indemnification','own_liability_cover') and ef.updated_at >= '2026-10-05' order by ef.updated_at desc; ```

**A18 — scores resting on fields downgraded after they were written (§7)** ```sql select sr.scorecard_id, sr.slug, sr.dimension, sr.score, sr.is_judged, sr.scored_by, sr.scored_at::date, count(ef.id) filter (where ef.value_status='present') as mapped_present_now, count(ef.id) filter (where ef.value_status='no_public_information' and ef.updated_at > sr.scored_at) as npi_after_score from scorecards_resolved sr join rubric_dimension_fields rdf on rdf.dimension=sr.dimension left join entity_fields ef on ef.entity_id=sr.entity_id and ef.field_key=rdf.field_key where sr.entity_status='published' and sr.slug in ('vouch','coalition','rentahuman-workman-rent') group by 1,2,3,4,5,6,7 order by sr.slug, sr.dimension; ```

**A19 — citation freshness (§9)** ```sql select cf.freshness, cf.confidence, count(*) from citation_freshness cf join entities e on e.id=cf.entity_id where e.status='published' group by 1,2 order by 1,2;

select round(percentile_cont(0.5) within group (order by extract(epoch from (now()-cf.cited_at))/86400)::numeric,1) as median_cited_age, round(percentile_cont(0.5) within group (order by extract(epoch from (now()-cf.newest_fetched_at))/86400)::numeric,1) as median_newest_age, count(*) filter (where cf.cited_raw_document_id=cf.newest_raw_document_id) as never_refetched, count(distinct cf.entity_id) filter (where cf.freshness='stale') as entities_with_stale, count(distinct cf.source_url) filter (where cf.freshness='stale') as stale_urls from citation_freshness cf join entities e on e.id=cf.entity_id where e.status='published'; ```

**A20 — the gate, both ends (§10)** ```sql select entity_status, count(*) as entities, count(*) filter (where promotion_ready) as promotion_ready, count(*) filter (where evidence_ready) as evidence_ready, count(*) filter (where clears_publication_floor) as clears_floor, round(avg(present_fields),2) as mean_present_fields, round(avg(distinct_sources),2) as mean_sources, count(*) filter (where identity_verdict='unchecked') as identity_unchecked, count(*) filter (where distinct_sources<=1) as single_source from promotion_readiness group by 1 order by 1;

select b as blocker, count(*) from promotion_readiness pr, unnest(pr.blockers) b where pr.entity_status='published' group by 1 order by 2 desc; ```

**A21 — vendor tier coverage (§11)** ```sql select e.subtype, count(*) as vendors, round(avg(pr.present_fields),1) as mean_present_fields, count(*) filter (where pr.promotion_ready) as gate_ready from entities e join promotion_readiness pr on pr.entity_id=e.id where e.status='published' and e.entity_type='vendor' group by 1 order by vendors desc; ```

**A22 — the widened wedge probe, and the listings it returned (§11)** ```sql select competitor, count(*) as listings, count(*) filter (where still_listed) as still_listed, max(last_seen_at)::date as corpus_last_seen, count(*) filter (where coalesce(name,'')||' '||coalesce(description,'') ||' '||coalesce(category,'') ~* '(insur|indemnif|liabilit|underwrit|lloyd|coverage limit)') as wedge_hits from competitor_listings group by 1 order by 1;

select competitor, name, category, description from competitor_listings where coalesce(name,'')||' '||coalesce(description,'')||' '||coalesce(category,'') ~* '(insur|indemnif|liabilit|underwrit|lloyd|coverage limit)' order by competitor, name; ```

**A23 — autonomy scale check (§13)** ```sql select count(*) as present_rows, count(distinct lower(btrim(value_text))) as distinct_values from entity_fields ef join entities e on e.id=ef.entity_id where e.status='published' and ef.field_key='autonomy_level' and ef.value_status='present'; ```

**A24 — instrument state (§12)** ```sql select job_name, age, is_stalled, max_age, last_success_at from job_heartbeats order by job_name;

select 'score_authority_conflicts' k, count(*)::text v from score_authority_conflicts union all select 'superseded_quote_flags', count(*)::text from superseded_quote_flags union all select 'superseded_adjudicated', count(*)::text from superseded_quote_flags where verdict is not null union all select 'false_absence_flags', count(*)::text from false_absence_flags union all select 'change_queue_pending', count(*)::text from change_queue where status='pending' union all select 'entity_identity_drift', count(*)::text from entity_identity_drift union all select 'published_floor_breaches', count(*)::text from published_floor_breaches union all select 'raw_documents', count(*)::text from raw_documents union all select 'newest_raw_document', max(fetched_at)::text from raw_documents union all select 'newest_evidence_retrieved_at', max(retrieved_at)::text from evidence; ```

---

## Appendix B — reconciliation

Each line is an independent route to a number printed above. All of them close.

1. Slots from first principles: 777 × 59 + 34 × 49 = 45,843 + 1,666 = **47,509**, equal to the queried `applicable_slots`. ✓ 2. Census partition: 13,129 + 31,835 + 2,545 = **47,509**. ✓ Shares 27.63 + 67.01 + 5.36 = 100.00%. ✓ 3. Published `entity_fields` rows total 44,992 (13,135 present + 31,857 absent) against 44,964 inside the applicable set — the 28-row difference is values filed on fields that do not apply to their entity type, reported in Vols. 7–10 at 6 and now 28. The census uses the applicable set; §2's copy rate uses all 13,135 present rows. Both denominators are named where used. ✓ 4. Category slots sum: 4,662 + 16,356 + 6,488 + 4,798 + 4,866 + 4,662 + 5,677 = **47,509**. ✓ 5. Score distribution: 507 + 1,013 + 357 + 1 = **1,878** = resolved published scores. ✓ Judged + machine: 731 + 1,147 = **1,878**. ✓ 6. Headline four-cell table sums to 648 + 872 + 83 + 275 = **1,878**. ✓ Judged rows 648 + 83 = **731**. ✓ Gap band 648 + 872 = **1,520**, matching the independent per-dimension sum 336 + 455 + 359 + 231 + 139 = **1,520**. ✓ 7. Evidence-basis partition of the 648 judged gaps: 503 absence-only + 29 touching a copy + 116 fully interpreted = **648**. ✓ Per-dimension: absence 93 + 94 + 135 + 121 + 60 = **503**; copies 6 + 9 + 0 + 2 + 12 = **29**; interpreted 32 + 39 + 4 + 10 + 31 = **116**. ✓ 8. Credit-band exposure: 19 judged + 247 machine = 266 of 357 = **74.51%**. ✓ 9. Per-dimension judged gaps: 103 + 131 + 142 + 133 + 139 = **648** = counted trust gaps. ✓ 10. Backlog by week: 8,678 + 44 + 39 + 1 = **8,762** = published copies. ✓ 11. The 09-01 baseline decomposition: interpreted 12,637 − 9,510 = 3,127; today 13,135 − 8,762 = 4,373; +1,246 = 748 remediated + 498 net new present. ✓ 12. Freshness partition: 4,111 current + 6,478 reconfirmed + 2,217 stale-high + 232 stale-medium + 97 unreadable = **13,135** = published present values. ✓ Never-refetched 4,111 equals the `current` count, as it must. ✓ 13. Stale rate denominator: judgeable recaptures = 6,478 + 2,449 = 8,927; 2,449 / 8,927 = **27.43%**. ✓ 14. `superseded_quote_flags` 4,011 equals the index-wide `citation_freshness` stale count of 4,011, as migration 0061 requires. ✓ 15. Gate blockers: the stale-citation blocker rows sum to **333**, matching `with_stale_hc` reached independently. ✓ 16. Floor breaches: 13 under 8 fields + 2 with no scored dimension − 1 breaching both = **14** = `published_floor_breaches`. ✓ 17. Published entities not gate-ready: 811 − 339 promotion-ready = **472** = 58.20%. ✓ 18. Risk-transfer values read: 1 + 1 + 3 + 4 + 8 + 8 = **25** across six fields on 19 distinct entities. ✓ 19. Wedge probe: 12 + 1 = **13** hits over 3,155 + 408 = 3,563 still-listed rows; the 3,573 figure in §11 is all 3,573 rows ever seen including 10 delisted, and both denominators are stated where used. ✓ 20. Every quote reproduced in §6 was tested whitespace-normalised against its own `raw_documents.content` and found verbatim. Two risk-transfer values read `stale` at high confidence — `agentcard`'s indemnification and `9bot`'s liability cap — and are described in §6 but **withheld from the citation set**, disclosed here rather than silently dropped. ✓

---

*The Trust Gap is published weekly from the aidispatch.news index. The scoring rubric, the field catalogue, and the definition of a trust gap are published at /methodology. Trust-gap findings link to exact.works, a commercial relationship disclosed on every page that carries one.*

Entries in this piece 17

Published index entries backed by the same source documents this piece cites.

Sources 22

  1. “Armilla provides named, affirmative AI insurance that responds to those failure modes directly”
    www.armilla.ai · checked Jul 30, 2026
  2. “aiSure TM -backed performance warranties enable you to indemnify your clients for their financial losses or legal liabilities directly related to AI errors.”
    www.munichre.com · checked Jul 31, 2026
  3. “Mosaic Insurance has partnered with Munich Re to harness the power of aiSure™”
    www.munichre.com · checked Jul 31, 2026
  4. “Active Cyber Insurance for Enterprises Comprehensive cyber coverage backed by proprietary intelligence and Allianz’s A+ rated capacity.”
    www.coalitioninc.com · checked Jul 31, 2026
  5. “Google’s IP indemnification policy helps protect Gemini Code Assist licensed users from potential legal ramifications concerning copyright infringements.”
    cloud.google.com · checked Aug 1, 2026
  6. “By using the extension, you agree to indemnify its creator from any liability.”
    chromewebstore.google.com · checked Aug 9, 2026
  7. “ElevenAgents is also the first agent platform eligible for AI insurance through AIUC, once certified.”
    elevenlabs.io · checked Aug 18, 2026
  8. “IN NO EVENT WILL THE TOTAL LIABILITY OF THE NOFIRE AI PARTIES TO YOU FOR ALL DAMAGES, LOSSES, AND CAUSES OF ACTION (WHETHER IN CONTRACT OR TORT, INCLUDING, BUT NOT LIMITED TO, NEGLIGENCE OR OTHERWISE) ARISING FROM OR RELATED TO THE TERMS, THE CONTENT, AND/OR YOUR USE OF THE SITE, EXCEED, IN THE AGGREGATE, $100.00.”
    nofire.ai · checked Aug 29, 2026
  9. “Has cyber insurance”
    trust.logicmonitor.com · checked Aug 29, 2026
  10. “Up to $100K additional Funds Transfer Fraud coverage”
    www.coalitioninc.com · checked Sep 5, 2026
  11. “Armilla Insurance Services is a Coverholder at Lloyd's. Affirmative AI Liability Insurance is underwritten by certain underwriters at Lloyd's.”
    www.armilla.ai · checked Sep 11, 2026
  12. “We never train on our customer's proprietary data. We adhere to strict data minimization principles, collecting and processing only what's necessary, backed by an indemnification clause in our terms.”
    augmentcode.com · checked Sep 18, 2026
  13. “Each party's liability arising out of or in connection with this DPA is subject to the limitations of liability set out in the Terms of Service.”
    mailkite.dev · checked Sep 19, 2026
  14. “The limitations of liability agreed between the parties in the main agreement apply equally to this DPA.”
    stackmint.ai · checked Sep 19, 2026
  15. “In no event shall TaleTok.io's total liability to you for all damages exceed the amount you paid to TaleTok.io over the past six months.”
    taletok.io · checked Sep 19, 2026
  16. “Service Provider shall indemnify and hold harmless Company and its affiliates, parents, subsidiaries, employees, officers, contractors, and agents from and against any third-party claims arising from (a) a breach of Service Provider's representations or warranties under this DPA”
    richpanel.com · checked Sep 26, 2026
  17. “We are not liable for any damages arising from your use of the Service, including data loss or service interruptions.”
    www.alttextlab.com · checked Sep 29, 2026
  18. “You agree to indemnify and hold harmless AltTextLab.com, its owner, employees, and partners from any claims or liabilities arising from your use of the Site, any content you submit, your breach of these Terms, or violation of third-party rights.”
    www.alttextlab.com · checked Sep 29, 2026
  19. “Liability Caps and Damages Waiver. To the maximum extent permitted under Applicable Data Protection Laws, each party’s total cumulative liability to the other party arising out of or related to this DPA will be subject to the waivers, exclusions, and limitations of liability stated in the Agreement”
    www.fathom.ai · checked Sep 28, 2026
  20. “9.1. Indemnification by Conversica. Subject to Section 9.3, Conversica shall indemnify, defend, and hold harmless Customer and its Affiliates and each of their respective employees, officers, directors, contractors, shareholders, agents and assigns (each a “Customer Entity”) from and against any and all damages, losses, costs (including reasonable attorneys’ fees), or other expenses arising from third party claims, actions, suits or proceedings against Customer alleging that any purchased Service when used by Customer and its Authorized Users as permitted in this Agreement infringes or misappropriates an intellectual property right”
    conversica.com · checked Sep 29, 2026
  21. “EACH PARTY’S AGGREGATE LIABILITY WILL BE LIMITED TO THE TOTAL AMOUNTS PAID OR PAYABLE BY CUSTOMER TO CONVERSICA IN THE TWELVE MONTHS PRECEDING THE FIRST INCIDENT OUT OF WHICH THE LIABILITY AROSE.”
    conversica.com · checked Sep 29, 2026
  22. “aiSure is a comprehensive suite of coverage for AI systems. Designed to address a wide range of AI-related risks for AI providers and corporate adopters.”
    www.munichre.com · checked Oct 6, 2026