How this documentation is generated

1A release goes out

The trigger is a release, not a merge. By the time a team cuts one they have already decided the work ships, and several teams here already mark which of their releases are external — so the signal exists before the pipeline does.

A GitHub Action in the service repository fires on release and collects the release notes, the diff since the previous release, and the two files below.

2The repository says how its own domain is documented

Each repository with public documentation carries a file describing its own conventions: which pages in the docs site correspond to it, the vocabulary it uses, and what may never be exposed.

# .continuous-docs.yml — id-verification-service
owns:
  - knowledge-base/idv/**
  - api-reference/workflow-api.md
never_expose:
  - the identity of document, biometric and eID vendors
  - internal queue names and service topology
prefer:
  "vendor SDK upgrade": "expanded document recognition coverage"

Putting this beside the code matters. A central policy is one that nobody outside the docs team ever reads, and the people who know that a vendor name is commercially sensitive are the people working in that repository.

3The OpenAPI spec is regenerated in the same release

The API reference is downstream of the service's source: controllers and DTOs are annotated in place, and those annotations generate the spec that renders the reference.

Regenerating it as part of the release means the machine-readable surface never lags the release that changed it. CI already enforces the other half of this — a pull request whose committed spec no longer matches what the code produces fails the build.

 "paths": {
   "/v1/workflows/{id}/steps": {
     "post": {
       "requestBody": { "schema": { "properties": {
         "type":          { "type": "string", "enum": ["document", "selfie", "aml"] },
+        "livenessCheck": { "type": "boolean", "default": false,
+                           "description": "Require an active liveness check on the selfie step." },

One property added, nothing removed or renamed: an additive, non-breaking change.

4Customer impact is extracted, and an agent drafts the change

The release notes are the input, because they are already written for an audience rather than for a commit log. An agent reads them together with the diff and the repository's conventions file, and returns a structured verdict before it writes any prose:

{
  "customerVisible": true,
  "changes": [
    "New optional request field `livenessCheck` on workflow steps",
    "Document recognition coverage expanded (vendor SDK upgrade)"
  ],
  "ignored": [
    "WorkflowRepo split into three classes — no behavioural change, no public surface"
  ],
  "pages": ["knowledge-base/idv/session-management-and-configuration.md"],
  "confidence": 0.86
}

The disclosure rules are applied before the prose is written, not scrubbed out afterwards:

The second bullet is the test. The release upgraded a named vendor SDK; the entry says what the customer gains and names nobody.

5A pull request is opened here, not there

The change lands in the documentation repository rather than in the service, so the reviewer reads prose rather than a diff of somebody else's implementation.

The pull request body is generated too, and written for the reviewer rather than the customer — what was detected, what was ignored, which pages changed, and how confident the filter was about each.

6The branch builds a preview

The rendered page is read before anyone outside sees it.

This is the smallest gap in the whole design: the site build already runs on every push, it is simply not wired to pull requests yet.

7Merge, and it is live

A GitHub Action builds the site and publishes it. The page is live within about a minute.

This step already works. It is how the page you are reading reached you.