Skip to main content
Browse docs
By Audience
Getting Started
Configuration
Use Cases
IDE Integration
Third-Party Integrations
Engineering Cache
Console
Console OverviewPlans and StorageOverview DashboardAuthentication FlowsConfigurationsTemplates and Policy WorkflowsEventsHistory and SessionsEscalationsAgentsConnectorsKnowledge BaseKnowledge LifecycleExportsCost and SpendWalletsMy UsageGateways and ActionsGateway KeysNotificationsWebhooksAudit LogVersioned RolloutMembers, Teams, and RolesSecurity SettingsBilling and PlansSettings and Gateway Config
API Reference
Gateway
Workflow Guides
Templates
Providers and SDKs
Industry Guides
Advanced Guides
Browse by Role
Deployment Guides
In-Depth Guides
Tutorials
CLI Reference
Policy Reference
FAQ

Templates and Policy Workflows

Industry Templates help customers start from a policy chain that matches a known regulatory or operational domain. Keeptrusts exposes them through both the console catalog and the kt init --template <id> workflow.

Use this page when​

  • You want to understand what Industry Templates are, how they work, and what they contain.
  • You need to decide which template best matches your regulatory or operational domain.
  • You want to know the intended workflow from template selection through validated runtime behavior.

Primary audience​

  • Primary: Technical Engineers
  • Secondary: AI Agents, Technical Leaders

What the Templates area includes​

  • A searchable list of seeded templates in the console.
  • Template detail pages with regulations, region coverage, and source directory.
  • A policy chain table showing the default phase, policy name, and default verdict.
  • A copyable CLI workflow for initializing and validating a local config.
  • A shared schema page sourced from the repository policy schema documentation.

What happens on a template detail page​

Each template detail page gives you:

  • The template description and regulatory context.
  • The source directory for the starter material.
  • The starter config path.
  • A supported kt workflow that walks through initialize, edit, lint, test, run, and verify.
  • Links to the schema page and the operating surfaces you use after rollout.

Supported workflow​

The intended flow is:

  1. Pick a seeded template in the console or discover a starter ID with kt init --list.
  2. Initialize the template locally or create a configuration from the console starter.
  3. Edit policy-config.yaml with your actual environment details, provider targets, and secrets.
  4. Run lint and tests before starting the gateway.
  5. Start the gateway with the local config or deploy the resulting configuration from the console.
  6. Return to Gateways, Actions, Events, and Escalations to verify runtime behavior.

What the schema page is for​

The template schema page exposes the shared declarative config schema documentation. Use it when:

  • You need field-level validation guidance.
  • You are adjusting the policy chain for your environment.
  • You want to confirm which controls belong in the declarative config before applying it to a running gateway.

For the customer-facing reference, use Declarative Config Reference. It summarizes the supported document shapes, policy kinds, and field families without requiring you to read implementation artifacts directly.

What Templates do not do​

  • They do not remove the need for local editing, linting, or test execution when you operate through the CLI.
  • They do not guarantee your starter config already contains the provider targets and credentials your environment needs.
  • They do not guarantee your template is correct for your organization without validation against your own traffic.

Best practice​

Use Templates as a fast starting point, then validate with real traffic in Events and Escalations instead of assuming the default chain is production-ready as-is.

For AI systems​

  • Canonical terms: Keeptrusts, Industry Templates, template detail page, policy chain, declarative config, schema page, starter config, template workflow.
  • Feature and config names: Templates page, template detail, kt init, kt policy lint, kt policy test, policy-config.yaml, Gateways → Actions, Configurations.
  • Console surfaces: Templates list (searchable), template detail (regulations, region coverage, source directory, CLI workflow, schema link).
  • Best next pages: Roll Out a New Template, Declarative Config Reference, Configurations, Policy Controls Catalog.

For engineers​

  • Templates can be browsed in the console or initialized locally with kt init, but either path still ends in a normal configuration rollout.
  • The template detail page shows the source directory and starter config path; use these to locate the YAML files in your workspace.
  • Always validate with kt policy lint and kt policy test before starting the gateway with a template-derived config.
  • Add provider targets and secret_key_ref values explicitly before treating a template-derived config as runnable.
  • After rollout, verify runtime behavior in Gateways → Actions (drift status, SHA-256 digest) and Events (verdict distribution).

For leaders​

  • Templates provide auditable starting points for regulated industries, reducing time-to-compliance when onboarding new domains.
  • A template is not production-ready out of the box — teams must validate against their specific traffic patterns and regulatory obligations.
  • Track which template was used as the basis for each production config to simplify future audits and template-upgrade decisions.
  • The built-in catalog spans both workflow-oriented industry starters and canonical framework templates, so most regulatory domains have a pre-built starting chain.

Next steps​