---
title: The product-change pipeline
description: How Thally turns configured product changes into reviewable documentation updates while keeping people responsible for what publishes.
url: https://pr-14-a9c4e9fe1b6c.thally.app/product-change-pipeline
---

# The product-change pipeline

How Thally turns configured product changes into reviewable documentation updates 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 the documentation your customers use and prepares a pull request for people
to review.

## How it works today

#### A configured event starts the check

    You choose whether Track runs for trusted, same-repository, non-draft pull
    request updates, merged changes, a UTC schedule, or a combination of those
    triggers. Track keeps the exact source revision that started each run.

#### Track fans the change out to review destinations

    Track reads the connected Product source and starts an independent run for
    the primary documentation repository and every Knowledge surface enabled
    for the site when the event arrives.

#### Each destination prepares and checks its result

    Every run uses the saved repository, branch, root, and exact path scopes.
    A destination that needs no update finishes without opening a pull request;
    other destinations continue independently.

#### A person decides what publishes

    When an update is needed, Track opens a ready-for-review GitHub pull request
    in that destination. Reviewers can accept, correct, or reject it; Track
    never merges its own work.

#### One reviewed source feeds every output

    After approval and publication, the same structured source powers HTML,
    Markdown, JSON, JSON-LD, search, embeddings, and agent context.

## The trust contract

#### You choose the starting point

    Configure pull request, merge, and scheduled checks for the way your team
    ships product changes.

#### The exact change stays attached

    Every run keeps the Product source and revision that reviewers need to
    understand why the documentation proposal exists.

#### No-change is a valid result

    Track can finish without a pull request when the source revision does not
    require a customer-facing documentation update.

#### Humans approve communication

    Automation removes discovery and drafting work, not accountability for what
    customers read.

## What Thally handles today

| Area            | Current behavior                                                                                                     |
| --------------- | -------------------------------------------------------------------------------------------------------------------- |
| Product sources | Connected GitHub repositories, branches, and optional watched paths                                                  |
| Triggers        | Trusted, same-repository, non-draft pull request updates; merged changes; and UTC daily, weekly, or custom schedules |
| Progress        | Persistent activity from change receipt through preparation, writing, checking, and pull request creation            |
| Output          | An independent ready-for-review pull request, no-change decision, or needs-attention result for every destination  |
| Approval        | Your existing GitHub review and deployment workflows                                                                 |

> **Note:**
  Track prepares proposals. Primary docs publish through the managed release
  path after review. Connected surfaces use their own repository checks,
  previews, reviewers, and publishing workflows.

For the complete trigger, confinement, validation, preview, and publication
contract, read [Extend Track to Knowledge surfaces](/guides/knowledge-surfaces).

## 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 source and
  choose its triggers.
- [Connect Knowledge surfaces](/guides/knowledge-surfaces) for customer-facing
  content outside the primary documentation repository.
- [Use the docs agent](/guides/docs-agent) for self-managed authoring tasks.
- [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 reviewed source
  before it publishes.