Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.truthlocks.com/llms.txt

Use this file to discover all available pages before exploring further.

Enforce compliance rules, trust requirements, and security policies across your ecosystem. Policies apply to three categories: MINT, VERIFY, and BUNDLE_EXPORT.
Looking to set up rule-based policies from the console or API? See the issuance policies guide for creating, managing, and simulating policies without writing code.

​
Policy Templates

B2C - Consumer

Consumer-focused policy with trust disclosure and risk protections. - Issuer must be in trusted status - Trust tier must be verified_org or higher - Block high/critical risk issuers - Key must be active

B2B - Enterprise

Business-to-business with industry requirements and key rotation. - Issuer must be in trusted status - Finance/Healthcare require regulated_issuer tier
  • Key rotation required every 180 days - Governance approvals for status changes

B2G - Government

Government-grade policy with strict compliance requirements. - All attestations require regulated_issuer tier - Block medium or higher risk issuers - Key rotation required every 90 days - Mandatory documented revocation reasons

B2B2C - Hybrid

Hybrid policy for enterprise-to-consumer scenarios with dual disclosure. - Issuer must be in trusted status - Trust tier must be verified_org or higher
  • Privacy protection: payload not stored - Consumer-friendly + enterprise audit details

​
Usage

import { EnterprisePolicyEngine, templates } from "@truthlock/policy";

// Create engine with B2B template
const engine = new EnterprisePolicyEngine(templates.B2B);

// Evaluate policy
const result = engine.evaluate({
  tenant_id: "tenant-uuid",
  issuer_current: {
    id: "issuer-uuid",
    status: "trusted",
    trust_tier: "verified_org",
    risk_rating: "low",
    jurisdiction: "US",
    assurance_level: "standard",
  },
  key: {
    kid: "key-1",
    status: "ACTIVE",
    valid_from: "2024-01-01T00:00:00Z",
    age_days: 30,
  },
  context: {
    request_type: "mint",
    industry: "technology",
  },
});

if (!result.allowed) {
  console.log("Denied:", result.code);
  console.log("Reason:", result.compliance_explanation);
}

​
Policy Result

interface PolicyResult {
  allowed: boolean;
  code: string; // e.g., "ISSUER_NOT_TRUSTED"
  reason: string; // Human-readable reason
  compliance_explanation: string; // Compliance-friendly explanation
  disclosures?: {
    type: "warning" | "info" | "critical";
    message: string;
    audience: "consumer" | "enterprise" | "all";
  }[];
}

​
Policy Versioning

Each policy instance has a unique hash computed from the template and rules. This hash can be stored with attestations for audit purposes. 
const engine = new EnterprisePolicyEngine(templates.B2G);

console.log("Policy hash:", engine.getPolicyHash());
// => "a1b2c3d4e5f6g7h8"

console.log("Policy version:", engine.getPolicyVersion());
// => "1.0.0-1704067200000"

​
Policy categories

CategoryApplies to
MINTAttestation minting requests
VERIFYVerification requests
BUNDLE_EXPORTProof-bundle export and data-portability requests
BUNDLE_EXPORT policies are evaluated whenever a user or API client requests a proof bundle download or submits a data-portability export. Use them to restrict exports by jurisdiction, trust tier, risk rating, or any other field available in the evaluation context. See export control policies for examples.

​
Policy lifecycle

Every policy has a status that controls enforcement:
StatusBehavior
DRAFTSaved but not enforced — use while iterating on rules
ACTIVEEnforced on every matching request
DISABLEDTemporarily turned off without deleting
Only ACTIVE policies are evaluated at request time. Each status change increments the policy version, which is recorded alongside every evaluation decision for auditability. A typical lifecycle:
  1. Create as DRAFT — build and refine rules without affecting live traffic.
  2. Simulate — test the policy against sample inputs.
  3. Set to ACTIVE — enforcement begins immediately.
  4. Set to DISABLED — pause enforcement without losing the policy definition.
  5. Delete — remove the policy when no longer needed.
See the issuance policies guide for step-by-step instructions on managing policy status transitions.

​
Simulating policies

Test how a policy evaluates a given input before deploying it. See the policy simulator for console and API usage.