Withdrawal of the Network Integrity findings — the sealed record

The instrument chain

A document cannot contain its own hash; each hash above is published beside the document and registered in the ledger. Each document’s served bytes were re-hashed when this page was built and compared against the pinned value.

Notice of withdrawal · 2026-08-04

sha256 238f46985f05c1487bb3d4530ad9a50055bdff337d738823c48fc9cf5a67d4ae

# NOTICE OF WITHDRAWAL — Network Integrity Record, licence-gap finding class

**Issued** 2026-08-04 · TrustNav LLC (Evolyn), Denver, Colorado
**Applies to** every edition of the Network Integrity Record that has ever existed, including
the edition that was pinned and publicly served at `https://trustnav.health/record/network-integrity`.

This document is published as a permanent, hash-sealed record. It is not a correction notice
appended to a standing finding set. **It withdraws the finding set.**

---

## 1. What is withdrawn

**All 182 findings of the contradiction class `active_but_unlicensed_in_state` are withdrawn in
full, in every edition in which they appeared.** They are withdrawn as of 2026-08-04, on the
authority of the operator, following an adversarial audit that concluded on 2026-07-31.

Combined with the 7 `no_corroborating_evidence` findings withdrawn on 2026-07-31, this leaves the
published Network Integrity Record with **no standing findings at all**:

| edition | sealed | findings published | standing after this notice |
|---|---|---|---|
| Edition One `cfc90a7936aa…` | 2026-07-28 | 189 (182 licence-gap + 7 no-corroboration) | **0** |
| withdrawn intermediate `03d3010c2d64…` | 2026-07-28 | 1,562 | **0** (withdrawn 2026-07-28) |
| Edition Two `733b056b6952…` — **the pinned, publicly served edition** | 2026-07-28 | 189 (182 + 7) | **0** |
| Edition Three `e2471e43a7e6…` — never pinned, never public | 2026-07-31 | 183 (182 + 1) | **0** (withdrawn 2026-07-31) |
| Edition Four `f7c5d16b7d67…` — never pinned, never public | 2026-07-31 | 183 (182 + 1) | **0** |

Edition Two is the one that matters to a reader, because it is the only one that was ever public.
**189 of its 189 findings are now withdrawn. Nothing in it stands.**

Editions Three and Four each carried one additional observation of a different class
(`active_but_nppes_inactive`). Neither edition was ever pinned, published, or deployed, and that
observation is not published anywhere. No edition of this record now stands on any finding.

Nothing is deleted. Every sealed edition artifact remains served, unaltered, at its original URL,
and every root remains resolvable at `https://trustnav.health/verify` — where each now answers
**withdrawn** rather than authentic. A history that quietly repairs itself is not a history.

---

## 2. Why they are withdrawn

The class asserted, of each subject, that no active Colorado licence could be bound to their NPI
under the run's matching method. An internal adversarial audit (four independent lanes plus a
synthesis that resolved lane disagreements against primary sources) found that the class has **no
discriminating power whatsoever**, and that a large majority of its findings passed through a
defective adjudication path.

**The control that settles it.** For 127 of the 182 subjects there was no licence identifier to
check at all — the entire basis was name matching. On that axis the accused are indistinguishable
from everybody else, in the wrong direction:

- **72.2%** of the accused match an **ACTIVE** Colorado licensee by exact first-plus-last name.
- **68.2%** of the 146,310-provider Colorado universe do the same.
- (Surname-only: 93.2% accused vs 93.8% universe.)

If these subjects were genuinely unlicensed, their match rate should be markedly **lower**. It is
**higher**. A signal that fires slightly more often on a control population than on the accused
population is not a weak signal; it is not a signal. **The uncertainty is the finding.**

**Provably false accusations.** Only 55 of the 182 declare any Colorado licence number. Of those 55,
**21 bind their own reported licence number to an ACTIVE Colorado licence** — the record accused
people whose active licence was sitting in the same payload that accused them.

**Demonstrated engine defect.** **158 of the 182 (87%)** have a demonstrated defect in their
adjudication path.

**Root cause — the map could not express the licences it was searching for.** The engine's
NUCC-taxonomy-to-Colorado-licence-type map searched for licence-type strings that **do not exist
among the 312 values Colorado's licence vocabulary actually uses**. It looked for `LMFT`, `OD`,
`DPM`, `LCSW`, `PT` where the state issues **MFT**, **OPT**, **POD**, **CSW**, **PTL** (also
`Pharmacist/RPH` vs **PHA**, `Dentist/DDS` vs **DEN**, and `RD/Dietitian`). For those professions
the compatibility test could never return true, so the suppression that would have withheld the
finding could never fire, so the finding published **regardless of actual licensure**. **81 of the
182 (44%) were forced false by construction, before any evidence about them was consulted.** The
credentials wrongly rejected are exactly the ones a behavioural-health-heavy roster would carry:
CSW ×30, prescriptive-authority APRN credentials ×21, MFT ×11, PTL ×10, LPC ×6, CDRH ×6, OPT ×3,
POD ×2.

**Three published corroboration signals were true in zero of 182.** Exact licence-number match,
the best-candidate city/state check, and the exact-name match tier each fired on **none** of the
182. The rigour the exhibit implied — a geography check, an exact-name tier, a licence-number
check — was not operating at all.

**36 findings contradicted their own payload on the same screen.** Eleven published
"no active licence found" while their own best-candidate record showed **Active**; twenty-five
published "expired or inactive" while their own best-candidate record showed **Active**.

**Five subjects had no resolved name at all** in our own store. We published a licence accusation
against people our own data never identified.

**Thirty-three of the 182 (18%) are behaviour analysts.** Colorado's 312 licence types contain no
behaviour-analyst credential. Those 33 were very likely accused of lacking a credential the state
does not appear to issue.

Asked to write the sentence it would say to a regulator who asked *"how do you know these providers
are unlicensed?"*, the audit could not write one it would defend. The honest sentence is: *we do not
know that. For 127 of 182 we never had a licence number to check, and for 125 we found an active
Colorado licence and discarded it.*

---

## 3. The limit of this notice — stated because it cuts against us

**No subject was checked against the live Colorado DORA public licence lookup.** Every number above
comes from our own data checked against our own data (an internal capture of the state licence file,
`co_dora_license-20260728`).

That is **sufficient to withdraw** — our own substrate exonerates 21 subjects outright and shows the
class has no discriminating power. It is **not sufficient to assert anyone's licensure status**, in
either direction. This notice does not establish that any subject is licensed. It establishes that
**we never established that any of them was not**, and that we published as though we had.

---

## 4. What is NOT withdrawn

The withdrawal is bounded, and stating its bound precisely is part of being accurate. The following
were never built on the ghost-provider audit engine, never used the licence-binding machinery, and
are **unaffected**:

- **The UnitedHealthcare Insurance Company / Surest public-file availability record.** Thirteen
  state-listed machine-readable files that failed every dated public-access test — listed URLs,
  portal search, and the federal catalog — while the Division's published sheet lists them valid
  through 01/01/2027. This is an availability observation against dated HTTP responses; it does not
  touch provider identity, licensure, or NPPES.
- **SERFF filed-versus-observed alignment.** Twenty filed Colorado Option plans placed beside the
  observed public rate files; sixteen aligned, four filed-but-not-observed, each stated with its
  SERFF filing anchor.
- **Exchange alignment across all six issuers.** 152 certified PY2026 plans from the exchange
  certification dataset beside each issuer's own observed public files.
- **The rate-benchmark packets**, including the Colorado Option cross-issuer comparison resealed
  2026-07-27 with its correction trail on its face.
- **The archive holdings inventory** — the hash-pinned record of what the archive holds, by family
  and date range.

None of these depend on a licence binding, a name match, or the taxonomy map named in §2.

Equally: this notice does not assert that any carrier directory is accurate, or that no listing
problem exists in the substrate that was screened. It asserts that **our record never established
one**, and that publishing as though it had was our error and no one else's.

---

## 5. What remediation requires before any licence-class finding publishes again

This class does not return by re-running the query. Every item below is a precondition:

1. **Derive the licence-type map from the state licence vocabulary itself** — all 312 values plus
   the subCategory field — instead of a hand-written short list of abbreviations.
2. **An unmappable taxonomy becomes a suppression, never a finding.** If the engine cannot express
   the credential it is looking for, the correct output is silence, not an accusation.
3. **A crosswalk between NPPES credential abbreviations and the state's board codes**
   (LMFT↔MFT, optometry/podiatry↔OPT/POD, advanced-practice prescriptive credentials↔APN).
4. **Drop the first-name-prefix predicate and the relevance-blind candidate cap** in the binding
   query.
5. **A subject with no resolved name is ineligible for any finding**, unconditionally.
6. **Repair or delete the city/state check and the exact-name tier** — a published signal that is
   true in zero cases must not be presented as though it discriminates.
7. **A base-rate control against the full Colorado provider universe becomes a release gate.** The
   control in §2 is the check that should have run before publication, not after. No class publishes
   again without demonstrating that it fires materially more often on the accused population than on
   the universe.
8. **Live-source verification.** No licence-class finding publishes again on internal substrate
   alone.

---

## 6. How to verify this notice

1. Fetch this document from `https://trustnav.health/record/editions/nir-withdrawal-notice-2026-08-04.md`.
2. Recompute its sha256. Compare it to the hash printed beside the link on
   `https://trustnav.health/record/network-integrity`. (A document cannot contain its own hash; the
   hash is published beside every link to it and registered in the ledger.)
3. Paste any edition root from the table in §1 into `https://trustnav.health/verify`. Each now
   answers **withdrawn**.

Corrections, disputes, and anything that looks wrong in this notice:
**corrections@trustnav.health**. A document claiming our seal that does not verify is exactly what
we want to hear about.

---

## 7. Posture

Review-only. Nothing in the withdrawn class was, or is, a regulatory determination, an accusation of
misconduct, or a statement about any provider's standing. The record's product is its credibility,
and a record that cannot withdraw its own flagship finding loudly does not have one. This notice is
issued on our own initiative, from our own audit, before any external party raised the defect.

Clinician names and NPIs are withheld from this notice, as from every outbound surface.

*TrustNav LLC (Evolyn), Denver, Colorado · ben@trustnav.health · corrections@trustnav.health*

raw artifact (for verification): /record/editions/nir-withdrawal-notice-2026-08-04.md

Supersession record · 2026-08-05

sha256 863393e41ae308e4fc7c7bd48321ef42856486db110c849d3f51c7b54ba321a9

# SUPERSESSION RECORD — Notice of Withdrawal (2026-08-04), §1 serving statement

**Issued** 2026-08-05 · TrustNav LLC (Evolyn), Denver, Colorado
**Supersedes, in part** the sealed document *NOTICE OF WITHDRAWAL — Network Integrity
Record, licence-gap finding class*, issued 2026-08-04, sha256
`238f46985f05c1487bb3d4530ad9a50055bdff337d738823c48fc9cf5a67d4ae`
(served at `/record/editions/nir-withdrawal-notice-2026-08-04.md`).
**Scope of supersession:** section 1 serving statement only. Nothing else in the
original notice is superseded, qualified, or reinterpreted by this record.

This is a formal, sealed, append-only supersession record — not page prose. It exists
because the original notice is hash-sealed and is never edited: when one of its
statements stops being true, the honest instrument is a new sealed document that says
so, names the statement, and leaves the original bytes untouched.

---

## 1. The superseded statement

Section 1 of the original notice states:

> "Nothing is deleted. Every sealed edition artifact remains served, unaltered, at its
> original URL, and every root remains resolvable at `https://trustnav.health/verify`
> — where each now answers **withdrawn** rather than authentic."

Only the **serving clause** of that sentence — "Every sealed edition artifact remains
served, unaltered, at its original URL" — is superseded, and only for the five
subject-level packet files listed in §2. The rest of the sentence remains true:
nothing is deleted, and every root still resolves at `/verify` as withdrawn.

## 2. The supersession

On **2026-08-05**, under the Gate 6 publication controls (ceremony review ADDENDUM 2:
subject-level artifacts of withdrawn editions must not remain publicly fetchable
beside a protected subject-level edition, because that would enable re-identification
and defeat the public record's small-cell protection), the five withdrawn-edition
subject-level packet files were moved out of public serving into the operator's
custody archive (`withdrawn-editions-custody/`, recorded in `CUSTODY-MANIFEST.md`).

Each file was moved **byte-identical** — its sha256 was computed before and after the
move and matched exactly:

| file | edition | sha256 (unchanged by the move) |
|---|---|---|
| `ghost_providers_cigna_co_CO_20260728T185342Z.md` | Edition Two (root `733b056b6952cf42a2328d381b7976068eba42afdf1d077ce93699190136c6c3`) | `7defcfd2342c6f7db95cfa9c33162fc4245079c174056e4a444f0d32df4bdec6` |
| `ghost_providers_cigna_co_CO_20260731T131109Z.json` | Edition Three (root `e2471e43a7e6060b528f5069dc3d3129ee9b447ec9ba2273e0263517f59a2ce4`) | `aeee62c3a2f9eceeea69d4ae0c208df9fcdd270c8fe9c953f826a792231cb307` |
| `ghost_providers_cigna_co_CO_20260731T131109Z.md` | Edition Three | `11fbb5a0d979762e4c1b479d4bc754a56044536b4814526d5f40d9ed22ecccf0` |
| `ghost_providers_cigna_co_CO_20260731T160612Z.json` | Edition Four (root `f7c5d16b7d6785ba0bed729fa2933918eb38619cef708cd804171fa38c7acd5c`) | `2b91dd2660ecf160c4152488907fe915249d00c2ff563e3a56a296ef9f10c924` |
| `ghost_providers_cigna_co_CO_20260731T160612Z.md` | Edition Four | `d899907bb2f989719fbe38a4cfebbde4208191af807b2f23edc7dfceb9d18366` |

Their former URLs under `/record/editions/` answer a **governed 410** that names the
edition and the reason for removal and repeats no subject-level content. Every
edition root above still resolves at `/verify` as withdrawn. Anyone holding a copy of
any of these files can verify it against the sha256 in this table.

## 3. The original notice stands unedited

The original notice has **not** been edited, re-rendered, or re-sealed. As of the
issuance of this record its served bytes still re-hash exactly to
`238f46985f05c1487bb3d4530ad9a50055bdff337d738823c48fc9cf5a67d4ae`. Its withdrawal of
the finding set, its stated reasons, its stated limits, and its statement of what is
not withdrawn are all unaffected by this supersession. A reader of the original
notice should read its §1 serving clause together with this record.

## 4. What this record does not contain

This record names editions, files, and hashes only. It contains no provider
identifier, no clinician name, and no subject-level allegation — and it makes no
assertion, in either direction, about any provider's standing.

## 5. How to verify this record

1. Fetch this document from
   `https://trustnav.health/record/editions/nir-withdrawal-notice-supersession-2026-08-05.md`.
2. Recompute its sha256 and compare it to the hash printed beside the link on
   `https://trustnav.health/record/network-integrity` (a document cannot contain its
   own hash; the hash is published beside every link to it and registered in the
   ledger, resolvable at `https://trustnav.health/verify`).
3. Fetch the original notice at
   `https://trustnav.health/record/editions/nir-withdrawal-notice-2026-08-04.md` and
   confirm it still re-hashes to
   `238f46985f05c1487bb3d4530ad9a50055bdff337d738823c48fc9cf5a67d4ae`.

Corrections, disputes, and anything that looks wrong in this record:
**corrections@trustnav.health**.

*TrustNav LLC (Evolyn), Denver, Colorado · ben@trustnav.health · corrections@trustnav.health*

raw artifact (for verification): /record/editions/nir-withdrawal-notice-supersession-2026-08-05.md

Addendum · 2026-08-06

sha256 408ba59a9af6ca9c00fb1caad00386d3c210b1583fc65ee252ea083afd815662

# ADDENDUM — Notice of Withdrawal (2026-08-04), §4 "What is NOT withdrawn", first bullet

**Issued** 2026-08-06 · TrustNav LLC (Evolyn), Denver, Colorado
**Supersedes, in part** the sealed document *NOTICE OF WITHDRAWAL — Network Integrity
Record, licence-gap finding class*, issued 2026-08-04, sha256
`238f46985f05c1487bb3d4530ad9a50055bdff337d738823c48fc9cf5a67d4ae`
(served at `/record/editions/nir-withdrawal-notice-2026-08-04.md`).
**Scope of supersession:** the **first bullet of section 4 only** — the
UnitedHealthcare Insurance Company / Surest public-file availability record.
Nothing else in the original notice is superseded, qualified, or reinterpreted
by this addendum.

This is a formal, sealed, append-only addendum — not page prose. It exists because
the original notice is hash-sealed and is never edited: when one of its statements
stops being adequate, the honest instrument is a new sealed document that says so,
names the statement, and leaves the original bytes untouched.

---

## 1. The superseded statement

Section 4 of the original notice lists what the NIR withdrawal does **not** reach.
Its first bullet reads:

> "**The UnitedHealthcare Insurance Company / Surest public-file availability
> record.** Thirteen state-listed machine-readable files that failed every dated
> public-access test — listed URLs, portal search, and the federal catalog — while
> the Division's published sheet lists them valid through 01/01/2027. This is an
> availability observation against dated HTTP responses; it does not touch provider
> identity, licensure, or NPPES."

Two clauses in that bullet are superseded:

1. **"Thirteen state-listed machine-readable files that failed every dated
   public-access test."** The *files* did not fail the tests; the *published URLs*
   did. The HTTP 403 those URLs return is `AuthorizationFailure`, which Azure
   returns at the storage-account level **before** it evaluates whether a blob
   exists. An invented blob name in the same container returns the same 403 with the
   same 246-byte `AuthorizationFailure` body — identical byte for byte apart from
   that body's own per-request `RequestId` and timestamp. The refusal therefore
   carries no information about the thirteen named files.
2. **"— listed URLs, portal search, and the federal catalog —"**, insofar as it
   reads as an exhaustive search. It was not exhaustive. The federal-catalog search
   filtered on the `_CO_` state-regime filename token and stopped at zero hits;
   removing that token resolves twelve of the thirteen basenames to live 2026-07-01
   counterparts at a carrier endpoint the Division's sheet does not list, all of
   which were retrieved on 2026-08-06.

The bullet's final sentence — "it does not touch provider identity, licensure, or
NPPES" — is **not** superseded and remains true.

## 2. The corrected statement

The availability finding, as it now stands:

> On 2026-08-06 the thirteen Colorado in-network rate-file URLs the Colorado
> Division of Insurance publishes for UnitedHealthcare Insurance Company (8) and
> Surest (5) return HTTP 403 `AuthorizationFailure`, as they did on 2026-07-08,
> 07-09, 07-14, 07-17 and 07-20. The refusal is scoped to the storage account, not
> to those files. The Division's sheet has published no submission since January
> 2026 — its January 2026 tab exported on 2026-08-06 is byte-identical to our
> 2026-03-10 custody copy and still carries the header "Downloadable Links
> (expiration date: 01/01/2027)". Separately, the carrier serves a 2026-07-01
> Colorado edition at an endpoint the sheet does not list; all thirteen Colorado
> in-network files it holds for these two entities were retrieved on 2026-08-06
> (43,976,796 bytes). Seven carry in-network rate rows; six are 157–166-byte gzips
> whose `in_network` array is empty.
>
> This asserts no failure of duty by either carrier or by the Division. Whether any
> of it breaches a requirement is a separate, open question and is not established.

## 3. Why this is an addendum and not a withdrawal

The availability finding is **not withdrawn**. Its central observation — that the
transparency links a state regulator publishes for two carriers do not resolve for
any member of the public, on every date tested across four months — is reproduced,
dated, origin-authored, and now carries a negative control that bounds exactly what
it proves. What is withdrawn is the **inference** the July artifacts drew from it:
that no public copy of those entities' Colorado rates existed anywhere. That
inference was false, and it was false when it was sealed.

The bullet's placement in §4 of the original notice therefore stands: the finding
was not built on the ghost-provider audit engine and is not part of the licence-gap
class. It simply needs to be read as corrected.

## 4. The governing correction record

The full correction — our method error, the negative control, the Division's sheet
as re-read, the per-file retrieval table, the non-conclusion list, and every sealed
artifact it supersedes with its sha256 — is:

> **CORRECTION AND SUPERSESSION RECORD — UnitedHealthcare Insurance Company /
> Surest public-file availability finding**, issued 2026-08-06 (**second issue, same
> day** — that record was itself audited and corrected; its §7 lists what changed),
> sha256 `b85a34fc2fbf53a9ea44e301f8e4804144ee972364a77f81259b28cd00ea5686`,
> served at `/record/editions/uhc-surest-availability-correction-2026-08-06.md`.

## 5. The original notice stands unedited

The original notice has **not** been edited, re-rendered, or re-sealed. As of the
issuance of this addendum its served bytes still re-hash exactly to
`238f46985f05c1487bb3d4530ad9a50055bdff337d738823c48fc9cf5a67d4ae`. Its withdrawal
of the licence-gap finding class, its stated reasons, and its stated limits are all
unaffected. This addendum is additive to, and does not replace, the 2026-08-05
supersession record (sha256
`863393e41ae308e4fc7c7bd48321ef42856486db110c849d3f51c7b54ba321a9`), which
supersedes the notice's §1 serving statement on an unrelated ground.

A reader of the original notice should read its §4 first bullet together with this
addendum.

## 6. What this addendum does not contain

It names documents, URLs, files, and hashes only. It contains no provider
identifier, no clinician name, and no subject-level allegation — and it makes no
assertion, in either direction, about any provider's standing, or about any
carrier's or regulator's compliance with any requirement.

## 7. How to verify this addendum

1. Fetch it from
   `https://trustnav.health/record/editions/nir-withdrawal-notice-addendum-2026-08-06.md`.
2. Recompute its sha256 and compare it to the hash printed beside the link on
   `https://trustnav.health/record/network-integrity` (a document cannot contain its
   own hash; the hash is published beside every link to it and registered in the
   ledger, resolvable at `https://trustnav.health/verify`).
3. Fetch the original notice at
   `https://trustnav.health/record/editions/nir-withdrawal-notice-2026-08-04.md` and
   confirm it still re-hashes to
   `238f46985f05c1487bb3d4530ad9a50055bdff337d738823c48fc9cf5a67d4ae`.
4. Fetch the correction record named in §4 and confirm it re-hashes to
   `b85a34fc2fbf53a9ea44e301f8e4804144ee972364a77f81259b28cd00ea5686`. If it does not,
   check the ledger entry `artifact.uhc_surest_availability_correction_2026_08_06`
   before concluding anything: that record is a correction instrument and is expected
   to be revised when it is found wrong. It was revised once on its day of issue —
   from `96a58b233f5ea0565e7d75803d8fa117fedc9b9199946d2d0d17be5ec0981ec7` to the hash
   above — and its own §7 records why.

Corrections, disputes, and anything that looks wrong in this record:
**corrections@trustnav.health**.

*TrustNav LLC (Evolyn), Denver, Colorado · ben@trustnav.health · corrections@trustnav.health*

raw artifact (for verification): /record/editions/nir-withdrawal-notice-addendum-2026-08-06.md

How to verify this bundle

1. Fetch any raw artifact linked above and recompute its sha256; compare it to the hash printed beside it here and on /record/network-integrity.
2. Paste any edition root from the notice's §1 table into /verify — each answers withdrawn.
3. Anything that looks wrong in any of these documents: corrections@trustnav.health.