SHEYU.AI舍予基业
Products/ZHISHEN · SHEYU AI REVIEW
ZHISHEN · Grant Application Review

Application packages into a checkable evidence table.

Tens to hundreds of pages, read in seconds. Every value carries its page, source text and a two-engine cross-check, so reviewers only confirm or override.

EVIDENCEvalue · 7 fields
Extracted value
  • File✓
  • Page✓
  • Coordinates✓
  • Source text✓
  • Extraction method✓
  • Engine cross-check✓
  • Confidence✓
7metadata fields on every value
4possible verdicts, never a default pass
5pipeline stages per package
4separated user roles
It does not review for you. It makes review faster, and makes it hold.
Why

No risk scores that cannot be traced

Before
With ZHISHEN · SHEYU AI REVIEW
Conclusion
Materials go to a large model, which returns low, medium or high risk.
Every conclusion traces back to the original guideline text.
Reviewer work
Reviewers search the materials page by page.
Reviewers confirm or override each extracted value.
Output
A number like "risk 0.73" that cannot go into an official document.
One of four plain verdicts.
Verdicts

Four verdicts, each in plain words

No probability scores. Each result states what it rests on.

Pass: the rule matched and the data is complete.
Fail: a deterministic rule found a mismatch, with the gap and the guideline clause named.
Needs human: input missing or on the boundary. The system does not guess.
Not verified: data source not connected or list not imported. Never treated as a pass.
Pipeline

Five things happen to every package

  1. 01

    Intake

    PDF text layers are read with coordinates, scanned pages go through local OCR, and Word and Excel files are accepted. Files are deduplicated and sorted against the required-documents list.

  2. 02

    Verify

    Deterministic checks such as credit code check digits, budget sums and date logic; hard matches against the in-house database for duplicate applications; and data-sharing interfaces. Each rule cites its guideline text.

  3. 03

    Compare

    Figures are compared with past projects in the same topic by median and quartiles. Marked as reference only, not grounds for rejection.

  4. 04

    Report

    A field evidence table for side-by-side checking, and a pre-review opinion in Word and Markdown. Return reasons list only items the applicant can fix.

  5. 05

    Govern

    Topic settings are frozen per year as snapshots, and each package is pinned to the version in force when it arrived. Revised guidelines do not reopen old cases.

Batch review

Review a whole batch, not one file at a time

A batch of projects is reviewed as one unit. People work only on the cells the system is unsure about.

Batch review
  • Progress with an estimated finish time, based on measured speed
  • Overview matrix: projects × rules, sorted by number of problems
  • One review queue for every 'needs human' item in the batch, with keyboard shortcuts
  • Batch issuing: passes, and returns with reasons filled in; the whole batch's opinions as one zip
  • Cross-project duplicate check runs automatically when the batch finishes
  • Batch summary exported to Excel
Four laws

Four rules behind every number

01

Locate, then extract

Fields are mapped to specific pages through the section tree. The model reads only those pages, not the whole package.

02

Code for numbers, model for meaning

Amounts, dates, counts and ratios are read and computed by code. The model steps in only when tables, regex and counting all miss, and must cite the source text.

03

No source, no value

A model value not found in the original text is voided on the spot and logged.

04

Four verdicts, no default pass

Pass, fail, needs human, not verified. If a data source is not connected, it says so instead of letting the item through.

Evidence

Seven facts attached to every value

Each extracted value carries its own provenance. Reviewers open any row and compare it side by side with the original page.

  1. 01File
  2. 02Page
  3. 03Coordinates
  4. 04Source text
  5. 05Extraction method
  6. 06Engine cross-check
  7. 07Confidence
Acceptance checks

Checks that read the materials themselves

01

Seals and stamps

Red seals are detected on each page: how many, what shape, and whether a seal straddles the page edge. Handwritten signatures are left to people.

02

Bound PDFs split by content

A single file holding a summary report, audit report and pledge letter is split page by page into each document type.

03

Same project, same organisation

Project name and lead organisation are compared across the contract, acceptance form and audit report.

04

Contract targets vs. results

Targets are read from the contract; completed values are taken only from the other materials.

05

Cross-project duplicates

The same invoice number, the same file or the same page turning up in more than one project.

06

Guideline checkpoints

Requirements like 'stamped', 'signed and dated' or 'report must cover the contract indicators' are checked with page evidence.

Configuration

From guideline to rule set, without code

Import a guideline or acceptance requirement and the system drafts required documents, fields, rules and checkpoints. Nothing takes effect until someone approves it.

Deterministic parsing always runs, section by section
With a model configured, every drafted item must cite a line number in the original, or it is dropped
Approve by merging into or replacing the topic configuration
Rule builder with templates: fields must match, compare to a limit, ratio, date order, duration, must be readable, conditional document, one of several documents, checkpoint
Custom expressions for advanced users, checked against a whitelist
Architecture

Multiple programmes and years, built in from the start

01

Programme group

Where the guideline comes from. One guideline, one group; used for grouping and provenance.

02

Topic

Which criteria apply. Each has its own required documents, field dictionary, rule set and comparison pool.

03

Topic family

Whether it is the same thing across years. Duplicate checks, like-for-like comparison and reviewer access follow it.

04

Annual version

Which rules a package was reviewed under. Cloned from last year, edited, and frozen as a snapshot on release.

05

Application batch

Whether packages can be received now. A closed window takes no more packages.

06

Applicant pre-check

Applicants can self-check before submitting and see only items they can fix.

Security

Data stays inside the network

Designed to run offline in a government network: local recognition, swappable models, role separation and a full audit trail.

Security
  1. 01OCR runs on the local CPU, not in the cloud.✓
  2. 02Uses an OpenAI-compatible interface; pointing it at an in-network model changes one address line. Without a model, those items fall back to manual entry.✓
  3. 03Four roles: administrator, reviewer, auditor, applicant. Audit and applicant views are masked, and page images are watermarked.✓
  4. 04Every override and every model call is logged and can be replayed.✓
ZHISHEN · Who uses it

Four roles, each seeing only what it should

Administrator

Sets up programmes and keeps the system running.

  • Programme groups, topics and annual versions
  • Guideline import and rule approval
  • Accounts and assignment
  • Backups and governance
Reviewer

Confirms or overrides what the system extracted, within assigned topic families.

  • Claim packages and work through batches
  • Field evidence table, side by side with the page
  • Review queue of 'needs human' items
  • Issue pre-review opinions
Auditor

Read-only oversight with masked personal data.

  • Full audit log
  • Who overrode which field, and when
  • Model calls and citation checks
Applicant

Sees only its own packages, by credit code.

  • Pre-check before submitting
  • See only items it can fix
  • Submit supplements
  • File an appeal
ZHISHEN · Full specification

Everything in ZHISHEN

Every item below is in the system running at zhishen.agecms.com.

Intake

  • PDF text layer read with coordinates
  • Local OCR for scanned pages
  • Table recognition
  • Word, Excel, images and PowerPoint accepted
  • Content-hash deduplication
  • Sorting into the required-documents list
  • Bound PDFs split into document types
  • Chunked uploads for large packages
  • Group a pile of files into projects by folder or file name

Extraction

  • Field dictionary per topic
  • Table lookup, regex and counting before any model
  • Model values checked against the source page
  • Seven metadata items on every value
  • Chinese uppercase amounts and unit normalisation

Verification

  • Credit code check digits
  • Budget sums and date logic
  • Required documents complete
  • Duplicate applications, past performance and project limits
  • Data-sharing interfaces, 'not verified' when not connected
  • Red seal detection, including seals across page edges
  • Project and organisation consistency across documents
  • Contract targets vs. completed values
  • Cross-project duplicate invoices, files and pages

Comparison and reports

  • Median and quartiles against past projects in the same topic
  • Marked as reference only
  • Field evidence table with side-by-side page view
  • Pre-review opinion in Word and Markdown
  • Expert review brief in Word or Markdown
  • Batch summary in Excel

Batch review

  • Batches with progress and time estimate
  • Projects × rules overview matrix
  • Single queue of 'needs human' items
  • Batch pass and return with reasons
  • Whole-batch opinions as a zip

Workflow

  • Assign and claim
  • Time limits with overdue checks
  • In-app notifications
  • Supplements create a new version, with a diff
  • Applicant appeals
  • Applicant pre-check before submission
  • Time limits and assignment set per topic, programme group or system

Security and accounts

  • Four roles: administrator, reviewer, auditor, applicant
  • Reviewers scoped by topic family; applicants by credit code
  • Masked views for auditors and applicants
  • Watermarked page images and exports
  • Passwords: 10+ characters, three character types, lock after 5 failures
  • Full audit log

Governance and operations

  • Annual configuration snapshots
  • Replay under the archived configuration
  • Regression and perturbation tests
  • Human–machine difference log and rule accuracy board
  • Online hot backups, 14 kept
  • OpenAI-compatible model interface; runs without a model
FAQ

Questions about ZHISHEN

Does ZHISHEN approve or reject applications?

No. It produces checkable evidence and a pre-review opinion; the final approval decision rests with human review.

Can I sign up now?

Not yet. At this stage it is open to internal accounts only and does not accept outside registration.

Does it handle scanned documents?

Yes. Scanned pages go through OCR that runs locally, alongside PDF text layers, tables, Word and Excel.

What happens when a data source is unavailable?

The item is marked "not verified". It is never passed by default.

Does it need a cloud AI model?

No. Any OpenAI-compatible model can be used, including one hosted inside the government network, and it also runs with no model configured.

Can it handle a single PDF with hundreds of pages of bound documents?

Yes. It reads the title area of each page and splits the file into its component documents, so a bound summary report or audit report is not reported as missing.

Does it check seals and signatures?

It detects red seals on each page, including seals across the page edge, and reports the facts with page numbers. Handwritten signatures cannot be detected by colour, so those are left to people.

Can it review many projects at once?

Yes. A batch shows progress, a projects-by-rules matrix and a single queue of items that need a person, and opinions can be issued for the whole batch.