Why We Open-Sourced Our Growth Team's Playbook: What’s Public, What’s Verified, and What Stays Gated

---

title: "Why We Open-Sourced Our Growth Team's Playbook: What’s Public, What’s Verified, and What Stays Gated"
description: "An inspection-first guide to this open-sourced growth playbook: what you can verify publicly, what is documented, and where the boundary begins."
slug: "open-sourced-growth-playbook-public-vs-gated"
date: "2026-07-13"
tags:

• open-sourced growth playbook
• SEO audits
• Google Search Console
• E-E-A-T
• technical SEO

---

Why We Open-Sourced Our Growth Team's Playbook: What’s Public, What’s Verified, and What Stays Gated

Open source is weak evidence unless a public rule connects to a public output.

If you are evaluating an open-sourced growth playbook, the real question is not whether a repo exists. The question is whether you can trace a public method to a public artifact, then see where that method stops and gated operations begin. This post is a current-state boundary ledger. It explains what is public, what is independently verifiable, what is only illustrative documentation, and what remains outside public inspection.

Everything in this article points to one of two evidence types: the public Groundcrew repository on GitHub or public TrustGrowth proof surfaces and documentation. That means every reader can inspect the same artifacts we are referencing: the Groundcrew repo at github.com/techwright-lab/groundcrew, its README, the public skills directory, the shared evidence schema at shared/evidence.schema.yaml, the example evidence file at examples/evidence/valid-keyword.json, the live proof page at trustgrowth.ai/proofs/trustgrowth, and the public AI team page.

This is not a launch post. It makes no outcome claims, names no competitors, and does not claim that the public repo equals the full product. It is a practical explanation of what opening a playbook lets an outsider verify and where the honest boundary begins.

Why publish an open-sourced growth playbook at all?

The trust problem in SEO software is simple: you are often shown a score before you are shown the evidence. In 2026, GitHub still matters here because a public repository gives you version history, authorship, and timestamps that a screenshot cannot. GitHub documents that commits preserve project history and attribution, which makes method changes inspectable over time according to GitHub Docs.

That is why we publish workflow components publicly. The goal is not to claim a complete or universal method. The goal is to create an inspection layer: a set of public artifacts you can review independently.

The problem with black-box growth systems

Most growth systems expose outputs like scores, alerts, and content recommendations. Many do not expose the operating logic behind them. If you have been burned by opaque tooling before, you usually want 3 things: provenance, evidence type, and boundaries.

Provenance means knowing whether the input came from a first-party source like Google Search Console, a site crawl, or a manually defined rule. Evidence type means knowing whether a statement is directly measured, schema-defined, or judgment-based. Boundaries mean knowing what is still private, human-mediated, or account-specific.

A score without inspectable evidence is only a claim.

What open-sourcing changes for you

Open-sourcing changes the evaluation standard. Instead of asking whether you like the pitch, you can inspect the method shape, the evidence format, and the public outputs.

For example, the Groundcrew repo exposes a public repository root, a README, a skills directory, and a shared evidence schema. That lets you inspect how work is framed and how evidence may be structured. It does not, by itself, prove that a given live audit was produced from that repo, or that every product action is public.

If you want the repo-specific walkthrough, see Open Groundcrew skills for SEO workflows. This article takes a broader inspection-first view.

What is public right now in this open-sourced growth playbook

The fastest way to evaluate an open-sourced growth playbook is to separate public artifacts from live outputs. Right now, there are 7 public artifacts that matter in this discussion.

Public inventory you can inspect today

1. Groundcrew repository: https://github.com/techwright-lab/groundcrew
   This proves a public project exists on GitHub with visible history and file structure.

2. README: https://github.com/techwright-lab/groundcrew/blob/main/README.md
   This documents the project at a high level. It is public documentation, not proof of a specific run.

3. Skills directory: https://github.com/techwright-lab/groundcrew/tree/main/skills
   This exposes public workflow components or skills definitions that outsiders can inspect.

4. Shared evidence schema: https://github.com/techwright-lab/groundcrew/blob/main/shared/evidence.schema.yaml
   This shows the expected shape of evidence. It is schema documentation, not a real live audit.

5. Example evidence file: https://github.com/techwright-lab/groundcrew/blob/main/examples/evidence/valid-keyword.json
   This is an illustrative example of a valid evidence object. It is not a production run.

6. Public proof page: https://trustgrowth.ai/proofs/trustgrowth
   This is a live public proof surface. It shows how findings are presented for a real public site.

7. Public AI team page: https://trustgrowth.ai/ai-team
   This provides a public-facing explanation of the AI team concept and operating context. It is descriptive, not equivalent to full product access.

Claim, public artifact, what it proves, and what it does not prove

Claim Public artifact What it proves What it does not prove A public playbook exists Groundcrew repo A GitHub repository is publicly visible and inspectable It does not prove the full product is open-source The project has public documentation README The method is documented at a high level It does not prove every documented component is active in production Public workflow components are exposed skills directory Outsiders can inspect named workflow assets It does not prove account-level orchestration is public Evidence has a defined public shape shared/evidence.schema.yaml Evidence fields are publicly described in YAML It does not prove a specific live proof page was generated from this schema A sample evidence object exists valid-keyword.json There is an illustrative example of a valid evidence payload It does not prove a real customer or site run Public outputs are live proof page A real public proof surface exists on the site It does not prove completeness of every possible finding Public AI operating context is described AI team page Readers can inspect how the AI team is framed publicly It does not prove unrestricted access to private tooling

That table is the core distinction. A public schema proves documentation. A public proof page proves a live output exists. They are not the same kind of evidence.

How the open-sourced growth playbook works at the public level

The public workflow can be understood at 3 levels: public method, public evidence shape, and gated product-account operation. That is the narrowest honest explanation supported by public artifacts.

1. Start with source-grounded inputs

Search performance claims should start from first-party data when possible. Google Search Console is the main named source here because it provides verified search data for clicks, impressions, average CTR, and average position in the Search Console Performance report, according to Google Search Console Help.

That matters because first-party source data and inferred recommendations are different things. GSC can tell you what Google Search recorded. It cannot, by itself, answer every trust, UX, or editorial quality question.

2. Apply structured checks across technical, trust, and content layers

A responsible audit separates measurable checks from judgment-based checks. That is why the interpretive boundary matters.

On the measurable side, you can inspect how a system talks about site health and performance through public explanations like site health score explained and why performance belongs in the TrustGrowth score.

On the judgment side, you should expect explicit caveats. The current public explanation of what you can quantify versus what still requires human judgment defines where structured checks end and interpretation begins.

3. Convert findings into proof-backed outputs

An output is more trustworthy when it names its evidence type. A warning based on a crawl observation is different from a warning based on a heuristic pattern or a manually interpreted trust signal.

The evidence label should make clear whether a finding is direct, derived, or judgment-based. Public proof pages then act as evidence surfaces: places where findings, score context, freshness cues, and page-level observations can be reviewed. They are evidence surfaces, not guarantees of completeness.

4. Keep account-level operation separate from public method

This is the boundary most companies blur. Public workflow artifacts show how work is organized. They do not automatically expose private workspace orchestration, user-specific audits, monitoring, or account-connected operations.

If you cannot inspect an account-level operation publicly, you should treat it as gated, even if it is available through the product.

Where the boundary honestly begins

The value of an open-sourced growth playbook is not that everything is open. The value is that the boundary is named clearly.

Public, inspectable, waitlist-gated, and not claimed

Category Current-state status Public example Boundary note Public repo existence Inspectable by anyone groundcrew repo Proves public code/docs presence, not full product scope Public documentation Inspectable by anyone README Documentation can describe a method without proving a live run Public workflow assets Inspectable by anyone skills directory Public assets are not the same as full orchestration Public evidence shape Inspectable by anyone evidence.schema.yaml Schema is illustrative documentation Public example evidence Inspectable by anyone valid-keyword.json Example file is illustrative, not a real run Public proof output Inspectable by anyone proof page Live proof output does not expose all private logic Account-connected audits Waitlist-gated or product-gated Product flows Not publicly inspectable in the repo Private orchestration and internal ops Waitlist-gated or private Internal workspaces Not claimed as public Full parity between public repo and product Not claimed None No claim that public artifacts equal the full product Full automation of all audit judgment Not claimed None No claim that proof removes human review

This is the part skeptical operators usually care about most. A boundary statement reduces ambiguity. It tells you what to audit and what not to assume.

How to evaluate any open-sourced growth playbook responsibly

You can use the same checklist on any SEO workflow, whether it lives on GitHub, GitLab, or a company site. The standard is simple: look for public rules, public outputs, and explicit limits.

Five-question audit for any open-sourced growth playbook

1. What are the source systems?
   Look for named systems like Google Search Console, GitHub, Google Search Central, YAML schemas, or crawl datasets. If the source is unnamed, the claim is weak.

2. Which parts are directly measured?
   Measured inputs include fields like clicks, impressions, or HTTP statuses such as 404. If a claim is measured, it should be tied to a source system or schema.

3. Which parts require judgment?
   E-E-A-T interpretation, trust signaling, and editorial quality often include heuristics. That is acceptable if the judgment boundary is stated clearly.

4. What can you inspect independently?
   Good signs include a public repo, visible commit history, a schema, examples, and live proof pages. GitHub and public site pages make this possible without requiring an account.

5. Where does the boundary begin?
   You should be able to point to the exact moment the workflow moves from public method to gated product operation. If that line is hidden, the workflow is harder to trust.

Signs a workflow is transparent enough to trust

A workflow is easier to trust when at least 5 conditions are present:

• Public artifacts exist.
• Evidence type is named.
• Freshness or timing is documented.
• Limitations are stated.
• Output interpretation is explained.

As a practical screening heuristic, if you can verify fewer than 3 of those 5 signs, the workflow may be too opaque for a high-trust audit use case.

FAQs about this open-sourced growth playbook

Is the full product open-source?

No. The public repository and public proof surfaces are inspectable. They do not equal the full product or all account-connected operations.

Can you inspect the workflow without creating an account?

Yes. You can inspect the public GitHub repository, the README, the skills directory, the schema file, the example evidence file, the live proof page, and the AI team page without signing in.

Does open-sourcing the workflow mean the outputs are fully automated?

No. Public workflow artifacts can show method structure and evidence shape. They do not prove that every output is fully automated or free from human interpretation.

Does Google Search Console provide all the evidence needed for an SEO audit?

No. Google Search Console provides strong first-party search evidence, including clicks, impressions, CTR, and average position, according to Google Search Central. It does not cover every trust, UX, or content-quality question by itself.

What does the schema and example evidence file prove?

They prove the public documentation includes an evidence format and an illustrative sample. They do not prove a real live run. The schema and example should be treated as documentation, not production output.

See the playbook and proof for yourself

If you want to evaluate this open-sourced growth playbook critically, start with the public artifacts, not the marketing copy. Read the Groundcrew repo, inspect the README, review the skills directory, compare the evidence schema with the illustrative example, and then inspect the live proof page. That sequence shows you public method, public evidence shape, and public output in under 15 minutes.

The useful question is not whether you agree with every rule. The useful question is whether you can inspect the rule, inspect the evidence, and see where the system stops making public claims.

What this means for your site

You can audit any published SEO workflow in 30 minutes with the five-question test: source, measurement, judgment, inspectability, and boundary. Open the repo. Check whether the docs name real systems like Google Search Console or GitHub. Look for a schema or evidence format. Then ask whether a live public output exists and whether the limitations are stated.

If you are reviewing TrustGrowth specifically, compare the public repo and proof surfaces first, then use the product only after you understand the boundary. That sequence gives you a better standard for trust than a score alone.