Doctrine

Documentation, help center, pricing, and changelog: product source hierarchy

Doctrinal note on the hierarchy of surfaces that describe a product or service: presentation pages, documentation, help centers, pricing, changelogs, contracts, and support responses.

EN FR
CollectionDoctrine
TypeDoctrine
Layerssa-e
Version1.0
Levelnormatif
Published2026-03-22
Updated2026-03-22

Documentation, help center, pricing, and changelog: product source hierarchy

Many sites describe the same product through different surfaces: feature page, documentation, help center, FAQ, pricing, version log, contract, support response. For a human reader, these surfaces do not have the same status. For a synthesis system, they are often perceived as variants of the same “about the product”.

This is the drift this page seeks to bound. The problem is not that a product is documented in multiple places. The problem appears when those places do not declare which source prevails for which type of statement.

This hierarchy is not meant to produce simpler marketing copy. It exists to prevent AI from reconstructing an average truth from surfaces that do not speak about the same act: capability, availability, commercial condition, version history, contractual commitment, or contextual explanation.


1. Not all product pages perform the same act

A product page is not equivalent to a pricing page. A pricing page is not equivalent to a changelog. A changelog is not equivalent to a contract. A support response is not equivalent to a canonical definition.

These surfaces may concern the same object while performing distinct functions:

  • the presentation page describes a perimeter or reading promise;
  • the documentation describes behavior, parameters, or usage limits;
  • the help center often addresses support and comprehension cases;
  • the pricing page qualifies commercial access conditions;
  • the changelog qualifies temporality and obsolescence;
  • the contract or policies frame what becomes enforceable;
  • the support response is often contextual and non-universalizable.

Endogenous governance is incomplete if it names a canon without distinguishing these documentary acts.


2. Product truth is distributed, therefore hierarchizable

In an interpreted environment, product truth does not appear as a homogeneous block. It is distributed by attribute types.

A few examples are enough to show the issue:

  • the existence of a feature does not prove its availability in every plan;
  • a help-center capture does not establish a contractual promise;
  • an update announcement does not equal permanent maintenance;
  • an old pricing page may remain readable while governing nothing any longer;
  • a support response may solve a local case without defining general product behavior.

Product source hierarchy therefore consists in declaring: which attribute must be read where, under which version, and with what scope.

This logic extends source hierarchy, but inside the on-site corpus itself. The arbitration no longer opposes only on-site and off-site. It opposes internal surfaces that do not carry the same jurisdiction.


3. Why synthesis systems confuse these surfaces

Synthesis systems prefer structured, short, categorical formulations. Yet pricing pages, capability tables, help centers, and support responses contain precisely this type of material.

Several recurrent confusions follow:

  • pricing redefines the product perimeter;
  • the help center redefines the general rule from a frequent case;
  • a support response becomes an implicit promise;
  • the changelog is read as decorative history rather than an obsolescence marker;
  • technical documentation is crushed by a simpler commercial formulation.

The analyses already published on SaaS pricing plans confused with capabilities and on customer support when AI commits the company without authority show that the problem is not the existence of these surfaces, but the absence of a readable hierarchy between them.


4. The changelog is not decorative

The changelog, or version log, does not merely indicate that “something happened”. It governs the version power of a product.

Without a clear signal of deprecation, removal, replacement, or effective date, older descriptions remain available as reusable matter. A removed feature can keep being cited. A modified limitation can keep being repeated. An old promise can survive as if it were still current.

This is where interpretive remanence and interpretive debt become central. What is no longer true does not need to remain majoritarian in order to keep being reconstructed. It is enough for the old version to remain easier to reuse than the new one.


5. When unspecified is more faithful than an averaged answer

A well-governed product hierarchy does not seek to make everything assertable. It seeks to make some assertions impossible without conditions.

If a price depends on volume, contract, or jurisdiction, the correct output is not an average. If a feature exists only in one plan, the correct output is not “the product does X” without qualification. If a support response is valid only for a documented case, it must not become general truth.

The role of the Q-Layer and of response conditions is precisely to prevent a synthesis from turning heterogeneous surfaces into a homogeneous response.


6. What a minimum product hierarchy should declare

A minimum product hierarchy should at least make the following distinctions visible:

  • definition source: where the product perimeter is declared;
  • execution source: where behavior is explained;
  • commercial source: where access conditions are bounded;
  • temporal source: where obsolescence, removal, or effective dates are stated;
  • contextual source: where a specific case is treated without being universalized.

The canonical cross-reference system becomes essential here. Without explicit cross-links between these surfaces, AI does not inherit the intended hierarchy. It reconstructs documentary proximity and interprets it as equivalence.

The situation becomes even more fragile in multilingual environments, where FR documentation, EN pricing, and a partially translated changelog can generate a hybrid response.


7. Scope and limit

This page provides neither UX guidance, nor legal advice, nor a product protocol. It establishes a doctrinal point: a product is not governed only by “more content”, but by an explicit hierarchy across its truth surfaces.

The issue is not to reduce the corpus. The issue is to prevent synthesis from treating as equivalent pages that do not exercise the same authority.


Canonical connectors