Skip to main content
The capture policy is the first line of defense between your process and Boundary’s ingest endpoint. It decides which fields on a BoundaryLogEvent actually get serialized.

​
The five buckets

createBoundaryLogger({
  capture: {
    inputs:   false,  // raw LLM prompt you sent                      (default: off)
    outputs:  false,  // raw LLM response you received                (default: off)
    repairs:  true,   // repair messages generated on failure         (default: on)
    errors:   true,   // failure category + rule/schema issues        (default: on)
    metadata: true,   // contract name, attempts, duration, ok flag   (default: on)
  },
});
Defaults are conservative. Raw prompts and completions are the most sensitive payload in an LLM pipeline — they stay off until you explicitly opt in.

​
Field-to-bucket mapping

Every field on the wire format BoundaryLogEvent is gated by exactly one bucket:
FieldBucketShown by default
contractName, environment, timestampalwaysyes
attempt, maxAttempts, ok, durationMsmetadatayes
model, rulesCountmetadatayes
sdk (name, version, runtime)alwaysyes
category, issueserrorsyes
repairsrepairsyes
inputinputsno
outputoutputsno
metadata is treated as always-on — the base identity and run stats are the minimum useful payload. If you need to disable everything, don’t wire a logger at all.

​
Why raw input/output defaults to off

  • User prompts contain customer data, PII, and internal context.
  • Model completions contain proprietary business logic (lead scores, financial calcs, medical reasoning).
  • Both can contain credentials echoed back by the model.
Turning them on is a deliberate operational decision. When you do:
  1. Enable them only in staging or development, not in production, until you’ve audited what actually flows through.
  2. Pair with redaction rules that match your data shape.
  3. Or use beforeSend to hash / summarize the input before it leaves.

​
Opt-in recipe: debug staging traffic

const logger = createBoundaryLogger({
  apiKey: process.env.BOUNDARY_API_KEY,
  environment: "staging",
  capture: {
    inputs: true,
    outputs: true,
  },
  redact: {
    fields: ["email", "phone", "ssn"],
    patterns: [
      /\b\d{3}-\d{2}-\d{4}\b/,                 // SSN
      /[\w.+-]+@[\w-]+\.[\w.-]+/,              // email
    ],
  },
});

​
Opt-out recipe: no failure details

If your failure strings themselves contain PII (rare — but possible when a rule interpolates record values into the error message), turn errors off: 
createBoundaryLogger({
  capture: {
    errors: false,  // drops category + issues from every event
  },
});
You’ll still see ok: false and the attempt count. You just lose the per-rule breakdown on the dashboard.

​
Order of operations

Capture runs first — anything it strips cannot be resurrected downstream.

​
See also

Redaction

Fields, patterns, custom per-leaf scrubbing

beforeSend

Per-event transform or drop

BoundaryLogEvent

Full wire format