Provenance and merge policy

Source order

1. Current Ministry of Civil Affairs endpoints for the snapshot date.
2. The 2022 party_branch MCA cache as a historical comparison layer.
3. Cleaned historical records in RICF_private.
4. The published RICF tables tracked in this repository.

Precedence applies within a field and time period. It does not mean older records are deleted. Older sources fill unavailable years and fields, and all source values remain traceable.

First-generation data sources (2013–2016)

The published 2013–2016 tables were crawled, parsed, and compiled manually or automatically by computer programs from the following six sources, ranked by their credibility, as documented with the data paper （RICF的数据来源根据可信度，由以下6个渠道获取）:

1. Annual reports and audited financial reports（年报与财务审计报告）. Chinese foundations are required to submit their annual reports to the civil affairs departments with which they are registered. These reports can be obtained from the foundations’ or the government’s official websites; foundation website addresses are recorded under ba_wb in the basic profile table.
2. Information disclosed by supervising government departments （政府监管机构披露的信息）, for example the annual filings disclosed by the Civil Organization Administration Bureau of the Ministry of Civil Affairs and the Shanghai Administration Bureau of NGOs.
3. Information disclosed by the China Foundation Database（中国基金会网, chinafoundation.org.cn）, an information-disclosing platform supervised by the Civil Organization Administration Bureau, closed in early 2016.
4. Information disclosed by the China Foundation Center（基金会中心网, foundationcenter.org.cn）, an information-disclosing platform run by a nonprofit organization.
5. News from the foundation’s official website（基金会官方网站）; website snapshots are stored with the historical evidence.
6. News from credible magazines or websites（其它可信网站、杂志）.

Raw envelope

Every live response is stored as compressed JSON containing:

• HTTP method, source, endpoint, URL, and token-redacted request payload;
• the unmodified JSON response;
• retrieval timestamp, HTTP status, remote IP, byte count, elapsed time, attempt count, snapshot ID, and response hash.

Processed rows point back to the raw envelope with _raw_artifact.

Identity links

Matching uses the following order:

1. Exact valid unified credit code.
2. Exact historical-ID bridges and exact normalized names from the imported raw_data/index/ evidence.
3. A normalized organization name only when it maps to exactly one current credit code.

Name normalization uses Unicode NFKC, removes whitespace, and does not apply fuzzy matching. Ambiguous or absent matches stay unmatched. Multiple historical IDs for one credit code—and one historical ID reused across credit codes—are written to the conflict table.

The source-index layer contains 43,943 untouched rows. It contributes 1,515 newly linked legacy rows across 591 names and records whether each link came from an exact source-index name, ID bridge, or foundation-catalog name. Twelve safe name changes are emitted separately; 14 ambiguous groups remain unresolved.

The public longitudinal profiles reuse those recorded links; they do not run a new browser-side matcher. Historical panels link by exact recorded credit code or by the deterministic (source_year, historical_ricf_id) crosswalk. The profile retains the historical ID, link method, confidence, and source table. Ambiguous links are excluded and counted in the generated detail manifest.

Variable identity

Organization identity answers which organization. Variable identity answers which measurement, and is decided separately in metadata/variable_crosswalk.json.

The crosswalk is tracked, hand-reviewable, and the only input the panel builder consults. Each mapping carries the grade of evidence that justified it, so a reader can weigh a value by how firmly its meaning is established:

Every panel row carries its grade in mapping_evidence, so an analysis can be restricted to the strongest evidence. As with organization identity, no fuzzy matching is used and nothing is resolved by similarity scoring. The method and its validation are documented in Harmonization method.

The same rule governs historical HTML mappings. A financial context enters metadata/variable_crosswalk.json only when the filing prints both an evidence-graded row label and an exact measure/period header. Pinyin field tokens carry no semantic weight. The current inventory has 594 such mapped contexts; everything else remains source_native_unmapped.

The current annual basic-information section is mapped the same way, in metadata/current_basic_information_mapping.json. Its labels come from the printed headings of six official filing renderings spanning four form revisions — 2019, 2021, 2023 and 2025 — because the form changed between them and a heading present in one is not evidence about another. Twelve labels that had rested on value shape were corrected against those prints: value shape proves a column holds phone numbers or names, never whose.

Every one of the section’s 76 published columns resolves to a codebook variable: 14 by an exact codebook label, 19 by a reviewed synonym recorded with the wording difference it bridges, 3 by an identity test in src/ricf/evidence.py, and the rest as variables the current form introduced, which are added to the Panel Crosswalk sheet rather than to the published 2017 codebook sheets. One column is published with no established meaning and says so. This is what lets the profile render one 基本信息 section for every year and the panel carry the component for 2013-2025 rather than stopping in 2017.

The two current person rosters each use a separate, equally explicit mapping: metadata/current_governance_roster_mapping.json and metadata/current_staff_roster_mapping.json. Human-readable meanings come from exact labels in official MCA filing prints, while the structure and the DOB column are independently tested in src/ricf/evidence.py. The staff form changed in 2025, so its mapping cites two prints and records both heading rows rather than assuming one covers the other; five of its columns exist only in the later form. KBE185 and KBE183 both remain internal; only their privacy-transformed derivatives are public.

Observation provenance

A Chinese annual report restates the prior period alongside the current one, and a balance sheet carries an opening balance. Both are evidence about a neighbouring year, and the panel never presents them as filed values:

A derived observation is emitted only for a year with no filing of its own. Where the year has its own filing, that filing is preferred and any disagreement is recorded in panel_restatements.parquet rather than dropped — the same evidence-preserving rule the registry entity view follows.

Source duplicates

Duplicate report IDs and modified historical records are preserved at the source-row level. Summary and validation files count them. The canonical registry entity view selects the first row in configured type and ascending-page order; displaced page-overlap rows and unkeyed rows are retained in explicit evidence tables. Its manifest states that selection rule and reconciles every source row.

The panel follows the same evidence-preserving rule. It retains 828,347 duplicate keys / 1,875,071 rows and gives every key exactly one deterministic rank 1. Its 594,380 cross-source keys use the tracked lineage policy, including the approved rule that a merged historical lineage outranks either single-source lineage; 233,967 within-table keys prefer direct identity, completeness, and source modification evidence. Identity conflicts are quarantined. The complete ranked set is in panel_duplicate_observations.parquet; the public charts and profiles consume rank 1 and exclude identity-conflicted rows rather than depending on row order.

Latest-filing metadata is represented as sorted candidate arrays when more than one source value exists; the interface displays a single value only when exactly one candidate is available.

Public-data decision

The current project setting treats imported records as public, as directed for this consolidation phase. Raw data still remain outside Git. The release builder excludes operational status tables by default, making a later field-level protection review possible before a public release or GitHub Pages publication. Public availability does not permit commercial reuse: the data and documentation license is CC BY-NC 4.0, subject to the scope and third-party-rights limits in LICENSE.md.

Current financial meanings are published only where the crosswalk records evidence for them; anything else stays source_native_unmapped.

The release gate excludes the companion imports, the historical HTML long tables, and the two rosters that carry a raw birth date. The opaque source-native annual-section tables and the survey remarks were excluded pending a field-level privacy review; that review was carried out when the withholding policy was narrowed to birth dates only, found a birth date in one of them, and released the rest. KBE185 remains the pattern: the DOB-bearing source stays internal while the validated privacy-safe roster is separately catalogued, and KBE183 is now the same: its raw form stays internal while current_staff_roster publishes.

Personal data

The Ministry of Civil Affairs platform is a statutory public-disclosure system. A foundation’s officers, its address, and its contact routes appear there because the law requires the foundation to publish them, and this project republishes them from it. Withholding them would make governance research on Chinese foundations impossible from this site while protecting nothing the source has not already made public.

What is published

What is withheld, and how

One thing, and only one. src/ricf/privacy.py is the only place that decides it; no other module re-implements the rule.

Dates of birth. Published nowhere and reconstructed by nothing. Governance rosters carry an age in whole years at 31 December of the filing year instead, computed by privacy.py at the privacy-safe derivative/publication boundary. A birth date recovered from that age is accurate to a year at best, which is what makes the age publishable where the date is not.

Two source columns are a birth date. akbe1185 is the board and supervisor roster’s, verified by the KBE185 identity test. akbe1161 is the KBE183 staff roster’s, identified when the opaque annual-section tables were reviewed for release: that table has the same shape as the board roster — name, gender, political status, birth date, and a role marker reading 员工 — and its 85,364 dated values have a median year of 1982 with none after 2015, where every event date in these filings spreads across 2015–2026. Both raw tables are excluded from releases, and each has a privacy-safe published derivative: current_governance_roster for the board and supervisors, current_staff_roster for the 85,475 full-time staff rows. Neither derivative carries a birth date under any name.

Withholding the column is necessary but not sufficient, because filers copy the date elsewhere. 49 historical roster rows and 16 current-roster values repeat the member’s birth date in another filed field. On the board and supervisor roster there are 14: ten in the field for the date the member was recorded with the registration authority, and four in the term-start field. On the staff roster there are 2, both in 任职起止时间（起）, that roster’s own term-start column. A value equal to a row’s own birth date is therefore withheld whatever column holds it.

Personal mobile numbers used to be withheld and no longer are. 3,437 of them sat in fields nominally for a landline, a name, a website, an address, or a postcode, four in the registry’s legal-representative field where a name belongs, and all were removed. The argument for removing them was that aggregation changes the exposure: the ministry discloses one organization at a time, and a searchable index of thousands of direct numbers is a different artifact from the source.

On review the maintainer decided otherwise, and the reasoning is recorded rather than the outcome alone. These are values the ministry already publishes under a regulatory disclosure obligation, and withholding them cost research more than it protected — a contact route that a researcher needs to reach a foundation, removed from a dataset whose purpose is to make that research possible. Every phone number a filing declares is now published wherever it appears. The consequence is stated here rather than left to be discovered: the published data is a bulk, downloadable index of contact numbers for named individuals, and anyone redistributing it inherits that. Platform account identifiers (creatorId, modifierId) are no longer withheld either, though the profile’s curated publication schema does not select them; they reach the release through the source-native tables.

Comparing the values as they arrive is not enough either, because the source formats the same date two ways. KBE185 stores a birth date as a timestamp (1956-02-06 12:00:00) and the columns a filer copies it into store a bare date (1956-02-06), so a raw string comparison matched neither. For one snapshot it matched only the * placeholder that occupies both columns, which is why an earlier revision of this page reported 15 withheld current-roster values: those 15 were placeholders, and all 14 real birth dates were published. Both sides are now reduced to a calendar date before they are compared, and a row whose birth-date column holds no date is treated as having no birth date to protect.

foundations/manifest.json counts the values withheld while building Pages and by the two upstream privacy transformations, per roster: 340,312 DOB-bearing rows and 14 copied DOB values from KBE185, 85,364 and 2 from KBE183. A reader can see how much was removed rather than having to infer it.

Attributing a person to an organization

Historical board rosters are keyed on organization name rather than unified credit code, and attaching a person to the wrong foundation is the failure that matters most. Every published historical row therefore records its exact link method and grade. Source-index back-fill is allowed only when the normalized name or historical-ID bridge is unique; unresolved and ambiguous rows remain counted rather than guessed.

Current KBE185 rows are different: the annual filing supplies unified_credit_code, report_id, and section_id, so the public roster uses that direct filing context. Validation requires an exact source-row relationship, no duplicate source IDs, decisive identity evidence, and a summary whose birth-date withholding counts match the derivative. Historical and current roster provenance are displayed separately on the People tab.