Dependency Aging in 2026: Timestamp and Provenance Facts

sales mutual action plan dependency aging study is evaluated below through published evidence and a reproducible, bounded method.

This evidence synthesis evaluates what is required to reproduce dependency aging in a mutual action plan. It does not claim that a particular dependency age predicts win rate. Public standards support consistent timestamps, provenance, controls, and data-quality checks, while the commercial interpretation remains local.

Published structural facts and their limits

These 3 numeric findings describe the cited standards, not observed sales outcomes. The year in the title identifies this review; each source label identifies the version being counted. Applications in the final column are our interpretations, not requirements imposed by the source.

Finding: elapsed time is undefined without four choices

Every duration needs a start event, stop event, clock, and treatment of open records. ISO 8601-1 defines standardized date and time representations, while RFC 3339 specifies an Internet timestamp profile with explicit offsets. Neither supplies a company holiday calendar, so “business days” needs a named calendar and version.

A dependency that remains open at cutoff has no observed completion time. Substituting the cutoff as though it were completion biases the result; excluding every open record hides the backlog. Report open-item age separately and retain the status at the frozen cutoff.

Graph-integrity finding

Aging begins only after the predecessor event defined by the plan. Before calculation, test that each predecessor ID exists, dates follow the allowed order, cycles are absent, and superseded milestones do not remain active. W3C PROV-O provides a useful vocabulary for linking revisions, activities, and responsible agents.

Release counts for eligible dependencies, valid closed dependencies, open dependencies, exclusions, missing predecessors, and cycles. If percentiles are reported, name the interpolation method and group size. An arithmetic mean alone is especially sensitive to a few long-running items.

Reproducible analysis packet

Freeze the plan export, time zone, holiday calendar, status mapping, dependency types, cutoff, and code version. Recompute a sample from raw timestamps and compare the graph before and after deduplication. GAO’s data-reliability guide supports documenting source assessment, testing, and limitations before use.

Compare cohorts only when their clocks and eligibility rules match. A customer-waiting state and an internal-review state may have different owners and stop rules; pooling them can obscure the actual constraint. Report descriptive results without causal language.

Limits

No cited source establishes a universal “healthy” dependency age for sales plans. RFC 3339 section 5.6 specifies a four-digit year in its timestamp grammar, but operational aging thresholds remain policy choices. A defensible internal study must publish exact counts and formulas rather than importing an unsupported benchmark.

Source-by-source evidence register

The sections below distinguish the published claim from our proposed operational application. Sources were checked on September 10, 2026; versioned publications are cited where a control identifier is used.

A date representation is not a working calendar

The ISO 8601-1:2019 abstract describes representations for interchange of dates and times. We rely on that public scope statement, not on inaccessible clauses of the paid standard. The choice of a holiday calendar is a separate input to this proposed dependency analysis.

Capture both the raw source date and the parsed value before measuring an interval. An item opened on a Friday and reviewed on a Monday has one elapsed duration, but its working-time duration depends on the chosen working week, local holidays, and office hours. Give the calendar an identifier and revision so a future analyst can reproduce the calculation after holiday rules change.

Offsets prevent one kind of ambiguity

RFC 3339, section 5.6 defines the Internet timestamp grammar, including a four-digit year and a time offset. Section 4.3 distinguishes an unknown local offset from known UTC. Neither representation identifies which business event should start the dependency clock.

Require a complete timestamp for event-based aging, and keep date-only commitments in a distinct field. Normalize known instants before subtraction, while retaining the original offset for review. If an imported timestamp lacks enough information to establish an instant, count it as a time-quality exception instead of assuming the server's time zone and allowing deployment location to change the metric.

Preserve the graph revision used at cutoff

W3C PROV-O, section 3.2 includes a revision relationship between entities. We apply it to successive plan exports and milestone definitions. It records derivation without claiming that every recorded dependency is valid.

When the customer replaces a procurement prerequisite with a different approval step, preserve the old dependency and identify its successor. The study should calculate aging against the graph that existed at the cutoff, not today's rewritten plan. Missing predecessor links and cycles require explicit validation in the analysis because a provenance link alone does not establish an executable or correctly ordered business process.

Make clock definitions an owned policy

The Federal Data Strategy playbook, Play 1, Step 2 addresses setting a governance vision. Our application is an agreed purpose for the dependency metric: distinguishing waiting states so an owner can act. It is not a mandate to score every milestone against a universal deadline.

The plan owner should approve the event definitions before an analyst sees the resulting durations. Specify whether owner reassignment, customer rescheduling, or a temporary pause creates a new interval or annotates the existing one. Store that policy revision with the results so a change made to improve workflow cannot quietly rewrite the historical trend.

Check whether the export can answer an aging question

GAO-20-283G, What GAO Found frames data reliability around the intended analytical purpose. For dependency aging, a current-state export may lack the event history needed to establish when a prerequisite became actionable. A populated creation date is not automatically the correct start date.

Reconcile eligible dependencies to the plan inventory and inspect a sample against activity history. Classify records with missing activation events separately from those with valid timestamps but long waits. The first group is a measurement limitation; the second may be an operational backlog, and combining them would give the same number two incompatible meanings.

Keep status edits auditable

NIST SP 800-53 Rev. 5, AU-8 addresses timestamps in audit records. Our proposed application stores each dependency transition as an event with a recorded instant. A mutable status field alone cannot show how long the dependency spent in each state.

Retain the previous status, new status, event source, and actor beside the timestamp. If a bulk migration replaces missing event times with the import time, flag those records and exclude them from completed-duration comparisons under a disclosed rule. They can remain in current backlog counts, because presence in the backlog and availability of historical timing evidence are different conditions.

Retain the analysis inputs under an explicit lifecycle

The NARA guidance introduction treats record creation and disposition as part of records management. We borrow that lifecycle perspective for frozen plan exports rather than deriving a private-company retention schedule from federal guidance. A dashboard screenshot does not preserve the underlying graph.

Store the export, calendar version, status mapping, and exclusion file together with an access owner. If the raw records cannot be retained for the intended review period, record that limitation when publishing the metric. A future reviewer should know whether a missing predecessor was absent at cutoff or became unavailable only when a source system later removed its history.

Keep predictions separate from observed age

NIST AI RMF 1.0, MEASURE 2.5 requires attention to validity and generalisation limits. That is relevant when a model predicts which open milestones will miss their dates. The observed age table should remain a separate, reproducible output.

Retain the model version, prediction time, and available input fields if predictions are added to the study. Do not backfill future completion facts into the earlier feature set, since doing so would make the retrospective model evaluation unrealistically informative. A long age can be a model input, but this synthesis supplies no evidence that age alone causes a lost deal.

Make queue ownership visible to the customer-facing team

CISA's 2023 explanation of Secure by Design describes ownership, transparency, and leadership as software-security principles. Their relevance to a sales plan is an organizational analogy, not a scheduling standard. They do not specify escalation ages.

Our proposed adaptation is to name who owns an unresolved dependency and make the reason for a pause visible to the plan coordinator. If the responsible team changes, record the handoff instead of resetting the item to a younger apparent age. Report internal and customer-owned waits separately so a single average does not conceal where an escalation can actually help.

Use governance outcomes only where the dependency concerns security

NIST CSF 2.0, GV.RR-02 addresses established and communicated cybersecurity responsibilities and authorities. It can inform ownership of a security-review prerequisite within a sales plan. It does not govern unrelated pricing approvals or customer budget decisions.

For a security dependency, identify the person who can approve the outcome as well as the person collecting documents. Track the acceptance event from that authorized owner rather than treating an assistant's upload as approval. This distinction makes the completion definition testable and avoids measuring the speed of document handling as though it were the speed of a substantive security decision.

Sources

For sales mutual action plan dependency aging study, these authoritative materials support the specific standards, structures, and control principles identified above. They do not supply company-specific sales outcomes.

1. ISO 8601-1:2019 overview
2. RFC 3339: Date and Time on the Internet
3. W3C PROV-O
4. Federal Data Strategy: Data Governance Playbook
5. GAO Assessing Data Reliability
6. NIST SP 800-53 Rev. 5
7. NARA Records Management Guidance
8. NIST AI Risk Management Framework
9. CISA Secure by Design
10. NIST Cybersecurity Framework 2.0

The related operating workflow explains how to capture the source records needed for a future internal measurement. The CRM data hygiene guide provides the second internal control reference for source maintenance.

FAQ

Can open dependencies be dropped?

No. Report their count and current age separately so the backlog remains visible.

Does ISO 8601 define business days?

No. It standardizes representations; the organization must name its business calendar.

What must be frozen?

The graph, timestamps, cutoff, calendar, status mapping, inclusion rules, and calculation code.

Does older mean commercially harmful?

This descriptive design does not establish a causal business effect.