System prompt catalog
This catalog is the public map of developer-controlled AI instructions in getbased. It covers literal system prompts, runtime system fragments, and app-authored task prompts that are deliberately sent in the user role for multimodal or local-model compatibility.To start with a button or action in the application, use Find a prompt by feature. It shows what getbased adds, what data accompanies the request, and links directly to the readable prompt text below.
Browse the catalog
Chat and retrieval
Base chat, dynamic context, personalities, discussion, continuation, summaries, and Knowledge Base query rewriting.
Import and extraction
Lab reports, PII rewriting, supplements, EMF reports, and light-device specification extraction.
Insights and reports
Dashboard, report, Biology Score, supplement, EMF, and marker-description prompts.
Light and Sun
Shared hardware guardrails and all ten Light & Sun verdict prompts.
Scope
Included:- every non-empty
systemvalue supplied to the shared AI router; - system-prompt fragments appended at runtime;
- developer-authored task instructions sent as user-role content;
- app-authored chat-message templates that an explicit UI action prefills or sends;
- automatic continuation and discussion messages that the app inserts;
- dynamic prompt contracts whose rendered text depends on schemas, marker catalogs, allowlists, or selected context.
- a user’s own chat message;
- the user’s own text, including edits they make to an app-authored starting message;
- provider capability probes such as the one-token
hirequest; - voice transcription and speech-synthesis payloads, which send audio or text plus model, language, and voice settings but no developer prompt;
- transport formatting that only maps the same instruction to a provider API;
- deterministic scoring formulas, schemas, and context data that do not instruct a model.
chat.prefills as user messages rather than separate privileged instructions.
Complete registry
Trust and assembly model
callClaudeAPI() is a provider-neutral router. The caller owns the instruction and context; transports do not invent a new medical persona.
[section:untrusted-profile-context] is documentation for the model, not a security boundary by itself. The parser, allowlists, normalization, review UI, and deterministic code remain the enforcement boundary.
Review workflow
1
Identify the contract
Record the catalog ID, source identifier, instruction position, runtime placeholders, expected output, parser, and fallback.
2
Build adversarial fixtures
Cover ordinary input, missing data, contradictory data, stale data, embedded instructions, sensitive data, demographic edge cases, and a small local model.
3
Review seven dimensions
Evaluate factual grounding, medical scope, bias and assumptions, prompt-injection resistance, privacy minimization, output compatibility, and cost/context size.
4
Change source and docs together
Update the literal or builder, the relevant catalog page, and focused contract tests. Do not patch only the rendered copy.
5
Compare behavior
Use fixed inputs and judge both regressions and intended improvements. Structured surfaces must also test malformed, extra, and partial output.
Required review questions
Change proposal template
Exact user health data and provider credentials do not belong in issues, fixtures, snapshots, or prompt documentation. Use synthetic examples.