Threshold-based auto-approval

Threshold-based auto-approval lets legal teams move routine contracts through intake without a human click on every file, as long as the agreement meets playbook rules and stays inside agreed value and risk limits. Contracts that clear every gate receive an automatic approval with a traceable record of which threshold rules fired and which contract fields matched. Anything that fails a gate, lacks required data, or exceeds a limit routes to counsel for review. Legal keeps ownership of exceptions; the workflow does not substitute judgment on edge cases.

Auto-approval works best when legal has already encoded repeatable decisions into a playbook: standard clause language, acceptable liability caps, permitted governing law, and vendor categories that repeat at volume. The playbook defines what “compliant” means. Threshold rules add quantitative guardrails on top: contract value bands, risk tier ceilings, term length limits, and data sensitivity classifications.

A contract qualifies for auto-approval only when it satisfies all three layers at once:

1. Playbook compliance — every required clause and prohibition passes, with no material deviation from approved language or fallback positions.
2. Value thresholds — total contract value, annual spend, or committed run rate falls within a pre-approved band for that contract type and counterparty category.
3. Risk thresholds — the intake-assigned risk tier and any escalated flags stay at or below the ceiling defined for unattended approval.

If any layer fails, the record does not auto-approve. The workflow routes the matter to the appropriate approver path instead. That design preserves speed on the long tail of standard agreements while keeping counsel in the loop wherever judgment, negotiation, or policy exceptions are required.

Risk tier assignment at intake sets the ceiling before playbook matching runs. Contracts classified above the auto-approval tier never reach threshold evaluation unattended. See risk tier assignment at intake for how intake scoring feeds the approval gate.

Threshold evaluation runs after structured fields are extracted and normalized from the contract record. Typical inputs include total value, currency, term start and end dates, renewal type, data processing scope, indemnity cap as a percentage of fees, liability carve-outs, and counterparty legal entity type. The engine compares each field against rule definitions stored as identifiable threshold rule IDs, for example THR-VALUE-STD-001 for standard vendor agreements under a dollar cap, or THR-RISK-T2-NDA-004 for tier-2 NDAs with mutual confidentiality and no special categories.

Evaluation is conjunctive: every applicable rule must pass. Partial matches do not produce a qualified auto-approval. When a deviation report shows a playbook fallback was accepted within policy, that acceptance must still appear as a satisfied rule with a linked deviation record. See playbook deviation report for how negotiated fallbacks are captured without breaking the audit trail.

Missing data stops the process early. If a required field is empty, null, or failed extraction confidence checks, auto-approval output is empty. The system does not infer defaults for threshold comparison. An incomplete value field or absent risk tier blocks unattended approval and sends the contract down the exception path. That fail-closed behavior prevents silent approvals on incomplete records.

Some teams layer an approval outcome predictor upstream to flag contracts likely to fail threshold checks before they enter the queue. Predictors do not replace rule evaluation; they reduce rework by surfacing probable exceptions during drafting or vendor submission.

Speed only holds up if every auto-approved contract remains defensible under audit. Each auto-approval event should cite:

• Threshold rule IDs that passed, in evaluation order, so reviewers can reconstruct the logic path without opening the rule engine.
• Matched fields with the normalized values used at decision time, not live document text that may change later. Store value, risk tier, term, and clause check results as structured snapshots.
• Playbook version and evaluation timestamp, tied to the contract version that was analyzed.
• Routing absence — explicit indication that no human approver was required because all gates cleared.

If any required field was missing, the approval block stays empty and the workflow logs a THRESHOLD_INCOMPLETE or equivalent reason code. Empty output is intentional: it signals “no unattended approval occurred” rather than implying counsel reviewed the file.

Downstream systems consume these citations differently. Ironclad and DocuSign CLM typically attach the rule ID list and field snapshot to the workflow history on the agreement record. ServiceNow and Workday often mirror the same payload into the case or requisition audit log so procurement and legal share one source of truth.

Exceptions are anything that fails playbook compliance, exceeds a value or risk threshold, triggers a mandatory legal review flag, or lacks required structured data. The approver routing engine assigns those records to counsel queues based on contract type, business unit, jurisdiction, or escalated risk tier.

Legal still owns exceptions end to end. Auto-approval removes repetitive clicks; it does not remove accountability for non-standard terms, novel counterparty structures, or policy updates. Counsel sets threshold bands, approves playbook changes, and defines which deviation fallbacks remain eligible for unattended approval. When a threshold is mis-calibrated and too many contracts queue unnecessarily, legal adjusts rule IDs and republication of the playbook rather than bypassing the gate.

A practical operating split:

| Outcome | Who acts | Typical trigger | |--------|----------|-----------------| | Auto-approved | System | All playbook + threshold rules pass; required fields complete | | Counsel review | Legal approver | Playbook deviation, risk tier above ceiling, or ambiguous clause | | Procurement + legal | Joint queue | Value above band but otherwise standard terms | | Blocked | Intake owner | Missing required fields; resubmit after data correction |

Speed comes from shrinking the first row, not from collapsing the others into automated consent.

Vendor implementations differ in where rules live and how approvals post back to source systems, but the threshold pattern is consistent.

Ironclad — Workflow Designer encodes threshold branches on structured properties pulled from the Ironclad AI layer or intake forms. Auto-approval steps fire when property sets satisfy playbook workflow conditions; rule IDs are often stored as custom metadata on the workflow instance for export to SIEM or audit tools.

DocuSign CLM — Clause and obligation objects feed threshold comparisons in CLM workflow rules. Agreements that pass all rule sets can advance to an automated “Approved” state with a workflow comment block listing matched attributes. Failures route to legal task lists inside CLM or via API to external counsel tools.

ServiceNow — Legal Service Delivery or Source-to-Pay flows evaluate threshold rules in Flow Designer or IntegrationHub scripts against fields on sn_hr_core_case or procurement records. Auto-approval updates case state and writes rule citations to sys_audit; exceptions create assigned tasks for legal groups with SLA clocks unchanged from manual review.

Workday — Supplier contracts and customer agreements in Workday CLM expose custom object fields for value, risk tier, and playbook outcome. Business process definitions include condition steps that auto-complete approval when thresholds match; Workday’s process history retains rule references for SOX and internal audit samples.

Across all four, keep threshold rule IDs stable across environments. Renaming rules without migration breaks historical reconciliation. Version playbook and threshold packs together when legal publishes policy changes.

Treat threshold bands as living policy, not one-time configuration. Review auto-approval volume monthly: a spike may mean playbook drift, a new vendor template, or a threshold set too loose. Review exception volume for the opposite signal. Legal should own the change calendar for rule IDs tied to regulatory or commercial policy updates.

Train intake owners on required fields. Most empty auto-approval outcomes trace back to skipped intake questions or failed extraction on non-standard PDF layouts, not bad legal policy. Fixing field completeness often restores speed faster than widening thresholds.

Document which deviation fallbacks remain auto-eligible in the playbook deviation report workflow. Counsel negotiates an exception once; the system should recognize the approved fallback on the next similar contract if policy allows, without forcing another full review cycle.

Threshold-based auto-approval is a speed outcome built on disciplined data, explicit rule citations, and clear handoff when anything falls outside the playbook. Legal keeps exceptions. The workflow handles the rest.