---
title: The product-change pipeline
description: How Thally connects product evidence to customer-facing knowledge while keeping people responsible for what publishes.
url: http://localhost:3040/product-change-pipeline
---

# The product-change pipeline

How Thally connects product evidence to customer-facing knowledge while keeping people responsible for what publishes.

Software teams ship continuously, but the places where customers learn about
the product are maintained separately. A single change can create work across
documentation, API and SDK references, tutorials, release notes, examples, and
AI context. The usual failure is not writing quality—it is that no system owns
finding all of that communication work.

Thally is built to own that handoff.

> Every product change. Every knowledge surface. Automatically in sync.

That is the direction of the product. The first implementation is intentionally
narrow: connect GitHub product changes to documentation, determine what is
affected, and prepare a pull request for a person to review.

## How it works today

    A merged pull request contains the diff, discussion, files, and intent
    behind a completed change. Track uses that reviewed record instead of
    guessing from an isolated commit.

    Repository and path rules establish the candidate scope. Track distills the
    change into a documentation task only when the evidence indicates a
    customer-facing effect.

    The agent reads the product evidence and the existing docs together,
    updates relevant pages, and validates the result with `thally check`.

    The result is a normal pull request. Reviewers can accept, correct, or
    reject it; the agent never merges its own work.

    After approval, the content engine serves the same structured source as
    HTML, Markdown, JSON, JSON-LD, search, embeddings, and agent context.

## The trust contract

    The pipeline begins with reviewed product evidence, not an ungrounded
    request to generate content.

    A change should produce communication work only after Thally can explain
    what customer-facing knowledge it affects.

    The proposed update keeps the product context available for reviewers
    instead of presenting generated prose as fact.

    Review remains a product invariant. Automation removes discovery and
    drafting work, not accountability.

## Current boundary and direction

| Area | Available now | Product direction |
| --- | --- | --- |
| Product source | GitHub pull requests, paths, and repositories | Additional integrations that extend—not unlock—the pipeline |
| Knowledge surface | Documentation pages and API-reference content in a Thally project | SDK references, tutorials, release notes, examples, AI context, and future surfaces |
| Output | Evidence-backed documentation pull requests | Coordinated updates across every affected surface |
| Approval | Existing GitHub review and deployment workflow | Human control over every important communication |
| Learning | Accepted content and repository configuration | A customer-specific Product Knowledge Graph strengthened by reviews and corrections |

Thally includes an open documentation engine, but the product is not trying to
be another wiki, CMS, or knowledge base. Those tools store knowledge. Thally's
job is to keep it synchronized as the product changes.

## Put the pipeline to work

- [Set up Thally Track](/guides/thally-track) to connect a product repository.
- [Initialize the docs agent](/guides/docs-agent) to prepare reviewable pull
  requests.
- [Add provenance](/guides/provenance) so people and agents can see when pages
  were updated and last verified.
- Run [`thally check`](/guides/cli-reference) in CI to validate the reviewed
  source before it publishes.