Berk Durmuş

Good security is mostly disciplined pruning. Every additional parameter is a new branch where something can break, be misused, or be attacked. The fastest way to improve safety is to shrink the surface area—especially the number of knobs operators can tweak at runtime.

Let ( P ) be the count of user-facing parameters and ( V ) the number of valid states per parameter. The configuration space is ( V^P ). Even with small ( V ), growing ( P ) explodes the number of states you must test, document, monitor, and defend. More states → more misconfigurations → more incidents.

In healthcare systems this gets expensive fast: every parameter multiplies the number of paths that can impact patients and providers.

Problems accumulate quickly when options multiply. Individually safe flags can combine into unsafe states. Environments drift apart until debugging becomes guesswork. Innocent‑looking switches accidentally bypass rate limits, guardrails, or auditing. And operational load rises because the system now depends on tribal knowledge of nine different toggles.

Favor capability over configuration: offer a safe verb rather than a toolbox of tunables—for example, a

mode

deterministic

creative

instead of raw

temperature

top_p

, and

top_k

. Reveal options progressively with sensible defaults, and put advanced switches behind an explicit “advanced mode” with warnings and audits. Constrain values with enums, ranges, and schemas so invalid states are unrepresentable. Default to safety with least‑privilege roles, input allowlists, and output filters. Make operations idempotent so retries don’t amplify risk, and treat high‑risk changes as one‑way doors that require review or a time delay.

Bad surface (5+ tunables encourages fragile behavior):


ts
invokeLLM({
  prompt, temperature, top_p, top_k, presence_penalty, frequency_penalty,
  max_tokens, stop, system, tools, toolChoice
});

Safer surface (capability + policy, not raw knobs):


ts
invokeStructuredTask({
  prompt,
  mode: "deterministic",          // or "creative"
  policy: "clinical_note_summarize", // enforces schema + allowlists
  maxOutput: "short",              // bounded outputs
});

Under the hood you still tune parameters—but privately, in code, with tests and audits. Users choose intent; the system chooses safe parameters.

In healthcare, schema‑first workflows pay off: parse inputs into typed objects and reject free text for critical paths. Allowlist tools so each step has only the capabilities it needs—no raw web or shell access by default. Keep outputs bounded as summaries, codes, or structured fields rather than free‑form paragraphs for decision‑making steps. Add human‑in‑the‑loop checkpoints when uncertainty rises or actions carry high impact. And observe everything by default with structured logs for inputs, outputs, decisions, and overrides.

Flexibility and safety can coexist. Ship a small, safe default surface that covers most cases. For the rest, offer an explicit advanced interface behind feature gates and audit trails. When someone does override the defaults, capture a brief reason and have those overrides expire automatically.

Before adding another parameter, ask a few questions. Does it expand capability or merely shape output? Could a discrete mode replace a continuous slider? What happens at extremes, and are those outcomes bounded? Can types and schemas make invalid states impossible to represent? And, if nobody reads the docs, is the default still safe?

Security, reliability, and velocity are all functions of simplicity. Reducing parameters reduces blast radius, shortens incident timelines, and makes outcomes more predictable—especially in clinical contexts. Start by removing one knob. Then another. The safest system is the one with the fewest ways to use it wrong.