---
title: The product-change pipeline
description: How Thally connects product evidence to customer-facing knowledge while keeping people responsible for what publishes.
url: https://pr-8-a9c4e9fe1b6c.thally.app/product-change-pipeline
---

# The product-change pipeline

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

Product changes can affect documentation, API and SDK references, tutorials,
release notes, examples, and AI context. Thally connects an exact GitHub change
to product evidence, identifies the documentation that may need work, and
prepares pull requests for people to review.

## How it works today

#### A product change supplies the evidence

    After a product pull request merges, Thally reads the exact merged commit.
    It extracts supported facts from OpenAPI, MDX, and TypeScript without
    running customer code, and keeps a link to the file evidence.

#### Thally explains what the change affects

    The Product Knowledge Graph compares the new facts with the previous
    version. Impact analysis keeps a docs page only when a supported graph path
    and evidence explain why it may need work.

#### Track updates each allowed destination

    Track receives the affected pages and supporting evidence, then prepares a
    pull request for the primary documentation repository. It may update an
    existing page or create a new page in the Product source's configured
    navigation group. When Knowledge surfaces are connected, it can also prepare
    draft pull requests in those Markdown or MDX repositories. If nothing is
    affected, the loop stops without creating a pull request.

#### A person decides what publishes

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

#### One reviewed source feeds every output

    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 product is the source of truth

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

#### Understand before generating

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

#### Evidence before confidence

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

#### Humans approve important communication

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

## What Thally handles today

| Area                  | Current behavior                                                                                                |
| --------------------- | --------------------------------------------------------------------------------------------------------------- |
| Product sources       | Connected GitHub repositories with OpenAPI, MDX, and TypeScript evidence                                        |
| Product understanding | Versioned product facts and links tied to exact commits and inspectable evidence                                |
| Knowledge surfaces    | The primary docs repository plus explicitly connected, path-scoped Markdown or MDX repositories                 |
| Automation            | Automatic drafting with new pages enabled and the workspace's available AI credits reserved for the run         |
| Output                | Explained impact results and evidence-backed documentation pull requests across existing or newly created pages |
| Approval              | Existing GitHub review and deployment workflows                                                                 |

> **Note:**
  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.

Connected Knowledge surfaces remain review-only destinations. Thally opens a
scoped draft pull request and never deploys the connected repository. The
primary docs repository is the only destination whose merged Track update can
enter the managed publishing pipeline.

Track uses bounded stages rather than sending an entire repository to one
model call. It seals the source evidence and exact destination revision, plans
the permitted files, drafts inside an isolated disposable sandbox, validates
the resulting diff, and gives publication authority only to the separate
review-gated GitHub step. This lets a larger feature change address several
documentation surfaces while preserving an inspectable source-to-claim trail.

## Put the pipeline to work

- [See how Thally works](/architecture) for the customer-facing publishing and
  update workflow.
- [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.