Planning method

Freshness is field-specific, not a site-wide badge

“Fetched today” is not the same as “safe for every decision today.” A place identity, a ticket rule, a weather forecast, and a route snapshot have different clocks and different meanings. Asmaliana keeps those clocks attached to the field or provider result instead of collapsing them into one green label.

Read the status dimensions separately

For a public assertion, inspect at least:

• review_status: whether the claim passed the declared review process;
• freshness_status: whether its recheck/applicability policy is current;
• resolution_status: whether the value is known, unknown, conflicting, or restricted;
• checked_at, valid_from, valid_to, and recheck_due_at: the clocks that explain the decision.

A claim can be reviewed and still be stale. A claim can be fresh and still be unknown because the source does not establish a value. A restricted value is not silently converted into unknown on one representation and exposed on another; the same rights-filtered projection is used in HTML, Markdown, JSON, REST, and MCP.

Different fields age at different speeds

An identity coordinate may be rechecked on a long schedule, while a ticket table or an operating interval needs a shorter review window. A certificate also has business validity that is separate from the moment its source page was retrieved. The timestamp that matters is the one attached to the assertion and the requested decision date, not the response timestamp alone.

Weather and routing have provider clocks as well. A forecast has issue and valid times plus a coverage horizon. The reviewed route matrix has a finite valid_to deadline; when it expires, the planner returns a stale or blocking unknown state rather than reusing an old duration or inventing one from straight-line distance.

Re-fetching is not re-reviewing

A source refresh can change retrieved_at and its content hash without proving that the published value changed—or that a reviewer accepted a new value. A safe refresh therefore follows this sequence:

1. fetch the bounded source response;
2. compare normalised values and source rights;
3. create or update a candidate with lineage;
4. review the candidate for the intended fields and surfaces;
5. publish a new immutable dataset revision only after the release gates pass.

If the normalised value is unchanged, retaining the prior checked/recheck clock is more honest than pretending a download alone was a fresh review.

What to do with an overdue field

Do not quietly substitute yesterday’s value, a search-engine snippet, or an uncited assumption. Read the operation-level result:

• fresh can support the field within its stated scope;
• stale means it must not establish a current hard constraint;
• unknown means the evidence never established the field;
• needs_verification tells the caller what remains unresolved.

The status endpoint and the daily operations audit expose the effective fresh, stale, unknown, and overdue counts. They are signals for a controlled refresh, not permission to bypass source rights or the publication review.

A compact reading checklist

Before relying on a field, ask:

1. Is this the right entity, branch, service, and requested date?
2. Was the value reviewed for this use and representation?
3. Is its validity window still open, and is its recheck deadline overdue?
4. Do applicable source groups agree?
5. Does the result disclose assumptions, unchecked dimensions, and the next action?

If any answer is unavailable, keep the uncertainty visible. That is a more useful result than a site-wide “verified” badge that hides which part has aged.