## TL;DR

Per-diem rates change yearly, and the agent loaded the 2025 table for 2026 travel, so every validation used outdated rates. Version the rate tables by effective year (and load the table whose range covers the travel date), then re-validate the affected claims. Date-keyed configuration is the fix; hardcoded tables are the bug.

## Error

```text
agent applied the 2025 per diem table to 2026 travel dates
```

## Steps

1. Confirm the staleness: compare the rates the agent used against the published 2026 table. Expected: the agent's rates match 2025, not 2026.
2. Store rate tables with effective date ranges (e.g. table_2026 valid 2026-01-01 to 2026-12-31). Expected: each table carries its validity window.
3. Change the agent to select the table by travel date, not by a hardcoded year. Expected: a 2026 travel date loads the 2026 table.
4. Re-validate all claims the agent processed with the wrong table. Expected: the re-validation flags the newly mispriced claims.
5. Add a startup check that warns when the newest table is older than the current year. Expected: stale tables are caught before the next audit run.

## When to use

- An agent validates per-diem claims against the wrong year's table.
- Rates change yearly and the agent hardcodes the table.
- Re-validating claims after a table update.

## When not to use

- The destination has no rate at all (a missing-entry problem).
- The rate is right but the dates are wrong (a date problem).
- The policy uses a flat company rate, not yearly tables.

## Tool compatibility

Applies to custom audit agents validating per-diem claims (Python, agent frameworks; current 2026 releases).

### Variant phrasings

### stale rate table in the audit agent

Version tables by effective date and select by travel date.

### per diem validated against last year's rates

Reload with the current table and re-validate the affected claims.

### hardcoded year in the agent's config

Replace with date-keyed table selection.

## Why it happens

Yearly-published tables (government per-diem schedules, company updates) change the numbers while the agent's configuration stays frozen. A hardcoded table year works until January, then silently misprices everything. Keying table selection to the travel date makes the agent correct across year boundaries by construction.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_zJlZOMFw-VL8gor-8PaN2w