Docupath provides three complementary systems that work together to manage how documents are processed, from initial extraction through final output. This "Read → Polish → Guardrail" mental model allows organizations to enforce consistent data handling across documents:
Instruction Builds (Read) teach the AI how to interpret, extract, and validate data
Transformation Rules (Polish) format and reshape data after extraction
Rejection Rules (Guardrail) block documents that violate compliance or business requirements
These systems operate at different scopes within an organization, with clear precedence determining which instructions apply when more than one is defined.
How It Works
The Read → Polish → Guardrail Flow
Read Phase (Instruction Builds)
Instruction Builds define natural language instructions that guide AI interpretation during document processing. Written in plain English, they are flexible and scalable. During the read phase, they can:
Teach the AI how to extract specific information from documents
Infer missing fields from context or related data
Split or merge line items intelligently
Apply language-specific or region-specific formatting
Validate extracted values against master data
Polish Phase (Transformation Rules)
After the AI completes extraction, Transformation Rules run automatically. They manipulate extracted data using conditional logic to SET values, INCREASE, DECREASE, MULTIPLY, or DIVIDE numeric fields. Multiple conditions can be combined using AND/OR logic before actions execute.
Guardrail Phase (Rejection Rules)
Rejection Rules deterministically block documents when conditions are met. Unlike transformations that correct data, rejection rules apply hard stops - if a condition is true, the document is rejected with no automatic corrections.
Scope Precedence
All three operate within a scope hierarchy. When more than one applies to a document, the most specific scope takes precedence:
Trading party relationship specific (Party A + Party B for a specific relationship) - most specific
Trading party specific (either Party A or Party B alone)
Organization specific
Country specific (Instruction Builds only)
Global - least specific
Trading party scoping supports both one-party (single entity) and two-party (relationship-based) configurations, allowing granular control over instructions and rules for specific business partnerships.
Enabling and Disabling Rules or Instructions
All three types can be enabled or disabled without being deleted, and only enabled items are applied when a document is processed. A disabled item stays configured and can be switched back on at any time.
Each type groups its items the same way, so the controls behave consistently:
In every case the group's row switch turns on when at least one item in it is enabled, and turning the group off switches off everything inside it. Everything is enabled by default, including items that existed before this capability was introduced, so behavior is unchanged until something is explicitly switched off.
Because disabled items are skipped, switching one off can change what the remaining instructions and rules do. This is covered in [Scope Precedence in Instructions and Rules]
Supported Configurations & Options
Instruction Builds
Instruction Scope Options:
Trading Party Specific (one-party or two-party relationships)
Country-Specific
Organization-Specific
Global
Capabilities:
Natural language instruction definition
Several separate instructions per scope, each individually enabled or disabled
Per-instruction AI refinement
Field inference and validation
Intelligent line item handling (splitting/merging)
Language and region-specific formatting
Master data validation
Transformation Rules
Condition Operators:
=(equal)<(less than)<=(less than or equal)!=(not equal)IS_NULL(field has no value)IS_NOT_NULL(field has a value)
Action Operators:
SET- assign a specific valueINCREASE- increment a numeric fieldDECREASE- decrement a numeric fieldMULTIPLY- multiply a numeric field by a factorDIVIDE- divide a numeric field by a factor
Logic Options:
AND- all conditions must evaluate to trueOR- at least one condition must evaluate to trueNote: AND and OR cannot be mixed within the same rule
Rule Scope Options:
Trading party specific
Organization specific
Country specific
Global
Data Sources:
CSV lookup tables (maximum 100,000 rows, 10 columns per table)
Rejection Rules
Condition Operators:
Same as Transformation Rules:
=,<,<=,!=,IS_NULL,IS_NOT_NULL
Logic Options:
AND- all conditions must be true for rejectionOR- document is rejected if any condition is trueNote: AND and OR cannot be mixed within the same rule
Rule Scope Options:
Trading party specific
Organization specific
Country specific
Global
Data Sources:
CSV reference files for validation (e.g., approved cost centers, authorized vendors)
Common Use Cases:
Missing required fields (e.g., missing PO number)
Test data detection
Master data validation (cost center, supplier, account codes)
Business rule violations (e.g., non-positive totals)
Other Technical Specifications
System Constraints
Rule Management Limits:
Maximum rule groups per organization: 100
Maximum rules per rule group: 500
Maximum rule groups per tenant: 1,000
Maximum instructions per organization: 100
Maximum instructions per country: 100
Maximum global instructions: 100
Data Handling:
Condition nesting: cannot mix AND and OR operators in single rule
Access Control:
Only Administrators can create or edit rules
All changes are audit-logged
Scope precedence is automatically enforced
Processing Order
Document enters system
Instruction Builds guide AI extraction (Read phase)
Rejection Rules evaluated; document blocked if any condition met (Guardrail phase)
Transformation Rules applied to extracted data (Polish phase)
Processed document exported with transformed data
Integration Points
External Data Sources
Transformation Rules and Rejection Rules can reference CSV files for:
Lookup tables for value mapping
Master data validation (cost centers, vendors, account codes)
Reference lists for compliance checks
Audit and Compliance
All rule changes are audit-logged, tracking:
Who created or modified the rule
When the change occurred
What was changed
The scope level affected
Organization Hierarchy
Rules respect the multi-tenant and organization structure:
Tenant-level constraints prevent runaway rule proliferation
Organization-specific rules override global rules
Trading party-specific rules enable customer-specific business logic
Notes
Rule Logic Constraints
No mixed AND/OR logic - Single rules cannot combine AND and OR operators. Workaround: create separate rules or use rule groups
No automatic correction in Rejection Rules - Documents rejected by guardrails are blocked entirely; transformation-style fixes are not applied during rejection
Scope precedence is automatic - Administrators cannot override precedence order; if a lower-precedence rule exists for a scenario, it is ignored in favor of higher-precedence matches
CSV Data Constraints
Row limits - CSV files limited to 100,000 rows may require external databases for larger datasets
Column limits - 10 columns per CSV may require denormalization of related data
Performance Considerations
Large rule sets - Organizations with many rule groups or rules in each group may experience slower evaluation times
CSV lookup performance - Large reference files (approaching 100,000 rows) may impact processing speed
Scope-Related Edge Cases
Multiple Trading Party matches - If both Party A-specific and Party B-specific rules exist for the same field, the one-party rules are evaluated in order of precedence (Party A before Party B by default organization config)
Country-Specific Instruction Builds - Available only for Instruction Builds; Transformation and Rejection Rules do not support country-level scoping
Empty scope intersections - If a two-party rule is defined but only one party is known during processing, the rule does not apply