A cookbook stays current when product releases trigger named checks and every recipe has an owner, last-tested receipt, support status, and retirement path.
Assign ownership at the recipe level
Give each recipe a product owner for behavior, a technical owner for the runnable artifact, and an editorial owner for public clarity. One person may hold several roles, but the responsibilities should remain explicit. Record the latest tested product, SDK, runtime, and recipe versions near the top so readers do not have to inspect package files to discover the support state.
Define release triggers before the next change arrives. Triggers can include an API revision, SDK release, authentication change, framework major version, deprecation notice, or repeated support issue. A trigger opens a review; it does not automatically overwrite public guidance. The current recipe stays published, receives a visible hold, or retires according to the buyer's release policy.
Retest from the reader's starting point
Run the documented setup from a clean checkout and a newly provisioned or reset test account. A maintainer's cached dependencies, existing resources, and elevated permissions can conceal missing steps. Continuous jobs help detect drift, but an account-dependent workflow may still need a scheduled human run. Preserve logs and expected-output assertions without retaining private credentials or customer data.
ReadMe's plan descriptions include changelogs, branches and reviews, recipes, and reusable content, reflecting a commercial documentation category built around controlled updates rather than static pages. Those features do not maintain a recipe automatically. Link the cookbook change to the product release, passing receipt, migration note, and approval so reviewers can see why the guidance changed.
Retire without erasing history
When a path is no longer supported, add a retirement date, affected versions, replacement recipe, and migration note. Keep the final tested receipt available to internal support even if the public page redirects. If there is no replacement, say so plainly. Silently editing an old recipe makes it difficult to diagnose customers whose implementation followed an earlier supported path.
Integration Atlas supplies the first release and maintenance runbook through Reality Contact, LLC. The buyer owns release notifications, product decisions, ongoing access, and public approval. Continuing retests are a separate engagement after the written maintenance period. The cookbook records known compatibility at named versions; it cannot promise permanent compatibility across future provider, SDK, framework, or operating-system changes.
Where the service stops
Reality Contact, LLC writes, tests, and packages integration documentation but does not certify the underlying product, guarantee compatibility with untested environments, operate production accounts, provide ongoing support outside the written period, or decide which product behavior the buyer promises. The buyer supplies safe access and the authoritative product contract, chooses the supported environments, resolves product ambiguities, approves each public recipe, and assigns an owner for future release-triggered maintenance. This developer-documentation and example-testing work does not replace the buyer's engineering, security, legal, compliance, or production-operations review, and it is not a promise that every customer environment will behave the same way. The buyer approves public product statements, supported combinations, credentials policy, and release status before any recipe is published.
Sources: ReadMe product pricing and documentation workflow features; GitHub documentation for dependency version updates.