# B2-B — Mature-market comparators: Yoopies, Rover, UrbanSitter **Bundle:** B2 (Mature-market comparators & business-model taxonomy), slice B — the three comparators named for this slice. **Access date:** 2026-07-30. **Author:** `[O]` (Opus seat, evidence editor). **Corpus:** `reports/evidence/B2-B-raw/` only — nine `.json` receipts and nine `.err` files. Retry run; no network access was used to write this paper. ## Headline **This slice produced no evidence about how Yoopies, Rover, or UrbanSitter operate.** Nine fetches returned one page title, two wrong-site 404 bodies, and six anti-bot responses. Every B2 taxonomy field the brief asks for — model type, revenue mechanism, category breadth, stated scale — is `NOT FOUND in this corpus` for all three comparators. What follows documents the fetch outcomes, because that is the only thing the corpus supports. --- ## 1. Scope and method ### 1.1 What this slice was for `01_RESEARCH/RESEARCH_BRIEFS.md` §B2 sets the question — *"What distinct care-platform models exist abroad, and what does each monetize?"* — and the per-platform fields: *"classify as directory / marketplace / managed matching / subscription / staffing / benefit (charter taxonomy), revenue mechanism, category breadth (single vs multi-care), stated scale"*, with bounds *"≤4 sources per platform; prefer official pricing/help pages and filings/press over blogs"*. Slice B covers exactly three comparators — **Yoopies, Rover, UrbanSitter** — at a cap of **3 captured URLs each**, nine captures total. Slice A (Care.com, Babysits global) is a separate file. ### 1.2 What was actually available This paper is written **from the local corpus only**. Constraints held for the retry: - Sources read: `PROJECT_CHARTER.md`, `01_RESEARCH/RESEARCH_BRIEFS.md`, `01_RESEARCH/evidence/SOURCE_REGISTER.md`, and the nine `B2-B-raw` JSON/ERR receipts. - No web search, page fetch, browser, `curl`, `webget`, or any other retrieval. Nothing outside this repository was read or modified. - **No model memory was used as evidence.** Where a comparator fact is commonly "known" but absent from the corpus, it is recorded as `NOT FOUND in this corpus` or left to `## 6. Open questions`, per the universal source contract §3. ### 1.3 Receipt schema Each of the nine JSON files is a single object with exactly four keys: ``` {"status": …, "final_url": …, "title": …, "text": …} ``` There is **no** field for the requested URL, the fetch client, the user agent, or a timestamp. Three consequences, all load-bearing for how this paper is read: 1. **The requested URL is not recorded anywhere in the corpus.** Only `final_url` exists. Whether any of the nine requests was redirected therefore cannot be determined from these files. The filename slug (`yoopies-pricing`, `rover-trust-safety`, …) is the only trace of capture intent, and a filename is not a receipt. Every citation in this paper uses `final_url`. 2. **The access date is not in the corpus.** `2026-07-30` comes from the task instruction and the `SOURCE_REGISTER.md` convention (*"Access date is 2026-07-30 unless stated otherwise"*), not from the receipts. Filesystem `mtime` on all eighteen files is `Jul 30 13:13`, consistent with one capture run, but `mtime` is filesystem metadata, not captured evidence. 3. **Which fetch tier was used is `NOT RECORDED`.** The corpus cannot tell us whether a plain HTTP client, a browser-TLS-impersonating client, or a headless browser produced these results, so it cannot support any claim about what tier would or would not clear the blocks. ### 1.4 All nine `.err` files are zero bytes Every `.err` sibling is empty. `[O]-CLASS`: no transport-level error was recorded for any of the nine fetches — each request completed and received an HTTP response. That distinguishes this slice from the B1 receipts, where transport failures did write error files (`SOURCE_REGISTER.md` rows B1-14 *"Host DNS failure from this server; raw `b1_sprawdzonaopiekunka.err`"*, B1-15 and B1-16 *"TLS hostname mismatch"*). **These nine failures are HTTP-layer answers, not connection failures.** They were answered — by an edge, a block page, or a wrong document root. ### 1.5 Marker legend | Marker | Meaning | |---|---| | **DIRECT** | Text captured in a local JSON file and quoted verbatim from it. | | **`[O]-CLASS`** | Editor classification or deduction by the Opus seat, over local strings only. Judgment, not capture. | | **RECEIPT** | Documents a fetch attempt and nothing more. Carries no information about the operator's business. | | **NOT FOUND in this corpus** | The brief asks for it; the nine local files do not contain it. Not a claim that it does not exist. | | **UNVERIFIED** | A hypothesis or open reading, explicitly not established by the corpus. | --- ## 2. Capture inventory Nine captures, three per comparator, at the slice cap. `Requested URL` is *not recorded* in any receipt (§1.3); the column is retained to make that absence explicit rather than to hide it behind the final URL. | ID | Comparator | Requested URL | Final URL (`final_url`) | HTTP | Raw capture file | Class | |---|---|---|---|---|---|---| | B2-B-01 | Yoopies | not recorded (`final_url` only) | `https://yoopies.com/` | **200** | `B2-B-raw/yoopies-home.json` | **DIRECT (title only)** | | B2-B-02 | Yoopies | not recorded (`final_url` only) | `https://yoopies.com/en/how-it-works` | **404** | `B2-B-raw/yoopies-how-it-works.json` | **RECEIPT** | | B2-B-03 | Yoopies | not recorded (`final_url` only) | `https://yoopies.com/en/pricing` | **404** | `B2-B-raw/yoopies-pricing.json` | **RECEIPT** | | B2-B-04 | Rover | not recorded (`final_url` only) | `https://www.rover.com/` | **403** | `B2-B-raw/rover-home.json` | **RECEIPT** | | B2-B-05 | Rover | not recorded (`final_url` only) | `https://www.rover.com/how-it-works/` | **403** | `B2-B-raw/rover-how-it-works.json` | **RECEIPT** | | B2-B-06 | Rover | not recorded (`final_url` only) | `https://www.rover.com/trust-safety/` | **403** | `B2-B-raw/rover-trust-safety.json` | **RECEIPT** | | B2-B-07 | UrbanSitter | not recorded (`final_url` only) | `https://www.urbansitter.com/` | **403** | `B2-B-raw/urbansitter-home.json` | **RECEIPT** | | B2-B-08 | UrbanSitter | not recorded (`final_url` only) | `https://www.urbansitter.com/how-it-works/` | **403** | `B2-B-raw/urbansitter-how-it-works.json` | **RECEIPT** | | B2-B-09 | UrbanSitter | not recorded (`final_url` only) | `https://www.urbansitter.com/pricing/` | **403** | `B2-B-raw/urbansitter-pricing.json` | **RECEIPT** | **Class tally:** 1 DIRECT (title only) · 8 RECEIPT. Zero captures contain comparator body content. **On `DIRECT (title only)` for B2-B-01:** the fetch succeeded (HTTP 200) and returned a real, non-empty title, so the title string is genuine DIRECT evidence of that response. But the receipt's `text` value is byte-identical to its `title` value — no body text was extracted. The capture is DIRECT for one string and empty for everything else. Compare `SOURCE_REGISTER.md` row B1-13, where Yoopies Poland returned *"HTTP 202 with empty title/text"* and was classed `Receipt`; here the title is present, so the row is not demoted to RECEIPT, but it carries almost as little. **Byte sizes** (filesystem, all nine): yoopies-home 160 · yoopies-how-it-works 536 · yoopies-pricing 531 · rover-home 112 · rover-how-it-works 125 · rover-trust-safety 125 · urbansitter-home 887 · urbansitter-how-it-works 900 · urbansitter-pricing 895. Used in §5.4. --- ## 3. Yoopies **Captures:** B2-B-01 (`https://yoopies.com/`, 200), B2-B-02 (`https://yoopies.com/en/how-it-works`, 404), B2-B-03 (`https://yoopies.com/en/pricing`, 404). Access date 2026-07-30. ### 3.1 DIRECT — the one content string in this slice `https://yoopies.com/` returned HTTP 200 with `title` and `text` both equal to: > `Yoopies | Find great childcare in no time` (DIRECT; `https://yoopies.com/`, accessed 2026-07-30, raw `B2-B-raw/yoopies-home.json`.) The full receipt, quoted: > `{"status": 200, "final_url": "https://yoopies.com/", "title": "Yoopies | Find great childcare in no time", "text": "Yoopies | Find great childcare in no time"}` **`[O]-CLASS` on what that supports.** One page title, self-authored marketing phrasing. The only care-category word in the whole slice is `childcare`, and it appears inside that title. It supports: at access date, a fetch of `yoopies.com` returned 200 and a title naming childcare. It does **not** support category breadth — a title that names childcare says nothing about whether elder care, pet care, or home care are also served, and the B2 brief's `category breadth (single vs multi-care)` field stays `NOT FOUND in this corpus`. The phrase `in no time` is promotional copy, not a speed or matching-time claim that this corpus can substantiate. ### 3.2 RECEIPT — both alternate pages returned a foreign 404 body B2-B-02 and B2-B-03 both returned HTTP 404 with `title`: > `Page not found · GitHub Pages` and `text`: > `Page not found · GitHub Pages 404 File not found The site configured at this address does not contain the requested file. If this is your site, make sure that the filename case matches the URL as well as any file permissions. For root URLs (like http://example.com/ ) you must provide an index.html file. Read the full documentation for more information about using GitHub Pages . GitHub Status — @githubstatus` (RECEIPT; `https://yoopies.com/en/how-it-works` and `https://yoopies.com/en/pricing`, accessed 2026-07-30, raw `B2-B-raw/yoopies-how-it-works.json` and `B2-B-raw/yoopies-pricing.json`.) **`[O]-CLASS`:** the two bodies are byte-identical apart from the URL. Their file sizes differ by 5 bytes (536 vs 531), exactly the length difference between `https://yoopies.com/en/how-it-works` (35 chars) and `https://yoopies.com/en/pricing` (30 chars). One generic 404 template, served twice. **This is an anomaly, and it is the most important thing in the Yoopies capture set.** The returned body is GitHub Pages' default 404 document, which is not a Yoopies-authored page. `UNVERIFIED` readings, none of which the corpus can settle: - the capture path did not reach the operator's origin (proxy, DNS, or harness interception); - these paths on this host genuinely resolve to a static-hosting document root with no such files; - the requested URLs (not recorded, §1.3) were not the URLs a Yoopies "how it works" or "pricing" page lives at. **Consequence for B2-B-01.** Two of three Yoopies responses in this run demonstrably did not come from an application serving Yoopies content. That puts the provenance of the third — the 200 root capture — in question too, and it is why §3.1 is scoped to *"a fetch of `yoopies.com` returned 200 and this title"* rather than to any statement about Yoopies the operator. Open question O-2. ### 3.3 NOT FOUND in this corpus — Yoopies Model type (directory / marketplace / managed matching / subscription / staffing / benefit) · revenue mechanism · pricing, fees, subscription or commission of any kind · category breadth · stated scale (users, carers, bookings, countries) · trust, identity, or background-check machinery · payments handling · geographic coverage. ### 3.4 `[O]-CLASS` taxonomy classification — Yoopies **UNCLASSIFIED — insufficient evidence.** The charter taxonomy cannot be applied to a page title. No classification is assigned, and none is guessed. --- ## 4. Rover **Captures:** B2-B-04 (`https://www.rover.com/`, 403), B2-B-05 (`https://www.rover.com/how-it-works/`, 403), B2-B-06 (`https://www.rover.com/trust-safety/`, 403). Access date 2026-07-30. ### 4.1 RECEIPT — three identical interstitials All three returned HTTP 403 with `title` and `text` both equal to: > `Just a moment...` (RECEIPT; `https://www.rover.com/`, `https://www.rover.com/how-it-works/`, `https://www.rover.com/trust-safety/`, accessed 2026-07-30, raw `B2-B-raw/rover-home.json`, `B2-B-raw/rover-how-it-works.json`, `B2-B-raw/rover-trust-safety.json`.) Full receipt for the home capture: > `{"status": 403, "final_url": "https://www.rover.com/", "title": "Just a moment...", "text": "Just a moment..."}` **`[O]-CLASS`:** `text` equals `title` in all three; the response is an interstitial holding page, not content. `Just a moment...` is the conventional title of an automated-challenge / bot-check interstitial, and a 403 status means the challenge was not passed. **The corpus does not name a vendor for Rover** — unlike UrbanSitter, where the string `Cloudflare` is literally present (§5.1) — so this paper does not name one. Attributing the Rover interstitial to a specific security provider would be memory, not evidence. **`[O]-CLASS`:** file sizes 112 / 125 / 125 differ only by `final_url` length (`https://www.rover.com/` = 22 chars; the two path URLs = 35 chars each; 112 + 13 = 125). Three requests, one identical response body. ### 4.2 NOT FOUND in this corpus — Rover Everything. The three Rover files contain no Rover-authored text of any kind. Specifically absent: model type · revenue mechanism, commission, or service fee · pricing · category breadth · stated scale · trust and safety machinery (note that B2-B-06 targeted a trust/safety path and returned the interstitial, so **no trust or safety fact about Rover is available from this corpus**) · payments · insurance or guarantee terms · geographic coverage. ### 4.3 `[O]-CLASS` taxonomy classification — Rover **UNCLASSIFIED — insufficient evidence.** Zero captured content. No classification assigned. --- ## 5. UrbanSitter **Captures:** B2-B-07 (`https://www.urbansitter.com/`, 403), B2-B-08 (`https://www.urbansitter.com/how-it-works/`, 403), B2-B-09 (`https://www.urbansitter.com/pricing/`, 403). Access date 2026-07-30. ### 5.1 RECEIPT — three named block pages All three returned HTTP 403 with `title`: > `Attention Required! | Cloudflare` and a `text` body which, for B2-B-07, reads in full (the client IP string is redacted here; the unredacted value is in the raw file): > `Attention Required! | Cloudflare Please enable cookies. Sorry, you have been blocked You are unable to access urbansitter.com Why have I been blocked? This website is using a security service to protect itself from online attacks. The action you just performed triggered the security solution. There are several actions that could trigger this block including submitting a certain word or phrase, a SQL command or malformed data. What can I do to resolve this? You can email the site owner to let them know you were blocked. Please include what you were doing when this page came up and the Cloudflare Ray ID found at the bottom of this page. Cloudflare Ray ID: a2349e7e6d309c83 • Your IP: Click to reveal [this server's egress IP — redacted in this paper, present verbatim in the raw JSON] • Performance & security by Cloudflare` (RECEIPT; `https://www.urbansitter.com/`, accessed 2026-07-30, raw `B2-B-raw/urbansitter-home.json`.) **Redaction note:** the only alteration to any quoted string in this paper is the client IPv6 address in the three UrbanSitter bodies, withheld because this repository may be published read-only to `baby.nurt.cloud` per the charter. The raw JSON files are unmodified and hold the full string. ### 5.2 DIRECT — what the block text does establish Three narrow facts, all about the fetch rather than the operator: - The block page names the host: `You are unable to access urbansitter.com` — the request reached the correct hostname's edge and was refused there. - The refusing layer names itself: `Attention Required! | Cloudflare` and `Performance & security by Cloudflare`. - The stated cause is generic and automated: `This website is using a security service to protect itself from online attacks. The action you just performed triggered the security solution.` ### 5.3 Per-page Ray IDs Each capture carries a distinct `Cloudflare Ray ID`: | ID | Final URL | Cloudflare Ray ID | |---|---|---| | B2-B-07 | `https://www.urbansitter.com/` | `a2349e7e6d309c83` | | B2-B-08 | `https://www.urbansitter.com/how-it-works/` | `a2349e81fd95479b` | | B2-B-09 | `https://www.urbansitter.com/pricing/` | `a2349e803a1b0dbe` | (DIRECT; raw `B2-B-raw/urbansitter-home.json`, `B2-B-raw/urbansitter-how-it-works.json`, `B2-B-raw/urbansitter-pricing.json`, accessed 2026-07-30.) **`[O]-CLASS`:** three distinct IDs mean three separate requests were made and separately blocked — not one result copied across three files. The shared `a2349e` prefix is consistent with the three requests falling in one narrow time window, matching the single-run reading in §1.3. ### 5.4 `[O]-CLASS` — the three bodies are byte-identical apart from the Ray ID File sizes are 887 / 900 / 895 bytes. The `final_url` values are 28, 41, and 36 characters (`https://www.urbansitter.com/`, `…/how-it-works/`, `…/pricing/`). Deltas of +13 and +8 in URL length match deltas of +13 and +8 in file size exactly, and all Ray IDs are 16 hex characters, so they contribute no length difference. **One block template, three times, differing only in the Ray ID.** No page-specific content leaked through on any of the three. ### 5.5 NOT FOUND in this corpus — UrbanSitter Everything about the operator. Specifically absent: model type · revenue mechanism · **pricing of any kind** (note that B2-B-09 targeted a pricing path and returned the block page, so **no UrbanSitter price, fee, subscription, or membership fact is available from this corpus**) · category breadth · stated scale · trust, vetting, or background-check machinery · payments · geographic coverage. ### 5.6 `[O]-CLASS` taxonomy classification — UrbanSitter **UNCLASSIFIED — insufficient evidence.** Zero captured content. No classification assigned. --- ## 6. Cross-comparator findings Six findings. Each is about capture outcomes, because the corpus supports nothing else. Findings 1–5 are supported by the local strings and sizes cited; finding 6 is method judgment, marked as such. **F1 — Content yield is one page title across nine captures.** Eight of nine receipts contain zero comparator-authored text. The ninth contains a 41-character title. Aggregate usable evidence about how these three businesses work: none. (Supported by §3.1, §4.1, §5.1.) **F2 — All four B2 taxonomy fields are empty for all three comparators.** The brief requires model type, revenue mechanism, category breadth, and stated scale per platform. That is 12 required data points; **0 of 12 were captured**. All three comparators are `UNCLASSIFIED — insufficient evidence` (§3.4, §4.3, §5.6). No charter-taxonomy classification of Yoopies, Rover, or UrbanSitter can be carried forward from this slice. **F3 — Two distinct failure modes, not one.** Six captures (Rover ×3, UrbanSitter ×3) were refused by an anti-bot layer with HTTP 403; two (Yoopies alternate pages) returned HTTP 404 with a body belonging to an unrelated static-hosting default; one (Yoopies root) returned HTTP 200 with an empty body. `[O]-CLASS`: these need different remedies. A 403 challenge is an access problem. A GitHub Pages 404 under a comparator hostname is a *routing or target-URL* problem and may not be a blocking problem at all. **F4 — Every failure was answered at HTTP level; none was a transport failure.** All nine `.err` files are 0 bytes (§1.4). Contrast the B1 receipts, where DNS and TLS failures wrote error files (`SOURCE_REGISTER.md` B1-14, B1-15, B1-16). `[O]-CLASS`: these three comparators are reachable from this server; the barrier is an edge policy or a wrong path, not connectivity. **F5 — The high-value pages were hit and specifically denied.** The slice targeted exactly the pages the brief calls for (`prefer official pricing/help pages`): two pricing paths (`yoopies.com/en/pricing` 404, `urbansitter.com/pricing/` 403), two how-it-works paths (`yoopies.com/en/how-it-works` 404, `urbansitter.com/how-it-works/` 403), one trust-safety path (`rover.com/trust-safety/` 403). `[O]-CLASS`: the gap is not a targeting failure — the right URLs were chosen and none returned content. **No pricing, monetization, or trust-mechanics fact about any of the three comparators may be sourced to this slice.** **F6 — `[O]-CLASS`, method:** whatever client produced these results is not sufficient for Rover or UrbanSitter, whose edges refused it three times each with no page-specific leakage (§5.4). The corpus does not record which client was used (§1.3), so this paper makes **no claim** about which tier would succeed. That is a decision for the next attempt, not a finding here. --- ## 7. Limitations and open questions ### 7.1 Limitations - **L1 — The corpus cannot support comparator business facts.** Any statement about Yoopies', Rover's, or UrbanSitter's model, pricing, scale, breadth, trust machinery, or payments would be memory or inference. None appears in this paper, and none should be lifted from it into the competitive matrix or the P2 council. - **L2 — Requested URLs are unrecorded (§1.3),** so redirect behaviour is unknown and the requested-vs-final distinction cannot be audited for any row. The B2-A slice was able to flag a requested/final mismatch (`SOURCE_REGISTER.md` B2-A-04, *"`final_url` differs from requested global home"*); this slice cannot, for any of its nine rows. - **L3 — No timestamps.** Access date rests on the task instruction and register convention, not on captured data. Filesystem `mtime` (`Jul 30 13:13`) is corroborating metadata only. - **L4 — No client, user-agent, header, or retry record.** The receipts do not show whether retries, backoff, or an escalation tier were attempted, so the run is not reproducible from the corpus alone. - **L5 — Yoopies root provenance is uncertain,** because two of the three Yoopies responses in the same run came from a non-Yoopies document root (§3.2). The single DIRECT string in this slice inherits that doubt. - **L6 — Bounds honoured, so coverage is capped by design.** Three URLs per comparator (the slice cap; the B2 brief allows ≤4). Nothing was dropped silently: the inventory in §2 is the complete capture set. ### 7.2 Open questions - **O-1 — Can Rover and UrbanSitter be captured at all from this server?** Both refused three requests apiece with an identical template. Whether an escalation tier clears them is `UNVERIFIED` and untested in this corpus. - **O-2 — Why did `yoopies.com/en/*` return a GitHub Pages 404?** Until this is answered, the whole Yoopies capture set is untrustworthy, including the 200. Three `UNVERIFIED` readings are listed in §3.2 and the corpus settles none. - **O-3 — Was the Yoopies root body genuinely empty, or was it dropped in extraction?** A 200 response whose `text` exactly equals its `title` is `UNVERIFIED` either way: an empty page, a client-side-rendered shell that a text extractor flattens to its title, or an extraction fault. Note `SOURCE_REGISTER.md` B1-13 records a related-looking outcome on the Poland host (*"HTTP 202 with empty title/text"*), which makes a systematic capture problem on Yoopies properties worth ruling out. Not established here. - **O-4 — Are the correct Yoopies "how it works" and "pricing" paths the ones fetched?** Unknowable from the corpus, since requested URLs are unrecorded and the returned 404 was a generic template rather than a site-authored one. - **O-5 — Should this comparator set be substituted?** If Rover and UrbanSitter stay uncapturable, the B2 comparator list may need different platforms to fill the pet-care and premium-childcare slots. That is a scoping decision, not evidence work, and it belongs to the seat that owns the B2 comparator list. --- ## 8. Not covered - **The four B2 taxonomy fields for all three comparators** (model type, revenue mechanism, category breadth, stated scale) — attempted, 0 of 12 captured. See F2. - **Pricing and monetization for all three** — two pricing paths fetched, both denied. See F5. - **Rover trust and safety** — path fetched, denied. Trust mechanics are B3's bundle in any case; this slice contributes nothing to it. - **The fourth allowed source per comparator** — the B2 brief permits ≤4 sources per platform; this slice was capped at 3. Nine of a possible twelve captures. - **Press, filings, app-store listings, help centers** — the brief allows filings and press. None are in this corpus; this retry was corpus-only, so no additional source type could be collected. - **Other B2 comparators** — Care.com and Babysits are slice B2-A. Managed-care models (Honor/Papa class), care-benefit players, elder-care and home-care platforms remain uncollected under B2. - **Visual and interaction capture** — B6's bundle. No screenshots exist for these three; any visual claim about them is `UNVERIFIED`. --- ## 9. Close-out **Status: honest failure, fully documented.** The retry did not recover the slice. It produced a clean account of why: nine fetches, nine HTTP-level answers, one page title of content, and zero of twelve required data points. **What is safe to carry forward.** The nine rows appended to `SOURCE_REGISTER.md` (B2-B-01 … B2-B-09), the two failure-mode classes in F3, and the reachability finding in F4. That is the whole yield. **What must not be carried forward.** Any characterisation of Yoopies, Rover, or UrbanSitter. If a later synthesis, matrix, or council brief needs one of these three classified, priced, or sized, the citation cannot be this paper — the field is `NOT FOUND in this corpus` and must be re-collected or written `UNVERIFIED:` per the source contract §2. **One flag for whoever runs the next attempt.** Rover and UrbanSitter present the same problem (an edge refusal) and Yoopies presents a different one (a routing or target-URL problem, §3.2, O-2). Yoopies is the cheaper of the two to resolve and does not obviously require a heavier fetch tier. Signed `[O]`, 2026-07-30. Corpus: `reports/evidence/B2-B-raw/` (9 JSON, 9 empty ERR). No network access was used to produce this paper.