Reference library▤

A specification defines terms, conformance and sometimes reference tests. It helps distinguish proposals, drafts and adopted standards.

1. Identify the publishing body and exact status.
2. Read normative sections and document date.
3. Compare features against actual implementation support.
4. Record incompatibilities and deployment limitations.

Caution : A W3C project title does not automatically make a document a W3C Recommendation.

Agent protocols and projects define discovery, messaging, tools and tasks but do not automatically grant action permissions.

1. Locate a dated version and required fields.
2. Separate capability descriptions from permissions.
3. Test exchanges on fictional data.
4. Review errors and final outcomes.

Caution : Publishing a schema does not prove every library implements it.

Trust methods document signatures, policies, risks or verification workflows. Interpret results within their stated scope.

1. Identify the exact claim being checked.
2. Verify source and technical scope.
3. Cross-check assertions against independent evidence.
4. Record unknowns and contradictions.

Caution : A signature or score does not automatically establish factual truth.

Regulatory texts establish duties within a defined scope. Exceptions, dates and versions shape their interpretation.

1. Read original definitions and articles.
2. Identify jurisdiction, actor and use case.
3. Check application dates and exceptions.
4. Seek legal review for real decisions.

Caution : Educational summaries are not personalized legal advice.

These sources describe search, crawling and publisher interactions with search products. Rules vary by service.

1. Distinguish search, ranking, crawling and training.
2. Check official guidance for each crawler.
3. Observe actual indexing and cited links.
4. Do not generalize vendor marketing claims.

Caution : No single optimization guarantees a model citation.

Web development documents help design structured, accessible pages usable beyond AI interfaces.

1. Identify the feature’s user purpose.
2. Read APIs, examples and browser constraints.
3. Test a fallback without a model or external service.
4. Measure accessibility and performance.

Caution : Documentation examples are not a replacement for device testing.

Model sources describe architectures, datasets and evaluations. Editorial status and licensing require independent review.

1. Identify authors, revisions and intended tasks.
2. Read model cards and license terms.
3. Compare evaluations and declared limitations.
4. Test representative domain examples.

Caution : An author-written model card is not independent certification.

Research publications propose concepts, results and methods. To understand their scope, inspect methods, datasets and reproducibility.

1. Identify manuscript or reviewed publication.
2. Read question, method and sample.
3. Inspect metrics, failures and limitations.
4. Look for replications, revisions and critiques.

Caution : A submitted preprint has not necessarily undergone peer review.

These documents concern models running in the browser or on-device. They explain availability, memory needs, acceleration and privacy.

1. Check browser version and hardware.
2. Inspect model size and licensing.
3. Measure latency, memory and failures.
4. Provide an accessible fallback.

Caution : The term local guarantees neither sufficient performance nor complete privacy.

Immersive standards cover spatial representation, hardware, interaction and sensor permissions. Read them together with Web accessibility guidance.

1. Identify supported devices and browsers.
2. Distinguish 3D, VR and AR.
3. Test comfort, performance and navigation.
4. Provide an accessible 2D mode.

Caution : A 3D scene is not automatically VR and does not guarantee historical fidelity.