Verifying GitHub Organizations

1. Ask: "May I research GitHub accounts and repositories for the target company and its verified companies and brands?" Skip only if this stage or the full investigation was already authorized.
2. Build search inputs from the cumulative register (legal names, former names, acquired companies, brands, domains, @domain patterns, developer/publisher names).
3. Run first discovery pass → verify attribution → run mandatory second pass (omission recheck) → update register → output table → ask permission for next stage.

Never skip the second pass, even if the first pass found nothing.

Progress:

• Step 1: Ask permission (unless pre-authorized)
• Step 2: Prepare search inputs from verified register
• Step 3: Run first discovery pass
• Step 4: Verify attribution for each candidate
• Step 5: Run mandatory second pass (omission recheck)
• Step 6: Handle any newly discovered entities
• Step 7: Output table, note recheck findings, ask permission for next stage

Step 1: Ask Permission

Use the exact question above. If the user already granted blanket authorization for the full workflow or specifically for Stage 4, state that you're proceeding under that authorization instead of re-asking.

Step 2: Prepare Search Inputs

Assemble from earlier-stage outputs:

• All verified legal entity names (current and former)
• All verified acquired-company names and subsidiaries
• All verified brand/product names
• All verified domains
• Generated @domain patterns for each verified domain (e.g., verified-domain.com → @verified-domain.com)
• Developer/publisher names surfaced during app research

Do not invent names, domains, or acquisitions not already verified in the cumulative register — this stage consumes prior verification, it doesn't redo it.

Step 3: First Discovery Pass

Search company/brand names separately, then in combination with domains, @domain patterns, products, and developer names. Adapt queries to the actual company rather than running boilerplate mechanically. Useful patterns:

• site:github.com "[Company Name]"
• site:github.com "[Legal Entity Name]"
• site:github.com "[Former Name]"
• site:github.com "[Acquired Company]"
• site:github.com "[Brand Name]"
• site:github.com "[Domain]"
• "@[domain]" site:github.com
• "[Company Name]" GitHub
• "[Domain]" GitHub
• "[Product Name]" site:github.com
• "[Developer/Publisher Name]" site:github.com

For each candidate, inspect:

• Organization profile (bio, pinned repos, linked website)
• GitHub verified-domain badge
• README files and repository descriptions
• Commit/maintainer info where relevant to attribution
• Links from official company sites or developer documentation pointing to the GitHub account/repo

Step 4: Verify Attribution

Classify each candidate as verified, lead (unconfirmed), or rejected.

Strong evidence (verified):

• Official company website or developer docs link directly to the GitHub org/repo
• GitHub's verified-domain indicator matches a domain already verified in the register
• An official document, blog post, or press release explicitly names the repository as company-maintained

Not sufficient on its own (reject or downgrade to lead):

• Repository merely mentions or uses the company's product
• Repository is a fork by an unrelated party
• Account is a personal/individual employee profile, even if bio mentions employer
• Email-domain match (@company.com appearing in commits/profile) — treat as a lead only, not proof
• Visual/logo similarity alone — use only as a last-resort tiebreaker, never as sole evidence

Additional checks:

• Confirm the account hasn't been renamed, transferred, or sold since acquisition
• Check whether repositories are archived (no longer active) vs. actively maintained — report status accordingly
• Check for unrelated namesakes (common company names may collide with unrelated GitHub users/orgs)
• If the target acquired a company, confirm the acquired company's GitHub org is still under target control (not divested or abandoned)

Step 5: Mandatory Omission Recheck (Second Pass)

Always run, regardless of Step 3 results. Re-search using:

• Alternate/former organization handles
• Acquired-company and subsidiary names not yet tried
• Brand names not yet tried
• Verified domains and @domain patterns in new combinations
• Links followed from official developer documentation
• Links followed from newly verified repositories (e.g., a verified org's pinned repos or org-wide README)

Goals: catch missed accounts/repos, verify any additions using Step 4 criteria, remove duplicates and false positives, and distinguish archived from active repositories. Record explicitly what the second pass searched and whether it changed the result set.

Step 6: Handle Newly Discovered Entities

If a GitHub org/repo reveals a previously unknown company, brand, product, or domain:

1. Record it as a lead in the cumulative register.
2. Verify its current connection to the target using available evidence (org links, verified domains, docs).
3. If verified, update the register and any earlier-stage findings it affects (note the update explicitly).
4. Search only its GitHub presence within this stage. Queue any other research (domains, apps, ownership) for their respective stages — do not perform it now.

Step 7: Report and Pause

Output a short table:

• Include only verified corporate GitHub assets.
• One or two short clickable evidence links per row (org page, verified-domain screenshot reference, or doc link).
• Note archived vs. active status where relevant.
• If nothing qualifies: state "None verified." Never state "no GitHub presence exists" — absence of proof is not proof of absence.

Then state briefly what the second pass checked and whether it found additions (e.g., "Second pass searched former name 'X Inc.' and domain pattern '@x.com'; added one archived repository, no other changes.").

Finally ask: "May I proceed to brand guidelines, DAM, and typography research?" Wait for permission unless the full workflow was already authorized.

Example 1: Input: Target: Microsoft Corporation. Verified domain: microsoft.com. Permission granted. Process: Search "Microsoft", "microsoft.com", "@microsoft.com" on GitHub → find github.com/microsoft, confirm verified-domain badge. Second pass: search product names → surface microsoft/vscode, confirm via official VS Code docs referencing this exact repo as the development home. Output:

Second pass searched product names and org-linked repos; added the vscode repository. Then: "May I proceed to brand guidelines, DAM, and typography research?"

Example 2: Input: Target: a small regional company with no engineering/dev presence. Permission granted. Process: First pass finds a personal account of an employee mentioning the company in their bio, and an unrelated open-source project with a similarly-spelled name. Neither meets attribution criteria. Second pass with former name and domain patterns finds nothing additional. Output: "None verified." Second pass searched the former company name and @domain pattern; no additions. Then: "May I proceed to brand guidelines, DAM, and typography research?"