8. Shared Model Configuration

Shared model configuration

Create an application-owned src/guard.config.ts:

import { defineGuardConfig } from "@intflows/genkit-guard";
export default defineGuardConfig({
  models: { extractor: "Xenova/all-MiniLM-L6-v2" },
  intent: { semantic: {
    threshold: 0.7,
    intents: { integration: "Azure Blob Storage, APIs and integration workflows" }
  } },
  pii: { mode: "classifier", model: "openai/privacy-filter", reversible: true }
});

Use it in both call sites:

import { guard, initGuard } from "@intflows/genkit-guard";
import guardConfig from "./guard.config.js";
await initGuard(guardConfig);
// ai is your configured Genkit instance.
const response = await ai.generate({
  prompt: "How do I integrate with Azure Blob Storage?",
  use: [guard(guardConfig)]
});

The helper returns the supplied configuration. You can also use satisfies GuardConfig. There is no global registration or automatic file discovery. Import the same object into both APIs. Different flows can use independent configurations.

Compatibility

Existing inline models.extractor, pii.model, pii.mode and no-argument initialization remain supported. Defaults remain MiniLM for intent and BERT NER for PII. Explicit classifier mode defaults to openai/privacy-filter. Custom extractors affect runtime intent scoring as well as startup. Shared GuardConfig values are accepted by native guardMiddleware as well as guard.

For a per-flow override, merge nested objects explicitly:

const flowConfig = {
  ...guardConfig,
  pii: { ...guardConfig.pii, model: "your-org/your-pii-model" }
};
await initGuard(flowConfig);
const middleware = guard(flowConfig);

See 5.-PII-Guard for label mappings and model requirements. Preload the same effective configuration that you use at runtime.

See 11.-Framework-Compatibility for legacy/native middleware behavior and 12.-Security-and-Operational-Errors for startup and request failure handling.