Skip to main content
Beta ← Back to Customization Cookbook Scenario: Standards don’t cover what you need — a specialty-specific section, a structured output schema for an EHR pipeline, or a writing style your clinicians have a strong opinion on. You want a curated, stable library that your product references on every call. What you do:
  1. Author each section via POST /documents/sections. Use Section Schemas as a design reference.
  2. Compose them into a template via POST /documents/templates.
  3. Publish versions explicitly (POST .../versions/{versionID}/publish). Iterate freely; the previously published version stays live until you publish a new one.
  4. Reference your template from POST /documents Path 1.
POST /documents/templates — compose your own sections
{
  "name": "Allergy follow-up note",
  "languages": ["en"],
  "labels": [
    { "key": "specialty", "value": "allergy" },
    { "key": "visit-type", "value": "follow-up" }
  ],
  "generation": {
    "instructions": {
      "prompt": "Produce a focused allergy follow-up note. The patient is known to the clinic; do not restate baseline history."
    },
    "sections": [
      { "sectionId": "<your-section-id>", "orderIndex": 0 },
      { "sectionId": "<your-section-id>", "orderIndex": 1 },
      { "sectionId": "<your-section-id>", "orderIndex": 2 }
    ]
  }
}
Why this lever: Full control. Versioned and publishable. Every clinician on every call sees the same output structure. Caveat: You own the prompts now. Schedule periodic reviews against new Corti Standards — sometimes the standard library catches up to your custom variant and you can simplify by switching to inheritance (Recipe 2).
Previous: Recipe 3 — Reference Corti Standards + per-call end-user overrides · Next: Recipe 5 — Your own sections & templates + end-user runtime overrides