A Contract Review Bot That Diagnoses Its Own Regex Failures

Motivation: Contract review is genuinely draining

Anyone who has worked in procurement or legal liaison probably knows the feeling: a contract comes in, and the formats are all over the place—some are Word, some are PDFs with a text layer, and others are directly photographed or scanned images. Manually reviewing a procurement contract, just pulling out key clauses like Party A and Party B, contract amount, payment ratio, delivery and acceptance, liability for breach, and auto-renewal, and then judging the risks, takes at least half an hour. When the volume of contracts piles up, the biggest fear isn't slowness, it's missing something—a clause like "If no objection is raised 30 days before the contract expires, it will automatically renew for one year, and the renewal price will follow Party B's current quotation," hidden at the very end, can mean a real financial loss if overlooked.

So I wanted to build something: throw in a contract (any format, even scans), and it automatically spits out a structured element table + risk list + modification suggestions. But I added one acceptance criterion: the report should be traceable back to the original text, so I at least know why it flagged something as a risk. I happened to have WorkBuddy and a few OCR skill packs from Tencent Cloud on hand. This post records the complete process, from installing the skills, configuring the environment, and packaging them into a dedicated assistant, to testing with 5 contracts in different formats, including a few "crashes" along the way.

Overall Approach: Three OCR capabilities assembled into a "dedicated brain"

Breaking down contract review, it's three actions: recognize the text → extract the elements → read the tables clearly. So I chose three Skills from Tencent Cloud to divide the work:

• General Accurate OCR GeneralAccurateOCR: The foundation. Scanned PDFs and photos don't have a text layer, so this is needed first to pull out all the text on a page.
• Table Recognition V3 RecognizeTableAccurateOCR: Handles detailed tables like procurement lists and payment schedules in contracts. Standard text recognition often messes up rows and columns in tables.
• Real-time Document Extraction Agent ExtractDocAgent: The core. Extracts structured information from the contract based on my custom-defined fields.

But I quickly found a problem: manually stringing these three skills together for every contract review was a hassle. So this became the focus of the post—I simply let WorkBuddy help me package these three capabilities into a dedicated skill that automatically completes the entire process of "format judgment → OCR → element extraction → risk analysis → report generation." The responsibilities of the three capabilities must be clear: OCR solves "was it read," the extraction Agent solves "what is the field," and the rules and model collaborate to solve "where is it suspicious"; the final acceptance or rejection remains a human judgment.

The entire chain looks like this:

A contract (TXT/DOCX/Text PDF/Scanned PDF)
      │
   Format Detection ──→ Scanned? ──Yes──→ General Accurate OCR for full text
      │                          │
   Contains tables? ──Yes──→ Table Recognition V3 ────┤
      │                          ▼
      └──────────────→ Document Extraction Agent (extract 20 contract elements)
                                 │
                          Risk Rule Engine (7 categories)
                                 ▼
                   Contract Review Report.html + Review Result.json

This chain also has a practical benefit: each step can be verified independently. If the format judgment is wrong, check the OCR branch; if the text is fully read but fields are missing, check the extraction configuration; if the number of risks is abnormal, go back to the rules and evidence snippets. When a problem occurs, you don't have to rerun the entire system as a black box.

Preparation: Install the three Skills first

In WorkBuddy's left sidebar "Experts · Skills · Connectors," enter the skill marketplace and install the three Tencent Cloud OCR skills mentioned above one by one. The interface is very straightforward; search by name and click install.

Don't rush to use them right after installation—Tencent Cloud Skills like these have a common trait: installing just puts the "calling code" locally; to actually run them, you still need the Python SDK, API keys, and the service activation status. If this step isn't done, the skills might start but won't get valid results.

Offload the "environment setup" hassle directly to WorkBuddy

In the past, installing SDKs, filling in keys, and activating services was the most daunting part for beginners. This time, I just took a shortcut and directly asked it: "Can you check if the 3 Tencent Cloud OCR Skills I installed are usable?"

WorkBuddy spent about 1 minute and 47 seconds doing a round of self-checks, and the conclusion was clear:

• The three SKILL.md files, their respective scripts/main.py, env_loader.py, and channel_detect.py were all present;
• tencentcloud-sdk-python was not installed;
• TENCENTCLOUD_SECRET_ID / TENCENTCLOUD_SECRET_KEY were not configured, and no .env file was found.

Then it directly listed "what you need to do": ① Install the Python SDK; ② Go to key management to get the SecretId / SecretKey, and activate the OCR service in the console.

A security reminder here: When I got the key on the key management page, Tencent Cloud popped up a prompt—it is not recommended to directly use the main account's API key; a more standard practice is to create a sub-account and authorize it with the least privilege. Also, never screenshot and leak the SecretKey; I will only refer to all key-related places by name below.

Then I took over the conversation: "Install the missing SDK for me, I already have the SecretId / SecretKey, where do I activate the OCR service?" WorkBuddy installed tencentcloud-sdk-python in an isolated virtual environment while pointing out the activation entry for me.

I followed the instructions and clicked "Activate Now" for the text recognition service in the console. Each interface came with a free quota (ranging from tens to 1000 calls), which was more than enough for testing.

After everything was configured, it proactively ran another round of end-to-end verification:

• General Accurate OCR: An image saying "Hello OCR Test 123" was recognized completely correctly;
• Table Recognition V3: A 3-row, 2-column table, all 6 cells correct;
• Document Extraction Agent: A simulated contract, 3 fields extracted, all correct.

The final environment was set: SDK 3.1.161 (isolated venv), keys (shared by the three Skills), services activated, and temporary test files automatically cleaned up.

I found this part quite interesting: the entire process of "install SDK + configure keys + activate services + self-test verification" was done with almost no manual command typing. I used dialogue to let the Agent diagnose and complete it itself. This is also what gave me the confidence later to let it directly package the skills.

The Key Step: Have WorkBuddy package the three Skills into a "Contract Review Assistant"

After each of the three skills was verified individually, I actually reviewed a contract and immediately felt the friction: first call text recognition for the full text, then call table recognition, then call the extraction Agent, and finally piece together the risk judgment myself—manually stringing this together for every contract was far from my original idea of "throw it in, get a report out."

So I explained my needs verbatim to WorkBuddy, asking it to orchestrate these three capabilities into a dedicated skill: automatically judge the format, OCR where needed, read tables where needed, then extract according to contract elements, and finally run risk rules and generate a report.

It spent about 14 minutes creating and self-testing a skill called contract-review-assistant. The structure was like this:

~/.workbuddy/skills/contract-review-assistant/
├── SKILL.md                 # Skill description and usage instructions
├── scripts/
│   ├── main.py              # Main orchestration: format detection→OCR→element extraction→risk analysis→report
│   ├── contract_fields.py   # 20 contract element definitions + regex matching
│   ├── risk_rules.py        # 7-category risk rule engine
│   ├── report_generator.py  # HTML report generator
│   ├── env_loader.py        # Key loading (reused from OCR skill)
│   └── channel_detect.py    # Channel detection (reused from OCR skill)
└── references/
    └── risk_rules.md        # Detailed risk rule documentation

It performed end-to-end verification using a self-made test_contract.png: format detection correctly identified it as an image → text recognition extracted 615 characters → table recognition completed → document extraction 20/20 → risk rules hit 7 items (5 high, 2 medium). Usage is also very simple: just send the contract file to it, or run python scripts/main.py --input contract_file_path in the terminal, producing Contract Review Report.html + Review Result.json.

At this point, the "dedicated brain" was essentially molded. Next came the real test—feeding it 5 fictional contracts in different formats one by one. I specifically emphasize "fictional" here because the article demonstrates the process and boundaries, not real contract information.

Real-world testing: 5 contracts in different formats

I prepared 5 contract samples covering different formats and difficulty levels (all are fictional test materials; Party A, Party B, amounts, and addresses are all fabricated), uploading them from easy to hard, focusing on three things: was the content fully read, were the elements fully extracted, and were the risk subjects reversed. The third point was a key acceptance criterion I only realized later.

TXT text version: Crashed on the first try, then fixed itself

The first was a plain text "Industrial Sensor Procurement Contract." I said, "Analyze using the Contract Review Assistant," and it automatically invoked the newly packaged skill.

But the first run immediately showed its flaws: only 3 risks were detected, and only 12/20 elements were extracted, clearly too few. What surprised me more was that WorkBuddy discovered the problem itself, checked risk_rules.py, and gave the judgment: "The regex patterns were basically written against that test contract and don't cover real Chinese contract phrasing enough," then automatically supplemented 5 missed detection rules for unilateral price adjustment, risk transfer, lack of acceptance criteria, etc.

After the fix, a rerun (total time for this sample, including self-optimization, was about 12 minutes 31 seconds): Elements 12/20 → 17/20, Risks 3 → 11 items (7 high, 4 medium), basically digging out all the buried landmines like disproportionately high payment ratio, unilateral price adjustment, early risk transfer, missing acceptance criteria, auto-renewal, imbalanced liability for breach, and dispute jurisdiction at Party B's location.

My judgment: This "crash → self-diagnosis → self-repair" segment is actually more valuable than a smooth first run—it exposed the real weakness of the rule engine and also showed how important it is to back-test with real data. After the rules were supplemented, we still need to observe whether false positives increased.

A note on invocation methods

After the skill is packaged, besides natural language invocation, you can also directly select contract-review-assistant from the skill menu to specify the call, saving it from having to guess.

DOCX table version: Done in 52 seconds

The second was an "Office Equipment Procurement Contract" (DOCX) with a procurement list table. This one was the most hassle-free, completed in 52 seconds, extracting 14/20 elements and detecting 2 risks (both medium): a 70% prepayment was too high, and dispute jurisdiction was at Party B's location. The model/quantity/unit price in the table were also neatly read out without row or column mix-ups.

Text-based PDF: Identified 8 risks, but also exposed a directional bug

The third was a "Cloud Service Procurement Contract" PDF with a text layer. It ran for about 4 minutes and 44 seconds, detecting 8 risks (4 high, 4 medium), with an overall judgment of "very unfavorable to Party A": 100% prepayment, all SLA indicators missing, auto-renewal combined with Party B's unilateral pricing, no acceptance assessment (high); missing data clauses, overly broad liability exemption with a low compensation cap, restricted termination rights for Party A, jurisdiction at Party B's location (medium).

The most interesting part of this one was its honest self-assessment: the deterministic regex engine only hit 3 of the 8 landmines I planted (the rest were supplemented by the model's semantic understanding), and there was one directional misjudgment—the original text stated "jurisdiction at the court of Party B's location," but the tool output "Party A's location"; additionally, the jurisdiction field was mixed into the beginning of the full text, and the contract amount and payment method were not extracted by the regex.

My judgment: This precisely illustrates that "rule engine + large model understanding" is a two-legged walk—rules are fast and explainable but brittle; models have broad coverage but can stumble on details like direction and subject. Without original text evidence in the report, secondary verification would be very difficult.

Scanned PDF: Full OCR chain, elements 20/20

The fourth was an image-based PDF without a text layer (a single-page scanned "Cloud Service Procurement Contract"). This one best demonstrated the value of OCR: it went through the complete chain of "General Accurate OCR for full text → Table Recognition → Document Extraction Agent," taking only about 1 minute and 41 seconds, extracting all 20/20 elements, with the rule engine detecting 2 risks (high: auto-renewal without prior notice; medium: jurisdiction at Party B's location). A pure image contract transformed into 20 structured fields—the experiential difference in this step was the most obvious.

Six-page scan: A "false negative" that was almost missed

The last one was a six-page image-based scanned PDF ("Equipment Procurement, Installation, and Maintenance Contract").

The skill's main script only OCR'd page 1, completely missing the next five pages, so naturally, it "saw" no risks—a classic false negative. Then it supplemented a page-by-page processing script itself, recognizing all 6 pages before reviewing, reaching a text volume of 2497 characters, extracting 19/20 elements, detecting 7 risks (5 high, 2 medium): unilateral price adjustment, early risk transfer, tenfold disproportionate penalty for breach, auto-renewal, missing acceptance criteria, etc.

By the way, a small bug: the "unilateral price adjustment" item in the risk template had the direction reversed, with the report stating "Party A enjoys the right to adjust prices," when in fact the original text had Party B as the adjusting party. This is the same type of issue as the jurisdiction location being written in reverse—the rule templates' handling of subject direction is still not stable enough.

Horizontal comparison of the five contracts

Summarizing the 5 samples into one table makes the effectiveness very intuitive:

Sample	Format	Time Taken	Element Extraction	Risk Detection	Notes
01 Industrial Sensor	TXT	≈12m31s (incl. self-optimization)	12→17/20	3→11 items (7 high, 4 medium)	Initial missed detections, Agent self-repaired regex
02 Office Equipment	DOCX	≈52s	14/20	2 items (2 medium)	Fastest, table read correctly
03 Cloud Service	PDF (text layer)	≈4m44s	—	8 items (4 high, 4 medium)	Exposed directional misjudgment
04 Cloud Service	PDF (single-page scan)	≈1m41s	20/20	2 items	Full OCR chain, perfect element score
05 Equipment Procurement & Maintenance	PDF (six-page scan)	≈3m38s	19/20	7 items (5 high, 2 medium)	Main script only OCR'd page 1→supplemented page-by-page

A perceptible comparison: in the past, manually pulling out the elements of a multi-page contract and then going through the risks took me at least half an hour from experience, and the longer it went, the easier it was to lose focus and miss things; using this assistant, except for the first one which took over ten minutes due to online rule optimization, the rest produced structured reports within 1 to 5 minutes, and it wouldn't miss hidden clauses like "auto-renewal" or "unilateral price adjustment" tucked away at the end due to fatigue. However, the experience of the six-page scan only reading the first page also shows that speed improvements cannot come at the expense of completeness checks.

Who it's for, and what else can be played with

The core of this combination isn't the three OCR skills themselves, but the act of packaging them into a dedicated skill based on a business process—turning "three tools" into "one assistant" that is reusable, iterable, and capable of self-correction. It suits procurement, legal, and administrative staff who frequently deal with contracts/documents in messy formats and suffer from slow manual initial reviews.

From the initial small idea of "throw in a contract, get out a structured report" to actually running through 5 formats and smoothly stepping on a few landmines along the way, my biggest takeaway from this whole endeavor is: the barrier to "assembling" AI capabilities into a handy, dedicated tool is lower than imagined—the hard part was never the invocation, but polishing it with real data until it's usable.

When landing this, I would position it as an "initial review assistant," not an automatic approver: keep three layers of records—original text snippets, machine extraction results, and human conclusions; for scanned documents, first verify the page count and text volume; for risks involving subject direction, perform another round of manual or model review. This way, efficiency gains won't come at the cost of accountability.

The contracts in this article are all fictional test materials. The test results are used to illustrate the process and boundaries and do not constitute legal advice.