Public evidence index › Proof-Backed Data Page Pilot
Turn one dataset you own into a page family that can survive scrutiny
For $499 once, get one reusable server-rendered template, five production-shaped sample pages, a URL and canonical plan, per-page provenance and gap labels, deterministic eligibility checks, a sitemap fragment, and an install guide.
You may have inventory, coverage, location, specification, compatibility, or availability data already sitting in CSV or JSON. The difficult part is not looping over its rows. The difficult part is deciding which rows deserve pages, proving where every statement came from, and making sure a thin or near-identical record cannot drift into the sitemap later.
Request a suitability review
$499 one time
This is a proposed service and is not built for any buyer yet. The form is not checkout: it charges nothing, starts no work, and commits you to nothing. Describe the dataset, its field count, approximate record count, publishing rights, target stack, and intended reader. Do not upload or paste the dataset.
If the data is too thin, its rights are uncertain, or the target pages cannot be meaningfully distinct, the request is declined before payment.
Eight artifacts, not a strategy deck
Delivery is a readable source package for your repository or developer. Each item below is independently checkable.
1. Approved dataset and written schema
A frozen, dated copy of the dataset you supplied after scope acceptance, plus every field, its type, whether it is required for page eligibility, and what an empty value means. The schema becomes the contract for future exports. A structural change becomes a visible failure instead of a quietly malformed page.
2. One reusable server-rendered template
One record renders to one page without client-side data fetching. The template uses named helpers and the conventions of your existing stack. Every changing value is bound to the schema. Fixed markup is limited to copy that is truly shared, so a developer can see what is data and what is presentation.
3. Five production-shaped sample pages
Five real records are selected to expose the range: one dense record, one sparse record, two ordinary records, and one record that fails eligibility and is withheld with its reason. These are working rendered pages, not image mockups. They show the family at its strongest, its ordinary case, and its boundary.
4. Page-family, URL, and canonical plan
The package states which records map to URLs, how slugs are formed, how collisions are resolved, where the hub belongs, and which pages are self-canonical. Pagination and filters are covered so an innocent query parameter does not mint duplicate addresses.
5. Per-page provenance and gap labels
Every rendered value traces to a field in the dated snapshot. Every absence is labeled as absent from the source, rather than presented as zero. A reader and a future maintainer can distinguish a published fact from a missing field without trusting institutional memory.
6. Deterministic quality checks
A runnable script evaluates each record and emits a machine-readable verdict: eligible, withheld, or unknown, with reasons. The same input produces the same result. There is no model judgment in the publishing gate. An unreadable record is UNKNOWN, never silently accepted and never misreported as zero.
7. One generated sitemap fragment
The fragment contains exactly the eligible page URLs produced by the check. Withheld and unknown records are absent by construction. The publishing decision and the discovery file therefore cannot become two hand-maintained lists that disagree.
8. Install and handoff guide
The guide covers wiring the template into your stack, running the checks in the build, regenerating the fragment, responding to schema changes, and diagnosing named failure modes. It also records the judgment calls made during the pilot. One correction round against the acceptance contract is included.
Acceptance contract
You can test delivery without trusting a summary. If a check below fails, correction is inside the fixed scope.
The publishing rules are stated before you buy
These rules prevent the pilot from becoming a doorway-page generator. They are enforced by code and included in the delivery.
One record, one identity
One page maps to exactly one stable record key. No page merges records, and no record mints two canonical pages. If keys churn between exports, the dataset is not accepted until the URL consequence is resolved.
Remove the key and the page must collapse
If a page remains a sensible, complete document after its identifying value is deleted, it is a generic template wearing a proper noun. It is withheld. This test is intentionally strict because a neat renderer can otherwise conceal that every page says the same thing.
Siblings differ by substance
Two records are compared field by field. If the only differences are the key, its grammatical echoes, or decorative metadata, one or both pages are withheld. A page family must give a reader record-specific information, not a fill-in-the-blank paragraph.
Every statement traces to supplied data
If the dataset cannot support a sentence, the sentence is not generated. There are no inferred specifications, rounded-up descriptions, industry averages, or paragraphs inserted to reach a word count. The source field and dated snapshot remain visible in the package.
Gaps remain gaps
A missing field renders as an explicit source gap or makes the record ineligible, depending on the schema. It never becomes a plausible estimate. This is the rule most likely to expose that an attractive rollout is not yet supportable, which is why the work starts with a pilot.
Withheld and UNKNOWN are first-class outcomes
Withheld records are counted, listed, and given reasons. A malformed or unreadable record is UNKNOWN and separately reported. A parser failure can never masquerade as an eligible page, a deliberate rejection, or an empty dataset.
This pilot delivers five source-backed sample pages and withholds any page whose data, differentiation, provenance, or buyer usefulness cannot be established.
What you supply
- One CSV or JSON dataset that your organization owns or controls, with one row or object per intended page.
- A stable unique key and a rough field dictionary naming what each field means.
- A written statement that you hold the right to publish the supplied data. Uncertain rights are declined; we do not clear licenses or give rights advice.
- After written scope, twenty representative rows including sparse and awkward records. The public request form accepts only a description and counts, not the rows themselves.
- The target domain, path prefix, stack, and a named developer or CMS owner who will receive the source package.
- The intended reader and the question a useful record page should answer.
How the pilot runs
- Scope request. Describe the dataset, counts, ownership, target stack, reader, and deadline. No payment is taken and no data file is accepted by the form.
- Suitability review. We check whether the proposed fields and representative rows can support keyed, useful, differentiated pages. This usually takes two business days after the authorized sample is available through the agreed channel.
- Written scope or decline. A suitable dataset receives a written scope naming the snapshot, schema, five sample records, expected eligibility boundary, fixed price, and delivery date. An unsuitable or uncertain-rights dataset receives a decline before payment.
- Payment after scope. No checkout appears on this page. Payment is available only after the fixed scope is accepted.
- Build and delivery. The readable source package is delivered within seven business days of payment.
- Handoff and correction. Your developer receives the install guide and one correction round against the acceptance contract.
- Your team deploys. You control production review, release timing, analytics, indexing controls, and future changes.
What is outside the fixed scope
- No data acquisition, scraping, enrichment, licensing clearance, or legal advice.
- No CMS migration, hosting, production deployment, analytics, tag setup, or ongoing operation.
- No ongoing content production, backlink outreach, or promotion.
- No promise of ranking, traffic, crawl frequency, indexing, impressions, leads, or revenue.
- No generated copy to hide missing fields and no customer data retained for an unrelated use.
Search engines decide whether to crawl or index pages on your domain. This package cannot commit them to an outcome. The claim is narrower: the delivered sample pages are keyed, source-supported, distinct, honestly labeled, and mechanically checkable at handoff.
Who this fits
A content, SEO, growth, product, or engineering lead with a structured dataset and a developer who can deploy source is a likely fit. The pilot is useful when the organization prefers forty defensible pages to four hundred thin ones and wants the rejection mechanism proven before approving a rollout.
Who should not request it
It is not a fit when the data is scraped, licensed with unclear redistribution rights, mostly unstructured prose, or too sparse to support distinct pages. It is also not a fit when the buyer needs us to host or deploy, wants generated filler, or is purchasing a search-performance outcome.
Owned proof, with its limits
Counted on 2026-08-09: 15,004 regular files in our owned source corpus matched this exact scope: files recursively beneath the repository whose path contains /blog/ or /content/ and whose extension is .json, .md, or .mdx. The scoping command was find . -type f \( -path '*/blog/*' -o -path '*/content/*' \) \( -name '*.json' -o -name '*.md' -o -name '*.mdx' \) -print | wc -l. It demonstrates operating discipline on a large owned file set. It is not a client result, traffic result, count of customer pages, and it is not evidence of demand for this pilot.
Our public page-portfolio quality record shows the rule-only gate used on our own public page families. A failing family stays out of our sitemap index while the pages remain reviewable, and an unreadable probe stays UNKNOWN. That public mechanism demonstrates the kind of deterministic admission control proposed here. It does not prove a customer outcome.
There are no testimonials or purchase-history claims on this page because this exact pilot has no buyer yet. This page is the demand test.
Common questions
Is the service already built for a buyer?
No. The first accepted buyer receives the first build against this specification. The page describes a fixed offer so demand can be measured before product work expands.
Why is there no checkout?
Some datasets cannot support a defensible family, and uncertain publication rights are an automatic decline. Suitability needs to be established before anyone should pay.
What if most records are withheld?
That is a valid pilot result. The package lists each withheld record and its reason, giving your team a concrete data-collection plan instead of hiding the weakness behind generated prose.
Can you fill missing fields with AI copy?
No. A generated sentence inside a source gap defeats the product's purpose. Missing information stays missing or makes the record ineligible.
Who deploys the pages?
You or your developer. The delivery is source and a handoff guide. We do not take production credentials or retain control of the page family.
Does the quality gate use a language model?
No. The delivered eligibility and admission rules are deterministic. The same dataset and configuration produce the same verdicts.
Will the pages rank or be indexed?
No ranking, indexing, impression, traffic, lead, or revenue outcome is promised or implied.
Start with suitability, not checkout
Describe one dataset, approximate record and field counts, your stable key, publishing-rights status, target stack, intended reader, and deadline. Do not paste rows, source code, credentials, private URLs, or personal data into the form.