Pramata Prompt Variables

This guide will help you understand how to effectively use Pramata's GenAI features to analyze your documents and create powerful, customized prompts.

 

Understanding Prompt Variables

Pramata's GenAI system uses special variables in prompts to provide context and extract specific information from your documents. These variables help ensure accurate and relevant insights while reducing the chances of incorrect responses.

 

Core Document Variables

Master Agreement Variables

  • {{MASTER}}: References all Master Agreement type documents
  • Example: Summarize the key terms in {{MASTER}}
  • Output: Summarize the key terms in [Master Agreement, Addendum]

Document Variable

  • {{DOCUMENT}}: References any document in repository regardless of contract type or category
  • Example: Review {{DOCUMENT}} for compliance issues
  • Output: Will analyze any document type with complete content
  • Features:
    • Always passes full text of documents
    • In Key Term Mode: passes both full text AND key terms together
    • Ideal for digitization, document review, and clause verification
  • Note: Analyzes documents comprehensively without filtering content

Document Structure Variables

{{TRUEDOC+}}: Use alongside contract variables to access tagged document format with structured metadata

  • Includes page numbers, paragraph identifiers, and table references
  • Enables accurate clause location tracking for Agent-powered reports and clause tagging workflows
  • Example: Identify all confidentiality clauses in {{TRUEDOC+}} {{MASTER}}
  • Output: Will process the document with full structural metadata, page references, and paragraph identifiers
  • Best for: Precise clause location tracking, detailed reporting, tagging workflows

{{TRUEDOC}}: Maintains the default untagged document format with cleaner text representation

  • Provides cleaner text when precise location tracking isn't required
  • Works seamlessly with all contract-based variables ({{MASTER}}, {{DOCUMENT}}, {{ORDER}}, {{AMENDMENT}}) and their page-specific variants
  • Example: Identify all confidentiality clauses in {{TRUEDOC}} {{MASTER}}
  • Output: Will process the document in standard untagged format
  • Best for: General analysis, cleaner text representation, when location tracking isn't critical

Order Variables

  • {{ORDER}}: References all Order type documents
  • Example: List all products and services in {{ORDER}}
  • Output: List all products and services in [Order, SOW]

Amendment Variables

  • {{AMENDMENT}}: References all Amendment type documents
  • Example: What changes are made in {{AMENDMENT}}
  • Output: What changes are made in [Amendment]

Contract Type Variables

  • {{ct.Contract Type}}: References a specific Contract Type
  • Example: Analyze {{ct.Master Agreement}}
  • Output: Analyze [Master Agreement]

Key Term Variables

Basic Key Term Usage

  • {{kt.Key Term}}: References a specific key term (without digital snapshot)
  • Example: Explain {{kt.Contract Term & Renewal}}
  • Output: Will show the Contract Term & Renewal information

Enhanced Key Term Usage

  • {{kt+.Key Term}}: References a key term with its digital snapshot
  • Example: Review {{kt+.Assignment}} clause details
  • Output: Will show Assignment information with associated digital snapshots

All Key Terms

  • {{kt}}: References all visible key terms (without digital snapshots)
  • {{kt+}}: References all visible key terms (with digital snapshots)
  • Example: Summarize all clauses: {{kt+}}
  • Output: Will include all visible key terms with their digital snapshots

Playbook Variables

Basic Playbook Usage

  • {{PLAYBOOK}}: References the appropriate playbook based on account type
  • Example: Assess {{MASTER}} risks using {{PLAYBOOK}}
  • Output: For a Vendor account: Assess [Master Agreement] risks using [Vendor Playbook]

Playbook Clauses

{{PLAYBOOK_CLAUSES}}: References specific playbook clause

  • Example: Analyze this section using {{PLAYBOOK_CLAUSES}}
  • Output: Will provide targeted guidance from your playbook for specific clauses
  • Works best when focusing on particular contract sections

{{ANY_PLAYBOOK_CLAUSES}}: References playbook clauses (optional)

  • Example: Apply {{ANY_PLAYBOOK_CLAUSES}} guidance if available
  • Output: Will use playbook clauses when available, continues without it if not
  • Helpful when playbook clauses may or may not exist

Note: For integrating Clause Analysis Models (CAM) with Playbook variables, see the FAQ section below.

Checklists Variable

Basic Checklist Usage

{{CHECKLIST}}: Requires the user to select a checklist before the agent can run. When a checklist is selected, the token in the prompt text is replaced with [checklist name] (e.g., [NDA Review Checklist]) and the checklist's tasks are injected into the LLM context as a Markdown table.

  • Example prompt: Evaluate {{MASTER}} against {{CHECKLIST}}
  • Prompt text sent to LLM: Evaluate [NDA Review Checklist] against [Master Agreement]
  • Context injected: ## Checklist: NDA Review Checklist
# ID Question Approvers Priority
1 42 Is the term length acceptable? Jane Doe, John Smith High
2 43 Are IP protections adequate? Jane Doe Medium

Note: If no checklist is selected at runtime, the agent returns an error: "This agent requires a checklist to be selected. Please select the relevant checklist and try again!" The validation is enforced when the interaction is executed, not when the agent is saved.

Optional Checklist Usage

{{ANY_CHECKLIST}}: Allows but does not require the user to select a checklist. When a checklist is selected, it behaves identically to {{CHECKLIST}} — the token is replaced with [checklist name] and tasks are injected. When no checklist is selected, the token resolves to the literal text [Any Checklist] in the prompt and no checklist context is injected.

  • Example (with checklist selected): Review {{DOCUMENT}} using {{ANY_CHECKLIST}} if applicable
  • Prompt text sent to LLM: Review [Document] using [NDA Review Checklist] if applicable
  • Context injected: Same Markdown table format as {{CHECKLIST}}
  • Example (without checklist selected): Review {{DOCUMENT}} using {{ANY_CHECKLIST}} if applicable
  • Prompt text sent to LLM: Review [Document] using [Any Checklist] if applicable
  • Context injected: None

Note: No error is raised when {{ANY_CHECKLIST}} is the only checklist token and no checklist is selected. The agent proceeds without checklist context.

Key Behaviors

  • Both {{CHECKLIST}} and {{ANY_CHECKLIST}} can coexist in the same prompt. There is no mutual exclusion. A prompt like "summarize {{CHECKLIST}} vs {{ANY_CHECKLIST}}" is valid.
  • All tasks in the checklist are injected. There is no active/inactive concept — the checklist_tasks table has no status or active column.
  • Tasks are ordered by created_at (ascending).
  • The injected Markdown table columns are: #, ID, Question, Approvers, Priority.
  • Approvers column lists stakeholder user names comma-separated, or - if none are assigned.
  • Priority column displays the task's importance value capitalized (High, Medium, Low), or - if not set.
  • Newlines within a task's question text are converted to <br> in the table.
  • Both variables can be combined with other prompt variables (e.g., {{MASTER}}, {{kt+}}, {{CAM}}, {{PLAYBOOK}}).
  • The checklist selection UI is driven by the agent_requirements configuration on the experience, not by detecting token names in the prompt text.

Example Combinations

  • Checklist-based review: Evaluate {{MASTER}} against the following checklist criteria: {{CHECKLIST}}
    — Requires both a master contract selection and a checklist selection.
  • Optional checklist with key terms: Review {{DOCUMENT}} using {{ANY_CHECKLIST}} and summarize findings for {{kt+.Confidentiality}} — Checklist is optional. Key terms are injected regardless. If a checklist is selected, its tasks are included; otherwise the prompt proceeds with [Any Checklist] as literal text.
  • Checklist with CAM: Assess {{MASTER}} using {{CAM}} and validate against {{CHECKLIST}}
    — Requires master contract, CAM, and checklist selections.

Contract AI Model Variables

Agent prompts can now reference Contract AI Models directly using dedicated variables, giving you richer and more flexible access to your clause analysis data. Previously, referencing clause analysis data in prompts required the {{PLAYBOOK_CLAUSES}} variable and a linked Playbook — even when the intelligence you needed lived entirely within a Contract AI Model (CAM). These new variables remove that dependency while still working seamlessly alongside Playbooks when they are in use.

Basic CAM Usage

{{CAM}}: References Contract AI Model clause definitions and positions (without digital snapshots)

  • Example: Analyze the contract using {{CAM}}
  • Output: Will load CAM clause definitions and positional guidance for analysis

Enhanced CAM Usage

{{CAM+}}: References Contract AI Model clause definitions and positions (with digital snapshots)

  • Example: Review {{CAM+}} for assignment clause guidance
  • Output: Will load CAM clause definitions along with associated digital snapshot text

Combining CAM with Key Term Variables

Variable Combination Data Accessed
{{CAM}} CAM clause definitions and positions only
{{CAM+}} CAM clause definitions and positions with digital snapshot text
{{CAM}} + {{kt+}} All key terms under the CAM, including their digital snapshot text
{{CAM}} + {{kt+.TermName}} A specific key term by name — e.g. {{CAM}} + {{kt+.Assignment}} loads the Assignment clause and its digital snapshot text
  • Example: Analyze the payment terms in {{MASTER}} using {{CAM+}} and focus on {{kt+.Payment Terms}}
  • Output: Will load the CAM with digital snapshots and isolate the Payment Terms key term for targeted analysis

Deprecation Notice: {{PLAYBOOK_CLAUSES}}, {{ANY_PLAYBOOK_CLAUSES}}, and {{PLAYBOOK_PROVISIONS}} have been deprecated in favor of the new {{CAM}} and {{CAM+}} variables. These legacy variables will remain functional through May 2026 to give your team time to update existing prompts.

Attachment and Template Variables

Attachment Variables

{{ATTACHMENT}}: References attached files

  • Example: Compare the payment terms in {{ATTACHMENT}} with our standard terms in {{MASTER}}.
  • Output: Will analyze the attached files in comparison with master agreement
  • Format: [ATTACHMENT | filename.extension]
    Note: Requires an attachment file to be provided

{{ANY_ATTACHMENT}}: References attached files (optional)

  • Example: Analyze terms in {{ANY_ATTACHMENT}} if available.
  • Output: Will analyze the attached file if provided, or proceed without it
    Note: Makes attachment files optional in your prompts

Template Variables

{{TEMPLATE}}: References a specific template file

  • Example: Summarize {{TEMPLATE}}
  • Output: Summarize [TEMPLATE | Master Template.docx]
  • Format: [TEMPLATE | filename.extension]
    Note: Requires a template file to be provided

{{ANY_TEMPLATE}}: References a template file (optional)

  • Example: Generate clauses based on {{ANY_TEMPLATE}}
  • Output: Will use the template if provided, or proceed without it
    Note: Makes template files optional in your prompts

Special Purpose Variables

Contract Request

  • {{CONTRACT_REQUEST}}: References contract request information
  • Example: Process {{CONTRACT_REQUEST}}
  • Output: Process [Contract Request]
    Note: Only works in a Contract Request context

Date Reference

  • {{TODAY_UTC}}: Inserts current UTC date
  • Example: Generate report as of {{TODAY_UTC}}
  • Output: Generate report as of December 9, 2024 (UTC)

Draft Contract Variables

Current Draft

  • {{DRAFT_CONTRACT}}: References the current draft contract
  • Example: Review {{DRAFT_CONTRACT}}
  • Output: Review [Draft Contract]

Previous Draft

  • {{PREVIOUS_DRAFT_CONTRACT}}: References the previous version of the draft contract
  • Example: Compare {{DRAFT_CONTRACT}} with {{PREVIOUS_DRAFT_CONTRACT}}
  • Output: Will compare current and previous draft versions

Contract Reference Variables

{{ANY_MASTER}}, {{ANY_ORDER}}, {{ANY_AMENDMENT}}: Optional versions of contract reference variables that include only matched contracts when available.

{{ANY_MASTER}}: References available ARP Master-type contracts

  • Replaced with a bracketed, comma-separated list of unique contract types categorized as "ARP Master".
  • Example: "Summarize {{ANY_MASTER}}"
  • Output: "Summarize [Master Agreement, Addendum]"

{{ANY_ORDER}}: References available ARP Order-type contracts

  • Replaced with a bracketed, comma-separated list of unique contract types categorized as "ARP Order".
  • Example: "Summarize {{ANY_ORDER}}"
  • Output: "Summarize [Order, SOW]"

{{ANY_AMENDMENT}}: References available ARP Amendment-type contracts

  • Replaced with a bracketed, comma-separated list of unique contract types categorized as "ARP Amendment".
  • Example: "Summarize {{ANY_MASTER}} and {{ANY_AMENDMENT}}"
  • Output: "Summarize [Master Agreement, Addendum] and [Amendment]"

Metadata Variable

Contract Metadata

{{METADATA}}: References contract metadata information

  • Example: Show contract details using {{METADATA}}
  • Output: Will display structured metadata for the contract

How it Works:

  • The Engine identifies the presence of {{METADATA}} in the prompt and provides corresponding metadata content
  • If {{METADATA}} is found alongside other contract variables ({{MASTER}}, {{AMENDMENT}}, {{ORDER}}, {{ct.<type>}}, {{kt.<type>}}, {{kt+}}), the system filters contracts to include only those eligible for the prompt
  • Context Mode: {{METADATA}} variable does not influence the Context Mode (DOC-AT-A-TIME/ALL-DOCS), it defaults to Full text mode unless another contract variable is identified.

Execution Behavior:

Variable Type Data Accessed Context Requirement Execution Behavior Context Mode
{{METADATA}} Variables Metadata only Not Mandatory LLM executes even if the context is missing ALL-DOCS (even in preliminary prompt)
Contract Variables Metadata + Text/KT Data Required The engine raises an error if missing DOC-AT-A-TIME/ ALL-DOCS
Contract Variables & {{METADATA}} combined Metadata + Text/KT Data Not Mandatory LLM executes even if the context is missing DOC-AT-A-TIME/ ALL-DOCS

 

Advanced Features

Page Specific Analysis

  • You can limit analysis to specific pages using the following syntax:
    • {{MASTER|n}}: Analyze first n pages of Master Agreements
    • {{ORDER|n}}: Analyze first n pages of Orders
    • {{AMENDMENT|n}}: Analyze first n pages of Amendments
  • Example: Summarize {{MASTER|2}} and {{ORDER|1}}
  • Output: This will analyze the first 2 pages of Master Agreement and first page of Order.

Key Term Mode vs. Full Text Mode

The system operates in two modes:

  • Key Term Mode: Activated when using any key term variables ({{kt}}, {{kt+}}, or {{kt.Key Term}})
    • Only passes specified key terms
    • Recommended for large documents
    • Reduces context window overflow
  • Full Text Mode: Default mode when no key term variables are used
    • Passes complete document text
    • Best for smaller documents (recommended under 120 pages)
    • More comprehensive analysis

Process Control Variables

{{ANSWER}}

The {{ANSWER}} variable is a specialized process control variable in Pramata AI Platform that enables complex problem-solving by managing thought processes in AI outputs. When included in your prompts, this variable creates a distinction between the AI's reasoning steps and the final answer, allowing for more efficient token usage and improved response quality.

This variable is a critical component of Pramata's comprehensive suite of prompt variables designed to optimize document analysis and orchestrate multi-stage AI workflows.

How it Works

When your Prompt uses {{ANSWER}} variable, the system

  • Allows the GenAI model to process the entire prompt and generate a complete response, including necessary reasoning steps (thought process)
  • Uses the variable as a delimiter between thought process and final answer
  • In preliminary prompts: Passes only the content after the {{ANSWER}} variable to subsequent final prompts
  • In the current implementation: Only shows the content after the variable to end users (with plans to make thought processes viewable in future updates)

Best Practices

  • Place the {{ANSWER}} variable where you want the final, concise output to begin.
  • Structure preliminary prompts to perform targeted analysis of specific documents or aspects.
  • Ensure the AI model includes the {{ANSWER}} variable in its response.
  • For complex contract analyses, combine with document variables and key term variables to focus the analysis.
  • Remember that all prompts have limited token capacity depending on the model.

Common Use Cases

  • Multi-document Analysis: Process individual documents separately before comprehensive account-level analysis
  • Contract Comparison: Analyze multiple contracts individually with detailed thinking, then pass only concise outputs to a final comparison prompt
  • Playbook Compliance: Evaluate individual clauses against playbook standards, using thought processes for thorough assessment while only passing final determinations
  • Staged Analysis: Create chains of prompts where each stage builds on previous results without carrying forward unnecessary thought processes
  • Token Management: Enable complex analyses that would otherwise exceed token limits if done in a single prompt

Orchestrating Complex Workflows

The {{ANSWER}} variable is fundamental to Pramata's approach of breaking down complex business problems into smaller, more digestible components:

  1. Preliminary Prompts: Process individual documents or specific aspects of a problem
    • Each preliminary prompt receives relevant context data
    • The LLM performs thorough analysis, showing its thought process
    • The {{ANSWER}} variable separates thought process from the final answer
    • Only the final answer (after the variable) is passed to the final prompt
  2. Final Prompt: Performs account-level or comprehensive analysis
    • Receives only the final answers from preliminary prompts
    • Has sufficient token headroom to generate comprehensive insights
    • Delivers the final analysis to the end user
    • This orchestration allows for processing large document sets that would otherwise exceed token limits if analyzed in a single LLM call.

Implementation Example

For a document analysis workflow that processes multiple contracts in an account:

Preliminary Prompt (runs for each document)

Analyze the following contract for payment terms.

Think through all aspects carefully, considering standard industry practices.

[MSA | Master Agreement | 2023-06-12 | Pramata Number: 10881] -> BEGIN

Section 3.4 Payment Terms:

Customer shall pay all undisputed invoices within thirty (30) days of receipt. Late payments shall incur interest at the rate of 1.5% per month or the maximum rate permitted by law, whichever is less. All payments are non-refundable and shall be made in U.S. dollars. Customer shall be responsible for all taxes associated with the services, excluding taxes based on Provider's income.

[MSA | Master Agreement | 2023-06-12 | Pramata Number: 10881] -> END

{{ANSWER}}

The Master Agreement (P No: 10881) contains standard net-30 payment terms with a 1.5% monthly late payment interest charge. Payments are non-refundable and must be made in USD, with the customer responsible for all applicable taxes except those based on the provider's income.

This approach ensures:

  • Each document receives thorough individual analysis
  • The preliminary prompt's thought process doesn't consume tokens in the final prompt
  • The final prompt has sufficient token capacity to deliver comprehensive insights

Technical Considerations

  • When processing prompts with the {{ANSWER}} variable, users will see "Processing... this may take a minute!" instead of the standard "Processing..." message
  • If the {{ANSWER}} variable never appears in the output, the system will display the full response
  • The variable helps manage token limits (8K for Sonnet 3.5 v2, 64K for Sonnet 3.7) effectively in multi-stage workflows
  • Current implementation hides thought processes from end users, though future updates plan to make these optionally viewable

Integration with Other Pramata Variables

The {{ANSWER}} variable can be used with other Pramata prompt variables to create sophisticated document analysis workflows:

Analyze the payment terms in {{MASTER}} and {{ORDER}}, focusing on {{kt+.Payment Terms}}.

Think through all compliance issues against the {{PLAYBOOK}} standards.

{{ANSWER}}

This approach allows you to:

  • Reference specific documents using {{MASTER}} and {{ORDER}}
  • Focus on key terms using {{kt+.Payment Terms}}
  • Apply playbook standards using {{PLAYBOOK}}
  • Separate thought process from final analysis

Form Data Variables

Form Data Context

{{FORM_DATA}}: Provides access to the complete form data as a JSON object

Use this variable when the agent needs to assess the entire form, correlate multiple fields, detect inconsistencies, or perform full-context risk evaluation.

  • Example: “Analyze the following contract request data: {{FORM_DATA}}”
  • Output: "Analyze the following contract request data: [FORM_DATA]"
  • Format:
[FORM_DATA] => Begin
{
"description_api_name": "This is a description",
"file_api_name": {
"name": "file.pdf",
"original_name": "path/file.pdf"
},
"file_api_name2": [{
"name": "file.pdf",
"original_name": "path/file.pdf"
}],
"contract_type": "NDA",
"effective_date": "2025-05-01",
"expiration_date": "2026-05-01",
"counterparty_name": "Acme Corporation",
"contract_value": 50000
}
[FORM_DATA] => End

 

Request Attachment Context

{{REQUEST_ATTACHMENT}}: Provides access to all attachments uploaded with the request form

Use when the agent needs to review uploaded contracts, extract key terms, validate compliance, or identify non-standard clauses across multiple documents.

  • Example: "Review these contract documents: {{REQUEST_ATTACHMENT}}"
  • Output: "Review these contract documents: [REQUEST_ATTACHMENT | file.pdf, file2.pdf]"
  • Format:
[REQUEST_ATTACHMENT | file.pdf] => Begin
...content of file.pdf...
[REQUEST_ATTACHMENT | file.pdf] => End
[REQUEST_ATTACHMENT | file2.pdf] => Begin
...content of file2.pdf...
[REQUEST_ATTACHMENT | file2.pdf] => End

 

Specific Attachment Context

{{REQUEST_ATTACHMENT.field_name}}: Provides access to a specific attachment referenced by the form field name

Use for targeted document analysis when different files serve distinct purposes or require specific validation based on their role.

  • Example: "Extract key terms from: {{REQUEST_ATTACHMENT.file_api_name}}"
  • Output: "Extract key terms from: [REQUEST_ATTACHMENT | file.pdf]"
  • Format:
[REQUEST_ATTACHMENT | file.pdf] => Begin
...content of file.pdf...
[REQUEST_ATTACHMENT | file.pdf] => End

 

Best Practices

  1. Use Key Term Mode for Large Documents
    • Helps prevent context window overflow
    • More focused and accurate analysis
  2. Include Digital Snapshots
    • Use {{kt+}} instead of {{kt}} when possible
    • Provides more context for analysis
  3. Be Specific with Document Types
    • Combine variables for precise scope
    • Example: Analyze payment terms in {{MASTER}} and {{ORDER}}
  4. Leverage Playbook Guidelines
    • Use {{PLAYBOOK}} for standardized analysis
    • Helps ensure compliance with organization standards
  5. Optional Variables need to be used only if there are any other mandatory variables present in the prompt, else it might tends to fail if no context is identified.

Common Use Cases

Contract Analysis: Summarize {{MASTER}} focusing on {{kt+.Assignment}} and {{kt+.Payment Terms}}

Compliance Check: Check if {{MASTER}} complies with {{PLAYBOOK}} guidelines

Document Comparison: Compare payment terms between {{MASTER}} and {{ORDER}} using {{kt+.Payment Terms}}

Risk Assessment: Assess risks in {{MASTER}} and {{AMENDMENT}} based on {{PLAYBOOK}}

CAM Analysis: Use {{PLAYBOOK_CLAUSES}} with {{kt+.Assignment}} to analyze contracts using Clause Analysis Model definitions

 

IMPORTANT NOTE: The effectiveness of your analysis depends on choosing the right combination of prompt variables for your specific needs. Start with basic queries and gradually incorporate more complex variable combinations as you become familiar with the system.

 

Frequently Asked Question

Q: How to Use Clause Analysis Model (CAM) in Agents

A: Follow the steps below to reference key terms from a Clause Analysis Model (CAM) in your Agent prompts:

  1. Create and associate a Playbook with your CAM.
    • The playbook can be empty - it just needs to be connected to your CAM
  2. Reference the CAM within your Agent prompt using the following variables:
    • {{PLAYBOOK_CLAUSES}} → Injects the CAM from the associated Playbook.
    • Combine with Key Term variables:
      • {{kt}} / {{kt+}} – All key terms without/with digital snapshot text
      • {{kt.<name>}} – To reference a specific key term from the CAM. Always use the exact name of the term as defined in the CAM when using this format. This can also be used without the {{PLAYBOOK_CLAUSES}} variable.

Example

Example 1

Analyze the contract using {{PLAYBOOK_CLAUSES}} and focus on {{kt+}} 
  • {{PLAYBOOK_CLAUSES}} loads the CAM from the Playbook.
  • {{kt+}} inserts all CAM key terms with digital snapshot text.

Example 2

Analyze the following {{kt+.Assignment}}
  • {{kt+.Assignment}} references the Assignment term defined in the CAM.