Recipe 6 — Inherit from your own sections to scale across customers/departments

← Back to Customization Cookbook Scenario: You have a working your-hpi section. Customer A wants telegraphic. Customer B wants narrative. Customer C wants narrative plus every line prefixed with a department code. The base content rules should stay shared — only the writing/format diverges. What you do:

Keep your-hpi as the canonical base. Don’t change it for the variants.
Create variant sections via POST /documents/sections with inheritFromId: <your-section-id> and override only the diverging fields (e.g. writingStylePrompt, itemFormat, outputSchema).
Compose customer-specific templates that reference the appropriate variant for each customer.
Route the request to the correct customer template based on tenant/customer context in your product.

POST /documents/sections — variant inheriting from your own canonical section

{
  "name": "HPI (Customer C — telegraphic)",
  "languages": ["en"],
  "labels": [
    { "key": "customer", "value": "customer-c" },
    { "key": "style", "value": "telegraphic" }
  ],
  "inheritFromId": "<your-section-id>",
  "generation": {
    "instructions": {
      "writingStylePrompt": "Telegraphic; no narrative; clinical abbreviations preferred."
    }
  }
}

Why this lever: Improvements you make to the canonical your-hpi (better contentPrompt, refined outputSchema) propagate to every customer variant for every field they didn’t override. You don’t have to update three sections — you update one, and the inheriting variants track. Caveat: Watch the outputSchema override rule — providing an outputSchema on an inheriting section fully replaces the parent schema; it is not a partial merge. If a variant overrides the schema, parent schema improvements stop propagating to that variant’s schema. See Create a Section — override semantics.

Use labels aggressively in this recipe. Tag each variant with a key:value label such as { "key": "customer", "value": "customer-c" } so your LIST /documents/sections?label=customer:customer-c discovery surface stays clean. The specialties field is the right place for clinical-specialty tags — labels is for free-form business tags.

Previous: Recipe 5 — Your own sections & templates + end-user runtime overrides · Next: Recipe 7 — The full stack

Documentation Index