A correct policy evaluated against a stale fact
Attribute-based access control makes decisions by evaluating policy against live request attributes — role, department, employment status, and similar facts about the principal or the resource. Attribute freshness asks how current those facts actually are at the exact moment the policy evaluates them: whether 'is this employee still active' reflects reality right now, or a value fetched and cached some time before this specific request arrived.
This is a genuinely different failure mode from a mistake in the policy's own logic. The rule can be written exactly right — deny access to anyone no longer employed, say — and the decision can still be wrong, purely because the attribute the rule is checking against hadn't caught up with an employee's actual, current status yet.
An explicit answer, not an assumed one
Systems that lean heavily on attribute-based decisions need an explicit, deliberate answer for how fresh each attribute has to be for the decisions built on it to be trustworthy — not a default inherited incidentally from however the attribute happens to be fetched or cached elsewhere in the system. A slowly-changing attribute like job title can often tolerate real staleness; a fast-changing one like active employment status, tied directly to something as consequential as continued access, generally can't.