Methodology
How this site works editorially. What we do and don't claim. The disciplines that make the verification states + field notes credible.
Verification states
Every applicable page (setup methods, plugin field notes, use-case recipes) declares a verification state visibly. There are five:
| State | Meaning | What it means for you |
|---|---|---|
| sourced | Researched from public docs / repos / vendor blogs. Sush has NOT personally run it yet. Most entries start here. | A sensible likely-correct path; verify before relying on it in production. |
| tried | Sush (or a contributor) ran it on real hardware. Date + version + platform + account tier captured in verificationContext. | You can follow with confidence; we know it works in this exact configuration. |
| verified | Tried, and Sush considers it correct (no surprises, no undocumented caveats). The highest signal. | The thing works as documented. Safe to rely on. |
| disputed | A reader has raised that something is incorrect, with linked discussion. | Treat with caution while we work it out. Read the linked dispute. |
| planned | Stub — does NOT appear in top nav until promoted. | Not yet ready. Don't follow. |
Most pages start as sourced on day 1 — Sush prepopulates the learning roadmap
from public docs so he knows what's possible to try. As he experiments, pages flip to
tried with the actual session log + platform/version notes. We don't backfill
claims we haven't verified.
The verification context on a tried entry typically captures
tool · version · platform · account tier · who tried it · when. Different versions of the
same tool can behave differently, so the context matters.
Field notes (not reviews)
Plugin pages in §4 are titled "Field note" not "Review." Lighter editorial stance than a verdict-band scorecard. Each field note declares:
- What we checked (e.g. "install path · default scope · documented permissions")
- What we did NOT check (e.g. "performance under heavy load · symlink edge cases")
- Whether we ran it (verification state badge)
- Risk profile + level
- Maintainer health
- Sources used (linked)
- A dispute link to a GitHub issue template
"Field note" not "review" because: we don't grade plugins on a 1–10 scale or assign verdict bands. We describe what we found. That's lighter, more honest, and reduces legal exposure to plugin-author pushback.
Dispute mechanism
Every entry has an "edit this page on GitHub" link and a "dispute or correct this entry" link. If we got something wrong, the right path is a GitHub issue or PR. We respond to corrections from plugin authors, vendor maintainers, and from readers. We don't gate corrections behind editorial pride.
Voice rules
Plain English. Honest take. Examples + scenarios + comparisons + "why this matters" for important concepts. A locked list of forbidden words is checked by voice-lint in CI — see that file for the full list, which includes typical marketing-speak signals around novelty, capability, and superlatives.
Why a fixed list: each one is a marketing-speak signal. The site fails its purpose if it reads like marketing. The lint runs on every push; advisory mode for general content, strict mode for roadmap docs.
Scope guardrails
Claw covers practitioner AI tools you can run, wire, script, compare, or operationally reason about — install paths, configuration, plugins/MCP/connectors, hands-on experiments, use-case recipes, pricing & limits, privacy & security models, "when to pick X over Y" comparisons, vendor updates. Voice-lint enforces this scope.
Out of scope:
- Prompt-engineering articles — not vendor-product-shaped; drifts into endless think-pieces.
- Model benchmark rankings — stales weekly; not learning-roadmap shape.
- AI ethics / safety / regulation commentary — easy to get wrong publicly; not builder-shaped.
- General "what is AI?" explainers — that's Plain AI's lane.
- Vendor PR / marketing reposts — no honest take = no value.
- AI news / punditry / hot takes — field notes ≠ commentary.
- Customer engagement detail — data classification rule. Microsoft-related content on Claw uses ONLY publicly-sourced material.
Positive inclusion test — a page belongs in Claw only if it answers ≥1 of: Can Sush install/run/configure it? Can it connect to files/repos/tools/agents/workflows? Does it change how Sush chooses between practitioner tools? Is there a concrete privacy/security/operational decision? Did Sush try it (or plan to)?
Sources & citations
Every page that makes factual claims links to its sources. For each vendor, sources include official docs (e.g. docs.anthropic.com, learn.microsoft.com, ai.google.dev, platform.openai.com/docs, docs.openclaw.ai), vendor blogs, official GitHub repos, and scoped community resources where appropriate. Where we synthesise across sources, we say so.
Microsoft entries are held to a stricter standard — public sources ONLY. No customer engagement detail. No internal-classified material. Voice-lint enforces a citation-required check on Microsoft pages.
Sourced primitive map (OpenClaw)
For the OpenClaw section, we built
src/data/openclaw-primitives.json — 46 primitives grounded in real source
URLs. Every OpenClaw concept page derives from this map. If we use an umbrella term that
isn't in OpenClaw docs (e.g. "Connections" as our category for channels+tools+models+memory),
it's flagged with officialSource: null so readers know it's our framing, not
OpenClaw's.
Why this matters: a tech-savvy OpenClaw reader spots invented or fuzzy primitives quickly. The primitive map is the source-of-truth that keeps us honest. We expect to build similar maps for each vendor as their sections grow.
Independence
Claw is an independent guide by Sush. Not affiliated with or endorsed by Anthropic, OpenAI, Google, Microsoft, the OpenClaw project, or any plugin author unless explicitly stated. Sush works at Microsoft as a Copilot Solution Engineer — all Microsoft content on Claw uses only publicly-sourced material (Microsoft Learn, official blogs, public GitHub, his own experiments at home). No customer engagement detail. Microsoft disclosure is inline at the top of any page that discusses MS-related deployments.
No paid tier. No email walls. No telemetry. No affiliate links unless explicitly disclosed. Repo is open under MIT for code, CC BY 4.0 for content where applicable.
Cadence
No schedule. Sush ships when there's something worth shipping. Watching the repo on GitHub is the way to see changes as they land. The §8 Updates page is the human-readable changelog.
Quality ratchet
Every push runs voice-lint, audit-claims (counts must match catalog), audit-verification-states (every applicable page must have a state), and integrity-check (broken-link count must stay below threshold). The threshold ratchets down as content lands. The site doesn't drift quality down silently.
What we don't do
- Formal scorecards with verdict bands (e.g. "8/10, Recommended"). Field notes only.
- CVE tracking. §6 security is patterns, not a vulnerability database.
- Vendor-sponsored content. Ever.
- "Get started" / "Try now" CTAs. The site is reading-shape, not selling-shape.
- Email capture. No popup. No newsletter wall.
- Out-of-scope topics (see §Scope guardrails above).
What we do
- Plain English. Even for technical concepts. Jargon explained on first use.
- Honest verification states. Sourced is the default until we run it.
- Cross-links forward and back. Every entry links to prerequisites + next steps.
- "Why this matters" blocks for important concepts.
- "Things to try" sections for action.
- Sourced everywhere. Hover any link; it goes to a real source.
- Verification context on every tried entry — tool · version · platform · account tier.
Last reviewed 2026-05-14. edit on GitHub →