---
name: cn-ib-document-control
description: Build, maintain, and review document-control registers for Chinese investment-banking transactions. Use for IPO、再融资、并购重组、辅导 and diligence projects involving 材料清单、原件清单、签字盖章、彩色扫描、函证、承诺函、调查问卷、合规证明、版本控制、缺失材料、负责人、截止日期、关闭状态 or project-file tracking. Use cn-ib-diligence-workpaper for substantive testing and conclusions rather than document custody and completeness.
---

# CN IB Document Control

Create one auditable register that answers: what is required, what has been received, in what form, which version is current, who owns the gap, and what evidence closes it.

## Principles

1. Never equate `received` with `complete`, `valid`, `signed`, `original`, or `reviewed`.
2. Track each independently controlled item as a separate row.
3. Preserve issuer/entity, document period, required form, and version.
4. Do not delete superseded records. Mark them superseded and link the replacement.
5. Close an item only with reviewable closure evidence.
6. Do not upload or commit confidential deal materials to a public repository.

## Workflow

### 1. Define the register scope

Identify:

- transaction and workstream;
- entities and persons covered;
- applicable period;
- source of the requirement;
- expected document form;
- responsible party and reviewer;
- delivery deadline and critical-path dependency.

Read `references/document-categories.md` to choose categories. Do not force unrelated items into a generic `other` bucket without explanation.

### 2. Create the register

Start with `assets/document-control-template.csv` or reproduce the same fields in an XLSX workbook.

Use a stable `document_id`. Keep the ID after revisions. Create a new row only when the controlled requirement is distinct.

Minimum fields:

```text
document_id, category, document_name, entity, period,
requirement_source, required_form, version, status,
original_status, signature_status, seal_status, scan_status,
owner, reviewer, due_date, source_path, closure_evidence, notes
```

### 3. Apply controlled statuses

Read `references/status-taxonomy.md`. Track independently:

- overall workflow status;
- original received;
- signatures complete;
- seal complete;
- scan quality;
- review status;
- superseded status.

Avoid free-text statuses such as `差不多`, `应该齐了`, or `最新`.

### 4. Reconcile received materials

For each delivery:

1. match it to an existing requirement;
2. confirm entity, person, period, document type, and version;
3. inspect completeness, signatures, seals, pages, color, legibility, and validity period;
4. record the source location without moving the original unless instructed;
5. update the register and reviewer;
6. create a new gap when the file only partially satisfies the requirement.

### 5. Run deterministic register checks

For CSV registers, run:

```bash
python3 scripts/review_control_register.py register.csv --output issues.csv
```

The script checks duplicate IDs, invalid statuses, overdue items, unversioned files, and closed items without closure evidence. Confirm every result in context.

### 6. Prioritize follow-up

Classify open items by:

- filing or signing blocker;
- dependency on issuer, sponsor, counsel, accountant, government authority, customer, supplier, bank, or individual;
- time required to obtain;
- expiry risk;
- whether a scan, copy, original, notarization, translation, signature, or seal is missing.

Produce a concise follow-up list grouped by owner, not only by document category.

### 7. Close and archive

Before setting `closed`:

- confirm the exact requirement is satisfied;
- record the accepted file/version;
- record reviewer and review date;
- record closure evidence;
- preserve unresolved qualifications;
- link any superseded item.

Retain only final requested registers in the project directory. Keep previews and extraction files in temporary storage.

## Outputs

Deliver:

1. master document-control register;
2. blocker list;
3. owner-based follow-up list;
4. upcoming deadline and expiry list;
5. duplicate/superseded/version exception list;
6. short completion statistics by category and entity.

Never report `100% complete` when critical fields are blank, closure evidence is missing, or unreadable files were not inspected.