Skip to main content
A purpose is a declarative rule: “for this kind of work, these elements are allowed, with this TTL.” Defining your first purpose graduates your adoption from L1 (observe) to L2 (test) on the maturity model.

Where purposes come from

Two paths:
  1. Generalize from observation — Inviolet’s Generalize workflow suggests purposes based on observed query patterns. Best for teams with 2+ weeks of observation data.
  2. Manual declaration — write a purpose against a known workflow. Best for greenfield use cases.
This guide covers the manual path. For the generalize-from-observation path see Generalize from observation.

Anatomy of a purpose

id: customer_support_lookup
name: "Customer Support Lookup"
description: "Look up a customer's identity + recent order history when answering a support ticket."
elements:
  - customer.name
  - customer.email
  - customer.order_history
ttl_seconds: 300
identity_required: true
approval_required: false
  • elements is the column allowlist. Anything outside this list will be rewritten or blocked at the database proxy.
  • ttl_seconds bounds the lifetime of any intent token minted under this purpose.
  • identity_required forces an IdP-authenticated user_id to be present on every call.
  • approval_required routes the call through a Slack / email approval queue before any intent token is minted.

Create the purpose

  1. App dashboard → PurposesCompose (new in Phase 18 lifecycle)
  2. Fill the form fields above
  3. Save — the purpose is created in shadow mode by default

Run in shadow mode

Shadow mode evaluates the policy on every matching tool call but does NOT block anything. The decision feed shows what would have happened. Watch this for a week or two.

Promote to live

Once the shadow stats look right (low false-positive denials, high match-rate on intended traffic), promote with one click: App dashboard → Purposes → pick the purpose → Promote to live Promotion is immediate. The next matching tool call gets a live decision written to the audit log.