Recipe 2 — Inherit from a Corti Standard via `inheritFromId`

← Back to Customization Cookbook Scenario: 90% of corti-hpi is right but you want family-centred language for a pediatric clinic. The change applies on every call from this clinic. What you do:

Create a section that inherits from the Standard. Pass the Standard’s UUID as inheritFromId; override only the fields you want to diverge.
Wrap it in a template (or create an inheriting template from an existing Standard template) and reference your inheriting section’s UUID in sections[].
Reference your new template from POST /documents using Path 1.

POST /documents/sections — inherit with an instructions override

{
  "name": "HPI (Pediatric)",
  "languages": ["en"],
  "labels": [{ "key": "specialty", "value": "pediatrics" }],
  "specialties": ["pediatrics"],
  "inheritFromId": "<your-section-id>",
  "generation": {
    "instructions": {
      "writingStylePrompt": "Use family-centred language. Refer to the patient as 'the child'. Address caregivers directly only when the source material does."
    }
  }
}

Variation — inherit with a schema override. Keep the Standard’s full prompt machinery (contentPrompt, writingStylePrompt, miscPrompt, heading) but swap the outputSchema to a structured shape your EHR pipeline expects. outputSchema overrides are wholesale — the schema you submit fully replaces the parent’s. See Section Schemas for design patterns.

POST /documents/sections — inherit with a schema override

{
  "name": "HPI (structured)",
  "languages": ["en"],
  "labels": [{ "key": "shape", "value": "structured" }],
  "inheritFromId": "<your-section-id>",
  "generation": {
    "outputSchema": {
      "type": "object",
      "fieldFormat": "{key}\n{value}\n",
      "fields": [
        { "key": "Onset",    "description": "When and how the illness began.",           "value": { "type": "string" } },
        { "key": "Course",   "description": "Progression over time.",                    "value": { "type": "string" } },
        { "key": "Symptoms", "description": "Current symptoms and pertinent negatives.", "value": { "type": "string" } }
      ]
    }
  }
}

When the schema change is structural (e.g. string → object/array), the parent’s writingStylePrompt may conflict with the new shape (“single paragraph” vs. multiple object fields). Override writingStylePrompt in the same inheriting section to keep instructions coherent.

Why this lever: Persistent and versioned. Inherits the Corti Standard’s published configuration on every field you didn’t override — including subsequent (typically silent) Corti improvements to those fields. Auditable — the inheriting section has its own UUID and version history. Caveat — silent upstream updates. Inheritance resolves against the Corti Standard’s published version at request time. Updates to Corti Standards are typically silent: small prompt refinements and quality improvements ship continuously, the same way many small API releases do, without per-change notes. Only clear schema-breaking changes or significant behavior changes are explicitly communicated. If your integration requires staying on a specific behavior, don’t use inheritFromId against the Corti Standard at all — instead, re-create the section (or template) as your own resource by copying the configuration into a POST /documents/sections request without inheritFromId. That decouples you from the Corti Standard entirely; subsequent silent improvements to the Standard will not reach you, and the resource is yours to version.

Previous: Recipe 1 — Use a Corti Standard out of the box · Next: Recipe 3 — Reference Corti Standards + per-call end-user overrides

Documentation Index