Skip to main content
Beta ← 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:
  1. Create a section that inherits from the Standard. Pass the Standard’s UUID as inheritFromId; override only the fields you want to diverge.
  2. Wrap it in a template (or create an inheriting template from an existing Standard template) and reference your inheriting section’s UUID in sections[].
  3. Reference your new template from POST /documents using Path 1.
POST /documents/sections — inherit with an instructions override
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
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