Campaign 3 — Lifecycle normalization

Status

This campaign declares the lifecycle of the 63 repositories whose latest observed push was in 2024 or 2025.

The partition is exact:

Group	Lifecycle	Count
Maintain	maintenance	5
Repair, then maintain	maintenance	12
Conditional revival	candidate	4
Freeze as historical evidence	frozen	21
Supersede and decide disposition	superseded	21
Total		63

The apparent mismatch previously seen in the full estate—23 frozen and 25 superseded—came from including repositories outside this campaign's cohort. One frozen repository was last pushed in 2026, one frozen repository was pre-2024, and four superseded repositories were pre-2024.

Canonical source

The declared decisions live in:

estate/lifecycle-decisions-2026.yaml

The Campaign 1 repository shards remain the observed inventory and structural classification. The Campaign 3 decision ledger adds:

• explicit declaration provenance;
• the campaign group;
• documentation action;
• settings action;
• review cadence;
• successor where already established;
• the distinction between archive recommendations and deletion review.

Generated views:

generated/lifecycle-normalization.csv
generated/repository-settings-checklist.csv
generated/lifecycle-banner-queue.csv

Validate or regenerate them with:

make lifecycle-check
make lifecycle-generate
make lifecycle-all

Lifecycle semantics

maintenance

The repository remains useful, but the default commitment is verification rather than feature development.

For the five bounded-maintenance repositories:

• retain the repository;
• add a lifecycle statement;
• verify annually;
• repair only observed breakage or unsupported public claims;
• do not create a modernization project merely because dependencies are old.

For the twelve repair targets, maintenance begins after the front door and canonical verification path are truthful.

candidate

The repository is preserved but inactive.

Revival requires all of:

1. a named current consumer;
2. a concrete capability the consumer needs;
3. evidence that the current estate does not already provide it;
4. the smallest bounded extraction or verification that satisfies the need.

Interest, elegance, or historical promise is not enough.

frozen

The repository is historical evidence.

Frozen does not mean poor quality, abandoned failure, or archived GitHub settings. It means:

• preserve the artifact and its context;
• add a visible historical banner;
• record the period, purpose, and limitations;
• retain useful lineage links;
• do not upgrade dependencies or reproduce results unless a new research or institutional use explicitly requires it.

superseded

The repository is no longer authoritative.

Before archiving:

1. merge a lifecycle/context PR;
2. identify a successor when one exists;
3. remove unsupported current-status language;
4. check whether any live deployment, package, submodule, workflow, or external link still depends on it;
5. apply the GitHub setting;
6. verify that the successor and historical links remain navigable.

econ-agg-shocks, test, and test3 are delete-review, not automatic deletions. Deletion remains a separate human decision because it destroys repository-level history and redirects.

Settings boundary

The connected GitHub app can create branches, text changes, and pull requests, but it does not expose:

• archive;
• delete;
• rename;
• visibility;
• fork detachment.

Those actions remain manual.

Use generated/repository-settings-checklist.csv as the execution queue. The default rule is:

Merge the lifecycle/context PR before applying an archive setting.

Do not archive frozen repositories merely because they are inactive. frozen and archived are intentionally distinct.

Documentation waves

Wave A — maintenance and candidate banners

Nine compact PRs:

• five annual-maintenance repositories;
• four consumer-gated candidates.

These establish the banner form and require little semantic investigation.

Wave B — historical context

Twenty-one PRs, grouped by genealogy where possible:

• economic complexity;
• spatial methods;
• public and institutional data;
• teaching and community artifacts;
• miscellaneous finished demonstrations and assignments.

Each PR should preserve the existing README and add only enough context to prevent modernization pressure or false currency.

Wave C — superseded disposition

Twenty-one PRs.

The README should state:

• that the repository is superseded;
• whether a named successor exists;
• what historical or compatibility value remains;
• whether the recommended setting is archive or delete review;
• what must be checked before the setting changes.

Settings should be applied only after the corresponding PR is merged.

Acceptance criteria

Campaign 3 is complete when:

• all 63 decisions remain an exact partition;
• lifecycle decisions are declared in the control plane;
• every maintenance, candidate, frozen, or superseded repository has a truthful visible entrance;
• successor links are present where supported;
• every settings action has an explicit prerequisite and execution owner;
• the three delete-review repositories receive separate human decisions;
• generated reports match the canonical decision ledger;
• repository settings, after execution, agree with the registry.