# Kibble installation contract: section 25 of 29 (guide version 3)

> This is **one section only**, not the whole contract. Complete document: https://www.usekibble.dev/AI/guide.md

## 25. Verify the installation {#verify}

1. Load a page of the site with the browser's network tab open. You should see exactly one request for `kibble.js` with status 200.
2. Before granting consent there must be **no** request to `/v1/collect`. Two other requests are not collection and are fine: a `POST /v1/erase` if an earlier `forget` left a pending erasure, and the Validation panel script (`site-check.js`) when the URL has a `#kibble-check` fragment.
3. Grant consent, then navigate to a second page. You should see `POST /v1/collect` requests with status 200 and a body of the form `{"accepted": n, ...}`. A 403 means the host or key is not registered; the SDK then stops sending on that page.
4. In the console, `kibble.debug.consent` should read `granted`. This dotted property exists only after the SDK has loaded; the queue stub does not have it. After `kibble('consent','denied')` sending must stop at once. Add `data-debug="true"` to see short SDK notices in the console.
5. Ask the human to open Manage → Health (`/manage/health`) in Kibble: it shows the first consented event and the event families received. Host-by-host registration is under Manage → Settings (`/manage/property`). This requires a staff sign-in; this public page cannot check a site for you.
6. If a booking engine or checkout is involved, complete a test flow and confirm exactly one outcome (or one outcome candidate when the signal has no reference) appears. For cross-domain, confirm the destination's first page view is a handoff and `_kbh` is gone from the URL.

### Installation acceptance checklist (Validation)

Data tracking → Events (`/manage/data-tracking/events`) leads with detected activity and decisions about business meaning. Advanced holds optional expectations: Expected here, Not expected here, or No expectation recorded. This note describes what you expect the site to send. It does not enable tracking or change counts. An administrator can update or clear it; either invalidates the current test. Never infer or overwrite a staff expectation from detected activity.

1. Start a validation from Manage → Validation (`/site-check`) and open the link on the site with consent granted. Validation never grants consent for you. Click the K to open the panel: newest activity first, each item opens to the exact payload sent, and the Developer view lists every request to Kibble with its status and every dataLayer push.
2. Page performance: with consent already granted, load a page, click something, then switch to another tab. The panel shows **Page speed measured** listing which of LCP, INP, CLS and TTFB the browser measured, and the page view's payload shows `perf: measured`. `late_consent` means consent arrived after the page started (expected right after clicking a banner; reload the page). This proves collection, not speed.
3. Perform the intended action with non-sensitive test inputs. No real booking and no real enquiry unless authorized. Validation activity is test traffic: it is stored and shown in the validation, but left out of report counts, and reports covering it say that a test ran.
4. The activity appears with the expected safe fields. Booking widget: "Searched for a stay" with hotel, stay start, nights and guests; a criterion missing from the payload is unmapped (the staff view says "Not recorded"). Booking-engine results: "Availability shown" with Available or Nothing available, or neither when the engine does not report it. A dataLayer push that Kibble can read but did not turn into an event is listed as such: check that the dataLayer integration is on.
5. The item says Stored (the collector confirmed it).
6. Verify the stage's meaning separately: Stored proves storage, not that a submit was accepted or a booking confirmed.
7. Site search: the row shows results some or none and never the words. In DevTools confirm that `POST /v1/phrases` carries no `browser_id` or `stream_id`, and that a phrase containing an email is not sent.
8. A staff member may save an optional test result (Data tracking → Events, `/manage/data-tracking/events`, or from the check itself) only for the families actually exercised, scoped to the host tested, and only after confirming the signal stands for the intended action. A test result changes no count, mapping or outcome confirmation, and activity is counted without one; it only changes how assurance reads. Ask the human to do this; never treat one stored event as a test.

To see what a property expects, what has been tested and what Kibble observed, a human can open Manage → `Health` (Overview, MCP and Processing). An assistant with a Kibble connection can read the same explanation with the `data_health` MCP tool. Manage → `Knowledge` (MCP `site_knowledge`) summarizes what Kibble can name — pages, hotels and products, suggestions waiting for staff — and lists next steps; it is counts only, never an inventory of the site. The final steps for an agent are in the [Agent completion checklist](https://www.usekibble.dev/AI#checklist).

Copy observation on Big Picture and opportunity evidence records the displayed finding, counts, reporting dates and qualifications. Its scoped evidence URL requires Kibble access; it grants no public permission and is not an archived snapshot. The Content report (API and existing `content` MCP tool) may include an optional `next_action` on at most two rows: one attention/tracking inspection and one onward-path review. These require ready coverage, at least 30 reaching visits and a non-withheld share; path review additionally requires at least 20% raw reach, and attention inspection uses recorded attention below five seconds per reaching visit, including absent attention. Preserve the supplied evidence and limitation. Absence is not a measured zero, attention coverage is not provided, and no action infers content quality, intent, abandonment or causation.

END OF SECTION verify