Skip to content

docs(guardrails): document the source-precedence ladder#151

Merged
initializ-mk merged 2 commits into
mainfrom
docs/guardrails-precedence
Jun 11, 2026
Merged

docs(guardrails): document the source-precedence ladder#151
initializ-mk merged 2 commits into
mainfrom
docs/guardrails-precedence

Conversation

@initializ-mk

Copy link
Copy Markdown
Contributor

Summary

Extends `docs/security/guardrails.md` § Architecture with a five-row precedence table mapping each config-source trigger to its outcome and what happens to lower-priority sources. Source-truth: `forge-cli/runtime/guardrails_loader.go:BuildGuardrailChecker`.

Why

The previous one-line summary (`Priority: FORGE_GUARDRAILS_DB env → guardrails.json → built-in defaults`) obscures three things operators reliably ask about:

  1. DB-mode failure is non-fatal — connect / ping errors fall back to file mode with a warning, not a hard exit. Misconfigured URIs become silent posture degradation unless someone watches the log.
  2. `guardrails.json` is still in the image even when DB mode is the runtime choice — the file is copied at build time, the runner just doesn't open it when `FORGE_GUARDRAILS_DB` is set. Toggling the env var at deploy time flips the mode without rebuilding.
  3. The fifth row (NoopGuardrailChecker) that fires when engine construction errors after a source was already picked. This is the "everything passes through" failure mode and was completely undocumented.

Changes

  • One section added to `docs/security/guardrails.md`: § Architecture / Source precedence
  • 5-row precedence table covering: DB-mode success, DB-mode failure → fallback, file-mode success, file-mode missing/invalid → defaults, engine-construction failure → noop
  • Follow-up notes covering: env-toggle without rebuild, non-fatal DB failure, FORGE_ORG_ID requirement, `cfg.GuardrailsPath` scope, and divergent audit sinks per mode

Test plan

  • Intra-doc anchor links resolve
  • No code touched, no tests required

… config

The doc previously said "Priority: FORGE_GUARDRAILS_DB env →
guardrails.json → built-in defaults" in one line and called it done.
That obscures three things operators reliably ask about:

1. DB-mode failure is *non-fatal* — connect/ping errors fall back to
   file mode with a warning, not a hard exit. Misconfigured URIs
   surface as silently-degraded posture unless someone is watching
   logs.
2. `guardrails.json` is still copied into the image even when DB mode
   is the runtime choice. Toggling FORGE_GUARDRAILS_DB at deploy time
   flips the mode without a rebuild — easy to forget when shipping
   "DB-only" deployments.
3. There's a fifth row (NoopGuardrailChecker) that fires when engine
   construction errors after the source was already picked. This is
   the "everything passes through" failure mode and was completely
   undocumented.

Replaces the one-liner with a five-row table mapping each trigger to
its outcome and the fate of lower-priority sources. Adds a follow-up
notes block covering the bypass semantics, the FORGE_ORG_ID
requirement, the cfg.GuardrailsPath scope, and the divergent audit
sinks across modes. Source: forge-cli/runtime/guardrails_loader.go.

No code changes — pure documentation.
…erence

Adds the missing pieces to the guardrails reference doc:

1. Library link in the opening paragraph — names github.com/initializ/
   guardrails, pins the version (v0.12.0 from forge-cli/go.mod), and
   points at models/config.go as the authoritative type definition.
   Operators reading this doc now know where the schema lives instead
   of having to grep the codebase.

2. A new "Full guardrails.json Schema" subsection enumerating all ten
   top-level blocks supported by models.StructuredGuardrails — five of
   them (moderation, urlFilter, approvalGates, nsfwText, hallucination,
   skillConstraints) were previously undocumented even though the
   library accepts them and they round-trip into MongoDB's AgentConfig
   in DB mode.

3. Per-block JSON snippets + field-level tables covering type,
   purpose, and value vocabulary. Reflects the actual struct tags in
   the pinned library version.

4. A compatibility notes block calling out:
   - what forge init bootstraps vs. what's accepted but not generated
   - omitted-key == disabled semantics
   - camelCase + bson tags round-tripping between file mode and DB
     mode without translation

Reinforces that both file-mode guardrails.json and DB-mode AgentConfig
share one schema, so an operator who learns one knows the other.

Stacks on the precedence-table commit (634997d) in the same docs PR.
@initializ-mk initializ-mk merged commit 16febf3 into main Jun 11, 2026
10 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant