Text Generation

​

New: Bring-your-own prompts — create sections & templates via API Beta

• Define every aspect of a section. Content instructions, context, writing style, plus a powerful new way to handle formatting that combines presets (list, paragraph, subheadings) with flexible customization options via the typed outputSchema (string, number, boolean, array, object).
• Compose templates from sections. A template adds top-level instructions and references published sections by UUID with an explicit order.
• API-first by design. You steer the section-specific prompts while Corti ensures the overall system prompts for document generation and guardrails continue to play nicely together.
• Versioning & publishing. Iterate freely via POST .../versions; previously published versions stay live until you explicitly publish a new one. Inherit from any existing section or template via inheritFromId — your inheriting resource keeps tracking future Corti improvements on fields you don’t override.

​

New: Guided Clinical Synthesis — POST /documents Beta

1. Plain templateRef — reference a stored template (optionally pin a version). Lightest path, no side-effects, ideal for production traffic.
2. templateRef with runtime overrides — keep your base template and patch a section’s title, instructions or output schema for a single call. A drift-proof, auto-generated template aggregate is persisted with inheritedFromId pointing at the base.
3. Assembly from stored sections — pick the sections you want, in declaration order, and assemble a template on the fly. The resulting aggregate is saved so you can reuse it.
4. Fully inline dynamic template — define the template and every section inline. Sections and the wrapping template are persisted for 30 days as drift-proof snapshots or “receipts” you can turn into permanent resources.

• context array — combine context types in one call, e.g. a referral letter as text + a transcript of the live consultation + a few pre-chart facts items, all shipped to the LLM together. (Classic could not mix types like this.)
• interactionId — let the API pull all non-discarded facts and transcripts already attached to that interaction implicitly. No manual context wiring.

• For clinical notes, this reduces formatting inconsistencies and improves output quality for multi-section documents.
• For advanced use cases, structured, typed outputs unlock much more control over downstream usage — think field-level documentation, structured data pipelines and clinical decision support.
• Drift-proof outputs — every path except plain templateRef snapshots the fully resolved template at request time; subsequent edits to base resources do not affect previously generated documents.

​

New: Foundation for template ownership & permissions Beta

• Corti-provided standards as read-only resources. Corti’s curated sections and templates are returned in LIST /documents/sections and LIST /documents/templates with source: corti and cannot be mutated. Inherit from them via inheritFromId for specialty variants or organization-specific tweaks; future Corti improvements propagate automatically to fields you have not overridden.
• API-client–authored resources. Sections and templates created by an API client are returned with source: user — they belong to the project in Corti Console that your API key is associated with. You hold write, version, publish and delete on these.
• Source-aware list responses. Both list endpoints return your project’s resources alongside Corti Standards in one response. Filter on the source field client-side (corti vs user) to scope a “browse” surface to the curated library or a “my organization” view.
• Server-side filters for narrowing the response. LIST /documents/sections and LIST /documents/templates accept lang (BCP-47), region (ISO 3166-1 alpha-3), specialty, label (key:value format) and published — all repeatable. Use these to narrow by the dimensions your integration actually cares about.
• Labels for finer-grained distribution. Apply Label objects ({ key, value }) to both sections and templates and pass them as ?label=customer:acme on LIST calls — the building block for distributing approved templates to specific customers, departments or workflows at scale.

​

Support for flush and factGenerationInterval Beta

​

Updates: More Descriptive Error Codes

{
"requestid": "<string>",
"status": 123,
"type": "<string>",
"detail": "<string>",
"validationErrors": [
  {}
]
}

​

Updates: Standard Templates and Sections

​

New: Documentation Modes

​

New: Customize existing sections

​

Changes and deprecations to document and template endpoints

​

New, improved documentation guardrails!

• We have re-architected our documentation guardrails to be faster and more accurate.
• Documentation guardrails are the by default automatic step that quality-controls the generated document to correct outputs ungrounded in the source input.
• In this re-architected, new approach, we in parallel for each section identify hallucinations and provide targeted fixes by reference (sentence/segment index), preventing mismatched edits and skipping ambiguous duplicates. The result is format-preserving precise, auditable corrections that deliver safer, more trustworthy clinical summaries.

​

Reduced token usage for text generation

​

New endpoint to extract facts from a provided text string input now available!

• so far FactsR™ was dependent on streaming audio over WSS to extract facts
• this new endpoint facilitates a REST endpoint as alternative to extract facts

• atomic endpoint, not part of interaction collection
• output is not stored into Corti database (zeroRetention is the only default)

• Improve handling of sections that do not have content generated so that an empty string is returned instead of a placeholder (e.g., <empty>).
• Fix to issue causing json text to be included in note output.
• nfc: Improve logging and exception handling in LLM hallucination guardrails service.

​

Introducing a new foundation for clinical AI, built not just to document care, but to support it: FactsR™.

​

New: Corti default templates