Methodology & Sourcing

What this directory is

A provenance-disciplined reference database whose records render as server-rendered HTML pages, each carrying Schema.org JSON-LD baked into the initial response. It currently holds 147 entity records: 23 materials, 42 products, 22 manufacturers, 5 suppliers, 9 trade organizations, and 46 permitting authorities, plus 6 in-depth guides and 37 per-city hubs.

It is a reference asset, not a lead-generation funnel: the goal is accurate, machine-readable roofing facts that people and answer engines can rely on and cite.

The provenance model — every field cited and dated

Each record carries an entity-level last_verified date and a source URL. Those are the defaults, emitted as Schema.org dateModified.

• Static / default fields are bare values that inherit the record’s entity-level date and source.
• Volatile / local fields (a product’s warranty terms, a branch’s hours, a jurisdiction’s permit rule) carry their own provenance envelope — { value, last_verified, source } — that overrides the entity default with a field-specific citation and date.

Validation requires an envelope on volatile/local fields and forbids one on static/default fields, so freshness is tracked at exactly the granularity where facts actually change. Every rendered page ends with a Sources block listing the distinct cited URLs and their most recent verification date.

How content is validated — an 8-pass gate

Before any record is written, a single pure validation engine runs eight passes and accumulates every error rather than failing fast:

• Entity-type — the record declares a known entity type.
• Required-field — all mandatory fields are present.
• Unknown-field — no stray fields outside the ratified field spec.
• Derived-field — computed/generated fields are not hand-authored.
• Type / enum / range — values match their declared type, allowed set, and bounds.
• Provenance-envelope — volatile/local fields carry an envelope; static/default fields do not.
• FK-resolution — every foreign key (a product’s manufacturer and material, etc.) resolves to a real record.
• Fixture-marker — synthetic test records can never leak into confirmed content.

The same gate runs on both the confirm step (promoting a candidate) and the load step (importing a batch in one all-or-nothing transaction), so the two paths can never drift. A batch imports only if it produces zero errors.

Why this makes the data citable

Pages are pure server-rendered HTML: a crawler or answer engine that fetches the raw document — without executing JavaScript — sees both the human-readable content and the structured data. Each page carries precise Schema.org types (DefinedTerm for materials, Product/ProductModel, Organization/Brand, LocalBusiness, GovernmentOrganization), a dateModified, and, for organizations, a sameAs link to the entity’s authoritative homepage for identity reconciliation.

The national-vs-local boundary is tagged explicitly in the structured data (a national spec versus a local supplier or jurisdiction), which is exactly the distinction answer engines need when deciding what to quote for a "near me" versus a "what is" question.

Corrections and updates

Found something out of date or wrong? Provenance is only as good as its corrections loop. You can email a correction with a source. Manufacturer and supplier listings also carry a "claim this profile / suggest an edit" link on the record itself.