Brinpage

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:

json
{
  "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.

javascript
// 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).