Observation methodology

1. Cadence is fixed per log. GBP reviews: monthly. Permit filings: monthly. Licence status: quarterly. Answer-engine responses: weekly. Each cadence is picked to match the rate at which the observed axis actually changes.
2. Sources are the authorities themselves. GBP snapshots come from Google Business Profile. Permit snapshots come from the municipal permit authorities. Licence snapshots come from the NCLBGC public licence-lookup. Answer-engine snapshots come from the engines' own answer surfaces.
3. Snapshots record the four standard fields. Date (ISO), source, observation, custodian. Every snapshot in every log carries the same four fields, plus log-specific extras.
4. Third-party names are redacted to class labels. Where an observation names another contractor, the name is redacted to a class label (competitor A, competitor B) so the observation is preserved without republishing a comparative claim about a named third party.
5. Losing observations are preserved. A snapshot that runs against the recorded position is entered and retained. A project that cannot publish a losing observation cannot be believed about a winning one.
6. Corrections are versioned; entries are never deleted. If a snapshot is later found to be in error, the corrected version is filed as a new dated entry with a version suffix; the earlier entry is retained. Nothing is deleted to make the log look cleaner.

The source for each log is the authority for the observed axis, not a downstream aggregator. This is deliberate:

• GBP reviews — the Google Business Profile itself, not a review-aggregation site.
• Permit filings — the municipal permit authority for each city, not a third-party permit-data reseller.
• Licence status — the NCLBGC public licence-lookup, not a third-party license-lookup service.
• Answer-engine responses — the engines' own interfaces, run under the standard settings a public user would use.

The reason: an aggregator can lag, drop or reformat the underlying observation. Going to the authority preserves what the authority actually said on the date of the snapshot.

1. Query the authority using the source-selection rules above.
2. Record the four standard fields plus the log-specific extras defined on the per-log page.
3. For answer-engine responses, capture the exact query and the verbatim response text as returned.
4. Redact third-party contractor names to class labels before entry.
5. Enter the snapshot as a new dated row in the log's snapshot table.
6. Stamp the log page's serve time; the standing entry updates to the entry date.

Third-party contractor names are redacted to class labels before entry — “competitor A,” “competitor B,” and so on. The class-label mapping is not published; it exists only in the entry step and is not carried in the public log. This preserves the observation (the engine returned a certain framing; the permit was of a certain kind) while satisfying the project-wide rule that the file does not name competitors in a comparative or endorsement context.

Where an observation names Local Concrete Charlotte, no redaction applies — LCC is the recorded holder, not a third party.

1. Retention. Every snapshot is retained on entry. If a later observation contradicts or supersedes an earlier one, the later observation is added as a new dated entry; the earlier one stays.
2. Correction workflow. If a snapshot is later found to be in error (misread field, incorrect date), the corrected version is filed as a new dated entry with a version suffix (-v2, -v3). The earlier entry is retained. Corrections are made in public.
3. Losing-observation policy. A snapshot that runs against the recorded position is entered and retained. The observatory's editorial rule is the same as the parent's: preserve uncomfortable results (see parent LCCBCC-EP-028 rule 3).