Campaign 4 — truthful freshness and deployment

Audit date: 2026-08-04.

Purpose

This campaign prevents repository recency, configured automation, committed future periods, and legacy deployment branches from being mistaken for current trustworthy products.

The machine-readable audit is estate/freshness-audits/2026-08-04.json. The review queue is generated at generated/freshness-review-queue.csv.

Results

Repository	Declared state	Verification
IPC-Argentina	Observed through July 2025; six-month projected tail through December 2025; daily workflow configured but last successful run unknown	expected green
empleoARG	Versioned historical snapshot through 2023 Q1; no repository automation identified	expected green
canastasINDEC	Derived, repriced and partly synthetic artifact; not an official current basket series	expected green for declared boundaries
min-economia-arg-datos	Weekly workflow configured but structurally inconsistent with repository paths; gh-pages is a hard-coded demo	expected red until repaired
atlas-pobreza-docs	Documentation draft; old gh-pages build and placeholder production configuration	expected red until repaired

Integration decisions

• Freshness is a property of a named artifact, not of the repository push date.
• A future maximum period does not imply observation: projected and synthetic periods must be declared.
• Automation is configured, healthy, or unknown; configuration alone is never called healthy.
• Public documentation surfaces remain downstream projections and must link to authoritative producers.
• canastasINDEC cannot be fresher than its IPC-Argentina dependency.
• Known-red checks are intentional gates. They should become green only through the linked bounded repair packet.

Commands

make freshness-check
make freshness-generate
make freshness-all

freshness-check validates the audit declaration and committed generated queue. It does not execute remote data sources or public deployments.

Close condition

Campaign 4 documentation is complete when:

1. the five repository PRs and this control-plane PR are merged;
2. make freshness-check passes in projects;
3. the three expected-green repository checks pass against their real committed artifacts;
4. the two expected-red checks are recorded as repair work, not ignored;
5. no README claims automatic current data or a verified deployment without execution evidence.

Runtime repair remains a later Codex/local task.