FDE BenchmarkPublic document reader
Available in sourcev0.1 · live public draft · official release pending

Canonical source view. This renders the bundled repository document as readable HTML. Source metadata remains in the repository, and relative document links remain inside this reader.

Recency and refresh research protocol

Status: Proposed / Not authorized
Policy effect: Evidence freshness and re-verification research only
Capability decay: Not authorized

1. Research question

How does the age of each evidence class affect the support it provides for a current, scoped claim, and when should corroboration be refreshed?

This is not the same as asking when a person's capability decays. Older evidence remains historical evidence. Its ability to support a current claim may weaken differently by capability, context, evidence class, and rate of technical change.

2. Prohibited shortcuts

The proposal forbids:

  • universal linear or exponential decay across all capabilities;
  • automatic subtraction from a capability value;
  • automatic demotion of an achieved historical trust event;
  • equating recent activity volume with current capability;
  • treating employment continuity, public commits, or social activity as a recency proxy;
  • interpreting missing recent public evidence as low capability; and
  • using recency to bypass human review, correction, accommodation, or appeal.

3. Proposed freshness states

Each eligible claim-to-capability link may carry one of:

  • current_under_proposal_window
  • refresh_due
  • historical_only
  • freshness_unknown
  • disputed

The state describes the support relationship at an evaluation date. It is not a score. A trust event remains in append-only history, while the current readiness state may become refresh_required. A future public system would withhold a stale trust label rather than silently display it as current.

4. Candidate policy structure

Every research rule must be capability- and evidence-class-specific and state:

  • the construct rationale;
  • the evidence and population studied;
  • the candidate freshness and review windows;
  • context-change triggers independent of elapsed time;
  • the action after a window expires;
  • how missingness and private work are handled;
  • accommodation and alternative evidence routes;
  • subgroup and access-risk hypotheses;
  • error and appeal monitoring; and
  • the evidence required to revise the rule.

The machine proposal additionally binds the policy digest, capability-registry release and digest, effective time, next review, expiry, controlled hypothesis ID, review and appeal policies, and automatic-expiry behavior. A proposal policy expires within one year and cannot be treated as current after its review or expiry boundary without a new version.

Permitted after-window actions are limited to:

  • mark the relationship refresh_due;
  • request re-corroboration for a future trust-progression decision; or
  • withhold that relationship from a new current-status decision pending review.

No proposal rule can mutate a capability value or erase historical evidence. Any temporary withholding or re-corroboration route is capped at 30 days, requires human review within 14 days, expires automatically, and requires notice, correction, independent appeal, alternative evidence, and accommodation routes. The relational gate rejects a review deadline later than the withholding limit or a stale/reversed policy timeline.

5. Candidate windows are hypotheses

The machine fixture contains illustrative windows so the contract can be tested. They are not calibrated recommendations. An authorized study should estimate stability separately for controlled assessments, credentials, repository attribution, employment assertions, public technical records, field-outcome corroboration, and referrals.

The study must predeclare hypotheses and acceptance criteria; include repeated observations over time; evaluate industry, role, access, leave, disability, and career-pattern effects; separate true construct change from measurement error; and publish uncertainty, failed hypotheses, and material corrections.

6. Activation gates

A recency policy cannot affect an operational or public record until there is:

  1. approved purpose and intended-use analysis;
  2. longitudinal evidence supporting each rule;
  3. measurement, fairness, accessibility, privacy, and legal review;
  4. a documented alternative-evidence and accommodation path;
  5. deterministic implementation and replay tests;
  6. notice, correction, human review, and appeal operations;
  7. independent approval of the versioned policy; and
  8. an authorized benchmark release that names it.