---
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-7-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. 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 |
| Output | Explained impact results and evidence-backed documentation pull requests |
| 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.

## 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.