$ cat Offline Lab Library

These six reproducible local demonstrations teach measurement, response comparison and defensive triage using invented data. The supplied Python program runs without network access or third-party packages. Its captured outputs establish what the code does on these fixtures; they do not measure Google rankings, AI-search citations, malware detection rates or language-model behavior.

python3 run_labs.py
# Windows launcher: py -3 run_labs.py

The fixtures and full source are inspectable. Expected results include a fixture SHA-256. A mismatched baseline fails the run instead of silently accepting changed results. The baseline and assertions were authored with the fixtures; they are teaching checks, not independent validation.

LAB 1 · Confounding and controls

Question: can two links to one target reveal which link caused its ranking change? Inputs: three invented pairs of effects that all sum to the same change. Procedure: run the kit and inspect results.lab1. It shows that effects [3,0], [0,3] and [1,2] fit one aggregate observation equally well. A second example computes the difference between a treated change of 4 and a control change of 1.

Observed output: three compatible explanations; synthetic difference in differences = 3. Interpretation: one shared target cannot identify two source effects. A control can illustrate trend adjustment but does not by itself establish parallel trends or eliminate confounding. An invented, unopposed query also risks a ceiling effect. No domains are registered and no links or clicks are sent. The corresponding external research question remains unresolved.

LAB 2 · File-integrity investigation

Question: which changes need an owner's explanation? Inputs: baseline and observed file contents, plus an approved deployment entry, in fixtures.lab2. Procedure: inspect the snapshots, predict additions/deletions/modifications, then run the kit and compare the SHA-256 inventories in results.lab2.

Observed output: one added document page, one deleted page and two modified files. The CSS change matches the approved release; three other changes remain unreviewed. Interpretation: an alert is a request for investigation, not proof of intrusion. Capture a real incident's logs and files before cleanup, compare against a trusted deployment, and review authorization. This is a filesystem-model exercise; it neither installs WordPress nor claims to scan a CMS.

LAB 3 · Crawler/browser response comparison

Question: which response differences warrant investigation? Inputs: three pairs of static HTML bodies and status codes. Procedure: run the same normalization on each pair; compare text only after checking status. Inspect results.lab3.

Observed output: formatting-only markup produces same-normalized-text; unrelated content produces review-content-difference; a 403/200 mismatch produces inspect-access-control. Limits: localization, authentication, consent, CDN caching and experiments can create legitimate differences. The parser is not a browser renderer; client-side or CSS-driven behavior requires separate inspection. A user-agent string does not prove crawler identity. For real incoming requests, the site operator can use Google's published verification procedure.

LAB 4 · Citation-scoring exercise

Question: what belongs in a citation-rate numerator and denominator? Inputs: six fictional response records, three per presentation condition. Procedure: inspect fixtures.lab4, deduplicate URL fragments within each response, retain uncited responses, and inspect results.lab4.

Observed output: both conditions have 2 cited runs out of 3. Two anchors on one cited URL count as one successful run. Limits: these are invented observations; no AI engine was queried, and there is no evidence of a content-format advantage. For a future study, record product, model/version, query, time, locale, device, session conditions and raw answer for every scheduled observation. The proposed citation study addresses sampling and retrieval variability separately.

LAB 5 · Instruction/data trust boundary

Question: why is removing hidden text insufficient? Inputs: a clean product description, a visible instruction to append BANANA, a hidden instruction and a record missing a required fact. Procedure: compare the deterministic toy's document-obedient, hidden-filter-only and facts-only modes in results.lab5.

Observed output: the intentionally vulnerable mode appends the marker for both instruction placements. Removing the fixture's hidden element stops only that hidden case; the visible instruction remains. The facts-only code emits Demo Lamp uses 5 W. or abstains when power is missing. Limits: no LLM is involved. The facts-only behavior is enforced by a fixed parser and output schema, not by a prompt. This teaches authority separation; it does not prove a universal injection defense. Real agent evaluation needs model/task versions, representative adversarial inputs and authorization checks at tool boundaries.

LAB 6 · Synthetic poisoning indicators

Question: which combined signals justify escalation? Inputs: four invented events, including an approved release page and an unexpected document page. Procedure: examine each signal before running the simple three-signal rule; inspect results.lab6 and the worked investigation.

Observed output: only the event combining an unapproved new page, material response difference and download-lure text is escalated for a human. A new campaign URL asks for an owner check; an approved download page remains routine. Limits: no live payload, malware signature or real incident data is supplied. One constructed match provides no detection-rate estimate, and a different attack could evade this rule. The lesson is corroboration, evidence preservation and change review.