Methodology and evidence grading: sources, scope, AI disclosure and corrections

This site's use of "evidence" is not a claim that it performs medical systematic reviews or turns citation counts into truth. It is an editorial constraint: every conclusion must state where its evidence came from, what that evidence can answer and what it cannot answer.

The common technical-writing failure is not a wrong number; it is copying a number from a secondary blog and promoting it from one room, device and version to a universal law. This page documents the workflow used to avoid that failure and the process for correcting it.

1. Classify the claim first

One source supports different claims with different strength:

The verb must match the evidence. A first-party run says "the measured value was"; an inference says "more likely"; an untested question says "unknown"; an unreproduced marketing claim says "claimed, not independently verified."

2. A–E evidence grades

A and B are not a simple ladder. A standard answers "what is the specification"; a paper answers "what worked under these experimental conditions"; a first-party run answers "what happened on this device this time." A standard cannot replace a performance measurement, and one paper cannot replace reproduction on current firmware.

At the last update, the reference registry contains 51 verified sources (A 2 / B 16 / C 25 / D 3 / E 5). Each entry stores the title, authors/institution, year, URL or DOI, verification method and date. Articles may cite only stable IDs from that registry.

3. Pre-publication verification

3.1 External sources

1. Write a falsifiable claim: object, variable, unit and scope;
2. prefer primary material: paper DOI, standard page, official documentation, source code or release, not a secondary summary;
3. record the level read: abstract, full text, appendix, official page or community discussion;
4. verify metadata: use DOI/Crossref for title, authors, year and venue;
5. preserve the relevant sentence: official and platform sources include the quote and access date;
6. check the version: commands, firmware, APIs and policies change quickly;
7. cross-check contested or high-risk claims with a second independent source or a reproducible experiment;
8. downgrade uncertainty: remove unsupported text, mark it unknown, or label it as a hypothesis.

Standards and surveys establish context. For example, the IEEE 802.11bf project page proves that WLAN sensing is a standardisation effort ^[2]; it does not prove that any current router has a particular sensing accuracy.

3.2 First-party experiments

A grade-E claim needs:

• device, firmware/software version, date and environment;
• raw data or a minimal reproducible sample;
• parser/analysis scripts and their version;
• explicit quality gates, exclusions and failures;
• a SHA-256 or versioned DOI; data revisions get a new version;
• key numbers that can be recomputed from the raw data.

The public 10-minute capture and toolkit are the basis of this project's E-grade evidence ^{[3] [4]}. "The serial port has data" or "the plot looks like breathing" is not validation; record count, timeline, gaps, matrix shape and hashes must agree.

4. Article review checklist

Automated builds, link checks and screenshot QA prove that the site is reachable and the layout does not overflow. They do not prove a paper's conclusion or a device's performance. Technical QA and factual review are separate processes.

5. Search and source selection

This site is not a systematic review and does not claim exhaustive search. The workflow normally includes:

1. use Crossref/DOI for authoritative paper metadata;
2. follow the paper and its references to the original experiment;
3. check standards, official docs, code and releases;
4. use GitHub metadata to verify that a tool exists, its license and last update;
5. seek independent papers or reproduction for marketing claims rather than treating popularity as accuracy;
6. record the access date. A historical fact is valid only for the date stated by the page.

High citation count means influence, not correctness. An official publication proves who published it, not product performance. Open source does not mean security-audited.

6. Data, figures and versions

• raw data and visualisations are stored separately; colour maps cannot change values;
• train/validation splits follow sessions or time, never random adjacent windows;
• report medians, percentiles, sample size and failures, not only the best-looking figure;
• distinguish 95.5 chain records/s, 12.68 closed groups/s and 12.64 groups/s after the documented filter ^[3];
• changes to statistics, chunks or field meanings update the manifest, SHA-256 and page;
• if a data revision changes meaning, publish a new version rather than silently replacing it.

7. AI-assistance disclosure

This site permits AI assistance for research organisation, drafting, translation, code suggestions, site implementation and test scaffolding, under these rules:

1. AI is never a source and is not entered in the bibliography;
2. external facts return to a primary paper, standard, official document or real measurement;
3. commands, parsers and YAML are syntax-checked or run; otherwise they are clearly marked untested;
4. the named human author remains accountable for the published text and risk;
5. no fabricated citations, experiment results or user testimonials;
6. medical, safety and privacy claims receive stronger review than prose quality.

AI improves organisation and proofreading, but it confidently invents APIs, numbers and references. Plausibility is not evidence.

8. Commercial independence

• ads, affiliate links and sponsorships are disclosed;
• a commercial relationship cannot buy a favourable conclusion, ranking or deletion of a negative measurement;
• products without first-party testing receive no performance endorsement;
• commercial pages may be noindex during review, but technical conclusions do not change with ad status;
• prices, fees and availability are grade-C facts tied to their access date.

9. Severity-based corrections

Changes to first-party data update checksums and, when necessary, create a new Zenodo version while preserving the old DOI. A retracted paper, corrected source or removed official document is downgraded or rewritten at the next review; the old conclusion is not silently preserved.

10. Scope and responsibility

This site is for technical research and learning. Human-sensing material is not a medical device, diagnosis, safety certification, insurance or legal advice. Deployment requires authorisation, household disclosure and compliance with local privacy law. Any automation needs a failure path and human review.

Report an error, failed reproduction or dead citation with the page URL, exact paragraph and supporting evidence to okwujun@gmail.com. Reproducible counterexamples receive priority.

The reference list is generated automatically at the end of this page; its count and grade distribution follow the registry.