AI generation & authoring

AI can author a whole flow for you — and it never authors a live clinical screen. In Flows, every step belongs to one of two planes. AI and the clinic freely write the presentation plane. The clinical plane comes only from neolife's certified questionnaire corpus, and a licensed provider approves it before publish. AI drafts, a licensed provider signs. That split is what lets a flow carry a certificate at all.

The two planes, as the AI sees them#

Everything AI writes lands in one of two buckets, and the buckets have different rules:

Plane	What lives here	Who may author it	Gate
Presentation	Landing copy, outcome/thank-you copy, theme tokens, the marketing quiz, A/B variants	AI and the clinic, freely	None — copy is copy
Clinical	Medical questions, disqualifiers, consent blocks	Only the certified corpus	A licensed provider approves before publish

AI generation never mutates a live clinical screen in place. When a flow needs a medical gate, AI selects a certified questionnaire from the corpus — it does not rewrite the questions. The clinical plane a patient answers is always a version-pinned, provider-approved question set, and the flow records its hash at publish. That hash is the moat: it's why the PHI boundary holds and why the certificate means something.

Rule: AI writes what a patient reads, never what a provider is accountable for. The presentation plane sells; the clinical plane screens; only the second one is signed.

Describe your program#

The fastest way to build a flow is to describe the program in plain language and let AI assemble it. It matches your description to a certified questionnaire, then writes the landing copy, outcome copy, and a theme to match.

curl -X POST https://api.neolife.health/v1/flows/ai/generate \
  -H "Authorization: Bearer $NEOLIFE_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "description": "A hair-loss program for men, calm and clinical, forest-green brand",
    "productName": "Regrow"
  }'

Field	Type	Notes
description	string	Plain-language description of the program and tone.
productName	string	Optional product/brand label for copy.

AI returns a draft flow: a matched certified questionnaire for the clinical plane, generated landing and outcome copy for the presentation plane, and a theme of --nl-flow-* tokens. Nothing is live yet — the draft opens in the form-based editor for you to adjust, and it still has to clear provider approval before it can publish. Requires the flow_ai_generation flag (open on every tier, including Pilot).

Because AI only selects the clinical plane here, the certificate a patient earns is identical to the one they'd earn answering that questionnaire anywhere else on the rail. The flow is a new front door onto an existing, already-certified gate.

When the corpus doesn't cover the product#

The corpus wraps 22 questionnaires. For a genuinely new product it doesn't cover, AI can draft a full questionnaire in the certified schema — but this is the one place AI touches clinical content, so it is fenced on every side.

curl -X POST https://api.neolife.health/v1/intake/questionnaires/ai-draft \
  -H "Authorization: Bearer $NEOLIFE_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "productName": "…",
    "clinicalContext": "…"
  }'

Three fences, all of which must clear:

1. A counsel-gated flag. The endpoint is dark unless flow_ai_freeform_medical is on for your tenant. It ships off; turning it on is a deliberate, counsel-reviewed decision, not a default.
2. A deterministic validator. The draft is run through the same schema validator that gates any human-authored questionnaire — structure, required disqualifiers, consent blocks, answer types. A draft that doesn't validate can't advance. No model sits in this check; it's a pure function of the draft.
3. A licensed provider approves it. The draft is inert until a provider with prescribing licensure signs it.

curl -X POST https://api.neolife.health/v1/intake/questionnaires/quest_123/approve \
  -H "Authorization: Bearer $NEOLIFE_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{ "note": "Reviewed disqualifiers and consent; approved for use." }'

Only after approval does the draft become a usable certified tenant questionnaire — a first-class member of your corpus that any future flow can select. The provider, not the model, is the author of record.

AI drafts a full questionnaire; a deterministic validator gates it; a licensed provider signs it. Same order, every time. The model proposes clinical content — it never ratifies it.

Approval gates publish, not draft#

Authoring and publishing are different acts, and the licensure gate sits on publish. You can draft, edit copy, retheme, and reorder steps all day without a provider in the loop — none of it is patient-facing. The moment you publish, the clinical plane's hash and the approving provider are recorded together as a flow approval certificate, and FLOWS_PUBLISH is enforced as the clinical/licensure act it is.

So the AI's output is always a proposal. A generated flow, a matched questionnaire, an AI-drafted questionnaire — each waits behind a human sign-off before a patient can reach it. See Flows for the full publish lifecycle and the certificate it records.

A/B variants stay in the presentation plane#

AI can also draft experiment variants — different landing headlines, different outcome copy, a different theme. By construction, a variant can only change the presentation plane. It cannot alter a clinical question, a disqualifier, or the consent block, so the certificate is byte-identical across every arm of an experiment.

That's not a policy you have to trust; it's a shape the schema enforces. Because arms can't diverge clinically, you can compare control-vs-variant qualify rates cleanly, and the analytics stay PHI-free-by-construction — analytics that cannot leak PHI, by schema, not by policy.

Everything runs offline#

Both AI paths — flows/ai/generate and intake/questionnaires/ai-draft — run against a deterministic stub when no model is configured. Drafts are reproducible, tests are hermetic, and a demo in NEOLIFE_MODE=demo never depends on a live model. The rest of the flow — validation, provider approval, publish — is deterministic regardless.

Next steps#

• Flows — the two-plane model, the builder, and the publish lifecycle.
• Intake & provider approval — the certified questionnaire and certificate the clinical plane reuses.
• The PHI boundary — why the flow's events and analytics carry no patient data.