Config
Config is how you make Brinpage predictable in production. Instead of “every request is a brand new prompt,” you define defaults and guardrails: routing rules, retrieval behavior (RAG), model preferences, timeouts, and safe overrides.
Two layers of configuration
- Workspace defaults: global settings you manage in the Platform panel.
- Per-request overrides: optional fields your backend can pass for a single call.
The goal is simple: stable defaults + controlled overrides.
What belongs in Config
- Routing: which provider/model to prefer, fallbacks, and policies.
- RAG defaults: tag strategy, retrieval depth, similarity thresholds.
- Safety & boundaries: system instructions, forbidden actions, tool permissions.
- Operational behavior: timeouts, retries, max payload sizes, debug flags.
Defaults vs overrides
In production, you want most requests to run on the defaults. Overrides are useful for: testing, migrations, A/B checks, or special-case flows (e.g. stricter RAG).
Rule of thumb
Expose overrides only from your backend, and only the few knobs your product actually needs. Don’t let the browser set provider/model directly.
A practical config checklist
The exact field names depend on your workspace setup, but the configuration surface usually maps to these categories:
{
"routing": {
"provider": "…",
"model": "…",
"fallbacks": ["…"],
"maxTokens": 0,
"temperature": 0
},
"rag": {
"tags": ["…"],
"k": 0,
"minScore": 0
},
"runtime": {
"timeoutMs": 0,
"retries": 0,
"stream": false,
"debug": false
},
"policy": {
"system": "…",
"tooling": { "enabled": false, "allow": ["…"] }
}
}Think of this as a mental map: routing + rag + runtime + policy.
What to expose to your app (recommended)
- tags (RAG scope): user selects “area” / “module” → you set tags server-side.
- k / minScore (RAG tuning): for internal tools, not end-user products by default.
- debug: only for admin users / staging environments.
- stream: only if you implement streaming UI and can handle partial responses safely.
Anti-patterns (avoid)
- Letting the browser set provider/model directly.
- Shipping your license key to the client.
- Exposing raw debug traces to end users (it leaks internal context and increases attack surface).
- Using overrides as a “configuration system” instead of storing stable defaults in Platform.
Example: safe server gateway
Your backend receives a request, maps user inputs to a small set of allowed config knobs, and calls Brinpage.
// PSEUDO: server-side only
// - do NOT accept provider/model directly from the client
// - map client inputs → allowed tags / allowed retrieval knobs
const allowedTags = new Set(["product", "policy", "faq", "docs"]);
function sanitizeTags(tags) {
if (!Array.isArray(tags)) return [];
return tags.filter((t) => typeof t === "string" && allowedTags.has(t));
}
export async function handleAsk(req, res) {
const { question, tags } = req.body || {};
const safeTags = sanitizeTags(tags);
const payload = {
question,
// safe overrides only:
tags: safeTags,
// optionally:
// k: 6,
// minScore: 0.18,
// debugEcho: false,
};
// server calls Brinpage with Authorization: Bearer <license>
// return only the fields your app needs
}When you reshare the private technical PDF, I’ll replace the pseudo sections above with the exact public field names and endpoint references (no guessing).