Skip to main content

Template Library: Share and Reuse Policy Configurations Across Teams

The template library is useful when your problem is not “how do I write YAML?” but “how do I stop every team from inventing its own baseline?” In Keeptrusts, the Templates page gives you a seeded catalog of supported policy starters, detailed template views, searchable and filterable metadata, and a direct path into Configurations so teams can derive managed configurations from the same starting point instead of copying one-off files around.

Use this page when​

  • Multiple teams need consistent policy baselines for similar workloads or regulated domains.
  • You want to start from a supported template rather than authoring every config from scratch.
  • You need a practical way to reuse policy intent across teams while still versioning local changes separately.

Primary audience​

  • Primary: Technical Engineers and Platform Owners
  • Secondary: Technical Leaders and Program owners

The problem​

Policy drift usually starts with good intentions. One team copies a working config into a new service. Another team removes a policy they think they do not need. A third team tweaks thresholds without documenting why. A month later, everyone is “using the same baseline” except they are not.

That hurts governance in two ways.

First, it makes support and review harder. When a flagged interaction shows up, you need to understand not just the policy concept but the exact local variant running in that environment.

Second, it slows down responsible adoption. Teams either wait for a platform owner to handcraft a configuration, or they start from a blank file and hope their first version is good enough.

The right answer is not to eliminate flexibility. Different teams do need different configurations. The right answer is to standardize the starting point.

The solution​

The Keeptrusts template library provides that starting point.

At the catalog level, the page supports search and filters that reflect how teams actually evaluate policy starters:

  • Search by industry, regulation, or region.
  • Filter by type, including canonical frameworks and industry starters.
  • Filter by region, regulation, category, jurisdiction, and assurance level.
  • Sort by recommended order, name, or regulatory density.

That matters because picking a baseline is usually a governance decision before it becomes a deployment decision.

At the detail level, a template is more than a title and description. The detail view exposes the policy chain defaults, supported metadata such as regulations and deployment profiles, whether the template includes a built-in escalation path, and the starter configuration blocks behind the policy chain.

Most importantly, the page gives you a direct Use this template action. In the current console, that takes you into /configurations/new?templateId=<id>, which means a template is not the final deployment object. It is the managed starting point for a configuration you will still save, version, and deploy through the Configurations workflow.

That separation is exactly right. Templates are shared baselines. Configurations are environment-specific managed records.

Implementation​

The best way to use the library across teams is to standardize on a short baseline workflow.

  1. Open Templates and search for the domain or regulation you need.
  2. Use filters to narrow to the right family of starters.
  3. Open the detail page and review the policy chain defaults, escalation path, and metadata.
  4. Click Use this template.
  5. Land in Configurations, make only the changes that are specific to the target team or gateway.
  6. Save a version with a meaningful change detail.
  7. Deploy and monitor the result.

The detail page is especially helpful before you commit to a baseline. It tells you how many policies are in the chain, which regulations the template covers, whether human review is built in, and what the default execution order looks like. That reduces the old pattern of blindly copying a file and only later discovering that it included a verdict path you did not expect.

The CLI provides the same baseline concept for teams that want to bootstrap locally first:

kt init --list
kt init --template finance --dir ./finance-gateway
cd ./finance-gateway
kt policy lint --file policy-config.yaml

That is a useful companion workflow even when the final rollout happens in the console. A platform team can validate the starter locally, then tell application teams which template family to use in the shared library.

The important organizational pattern is this:

  • The template is shared.
  • The derived configuration is versioned per deployment context.
  • Local changes are recorded as configuration versions, not by forking the shared idea into unmanaged files.

That is how you get reuse without losing accountability.

Suppose your organization runs multiple regulated assistants: one for finance, one for internal legal research, and one for support operations handling personal data.

Without a library, each team might begin from a different historical config. With the library, the platform owner can say:

  1. Finance teams start from the finance template.
  2. Teams handling grounding-sensitive output evaluate the citation-verification or quality-benchmarking templates.
  3. Agentic tool-calling workflows start from the agent-firewall template.

Each team still gets room to adapt the final configuration, but the baseline reasoning becomes consistent.

The template detail view is also useful for review conversations. Because it exposes policy chain defaults and starter config sections, a platform owner can explain why a template is appropriate before anyone deploys it. That is much better than distributing a YAML file and asking teams to trust it.

One practical point is worth stating clearly: the current template library is a supported catalog, not a free-form custom sharing marketplace. The reuse pattern comes from teams starting from the same template and then managing their derived configurations through Configurations. That is still enough to standardize rollout behavior across groups.

This also connects naturally to grounded AI work. A team may start from a compliance or safety template for policy behavior, then pair the resulting configuration with a governed knowledge asset strategy in Knowledge Base when response quality depends on approved internal context.

Results and impact​

Template-driven reuse reduces both drift and startup time. Teams stop beginning with blank YAML or inherited copies of unclear provenance. Platform owners stop re-explaining the same baseline from scratch for each new deployment.

It also makes cross-team reviews easier. If two teams both say they started from the same template family, reviewers can focus on the local differences rather than re-auditing the entire conceptual baseline every time.

This is the practical value of a template library in governance work: not rigid uniformity, but a smaller and more understandable set of variations.

Key takeaways​

  • Templates are shared starting points; configurations are the managed deployment records derived from them.
  • Use the catalog filters to choose a baseline intentionally instead of searching for old YAML by hand.
  • Review policy chain defaults and escalation behavior on the template detail page before deriving a configuration.
  • The Use this template action is the bridge from reusable baseline to versioned configuration workflow.
  • Reuse works best when teams standardize on the same template family and record their local changes as configuration versions.

Next steps​