A scan of the corpus proposed more shared causes than survived the reading. The rejected ones are kept here, with the reason, so a later pass cannot quietly re-derive a link this one judged unfounded — and so a reader can see what the surface chose not to say.
the dominant electronic-health-record platform
Both deployments ride a record system whose vendor the dossiers decline to name in their own text: one records only "the EHR vendor's proprietary sepsis prediction model" and names the firm nowhere but in the titles of its cited sources, and the other marks the attribution as context rather than a direct in-text vendor claim. Drawing a shared-platform dependency would supply a name both records withheld. The dependencies also differ in kind — one deployment bought the vendor's model, the other only hosts its own model on the vendor's platform.
the hosting cloud provider
This is where the plan's "model family" axis would have lived, and it is unbuildable on this evidence. Both records write "a major cloud provider" — the corpus's standard form for withholding a host — and one adds "a commercial large-language-model platform" without naming it. Supplying the name would be invention, and naming a model would breach the repository's own ban on model identifiers in committed content. Two independent reasons, same answer: no model-family axis.
the analytics vendor
One dossier names an analytics firm in its supplier field. The other deliberately writes "a data-analytics vendor's deep-learning fraud engine" and the firm appears only as the publisher of the cited customer case study. A citation is not a supplier record, and the second dossier chose not to make one.
one pilot entered twice
The scan saw one builder across two entries, but the two entries describe the SAME pilot at two granularities — both jurisdictions read as the same partnership pilot. A common-cause link requires two deploying organizations, and there is only one here.
a builder that later closed
A nonprofit named as a co-builder of one deployment is itself the subject of another entry, which documents its abrupt closure — a real supplier-continuity risk, but only ONE deployment depends on it, and the second entry IS the party rather than a second dependent. The two-dependents rule rejects it: a dependency plus one dependent is a supplier relationship, not a correlation across organizations.
a productivity-suite provider
One deployment records the firm as its supplier. The other mentions it only as the account estate the monitoring service scans. Being scanned is not being supplied, and the surviving half of the pair would be a single dependent in any case.
The Cigna Group as corporate parent
The shared-parent fact is real and the bundle states it — eviCore by Evernorth is recorded as owned by The Cigna Group since 2018 — but it is stated in that entry's `jurisdiction` field, which is not one of the two evidence carriers this registry grounds on. Neither entry's `description` names The Cigna Group and neither carries a supplier field at all, so no quote from a carried field names the cause. The cluster passes the gate only if the cause is weakened to "Cigna" and grounded on sentences about the operator disputing press coverage — adjacent prose, not evidence of the ownership link — and that weaker cause would also misdescribe the relationship, since for the post-service review Cigna is the operator itself rather than a party it depends on. Restore this candidate only if a PAN text change carries the ownership sentence into both descriptions AND both deployments have Lab networks.
a shared investigative newsroom
Two deployments name the same newsroom because the same reporters investigated both, which is correlation in what is DOCUMENTED about them and not in anything they depend on. A shared source of evidence is the opposite of a shared cause: it is why the record exists at all. Admitting it would also make the finding self-fulfilling in a catalogue assembled largely from investigative reporting, where the most-cited newsroom would necessarily link the most deployments. None of the registry's three kinds — supplier, assurance, instrument — covers who reported a story.
the national organ-allocation network and its contractor
The scan's strongest candidate on paper and the clearest failure in practice. This deployment depends squarely on two named outside parties — the OPTN as the network that ordered the correction, and UNOS as the contractor operating UNet, the custom reporting tools and the monitoring reports — and both are named openly in the dossier, so the name-withholding problem that killed four of the six shipped rejections does not arise here. It fails on the TWO-DEPENDENTS rule instead: across all 147 Lab-networked deployments in the pinned bundle, exactly ONE depends on either party. A dependency with a single dependent is a supplier relationship, not a correlation across organizations, and the registry rejects it for the same reason it rejected `rejected-single-dependent`. It stays here rather than being dropped so that a future transplant, organ-allocation or registry-operated deployment entering the catalogue is read as the SECOND dependent that would make this cluster real.
the CKD-EPI estimating equations as a shared instrument
The instrument axis is the one this deployment would most naturally join — `instrument-vi-spdat` is the shipped precedent for a published assessment instrument shared across deployments, and a clinical equation embedded in thousands of independent laboratories is exactly that shape. It fails on the corpus, not on the concept: no other entry in the pinned bundle runs on eGFR, on a creatinine-based estimate, or on any race-coefficient-bearing clinical formula. The two candidates a reader might reach for do not hold. The cost-proxy care-stratification deployment is a different instrument doing a different thing — a spend variable standing in for need, not a formula with a race term — and the pediatric abuse-detection deployment runs a screen, not an estimating equation. The scarcity is itself the finding, and the registry's header already says so about this corpus: the instrument axis is thin because the dossiers rarely name a shared instrument, not because one was overlooked here.
the health-information-exchange and record-retrieval platform
Two independent reasons, same answer. FIRST, the shipped `rejected-ehr-platform` row already rejects this exact axis for the two deployments that ride the platform, on the ground that both dossiers decline to name the vendor in their own text; nothing in this record changes that. SECOND and decisive, the DEPENDENCY IS THE WRONG KIND. Those deployments run ON the record system. This one RETRIEVES FROM it: the trade guidance names record-retrieval and health-information-exchange systems as one of several routes a transplant program used to reach creatinine values held by other hospitals, alongside direct requests to reference laboratories and dialysis centers. Being a source a program queries is not being a platform a deployment depends on, and the registry has already ruled on the same distinction in `rejected-account-estate`: being scanned is not being supplied.
Allscripts Healthcare
One name, two unrelated relations. On the child-abuse alerting board Allscripts is the record platform one of the disseminated health systems runs on, and the deployment's own record says the platform bounded what its build team could express — a live dependency. In the sponsored pain-alert record Allscripts is only the acquirer, which bought the company on or about 13 February 2018, after the conduct the criminal resolution concerns, and supplied nothing into the deployment; its documented connection is the reported purchase price and the charge taken for the resolution. A shared-supplier cluster asserts shared reliance on one party's practices and defaults, and there is none: the dependency here would run backwards in time. The sponsor in this record stands behind one network only, so no sponsorship cluster exists either.
Amazon as corporate parent and operator
The repeat is real and the bundle states it plainly, and it is still not a common cause. Every kind this registry carries — supplier, assurance provider, instrument — names a party the members DEPEND ON, and in every one of these entries Amazon is the operator itself: two of them record no vendor field at all because the deploying organisation built every part of the system, and the other two record in-house builds in words that name no company. A shared-operator row would assert only that one company runs several of its own systems, which describes how the roster was selected rather than a dependency any reader could act on, and the file has already declined the identical move once: the Cigna candidate was dropped in part because the cause 'would also misdescribe the relationship, since for the post-service review Cigna is the operator itself rather than a party it depends on.' AMENDED 2026-08-31 (P6-HIRING): when this row was first written the contractor-rating deployment had no Lab network and was listed as the fourth one out. It has one now, so ALL FOUR Amazon deployments ship — the hiring-model case, the warehouse productivity and pacing process, the productivity-discipline programme and the contractor standing-and-deactivation programme — and the count is stated at four here rather than left to age. The count moved and the ruling did not, and the difference was MEASURED rather than assumed. Offered to the shipped gate over the ASSEMBLED catalogue as a private in-memory FOUR-member supplier cluster with Amazon as the cause, on the recorded supplier field: four problems, one `quote-not-carried` per member, because two of the four carry no supplier field at all and the other two carry one that names no company. Re-offered on the dossier description — the carrier that treats this candidate best, since three of the four descriptions do contain the word — it still fails, once, on the hiring-model case, whose description names no company anywhere. `too-few-dependents` does not fire at four members and never did the work here: what refuses this candidate is the KIND, not the count. Restore this candidate only if the registry gains an operator-family kind by owner ruling.
a shared congressional investigative record
Both deployments cite the same December 2024 Senate committee majority report, and it is the single largest documented overlap between them — which is exactly why it is written down here rather than left to be noticed again later. A shared citation is not a shared dependency: no deployment depends on an investigative report in order to operate, nothing about either system's behaviour is correlated through it, and the two case files read separable parts of it (the discipline findings against the injury and pace findings). Promoting it would turn this surface into a bibliography-overlap index, which is a different instrument with a different meaning. The honest place for the overlap is each case file's own boundary statement, where it already sits.
a shared corporate parent across three deployments
FOUR deployments in this catalogue run inside one corporate group — a contractor standing-and-deactivation programme, a warehouse productivity and pacing process, a hiring-model case and a productivity-discipline programme. (AMENDED 2026-08-31, P6-HIRING: this row was written at three shipped plus a fourth 'in preparation'; the fourth landed in the same car that ships the contractor-rating board, so the number is stated at four rather than left to age, and the measurement below was re-run at four rather than carried over from three.) That is a real relation and it is not one this registry can express. The registry records THREE kinds of shared dependency, supplier, assurance and instrument, and a corporate parent is none of them: the question it exists to answer is which networks rely on the same OUTSIDE party or instrument, and a group relying on itself is not an outside reliance. The mechanical refusal follows from the same fact. Every evidence carrier the gate accepts is a supplier field or a description naming a supplier, and each of these deployments is FIRST-PARTY with no external vendor anywhere in it: two record no supplier field at all, and the two that do record one describe an in-house build without naming the parent. Offered to the shipped gate over the ASSEMBLED catalogue on 2026-08-31, as a private in-memory FOUR-member supplier cluster, the candidate fails four times, once per member, with `quote-not-carried`: a link whose quote does not resolve is authored. Re-offered on the dossier description instead, the carrier that treats it best because three of the four descriptions do contain the name, it still fails once, on the hiring-model case, whose description names no company anywhere. `too-few-dependents` does not fire at four members, so the count is not what refuses this candidate — the kind is. The one adjacent candidate was also examined and also refused: the municipal deactivation-rights ordinance is a shared INSTRUMENT in the ordinary sense, but the other companies it binds — three of which appear in the same quarter's enforcement record — have no Lab network and no bundle entry, so there is no second member to link to. Recorded here so a later pass does not silently re-derive either candidate.
Deloitte, and the vendor's named customer list generally
This is the one candidate on the corpus that a later pass would reach for, so it is written down measured rather than dismissed. The shipped `assurance-deloitte` cluster already links four deployments through one firm acting as commissioned reviewer, assurance reviewer and systems integrator, and the ACLU's complaint quotes the assessment vendor's own site and third-party lists naming Deloitte among its customers. THREE INDEPENDENT REASONS, and the first is machine-measured. FIRST, the shipped gate rejects it. Offered the extended cluster, `collectCommonCauseProblems` returns exactly one problem, `quote-not-carried`: the deployment's own pinned dossier description does not contain the string, because the PAN file for this deployment deliberately names no client at all. A link whose quote does not resolve is authored, and this one does not resolve. SECOND, the RELATION IS THE WRONG KIND. The registry's three kinds are supplier, assurance and instrument. In the shipped cluster the firm BUILT or REVIEWED the deployed systems; here it would be a party that BOUGHT an assessment, named in the seller's marketing. Being a customer of a vendor is not depending on that vendor's practices in any sense the registry means, and the same distinction has already been ruled on twice in this file — being scanned is not being supplied, and being a source a program queries is not being a platform a deployment depends on. THIRD, the evidence record forbids the reading in terms. The customer names come from the vendor's own marketing and from third-party lists quoted in an advocacy complaint; the client employer that IS a respondent on the discrimination charges is publicly unnamed, described only as a mid-sized company headquartered in the United States, and the dossier states that the vendor's marquee customers must never be presented as that respondent. A cluster built on the customer list would put exactly that inference on a public page. THREE FURTHER CANDIDATES WERE SCANNED AND FELL EARLIER, before any gate run. (a) The commercial speech-to-text service inside the video product would be a supplier link if it were named — but the identification comes from a developer's published dissertation and a patent rather than from any vendor disclosure, the complaint itself notes that the error research tested a system from the same provider rather than necessarily the deployed version, and this bundle names no provider anywhere; a supplier cluster cannot be built on an identification the record declines to make. (b) The civil-liberties complainant appears in seven pinned entries and the two federal forums appear in five and eight, but a shared COMPLAINANT or a shared REGULATOR is a common observer rather than a common cause, and neither is one of the registry's three kinds; measured, none of them is named in a gate carrier on any entry. (c) The other video-assessment vendor in this catalogue shares a market, a domain and a candidate population with this deployment and shares no supplier, instrument or parent with it whatsoever — two competitors are the opposite of a common cause. The scarcity is the finding the registry's own header already states about this corpus.
Checkr
One consumer reporting agency furnishes the background reports that many gig platforms act on — on its own marketing, ninety percent of that market's checks — which makes this the clearest shared-supplier candidate in the corpus and the whole subject of the deployment modelled here. It is nonetheless unbuildable on this evidence, for three independent reasons measured against the shipped gate rather than reasoned about. First, the agency's own dossier description writes it in the third person throughout, as "the vendor" and "the reporting agency", so a description quote does not resolve; the name appears in that entry's key_factors and in its source strings and URLs, and a citation's title is not the dossier saying who built the system. Second, the two platform-side deployments in the bundle that mention a gig platform at all name no screening vendor in either carrier the rule reads. Third, neither of them has a Lab network at this bundle, so the cluster carries a single dependent where the rule requires two. The third reason expires if either platform-side deployment gets a network; the first two do not, and clear only if the dossiers themselves start naming the party. The lending fleet's name-screening deployment does name its own agency in a carrier, but that is a different party in a different market and joining the two would be a resemblance link rather than a shared cause.
the 1959 lie-detector statute as a shared instrument
The registry's `instrument` kind exists for a shared measuring instrument travelling between deployments — the housing triage questionnaire and the kidney-function estimating equations are the shipped examples — and a forty-year-dormant employment statute reaching a new assessment layer looks, at first glance, like exactly that: one 1959 definition of a banned instrument, applied by its purported function, now reaching whatever a vendor happens to claim in marketing. It is not buildable here, and the reason is a count rather than a judgement. Measured across all 205 deployments in the pinned PAN bundle, the statute reaches ONE: the terms "polygraph" and "lie detector" appear in exactly one entry, this deployment's own, and in no other. The copycat wave the ruling produced is real — more than twenty follow-on suits in about a year, including against a large consumer-goods manufacturer — but none of those defendants is a deployment in this library, and most of those suits allege no screening device at all, so even a later entry would need its own AI deployment before it could be a member of anything. A cluster of one is not a cluster. Separately and independently: the ten deployments that mention Massachusetts, seven of them in a gate carrier, share a JURISDICTION rather than a cause, and clustering on a state would link seven unrelated systems on nothing but a map. Both were scanned rather than reasoned about, and both are written down here so that a later pass finds the measurement instead of re-deriving the idea.
HireVue
Four deployments in the pinned bundle involve one video-assessment vendor, and this is the clearest shared-supplier candidate in the corpus — one engine, many employers, which is the vendor-layer deployment's whole subject. It is nonetheless unbuildable on this evidence, for two independent reasons. First, not one of the four names the vendor in either carrier the rule reads: the vendor's own dossier description writes it in the third person throughout, and the deployer's recorded supplier field reads "a games-based assessment vendor plus an automated video-interview scoring vendor, chained in one pipeline", naming neither vendor. The name appears in the bundle only inside reference strings and source URLs, and a citation's title is not the dossier saying who built the system. Second, at this bundle only two of the four have Lab networks, and one of those two IS the vendor, so the cluster carries a single dependent where the rule requires two. Both failures were measured against the shipped gate rather than reasoned about. The second reason expired on 2026-08-31, when the two client deployments of this vendor's engine landed in the same car and gave the cluster three dependents against the vendor as the cause; re-run against the shipped gate over the ASSEMBLED catalogue with all four members present, `too-few-dependents` no longer fires. The first reason did not expire and does not expire on its own: re-measured with four members, `quote-not-carried` fires on all four of them, because not one of the four dossier descriptions names the vendor anywhere. It clears only if the dossiers themselves start naming the party.
automatic speech recognition as a shared substrate across deployments
This is the candidate this board makes most tempting, and it is the one a later pass is most likely to re-derive, so it is written down rather than left to be rediscovered. The registry's `instrument` kind exists for a shared measuring instrument travelling between deployments — the housing triage questionnaire and the kidney-function estimating equations are the shipped examples — and automatic speech recognition looks like exactly that here: ONE substrate appearing TWICE inside a single record, at two different companies, four years apart. In 2020 the employer's own call-monitoring metric scored script adherence from speech-recognition transcripts of customer calls and, as alleged, read a Deaf employee's accent as departure from script. In 2024 the same employee's promotion assessment, on the charge's pleaded account, ran her recorded spoken answers through speech recognition again. The published research the charge relies on measured four widely used general-purpose commercial services at a mean word error rate of 52.6 percent for deaf and hard-of-hearing speakers against 5.0 percent for normal-hearing speakers. A substrate with a measured population-level accuracy gap, reused across systems, is precisely the shape a common cause has. It is not buildable, and the reason is a count rather than a judgement. Measured across all 205 deployments in the pinned PAN bundle, the terms "speech recognition", "automatic speech recognition" and "captioning" each appear in exactly ONE entry — this deployment's own — and in no other, in a gate carrier or anywhere else. A cluster of one is not a cluster. Separately and independently, a second reason that would survive even if a sibling deployment appeared: the two systems in this record belong to DIFFERENT companies and the record establishes no shared supplier, no shared model and no shared implementation between them. What they share is a class of technology, and clustering on a technology class rather than on a traceable common supplier or instrument would link deployments on nothing more than a category — the same objection that keeps a shared jurisdiction out of this registry. Both were scanned rather than reasoned about, and both are recorded here so that a later pass finds the measurement instead of re-deriving the idea. A third scan is also recorded so it is not repeated: "accommodation" appears in a gate carrier for three PAN deployments, two of which have Lab networks (this one and a rough-sleeping triage system in another domain and another country). Those two share a duty owed under general disability and equality law, not a cause. A shared legal duty is not a shared instrument, and clustering on one would put every deployment subject to an anti-discrimination statute in the same box.
The U.S. Equal Employment Opportunity Commission
A shared REGULATOR is not a common cause in this registry's sense, and admitting one would break the surface. The registry records shared DEPENDENCIES whose defects correlate across deployments: a builder, a supplier, an instrument, an assurance provider. An enforcement agency is the opposite of a dependency — it acts on a deployment from outside, after the fact, and its involvement is evidence that the two records were separately examined rather than that they share a hidden component. The two deployments also relate to the agency in incompatible ways: this one was sued by the Commission and resolved by a consent decree it now monitors, while the screening-platform record's live proceeding is private collective litigation in which the Commission is not the plaintiff. Admitting this candidate would additionally cluster every deployment in the domain with every other, since six PAN entries mention the Commission and the number can only grow, which is exactly the padding the module header says the surface refuses.
Automated screening at the top of a hiring funnel
Resemblance is not common cause, and this candidate is pure resemblance. The four hiring deployments share a position in a funnel and nothing else: one is an authored deterministic rule built in-house with no vendor at all, one a learned ranker trained in-house on a decade of the organisation's own hiring, one a vendor platform running inside thousands of separate employers, and one a chain of two outside vendors' assessment products. No shared builder, supplier, model, codebase, instrument or assurance provider is documented between any pair of them. The registry's derivation explicitly rejects links proposed by similarity rather than by a named repeated party, and clustering on shape would turn the surface into a taxonomy of deployment types, which the domain pages already are.
Workday
The conversational-hiring vendor behind this deployment was acquired by the company behind a shipped screening board in this catalogue, under an agreement announced 21 August 2025 and completed 1 October 2025, so a shared-parent cluster is the obvious candidate and the dossier itself flags the concentration. It is unbuildable on this evidence, for three independent reasons, and the first two were measured against the shipped gate rather than reasoned about. First, neither deployment names the parent in either carrier the rule reads: this deployment's dossier description writes the acquirer in the third person throughout, as a larger human-capital software company, and the screening deployment's own description does not name it either. The name appears in this bundle only inside reference strings and source URLs, and a citation's title is not the dossier saying who owns the system. Second, only one of the two has a Lab network besides the parent's own board, so the cluster carries a single dependent where the rule requires two. Third, and the reason this rejection should outlive the other two: the relationship post-dates both records. This case is documented from the June and July 2025 record, when the vendor was independent. A common cause explains a correlation between two deployments, and a corporate relationship formed after both records close explains neither. The second reason expires when another of that parent's deployments gets a network; the first clears only if the dossiers themselves start naming the party; the third does not expire at all.
the platform operator common to four deployments in the catalogue, three it operates and one a vendor workforce governed by its policy
Four deployments in this corpus are run by or for the same platform operator, and not one of them carries that operator's name in a carrier the registry reads. Measured against pinned bundle 6.2.61.30: three of the four entries have no supplier field at all and the fourth's records only "in-house ML classifiers and hash-matching across policy areas", and none of the four descriptions contains the operator's name — they write "the operator", "the platform" and "the deployer" throughout. On two of the four the name at least appears in the jurisdiction field, which the registry does not read. On the enforcement-exemption deployment it does not appear even there — that entry writes "United States (Menlo Park, California)" — and on the outsourced-workforce deployment it appears in no authored field either; on both of those the only occurrences anywhere in the entry are citation strings, and a source title is not the dossier saying who runs the system. Beyond the carrier failure the relationship is the wrong kind for three of the four: a supplier cluster asserts that its members DEPEND ON a named outside party, and an operator running its own systems is not an outside party to any of them. The outsourced-workforce deployment is the exception worth stating rather than hiding, because it is the one member where the dependency would be genuine rather than self-operation — a vendor and its review workforce governed by another company's policy, tooling and review targets — and the rejection still holds there, on the carrier test alone. Recorded so a later pass does not re-derive the link from the case files, where the operator is named in prose as the Lab register permits.
the 2020 cooperative source-code audit of one game-based assessment vendor
Two shipped-or-scheduled deployments trace their only source-code-level fairness assurance to a single 2020 academic engagement, and a third names the same city bias-audit mandate. That is a real correlated exposure and it is nonetheless unbuildable on this evidence. Four candidate clusters were put through the shipped gate. A shared-supplier cluster fails twice on quote-not-carried and once on too-few-dependents: this deployment's dossier description writes the vendor in the third person throughout, and the deployer's recorded supplier field reads "a games-based assessment vendor plus an automated video-interview scoring vendor, chained in one pipeline", naming neither party. A shared-instrument cluster on the city mandate fails on quote-not-carried at both members, because both dossiers describe the mandate rather than naming it. A shared-assurance cluster on the audit itself fails on cause-not-named, because the two dossiers describe the same engagement in phrases that share no substring naming it. The fourth candidate, keyed on the four-fifths rule, PASSES the gate with zero problems and is rejected on the vocabulary: the kind `instrument` means the same named tool or questionnaire was administered, and a four-fifths adverse-impact rule of thumb is a legal convention the whole sector applies rather than an outside party anyone is exposed to. Shipping it would put the genuine relationship into the registry under a cause name the evidence does not support. Every one of these four failures was measured against the shipped gate rather than reasoned about. The dependent-count failure expires when a later wave lands another network; the quote and cause failures do not, and clear only if the dossiers themselves begin naming the party or the engagement.
iCIMS
One commercial applicant-tracking platform whose matching and shortlisting features many employers license is the textbook shape for a shared-supplier cluster, and this deployment is a single employer running exactly such a platform. It is nonetheless unbuildable on this evidence, for three independent reasons measured against the shipped gate rather than reasoned about. First, this deployment's own dossier description writes it in the third person throughout, as "the employer" and "the platform vendor", so a description quote does not resolve; the platform's name appears in that entry's source strings and URLs only, and a citation's title is not the dossier saying who built the system. Second, no second deployment of this platform exists anywhere in the corpus, so the cluster carries a single dependent where the rule requires two. Third and decisively, the only screening deployment available to pair it with runs a DIFFERENT vendor's platform, so joining the two would be a resemblance link between two applicant screens rather than a shared cause. The first two reasons expire if a second deployment of this platform is ever networked and its dossier names the vendor in a carrier the rule reads. The third does not expire at all.
the published bridging scorer
This is the corpus's strongest shared-INSTRUMENT candidate on its face: one platform publishes a bridging scorer under a permissive licence, and in March 2025 a second very large platform began testing a system it stated would use that open-source algorithm as the basis of its own rating system. It is nonetheless unbuildable on this evidence, for three independent reasons. First, neither dossier names the instrument in either carrier the rule reads: the crowd-notes deployment's own description writes the mechanism generically throughout and carries the product name only in its jurisdiction field and its citation strings, and the other platform's description does not mention it at all. Second, the second platform's Lab network is its CLASSIFIER enforcement deployment, which is a different system from the crowd-notes product it adopted, so the board that would carry the dependency is not the board that has it. Third, with the originating deployment listed as the cause, the cluster carries a single dependent where the rule requires two. The second and third reasons expire if the adopting platform's own crowd-notes deployment is ever modelled; the first does not, and clears only if the dossiers themselves start naming the instrument.
one platform operating two modelled deployments
Two Lab networks now sit on the same platform: crowd-written contextual annotation ranked by a published scorer, and in-house classifiers performing hateful-conduct detection with visibility filtering, removal, a paid primary-language reviewer workforce and an appeals ladder. They share an operator and nothing else — not a mechanism, not an enforcement action, not an actor set, not an evidence base, not a governing duty. The registry declines this for two reasons that both hold. Measured against the shipped gate, neither dossier description contains the operator's name in either carrier, so the link would rest on a quote that does not resolve. And more fundamentally, the registry's kinds are deliberately three — shared supplier, shared assurance provider, shared instrument — with no parent or common-operator kind, because a common owner is not a shared dependency in the sense this surface reports. The one point of contact worth policing is the December 2023 Commission proceeding, which lists both an illegal-content limb and an information-manipulation limb; each case file cites only its own limb and neither may claim a finding, because the proceeding has produced none.
the GIFCT Hash-Sharing Database as a shared enforcement instrument
The strongest-looking candidate in the corpus and unbuildable on the evidence, twice over. Thirty-nine platforms query one shared index, so a shared-instrument cluster is what this deployment IS — but the gate needs the dossier text to carry the cause, and the consortium's own dossier description names neither the consortium nor the database anywhere in its 6,344 characters, writing "the consortium" in the third person throughout; its supplier field is null. Independently, there is no second dependent to build the cluster from: scanning all 205 entries in the pinned PAN bundle, in both gate carriers, returns zero mentions of "GIFCT", "Global Internet Forum to Counter Terrorism", "Hash-Sharing Database" or "ThreatExchange" anywhere, including in the four Lab-networked moderation deployments whose operators are named members of it. The rule requires at least two dependents; this candidate has none. Supplying the link would mean supplying a name every dossier in the corpus withheld.
the national clearinghouse that receives statutory child-safety reports
Real dependency, unbuildable carrier. This deployment's whole referral leg runs into a national clearinghouse for missing and exploited children, and its own dossier calls the reporting one-way, but that dossier never names the organisation: it words the party generically as 'the national clearinghouse' and 'the clearinghouse' throughout, in keeping with its naming posture. Run against the shipped gate at pan_version 6.2.61.30, a cluster on the proper name returns two `cause-not-named` problems and a cluster reworded to the generic phrase returns one, because the only other shipped Lab network whose description mentions the clearinghouse names it as the operator of a separate victim-initiated under-18 removal service rather than as the recipient of a statutory report. Two PAN entries do carry the dependency in the right capacity and neither has a Lab network in this catalogue. Re-run the scan when one of them acquires one; the too-few-dependents half may then clear, but the cause-not-named half will not, because it is a fact about this deployment's own bundle text rather than about how many neighbours it has.
National Center for Missing & Exploited Children
One congressionally authorised non-profit operates both deployments, and the corpus will not carry the link. Measured against the pinned bundle: the triage deployment's own dossier description runs 7,680 characters and names the operator nowhere, writing "the clearinghouse" throughout, so there is no carrier text to quote; the hash-removal deployment's description names "NCMEC" but not the full cause string. Offered to the shipped gate, the proposed cluster returns quote-not-carried on the first member and cause-not-named on the second. The relationship is also the wrong kind, on this registry's own precedent: a supplier or parent cluster asserts a dependency on an OUTSIDE party, and an organisation running its own two programmes is outside neither. And the two are genuinely different programmes with opposite information designs — one is a statutory intake that may filter nothing and refers to law enforcement, the other is victim-initiated, investigates nothing and refers to nobody — which is why the triage deployment's evidence record carries an express instruction not to fold them together.
the assurance firm behind both the mandated platform audit and a government-commissioned model review
The same firm returned the mandated Article 37 independent audit opinion on the platform-moderation deployment and, separately, a government-commissioned technical review of a national welfare-fraud risk model — two different deploying organisations, two jurisdictions, two statutes, one assurance provider. The link was proposed to the shipped gate and refused: the platform deployment's own PAN description does not name the firm anywhere in its 6,891 characters, referring to the channel functionally throughout as the independent audit and the auditor. The welfare deployment's description does name it and resolves cleanly, so the refusal falls on one side only. Supplying the name from the site-side evidence dossier to complete a link the PAN text declines to carry is precisely the authoring this registry's quote rule exists to prevent, and this row records the refusal rather than the workaround. Re-run the scan before re-proposing: unlike a too-few-dependents rejection, this one can clear on a later PAN sync alone, if the entry's description ever names the firm. Measured 2026-08-31 against pinned bundle 6.2.61.30.
the published Wikipedia edit-scoring service
This deployment is a shared instrument by construction — one scoring service serving more than 250 language editions, read by every agent and tool that acts on a score — so the candidate was built and run through the gate rather than dismissed. It fails twice over. First, no other deployment in the corpus depends on it: a scan of all 205 PAN entries in both gate carriers finds the operator, the service, its successor platform, its models, its agents and its tools named in exactly one entry, this one. A shared cause needs at least two dependents, and this one can never acquire a second, because the service scores Wikipedia revisions and nothing else. Second, the entry's own dossier text never names the cause: across 7,417 characters it writes "a scoring service" and "the operator" in the third person, so a quote of the service's name does not resolve, and the one quotable occurrence of "Wikipedia" is adjacent prose about patroller-facing help text rather than evidence for this cause. The wider candidate — an open-licence model estate shared with the nine PAN entries whose carriers mention open source — was not built: a common cause has to be a party or an instrument, not a property two deployments happen to share, and none of those nine shares a model, a pipeline, a licence grant or a maintainer with this one.
the platform operator behind two of its own moderation channels
Two Lab networks do run inside the same platform company — a copyright matching channel and a community-guidelines enforcement channel — and a shared-parent link is the obvious candidate. It is unbuildable on this evidence, and the shipped gate says so rather than a reviewer: run over the proposed cluster it returns quote-not-carried on BOTH members. Neither dossier names the operator anywhere in the carrier the registry reads. The copyright entry writes "the operator", "the platform" and "the deployer" through 8,162 characters and names the company zero times; the enforcement entry does the same through 1,528, and its only supplier text is "in-house enforcement classifiers operating with human review withdrawn", which names nobody. Supplying the name would be the invention this check exists to stop. Note also that the two channels share an operator and almost nothing else: different principals, different statutes, different appeal ladders, different transparency publications, and two separate strike ledgers under different rules. Unlike a too-few-dependents rejection this one does not clear when another same-operator deployment lands, because it is a fact about these two entries' own text.
the federal consumer-finance supervisor and the adverse-action duty
Measured at the pinned bundle, not judged from resemblance. This deployment has no supplier, no commissioned assurance provider and no administered instrument, so it is eligible for no cluster of any of the three legal kinds: its consent order names no software product, no scoring model and no third-party screening vendor, and the discriminating artifact was a rule carried in training and supervision rather than a tool anyone bought or administered. The one shared party a scan does surface is the federal supervisor, named somewhere in fourteen bundle entries and in a gate carrier in two of them, neither of which has a Lab network. A proposed cluster joining this deployment to two US consumer-lending networks on that basis was run through the shipped gate and returned three quote-not-carried failures, one per member, against a clean baseline over the shipped registry. Independently of the gate, a supervisor is not a supplier, an assurer or an instrument, and 'answers to the same agency' is resemblance rather than correlated exposure to a shared dependency: the same reasoning would join mortgages, auto lending, savings apps, credit reporting and gig screening in one link. The same objection disposes of the statutory adverse-action duty, which is a law rather than an outside party, and of the consumer-reporting agencies, which receive this deployment's output and supply nothing to it.
the dealer-facing origination software a subprime vehicle lender supplies to its dealer network
Two deployments in the pinned bundle score a vehicle deal that a dealership assembled, inside software the lender puts on the dealership's desk, and one of them charges a monthly fee for access to it. The resemblance is close enough that a later pass would very likely re-propose it, which is why it is disposed of explicitly rather than left unstated. It fails on the evidence before it fails on the gate: an ADMINISTERED INSTRUMENT is one thing administered ACROSS the deployments that depend on it, and there is no such thing here. Each lender wrote, owns and licenses its OWN proprietary software to its OWN enrolled dealerships; no vendor, platform, standard or shared component is named in either record; and the two systems compute different quantities for different purposes — one forecasts net collections and prices what the lender pays a dealership, the other forecasts default and places an applicant in a pricing tier that sets what the borrower is charged. Offered to the shipped gate anyway, the cluster returns three problems: one member has no Lab network at this bundle version, the quoted carrier text does not name the proposed cause, and the cluster would carry one dependent where the rule requires two. The first reason does not expire when the second network lands, because software each party built for itself does not become a shared instrument by being similar. Recorded separately from `rejected-subprime-auto-market`, which rejects a shared MARKET across the same pair: this row rejects a shared INSTRUMENT, which is one of the three kinds the registry does recognise and therefore a different question. Also measured and recorded here so it need not be re-derived: the one external data feed either record documents — published vehicle book values — is named by NO deployment in the 205-entry bundle, so no instrument cluster is buildable on it either.
partner-bank origination of a consumer credit product
A shared ARRANGEMENT is not a shared party. Both deployments are consumer fintechs whose regulated product is originated or held by a chartered bank they do not own, and both dossier descriptions say so — which is why the scan proposed it. But the banks are different banks: this deployment names Evolve Bank & Trust and Coastal Community Bank, and neither appears in any other entry in the pinned bundle (Coastal appears nowhere in it at all). The registry clusters on a dependency with a NAME, so that no reader can be told two networks share an exposure they do not. Measured against the shipped gate, the strongest form of this cluster fails three checks: two co-members do not carry the quoted text in the bundle at all, and this deployment's own carrier text does not name the proposed cause. The deeper reason no cluster is available here is that this deployment has none of the three legal kinds: no supplier, because the operator builds and operates the engine in house and no third-party model vendor exists anywhere in the record; no assurance provider, because nobody has ever been commissioned to review the engine and no model documentation, validation report or independent evaluation of it exists; and no administered instrument, because the inputs are the member's own bank transactions rather than any named tool or questionnaire.
the unnamed lead generators and the unnamed debit-card processing vendor
This deployment has two suppliers on its documented harm path and neither can anchor a cluster, because neither is named anywhere in the primary record. The consent orders identify the parties that sold the consumer applications whose bank details were written over the account on file, and the payment processor whose false failure responses drove duplicate debits across 1,378 consumers, by ROLE only — "Lead Generators" and "a third-party vendor" — and no reliable identification of either was found. Measured over the pinned bundle, the party strings this record does carry appear verbatim in exactly one description: this one. Run against the shipped gate, a supplier cluster quoting this deployment's own description resolves for this member and fails on every proposable co-member, which is the honest shape of the problem: there is no second deployment whose own text carries the same party, and the party itself has no name to carry. A cluster keyed to an unidentified supplier would assert a dependency the record refuses to state.
FICO
One name, three unrelated relations, and the shipped gate cannot tell them apart — measured: collectCommonCauseProblems returned ZERO problems over [the seven shipped clusters + a proposed two-member supplier-fico cluster joining the score-delivery board and the alternative-data underwriting board], so this row exists to refuse a link the mechanism would have allowed. On the score-delivery board FICO is a genuine third-party supplier whose algorithms the bureau's platform executes — and it is the one deployment in the corpus whose record EXONERATES that supplier in terms: FICO stated publicly that the problem was an Equifax issue and not a FICO issue, and no source identifies a defect in any scoring model. A shared-supplier cluster asserts shared reliance on one party's practices and defaults; here the finding is that the supplier's practices and defaults were not implicated, and the defect sat in the attribute pipeline upstream of them. On the alternative-data underwriting board 'FICO 620 to 660' is a BAND LABEL inside a regulator's published access finding, describing which applicants were approved at roughly twice the rate — a numeric scale used to describe a population, not a supplier relationship, on a deployment whose case is precisely that it does not underwrite on a traditional score. On the subprime auto board the phrase is 'a proprietary FICO-like scale', which is a simile. A supplier, a scale and a simile are not one cause. This is the rejected-allscripts-acquirer defect class in a lending register, and it is refused for the same reason.
Fannie Mae / Freddie Mac automated underwriting and seller rules
The strongest INSTRUMENT candidate this deployment carries, and it fails the shipped gate on two counts — measured, both quoted: 'unknown-org :: cluster names org "org-navy-federal-mortgage-underwriting-class", which is not in the Lab catalogue', and 'cause-not-named :: the quote has to be the evidence for THIS cause, not adjacent prose'. The first failure is a fact about today and will clear on its own if that board lands. The SECOND will not, and it is the one that matters: only ONE entry in the 205-entry PAN bundle names Fannie Mae, Freddie Mac, Desktop Underwriter or Loan Product Advisor in either gate carrier, and it is this deployment's own. A cluster needs the cause named in each member's own record, and a mortgage-underwriting board that happens to sell into the same secondary market supplies a resemblance rather than a quotable dependency. There is also a substantive objection that survives both: on this board the enterprises are not a shared supplier the deployments depend on, they are the party that COMPELLED the only mandatory correction in the record, which is a different relation from the one a common-cause cluster asserts. Re-run cc.mjs before adding anything; do not treat the arrival of a second mortgage board as clearing this row.
a common corporate parent
Both deployments have been owned by the same company since 22 December 2021, and that is the whole of what they share — which is why the scan proposed a cluster and why the proposal must be refused. The registry links deployments that depend on the same outside party, so that a reader can be told two networks carry one exposure. Common ownership is not such a dependency here, and both records say so in their own terms: the conduct in each predates the acquisition, the savings-side deployment's investigation was disclosed in acquisition diligence rather than arising from the parent's practice, and the two systems share no model, no data, no supplier, no consumer population and no legal instrument. One is an automated money-movement engine acting on members' own checking accounts under a marketing undertaking; the other is a collections deployment acting on borrowers. Measured against the shipped gate, the strongest form of this cluster fails exactly one check today — the second deployment has no Lab network yet — and that failure will clear on its own the moment that board lands. That is precisely why this row exists rather than a note: it must not be built THEN either, and the reason is evidential rather than mechanical. A separate partner-bank arrangement was also proposed and fails on its own terms, because this deployment's partner-bank names sit in its published terms and not in the carrier text the gate reads; the concurrent lending-fleet entry `rejected-partner-bank-origination` already records that arrangement and names this deployment's PAN source, and it is not duplicated here.
the federal mortgage-disclosure public loan-level file
Proposed and MEASURED UNBUILDABLE at the pinned bundle rather than declined on judgement. Every mortgage lender above the federal reporting threshold files into one public loan-level disclosure file, and the structural fact this board is drawn around is what that file leaves out by rule — so a shared-instrument cluster is the obvious candidate here, and it is the one that fails. Run through collectCommonCauseProblems against the shipped registry, a cluster with this deployment and the two nearest US-lending Lab orgs returns three quote-not-carried problems, one per member: no member's PAN description contains the string 'Home Mortgage Disclosure Act'. This deployment's description writes the regime in the third person throughout and never names the statute; the other two do not report into the mortgage disclosure file at all, one being an unsecured-personal-loan model and the other a credit-card line-assignment matter. A link whose quote does not resolve is authored, and this registry does not carry authored links. No weaker cluster is available either: there is no supplier, because no third-party underwriting vendor is identified anywhere in the verified record; and there is no shared assurance provider, because the one reviewer in this record is the operator's own defence counsel, reviewed this deployment alone, and appears in zero entries of the PAN bundle. The one PAN deployment that does name the disclosure statute in a gate carrier, wells_fargo_refi_underwriting, has no Lab network today; if such a board ever lands, this pair is worth re-testing, and it will still need a third member because the rule requires two dependents.
the small-claims and justice-court forum a lender escalates a delinquency into
The court is the most tempting cluster on this board and it is the wrong kind of thing. A forum is genuinely shared across every first-party creditor that sues its own borrowers, it genuinely shapes outcomes — a $10,000 claim cap and a fifty-dollar filing fee with non-attorney filing permitted on one side, a $2,500 cap with counsel barred on both sides and no interpreter guaranteed on the other — and a later pass reading this board would very likely propose it, which is why it is disposed of explicitly. It fails on the evidence before it fails on the gate. An ADMINISTERED INSTRUMENT is one thing administered ACROSS the deployments that depend on it, by a party whose choices those deployments inherit. A county court is not administered by or for any of them: it is a public institution each of them chose to use, its rules are set by state legislatures rather than by any supplier, and no deployment in the bundle depends on another's use of it. Offered to the shipped gate anyway, the cluster returns three problems: the quoted carrier text does not resolve for either proposed member at the pinned bundle version, and the cluster would carry one dependent where the rule requires two. The first ground does not expire when more collections boards land, because a shared public forum does not become an administered instrument by being used more often. Recorded separately from the two rejections this bundle deliberately does NOT duplicate: the common corporate parent, which the concurrent hello-digit board already registers and which this bundle re-measured rather than re-derived, and the shared federal supervisor, which the concurrent citi board already registers. Also measured and recorded here so it need not be re-derived: the two largest national debt buyers are named in this record only as a volume comparison and by NO other deployment in the 205-entry bundle, so no debt-buyer cluster is buildable either.
the commercial credit-bureau score
Three lending deployments in the pinned bundle name the same commercial bureau score in a carrier the rule reads, and a two-member cluster over the two that have Lab networks PASSES the shipped gate with zero problems — measured, not assumed. It is rejected on the evidence regardless, for three reasons. First, the naming dossier's own caution states that the record names no third-party modelling vendor and that the bureau score appears in it as a credit-bureau input and as the comparison for the shape of a proprietary scale; a passing mention of an input is not a dossier saying two organisations depend on a shared party. Second, a commercial bureau score is the universal substrate of United States consumer lending, so on this axis every consumer-lending board in the catalogue would join, and a cluster that every member of a domain belongs to reports the domain rather than a correlated exposure. Third, neither deployment's record documents any incident, dependency or exposure reaching it through that score, and correlated exposure is the claim a link makes. A third deployment in the bundle does document exactly that exposure and has no Lab network at this version; if it lands, the question is worth re-deriving from ITS evidence, and this deployment joins only if its own record then supports membership. The first reason does not expire when that happens.
the subprime vehicle finance market
Two deployments in the pinned bundle score subprime vehicle borrowers through dealer channels, and one of them names the other in a carrier the rule reads, so the candidate is obvious and has to be disposed of explicitly. It fails on the vocabulary before it reaches the evidence: the registry recognises a shared supplier, a shared assurance provider or a shared administered instrument, and these two share none of the three. Both models are in-house and different, no third-party model vendor appears in either record, no firm reviewed or assured both, and no instrument was administered across them. What they share is a market and a borrower population, which is a domain rather than a common cause, and the two boards are separated for exactly that reason: one forecasts default and prices a tier the borrower is charged, the other forecasts net collections and prices what a dealer is advanced. The second deployment also has no Lab network at this bundle version, so the cluster would carry one dependent where the rule requires two. Neither half of this is a reason to revisit it when that network lands: a shared market is still not one of the three kinds.
the Treasury sanctions list, and the third-party matching supplier behind it
This is the corpus's only sanctions-screening deployment, and a common cause needs a second one. Two clusters were proposed and measured against the shipped gate rather than reasoned about. An instrument cluster on the Treasury Specially Designated Nationals list returns too-few-dependents: no other Lab network in the catalogue screens anybody against a sanctions list, and the two Lab-networked deployments whose dossiers mention the Treasury at all are a tax call-centre assistant and a federal identity gate, neither of which does. A supplier cluster on the named third-party matching vendor fails a step earlier: exactly one deployment in the bundle names it, and it is this one, so the cause would have no dependents at all. The adjacent temptation is a shared-statute cluster over the four deployments that cite the same consumer-reporting law, and it is refused on principle: a statute is not a supplier, an assurance provider or an administered instrument, and deployments sitting under one law share a jurisdiction rather than a cause.
the two government-sponsored enterprises' automated underwriting systems
This deployment runs two enterprise automated underwriting systems alongside its own stack, and the divergence between their answer and the final decision is how the litigation's own proposed classes were defined — so a shared-instrument reading is not a stretch here, it is close to the deployment's subject. It is still not buildable. Measured against the pinned bundle, this deployment's own description names the two systems only generically, as "external enterprise automated underwriting systems", and the products' names appear in a gate carrier in exactly one entry in the whole bundle, which is not this one and which has no Lab network. Run through the shipped gate with the two nearest US consumer-lending Lab orgs as co-members, the proposal returns three quote-not-carried problems, one of them against this deployment itself. A cluster whose quote does not resolve in its own members' descriptions is authored, and the honest record of that is this row.
the federally mandated public loan-level mortgage disclosure file
Every US mortgage lender above the reporting threshold files into the same public disclosure instrument, and what that instrument leaves out — the applicant credit score, excluded by rule — is the single structural fact this deployment is drawn around, so the candidate is obvious and was tested rather than assumed. Measured against the pinned bundle it fails on both halves. The statute is named in a gate carrier by one PAN entry, which is not this one: this deployment's description writes the regime in the third person throughout and names the statute only in its sources block. And neither of the two nearest US consumer-lending Lab orgs reports into the mortgage disclosure file at all, one being an unsecured-personal-loan model and the other a credit-card line-assignment matter. Run through the shipped gate the proposal returns three quote-not-carried problems. A sibling bundle records its own rejection of the same instrument from the other side of the same wall; both rejections stand and neither is a reason to build the cluster later without re-running the gate.
