Continuous-Close Freshness
Measure continuous-close data freshness and pipeline-check status.
Description
Close-data freshness compares a recorded timestamp with an assessment timestamp.
Close-data freshness compares a recorded timestamp with an assessment timestamp. Pipeline failures take status precedence.1
Measure continuous-close data freshness and pipeline-check status.
When to use Continuous-Close Freshness
Use this tool to measure continuous-close data freshness and pipeline-check status.
Prepare the documented facts, aligned totals or expected/observed evidence labels requested. Choose applicable requirements and thresholds separately before interpreting a planning screen.
How to use Continuous-Close Freshness and understand its results
- Prepare the documented facts, aligned totals or expected/observed evidence labels requested. Choose applicable requirements and thresholds separately before interpreting a planning screen.
- Enter lastCloseTimestamp, asOfTimestamp, maximumAgeHours, failedPipelineChecks using the field table and calculation rules, then run the tool.
- Read dataAgeHours, ageMarginHours, fresh, assuranceStatus. The explanation below defines the units, signs, ordering and any flags or placeholder values.
- If the tool reports an input issue, correct the values and run it again. Apply the stated assumptions when interpreting a successfully returned result.
| Input field | Meaning | Value type; see rules below | Requirement |
|---|---|---|---|
| lastCloseTimestamp | Last close timestamp | string | Required |
| asOfTimestamp | As-of timestamp | string | Required |
| maximumAgeHours | Maximum data age (h) | number; minimum: 0 | Required |
| failedPipelineChecks | Failed assurance checks | integer; minimum: 0 | Required |
Enter parseable ordered timestamps, nonnegative maximum age and integer failed checks. Return age/margin/inclusive fresh; status failed if any failures, otherwise current or stale.
ageHours=(asOf−last)/3,600,000; margin=maximum−age Units, indexing, boundary conditions and exceptional cases are defined in the calculation rules above.
| Output field | Meaning | Value type |
|---|---|---|
| dataAgeHours | Close data age (h) | number; minimum: 0 |
| ageMarginHours | Freshness margin (h) | number |
| fresh | Data is fresh | boolean |
| assuranceStatus | Assurance status | string; one of "current", "stale", "failed" |
{
"input": {
"lastCloseTimestamp": "2025-01-01T00:00:00Z",
"asOfTimestamp": "2025-01-01T06:00:00Z",
"maximumAgeHours": 8,
"failedPipelineChecks": 0
},
"output": {
"dataAgeHours": 6,
"ageMarginHours": 2,
"fresh": true,
"assuranceStatus": "current"
}
} Limitations and assumptions
Use explicit zones to avoid runtime-local interpretation. No pipeline checks or accounting-close evidence are verified.
Numeric inputs, where present, must be finite. Follow the calculation-specific rules for overflow, underflow and exceptional cases. Extremely large text inputs are rejected. Missing required fields, extra fields, wrong value types and violations of the calculation rules are input errors. A successfully returned false flag is an evaluated outcome; its meaning is explained above.
Alternative or Complementary methods
Use Token Rotation Due: Calculate API token rotation due date and overdue status. For a complementary task, use RTO/RPO Tier Classifier: Classify RTO and RPO against caller-defined application-tier limits.
References
-
Continuous-Close Freshness — tool.io
Similar or alternative tools
- Token Rotation Due
Calculate API token rotation due date and overdue status.
- RTO/RPO Tier Classifier
Classify RTO and RPO against caller-defined application-tier limits.