> ## Documentation Index > Fetch the complete documentation index at: https://developers.argosidentity.com/llms.txt > Use this file to discover all available pages before exploring further. # Policy Writing Guide > Best practices for writing effective natural language verification policies. Your policy is the most important part of an Omni workflow. It tells the AI agent exactly what to check, how to evaluate documents, and when to approve or reject. A well-written policy produces accurate, consistent results. A vague one produces unreliable output. This guide covers the principles of effective policy writing, provides templates for common use cases, and explains how your policy language influences engine selection. ## What Makes a Good Policy Good policies share four characteristics: | Characteristic | Description | | -------------- | ---------------------------------------------------------------- | | **Specific** | States exactly what fields to check and what documents to expect | | **Structured** | Uses numbered steps that follow a logical verification order | | **Decisive** | Defines clear approve/reject/flag criteria | | **Complete** | Covers all checks your manual process would perform | Omni's NLP Workflow Generator parses your policy to determine which engines to activate and how to orchestrate them. The more precise your language, the more accurate the engine selection and execution. ## Policy Structure Template Every policy should follow this four-part structure: ```text theme={null} [Objective] Verify the submitted [document type(s)] for [purpose]. [Input Documents] Expected documents: [list of document types] [Verification Steps] 1. Extract [specific fields] from [specific document] 2. Verify that [condition A] 3. Check that [condition B] 4. Cross-validate [field X] against [field Y] 5. Screen [person/entity name] against [database/list] [Decision Criteria] - APPROVE if [all success conditions] - REJECT if [any failure conditions] - FLAG for manual review if [ambiguous conditions] ``` You do not need to use these exact section headers. What matters is that your policy covers all four areas: objective, inputs, steps, and decisions. Omni parses the meaning, not the formatting. ## Examples by Use Case ```text theme={null} Verify the submitted business registration documents for corporate entity validation. Expected documents: business registration certificate, corporate registry extract Verification steps: 1. Extract company name, registration number, incorporation date, registered address, and representative name from the business registration certificate 2. If a corporate registry extract is provided, cross-validate company name and registration number between both documents 3. Verify that the incorporation date is in the past and the registration has not expired 4. Check that the registered address includes street, city, and country 5. Screen the representative name against AML/sanctions watchlists 6. Verify that all required fields are present and non-empty Decision criteria: - APPROVE if all fields are consistent across documents, no AML matches found, and registration is valid and not expired - REJECT if AML screening returns a high-risk match (SAN-CURRENT, PEP-CURRENT) or the registration is expired - FLAG for manual review if AML returns a partial or medium-risk match, or if fields are inconsistent between documents ``` **Engines activated:** Text Verifier - Glove, AML Search - Person ```text theme={null} Verify the submitted invoice for payment processing approval. Expected documents: invoice (PDF or image) Verification steps: 1. Extract vendor name, vendor address, invoice number, invoice date, payment due date, line items (description, quantity, unit price, amount), subtotal, tax amount, and total amount 2. Verify that all required fields are present: vendor name, invoice number, invoice date, at least one line item, and total amount 3. Calculate the expected subtotal from line items (quantity x unit price for each) and check it matches the stated subtotal 4. Verify that tax is calculated correctly based on the subtotal 5. Check that the total equals subtotal plus tax 6. Validate that the invoice date is not in the future 7. Validate that the payment due date is after the invoice date Decision criteria: - APPROVE if all required fields are present, all calculations are correct, and dates are valid - REJECT if required fields are missing, amounts do not add up, or the invoice date is in the future - FLAG for manual review if minor discrepancies exist (e.g., rounding differences less than 1%) or if any field is partially unreadable ``` **Engines activated:** Text Verifier - Glove ```text theme={null} Review the submitted compliance document to verify regulatory requirements are met. Expected documents: regulatory license, compliance certificate, or permit document Verification steps: 1. Extract document type, issuing authority, issue date, expiration date, license/permit number, entity name, and scope of authorization 2. Verify that all required sections are present: document header with issuing authority, body with license details, signature block, and date fields 3. Check that the expiration date is in the future (document is currently valid) 4. Verify that the entity name on the document matches the expected entity name 5. Confirm that the license/permit number follows the expected format 6. Check that the issuing authority is a recognized regulatory body Decision criteria: - APPROVE if all required sections are present, the document is not expired, entity names match, and the license number format is valid - REJECT if the document is expired, required sections are missing, or entity names do not match - FLAG for manual review if the entity name is a close but not exact match, or if the issuing authority cannot be verified ``` **Engines activated:** Text Verifier - Glove ```text theme={null} Screen individuals referenced in the submitted documents against AML/sanctions databases. Expected documents: any document containing person names (contracts, corporate filings, partnership agreements, board resolutions) Verification steps: 1. Extract all person names mentioned in the submitted documents, along with any available identifying information (date of birth, nationality, role/title) 2. For each extracted person, perform AML/sanctions watchlist screening 3. Classify screening results by risk level: - High risk: current sanctions (SAN-CURRENT), current PEP (PEP-CURRENT), regulatory enforcement (REL) - Medium risk: linked to PEP (PEP-LINKED), former PEP (PEP-FORMER), former sanctions (SAN-FORMER) - Low risk: media reports (RRE), insolvency (INS) 4. Summarize all screening results with person name, match status, and risk level Decision criteria: - APPROVE if no AML/sanctions matches are found for any screened individual - REJECT if any individual has a high-risk match - FLAG for manual review if any individual has a medium-risk or low-risk match ``` **Engines activated:** Text Verifier - Glove (for name extraction), AML Search - Person (for screening) ## Common Mistakes Avoid these pitfalls when writing policies: **Problem:** Omni does not know what to verify. "Verify the document" gives no information about which fields to check or what constitutes a pass. **Fix:** Be explicit about what to check. ```text theme={null} # Bad Verify the document and check if it is valid. # Good Extract the company name, registration number, and incorporation date from the business registration certificate. Verify that all fields are present, the registration number follows a valid format, and the incorporation date is in the past. ``` **Problem:** Without clear approve/reject rules, the AI agent has to guess what constitutes a passing result. **Fix:** Always end your policy with explicit decision criteria. ```text theme={null} # Bad Extract invoice details and check the amounts. # Good Extract invoice details and check the amounts. - APPROVE if all line item amounts sum to the stated total and all required fields are present - REJECT if amounts do not match or required fields are missing - FLAG for manual review if amounts match but optional fields are missing ``` **Problem:** Omni performs better when it knows what type of document to expect. Without this context, extraction accuracy can suffer. **Fix:** Specify expected document types at the beginning of your policy. ```text theme={null} # Bad Check the submitted files for compliance. # Good Review the submitted business registration certificate (PDF or scanned image) for corporate compliance requirements. ``` **Problem:** Putting too many unrelated verification tasks into one policy makes it hard for the AI agent to execute cleanly. Results become less reliable. **Fix:** If your process involves fundamentally different types of checks (e.g., invoice validation AND employee background screening), split them into separate workflows. ```text theme={null} # Bad - one policy doing everything Verify the vendor invoice, check the vendor's business registration, screen all directors against AML lists, validate the vendor's insurance certificate, and confirm their bank account details. # Good - split into focused workflows Workflow 1 (Invoice): Verify invoice amounts, dates, and required fields Workflow 2 (Vendor KYB): Validate business registration and screen directors Workflow 3 (Vendor Compliance): Check insurance certificate and bank details ``` ## Policy and Engine Mapping Omni's NLP Workflow Generator analyzes your policy text to suggest which engines to activate. Understanding this mapping helps you write policies that trigger the right engines. ### AML Search - Person This engine is suggested when your policy contains keywords related to sanctions and watchlist screening. **Trigger keywords:** * "AML", "anti-money laundering" * "sanctions", "sanctioned" * "watchlist", "watch list" * "screening", "screen against" * "PEP", "politically exposed" **Example phrases that activate AML Search:** ```text theme={null} "Screen the representative name against AML/sanctions watchlists" "Perform AML screening on all directors" "Check individuals against sanctions databases" ``` ### Text Verifier - Glove This engine is suggested when your policy describes document analysis, data extraction, or field validation tasks. **Trigger keywords:** * "extract", "extraction" * "verify", "validate", "validation" * "check", "compare", "cross-check" * "match", "consistency" * "present", "missing", "required fields" **Example phrases that activate Text Verifier:** ```text theme={null} "Extract the company name and registration number from the certificate" "Verify that all required fields are present" "Cross-validate the address between the two documents" "Check that the invoice total matches the sum of line items" ``` Both engines can be activated simultaneously. For example, a KYB policy that mentions "extract company details" (Text Verifier) and "screen directors against AML watchlists" (AML Search) will correctly suggest both engines. You can always manually override the suggestions in Step 3 of workflow creation. ### Quick Reference | If your policy needs to... | Engine | Key phrases to include | | ------------------------------- | --------------------- | ----------------------------------------------- | | Extract data from documents | Text Verifier - Glove | "extract", "parse", "read from" | | Validate field values | Text Verifier - Glove | "verify", "check that", "validate" | | Compare fields across documents | Text Verifier - Glove | "cross-validate", "compare", "match between" | | Check document completeness | Text Verifier - Glove | "required fields", "all sections present" | | Screen names against watchlists | AML Search - Person | "AML screening", "sanctions check", "watchlist" | | Assess AML/PEP risk | AML Search - Person | "risk assessment", "PEP screening", "sanctions" | ## What's Next? Put your policy into action by creating a workflow. Start with a pre-built template and customize it.