Skill packs › Skill

Evidence VerificationIN EVERY PACK

Establish what is actually TRUE about a client and prove it with records a stranger can check. Find the hard anchors hiding in public registries (Secretary of State, bar admission, ISBN, patents, ORCID, authority files), verify identity by matching a second fact rather than a matching name, and never let “we haven’t looked yet” render as “they scored badly.” The upstream skill every authority skill depends on — knowledge-panel-entity-seo, grokipedia-authority and ai-search-visibility all fail the same way when the underlying facts are wrong.

Skill file evidence-verification.md · last updated Aug 2, 2026

Use this when you are about to assert something about a client in public — a schema field, an encyclopedia submission, an audit score, a bio, a Knowledge Panel claim — and you want to be certain it is true, and provable by someone who does not trust you.

This skill exists because of a specific, repeatable failure. In July 2026 our records described a client as a style and image coach in Austria. She is a sewing author in South Tyrol, Italy. The error had been flagged in a research note five weeks earlier and never actioned. It was one submission away from putting a false description of a real person into an encyclopedia — which would then be scraped by every AI assistant that reads it.

Nothing about that failure was exotic. A field was wrong, a note said so, nobody carried it through, and the next system downstream treated the field as fact.

The one idea

A fact about a client is not established until a stranger can check it without asking you.

Your client’s own website is not evidence of anything except what your client wants to say. A testimonial is not evidence. A follower count is not evidence. What counts is a record held by someone with no stake in the outcome: a government registry, a national library, a court, a standards body, a publisher, a newsroom.

Everything below is machinery for finding those records and refusing to fake them.

Part 1 — Find the anchors nobody looked up

Most clients already have hard, verifiable public records. Nobody has searched for them. Work this list in order of how cheap the win is.

The business registry — the anchor almost every client has

Every LLC, corporation and partnership is registered with a state or national authority, and those records are free, public, and name the officers. In the US it is the Secretary of State (or Corporation Commission); in the UK, Companies House; most countries have an equivalent.

What you get: legal entity name, charter or company number, formation date, status, registered address, and — the part that matters — named officers, managers and registered agents.

Worked example. A client was known to us only as “Roland.” No surname in eleven email threads, none in the client tracker. His business was a registered Louisiana company:

JUNKS ABOVE LLC · charter 42116285K · filed 30 December 2015 · Active, in good standing ·
Officer: ROLAND LEBLANC, title Manager · domicile 4626 D’Hemecourt St, New Orleans

Two minutes in a public database produced a surname, a title, a formation date, and a verifiable charter number. Nearly every local-service client on a roster is an LLC owner, which means most clients sitting at zero corroboration have an anchor like this waiting, unclaimed.

The rest of the ladder, by profession

Weighting: not all anchors are equal

A registration proves someone runs a business. It does not prove anyone independent found them notable. Weight accordingly, and say so out loud when you report:

1. Strongest — Wikipedia article, national-library authority record, book with an ISBN from a real publisher, sustained national press where they are the subject
2. Strong — a single national press piece as subject, a named award, an academic publication record, a patent
3. Real but modest — business registration with a charter number, professional licence, named speaking role
4. Not an anchor — their own website, their own bio, follower counts, testimonials, directory listings they submitted themselves, press releases

Never let a category-3 anchor alone trigger a public submission. It is enough to establish identity; it is not enough to establish notability.

Part 2 — Verify identity with a second fact

A matching name is not a match. This is the single most expensive mistake in entity work, because the output looks completely normal when it is wrong.

Rule: confirm on a second, independent attribute — an address, a formation date, a brand name, a co-founder, a licence number, a photograph.

In the Roland example the identity proof was not the name. It was that the registry’s domicile address and the address on the shop’s website were the same street address. Same name in the same city would have been a guess. Same name and same address is an identification.

The inverse error is just as costly. A client was filed as a “namesake trap” — the Wikidata item matching her name was assumed to be somebody else. Five weeks later the record was followed properly through its authority file to the national library, which showed it was her own item all along. The stale warning had been suppressing her score and excluding her from work for over a month. A warning that has been disproved is worse than no warning, because nobody re-examines someone the file says is unsafe to touch.

So:

• Two identifiers agreeing = identified.
• One identifier = a hypothesis, and it must be labelled as one.
• A namesake flag must carry the evidence and the date it was established, so it can be re-tested rather than inherited forever.

Part 3 — Read negation

Research prose records absence as often as presence. Your own notes will say:

“Confirmed to have NO Knowledge Panel, NO Wikipedia, NO Wikidata and NO Grokipedia.”

A keyword matcher scanning that sentence finds Wikipedia, Wikidata and Knowledge Panel and records three anchors the client does not have. That is exactly what happened to a client audit in August 2026: the sentence documenting that he had nothing was read as proof that he had everything, and it promoted him to “ready to submit.”

Any automated anchor detection must check for negation before the match — no, not, never, without, lacks, missing, zero, none, absent. Scan a short window to the left and stop at a clause break so a negation in one sentence cannot suppress a real anchor in the next.

And when you add a new anchor type later, add it to the negation guard in the same edit. This is the kind of check that silently stops applying the moment someone extends the system.

Part 4 — “Not researched” is not “failing”

This is the rule that protects the client relationship, and it is easy to get wrong in a way nobody notices until a client sees the report.

If nobody has researched a client yet, that is a gap in our knowledge. It is not a judgement about them. A system that scores unresearched entities as zero produces a report where “we never looked” and “we looked and they have nothing” are visually identical — and the client cannot tell which one you meant.

Build the distinction into the data model, not the wording:

• UNKNOWN — no research done. No score at all, not a zero. Goes to a research queue with the specific questions to answer.
• BUILD — researched, no anchor found yet. A real, honest finding.
• NEARLY / READY — researched, anchors found.

Then enforce it with a test that fails if any scored entity has a score of zero, and another that checks the UNKNOWN action text describes our next step rather than the client’s deficiency. Wording drifts; tests do not.

Part 5 — Carry the evidence into the artifact

Research that stays in a research file is wasted. Whatever you produce at the end — a submission, an audit, a schema block, a pitch — must carry the specific verifiable anchors, not a summary of them.

A generator that says “active professional presence; any press, podcast appearances, books” has thrown away everything that mattered and produced filler that reads as unsourced. Compare:

Before: “Documented independently; entity home with structured data; active professional presence.”
After: “Independently verifiable: published by Springer Nature; ISBN 978-3-662-62443-2; authority records GND 130452106, VIAF, ISNI; Wikidata Q108866818; existing German Wikipedia article.”

The second one a reviewer can check in four clicks. The first one is a shrug.

And when there is no hard anchor, say so loudly in the artifact rather than dressing up the absence. A package that admits “no third-party anchor found — expect rejection, surface one proof first” is more useful than one that bluffs and gets bounced.

Part 6 — Fix at the source, in the same run

Every failure in this document has the same shape: someone found the problem, wrote it down, and moved on.

• The wrong niche was recorded in a research note five weeks before it nearly shipped.
• The disproved namesake trap was resolved in one file and left standing in another.
• The “does this have any hard anchor?” check existed in two places; adding a new anchor type updated one and not the other.

So:

1. Fix the source record, not just the output. If the roster is wrong, fix the roster.
2. Make the contradiction self-detecting. If two records disagree about the same identifier, that is a testable condition. Write the test; do not rely on someone noticing.
3. One authoritative definition. If a rule is expressed in two places, they will diverge — usually at the moment someone extends the system, which is the worst possible time.
4. A note saying “X is wrong and should be corrected” is not a correction. Either fix it in the same run or file it somewhere that fails until it is fixed.

How to run it

1. Inventory — list every client, partner and entity. Mark active/inactive from the authoritative source, and record a reason for every inactive one.
2. Probe what already exists — before researching anything, check whether the entity already has a Wikipedia page, Wikidata item, Knowledge Panel or Grokipedia page. Run controls first: a known-good lookup and a deliberately nonsense one. A check that cannot fail is not a check. (Our first fleet run found pages already existed for a client and for one of our own companies — nobody knew, and nobody was checking them for accuracy.)
3. Hunt anchors — work Part 1’s ladder, cheapest first. Business registry before anything else.
4. Verify identity — second attribute, always. Record which two facts agreed.
5. Score honestly — UNKNOWN where you have not looked.
6. Carry evidence into the artifact — specific records, and a loud warning where there are none.
7. Report the corrections you made, not just the findings. A run that fixed two wrong records delivered more value than one that found three new anchors.

What good looks like

• Every assertion traces to a record a stranger can pull up.
• Every identification names the two facts that agreed.
• Nobody is scored on evidence they do not have, in either direction.
• The count of unresearched entities is stated plainly and never disguised as a low score.
• Corrections to source records are reported in the same run they were found.

Related skills

• knowledge-panel-entity-seo — consumes these verified facts as schema. Wrong facts here become wrong structured data there, which Google then believes.
• grokipedia-authority — the encyclopedia submission. Its “Insufficient Citations” rejections are this skill’s absence, showing up downstream.
• ai-search-visibility — what ChatGPT and Perplexity say about a client is assembled from exactly these records.
• positive-mentions-harvester — finds the press; this skill decides which of it is a real anchor.
• client-access-checklist — access is the precondition for measuring; verified identity is the precondition for publishing.
• recursive-self-improvement-qa — the discipline in Part 6 is that skill applied to facts instead of code.

Learned in the field

Appended automatically by the self-improvement loop (Skill-Learnings/): dated lessons from real runs. Newest at the bottom.

<!– learning:2026-08-02-a-row-in-a-table-is-not-a-page –> August 2, 2026 (from: grokipedia-fleet)

August 2, 2026 (from: grokipedia-fleet)

We had 24 skills and nowhere to send someone who asked what one of them was.

Each skill existed in three places — a markdown file in the repo, a file inside every pack zip, and a single row in a table on /skill-packs/. All three are real. None of them is a page. There was no URL for “what is evidence-verification and why would I run it,” which means there was nothing for a search engine to rank, nothing for an AI assistant to cite, and nothing to link to in a client email.

That is the same mistake we diagnose in clients every week. A capability that exists but has no citable address does not exist to anything that reads the web.

Fixed by generating one page per skill from the master .md files — 24 pages at /skills-<slug>/, each carrying the same five-rung ladder block as the rest of the system tree, each linking up to the pack directory and across to the Task Library.

Three things worth carrying forward:

Generate, never hand-write. The pages are built from the skill files that already exist, so a skill and its page cannot describe different things. The moment someone edits a page in wp-admin, the next run overwrites it and nobody finds out for weeks. Say GENERATOR-OWNED in the file header, and mean it.

A new tier of pages needs a new line in the verifier, the same day. Twenty-four pages went live at once, entirely outside the daily link-graph check. That is precisely how aibuilderspotlight.com/skill-pack linked to nothing for weeks inside green reports. The verifier now checks that every master skill on disk has a page linked from the directory, and samples three live pages per run on a rotating index so all of them get covered over time.

A page tier needs a line in the runner too, or it becomes a slower clock than its source. The daily job rewrites the master skill files every morning. Without a regeneration step the published pages would keep describing whatever the skill said the day they were generated, while the directory printed a fresh “last updated” date next to them — a stale page wearing a current timestamp, which is worse than an obviously old one. This is the third time the same defect has appeared in this system (Dorine’s mirror pack, the cloud runtime mirror, now the skill pages). Any artifact derived from a source that changes daily needs its own step in the daily job. Look for the pattern rather than waiting to be bitten by it a fourth time.

One smaller thing, worth its own note: the page generator imported propagate_all_packs just to read its MANDATED list. That module parses sys.argv at import time, so the generator’s own argument errors came out under the propagator’s name and usage text. Never import a module that acts at import time in order to read one constant from it — parse the constant out of the source instead.

Other skills: ai-search-visibility · boil-the-ocean · client-access-checklist · client-relationship-cadence · content-agent · content-factory

The full run order is on the skill-pack directory. Every skill here is one task from the Task Library — the library is the catalogue of what can be done; a pack is the subset you install; an agent is who runs it.