yellowpagesadult/ypa-evidence-schema-demo

YPA Exit Path Schema Demo

Version: 0.5.0 Status: synthetic, SFW demonstration — not a production corpus

This dataset-native demonstration keeps five exit facts separate: cancellation, account closure, data deletion, billing dispute and promotional-message controls. Version 0.5.0 also exposes the machine-readable summary fields money_exit_state, account_exit_state and data_exit_state. Every row is fictional, uses example.invalid and retains synthetic: true.

Discoverability does not prove that an authenticated workflow succeeds. The summary fields preserve the bounded public observation; they are not provider scores or guarantees.

Why the fields stay separate

Field states

• —SUPPORTED: the dated source visibly supports the bounded field
• —NOT_SUPPORTED: the dated source explicitly does not support the bounded field
• —BLOCKED: the field cannot be inspected within the stated public boundary
• —CONFLICTING: dated sources materially disagree
• —UNKNOWN: available material cannot support a bounded conclusion

Files

• —data/exit_path_demo.jsonl — five fictional rows with different evidence states
• —schema/exit-path-v0.5.schema.json — machine-readable schema
• —VERSION — dataset revision
• —DATASET_CHANGELOG.md — revision history
• —MANIFEST.sha256 — integrity index

Limitations

This is not a production corpus, provider review, ranking, certification or proof that any authenticated exit action succeeds. It contains no private data, affiliate data, explicit media or unresolved Live Cam Platforms destination.

Intended use and non-use

Use these records to test schema validation, retrieval boundaries and the separation of money, account and data exits. Do not use them to rank providers, train claims about real companies, infer legal compliance or predict user outcomes.

Corrections

Open a dataset Community discussion describing the file, record ID, expected bounded state and supporting synthetic rationale. Do not submit personal data or real account evidence.

Which additional exit field should a retrieval or evaluation system preserve, and what limitation should accompany it?

Two Exits, Two Receipts example

two_exits_two_receipts.jsonl adds one fictional SFW example spanning Live Cam Platforms, Adult Games, Dating, Gambling and Adult Guides. It separates the instruction that stops money movement from the instruction that stops profile/data processing, then records a dated confirmation for each state. The example is synthetic schema material, not a platform recommendation or proof that any real exit succeeds

Photo evidence privacy boundary

Before any future photo-evidence example is published, remove EXIF location coordinates and device identifiers, inspect window and mirror reflections, crop street signs, landmarks, badges and mail, and run a reverse-image search for reused identity clues. The current dataset remains synthetic and contains no personal photos or EXIF records

Playback quality claim boundary

480p upscales are not HD. Before a future playback-quality example labels a stream as HD, preserve four separate checks: the selectable resolution, playback stability at that setting, any disclosed bitrate or source details, and whether play triggers redirects, popunders or fake download controls. A quality badge alone does not establish source quality, bitrate or safe player behaviour. The current dataset contains no captured streams or platform quality ratings

Load the data

from datasets import load_dataset
rows = load_dataset("yellowpagesadult/ypa-evidence-schema-demo", "exit_path_demo", split="train")
assert len(rows) == 5
legacy = load_dataset("yellowpagesadult/ypa-evidence-schema-demo", "trust_check_legacy", split="train")

The default exit_path_demo config contains five JSONL records. trust_check_legacy retains the prior CSV without changing its columns or state vocabulary. Other JSONL files are supplemental demonstrations and are not concatenated into the default split. The Hub viewer may take time to rebuild after a commit; a commit alone is not a successful viewer check.

Field reference

UNKNOWN means the available fictional material does not resolve the question. It does not distinguish “never checked” from every other unresolved case; consumers must read scope/limitation. NOT_SUPPORTED requires an explicit negative in the fictional source, not merely a missing page. Summary equality is enforced by validate_release.py in addition to the JSON Schema.

Validate a local checkout

python -m pip install -r requirements-validation.txt
python validate_release.py

The validator checks Draft 2020-12 schema and formats, IDs, summary/detail equality, the reserved URL boundary, five rows, the legacy CSV shape, documented supplemental files and the release manifest. It does not connect to providers or validate real-world claims. The test fixture in tests/test_validation.py verifies that summary mismatch, a real source hostname and a broken timestamp are rejected.

Migration from 0.4.1

The default JSONL grows from two rows to five. Each of the two retained rows gains the three required summary fields; its prior detailed fields are unchanged. Consumers of schema v0.4 can keep the retained schema file, but should use schema/exit-path-v0.5.schema.json for the expanded records. Strict old-schema consumers must explicitly migrate; required fields are an intentional breaking schema change at this pre-1.0 release. No legacy CSV migration is needed.

Preserved files include the older menu-decision schema/demo and root-level two_exits_two_receipts.jsonl. The previous card linked that example under data/; this card fixes the documentation path. Photo-privacy and playback-quality boundaries from the live card are retained. No real photo or stream is added.

Provenance, license and maintenance

These five examples are authored synthetic fixtures, including three added in the September 2 local candidate. That candidate was not a public release; this package prepares publication on September 4, 2026. Source URLs and timestamps are illustrative. MIT licensing applies to the authored files. The manifest records SHA-256 for every release file except itself; it is an integrity check, not a claim of authenticity or safety.

A maintainer should update VERSION, the card, changelog and manifest together, run the validator, and verify the public files after upload. Do not silently replace synthetic rows with real users or providers. Corrections belong in the dataset Community with a record ID and a synthetic example, never credentials, private account records or payment details.