KnitKnot

# A content playbook is one record your team works from

A KnitKnot playbook holds the diagnosed issue, its evidence, the target page, the proposed change, the ship record, and the later measurement. Your team writes the page and publishes it. KnitKnot supplies the diagnosis and reads the next benchmark.

## What a playbook record holds

Six fields on one record: the issue a benchmark diagnosed, the evidence behind it (captured answers, the sources those answers cited, and approved company facts), the target page, the proposed change, the ship record, and the measurement that follows. The target page is a live URL rather than a topic, because a page has to be indexed and eligible to appear with a snippet before [Google's AI features](https://developers.google.com/search/docs/appearance/ai-features) can show it as a supporting link.

## See the change before anyone writes it

The playbook proposes the change as a diff against the page that already exists, with the record behind each added claim. Some playbooks ask for a crawler rule instead of a paragraph: [OpenAI's crawler documentation](https://platform.openai.com/docs/bots) states that a site opted out of OAI-SearchBot will not be shown in ChatGPT search answers.

## Work it in your own tools, on your own schedule

Query issues, evidence, and the supported playbook fields from the console or the customer MCP tools. Write and publish the change through your own content workflow, on your own schedule. KnitKnot then detects the page change and reads later benchmark movement against the original diagnosis.

## Choose who owns the page change

Use a playbook when your team writes and publishes. Eligible page classes can use the managed revision cycle instead, where KnitKnot proposes a bounded revision, runs deterministic checks, routes approval, and publishes under your policy. Both paths carry the same evidence and the same measurement: https://knitknot.ai/product/managed-agent-content/.

## What a playbook does not promise

A playbook never publishes anything to your site, and it does not guarantee a different answer from ChatGPT or Gemini. Publishing makes the page available to whoever retrieves it. [Bing's AI Performance preview](https://blogs.bing.com/webmaster/February-2026/Introducing-AI-Performance-in-Bing-Webmaster-Tools-Public-Preview) shows which of a site's URLs are cited in AI answers, and says those counts reflect how often pages are cited, not ranking, importance, or placement. KnitKnot reads its own benchmark on the same terms and reports what the next eligible benchmark observed, at the same journey and cycle grain.

Customer-managed work

A content playbook is one record your team works from.

It holds the diagnosed issue, the evidence behind it, the page to change, the change KnitKnot recommends, the ship record, and the measurement that follows. Your team writes the page and publishes it. KnitKnot supplies the diagnosis and reads the next benchmark.

Product evidence plate

Correct the RBAC claim AI keeps repeating

High priority

AI tells security buyers that Basalt has no role-based access control, then cites Loupe as support. Revise the enterprise security page with the verified answer and its receipts.

Issues
2
Answers
14
Monthly value at stake
$4.8K
Overview Brief Impact

What to change

Revise · Correction basalt.io/enterprise-security
Basalt supports role-based access control for enterprise deployments. State the verified capability directly, show buyers how access is scoped, and make the supporting product evidence easy for people and AI systems to retrieve.
  1. 01 Open with the verified RBAC answer before any general security positioning.
  2. 02 Show how access control works across users, teams, and self-hosted deployments.
  3. 03 Add the company-fact receipt and link to the product documentation that proves it.
  4. 04 Answer the comparison questions where AI currently repeats the outdated claim.

Updated

The record

What a playbook record holds

Every playbook starts at a diagnosed issue and ends at a page your team owns. The target page is a live URL rather than a topic, because a page has to be indexed and eligible to appear with a snippet before Google's AI features can show it as a supporting link.

One record, from the answer that opened the work to the benchmark that reads it next.

Issue
The representation problem a benchmark found, with the answers that showed it.
Evidence
Captured answers, the sources those answers cited, and approved company facts.
Target page
One URL your team owns and can edit.
Proposed change
The wording, structure, or access fix KnitKnot recommends for that page.
Ship record
What your team published, and when.
Measurement
The next eligible benchmark, read at the same journey and cycle grain.
Proposed change

See the change before anyone writes it

The playbook proposes the change as a diff against the page you already have, with the record behind each added claim. Some playbooks ask for a crawler rule instead of a paragraph: OpenAI's crawler documentation states that a site opted out of OAI-SearchBot will not be shown in ChatGPT search answers.

basalt.io/enterprise/security Bounded addition · 2 claims
38 Enterprise access controls
39 − Security controls are available for enterprise teams.
39 + Enterprise plans include SAML SSO and role-based access control.
40 + Admins can scope permissions by workspace and role.
41 See the access-control documentation for configuration details.
  • ✓ Claims backed by approved facts
  • ✓ Locators still resolve
  • ✓ No unsupported statement added

Your team can take the diff as written, edit it, or decide the page should stay as it is.

Ownership

Work it in your own tools, on your own schedule

Playbooks are queryable from the console and from the customer MCP tools, so the work can start wherever your team already tracks content.

KnitKnot opens the work and reads what happens after it. Your team owns the middle.

  1. 01 · Query Pull issues, evidence, and the supported playbook fields from the console or the customer MCP tools.
  2. 02 · Ship Write and publish through your own content workflow, on your own schedule.
  3. 03 · Measure KnitKnot detects the page change and reads later benchmark movement against the original diagnosis.
Workflow choice

Choose who owns the page change

Both paths carry the same evidence and the same measurement. They differ on who writes the page and who presses publish.

Playbooks compared with the managed revision cycle
Playbook Managed revision cycle
Who writes the page Your team KnitKnot proposes a bounded revision
Who publishes Your team, on your own schedule You approve; KnitKnot publishes under your policy
Page eligibility Any page your team owns Eligible managed page classes only
Checks before publish Your own review Deterministic checks, then routed approval
Rollback Your CMS history Publish receipt and rollback kept together
Evidence attached Issue, sources, approved facts Issue, sources, approved facts
Later measurement Next eligible benchmark, same journey grain Next eligible benchmark, same journey grain
Read the managed content workflow
Before the first playbook

What teams ask before they take one on

Engines have started reporting part of this themselves. Bing's AI Performance preview shows which of a site's URLs are cited in AI answers, and says those counts reflect how often pages are cited, not ranking, importance, or placement. KnitKnot reads its own benchmark on the same terms.

A playbook never publishes anything to your site.

Does a playbook guarantee a different answer from ChatGPT or Gemini?

No. Publishing makes the page available to whoever retrieves it. Whether an engine reads it, cites it, or changes what it says stays the engine’s decision, and KnitKnot reports what the next benchmark observed.

Where does the evidence come from?

From benchmark runs. A playbook carries the answers a run captured, the sources those answers cited, and the approved company facts that support any claim the change would add.

Can we work playbooks outside the console?

Yes. The customer MCP tools expose issues, evidence, and the supported playbook fields, so the record can be read from a chat client or pulled into the tracker your team already uses.

What happens to the record after we ship?

It stays. The diagnosis and its evidence remain readable after the page changes, which is what makes a later benchmark comparable to the one that opened the work.

Start with the evidence

Move from diagnosis to a scoped change.

Keep authoring in-house with a playbook, or put eligible pages into the managed revision cycle.

Question → claim → source → response