Skip to content
Portfolio/Capabilities

CAPABILITY 16 / 30

What has gone stale

A board that says what is overdue, who owns it, and which generated file no longer matches its source.

IN PRODUCTION

This runs in client systems today. The sample below was regenerated for a fictional company.

Knowledge rots quietly. This tracks a review date and an owner for every artifact, shows the batch runs that keep them current, and separates two kinds of drift: a source that moved and needs a regenerate, and a twin somebody edited by hand, which is worse because the next run will overwrite their work.

TRY IT / RUNS IN YOUR BROWSER

Use it here.

The mechanism is the production one. The company, the catalogue, and every figure are fictional.

Loading the review telemetry, the batch log, and the twin register.

THE OUTPUT / GENERATED FOR APEX INSTRUMENTS

What comes out.

JSON
120 tracked artifactsData · Facts files, approved documents, templates, price data, guides and dashboards. Each carries a last review date, a review interval in days, an owner role and the person in it, the source it derives from, and the state that follows from those. 70 fresh, 15 due, 26 overdue, 9 unowned. The nine with no owner are spread across five kinds and include two approved documents, which is the uncomfortable part.Open the file ↗
JSON
The last 20 batch runsData · Regenerations, rebuilds and imports. Start time, duration, items planned and processed, items failed, outcome, and for every failure the item it was and the reason it gave. 3,514 items processed, 22 failed, 2 runs stopped part way through and one of those never reached 174 of its items.Open the file ↗
JSON
30 generated twins and their sourcesData · Each pair carries the source hash and twin hash now, plus the two hashes the generator recorded when it wrote the twin, and when each side was last touched. That is what makes the state derivable rather than declared. 25 in step, 4 with a source that moved, 1 edited by hand whose source also moved.Open the file ↗
MJS
The fixture generatorData · Deterministic. Dates are derived from a fixed as-of date and where each artifact was meant to sit relative to its due date, so the distribution is a decision and not an accident of a random seed.Open the file ↗

THE MECHANISM / SHOW THE SHAPE, NOT THE SOURCE

How it works.

What a skill is
  1. 01Set the clock

    Every artifact carries a review interval and an owner. No owner is its own finding.

  2. 02Watch the dates

    The board sorts by what is overdue, not by what is convenient.

  3. 03Run the batches

    Regenerations and imports leave a record with a duration and a failure count.

  4. 04Compare the twins

    A generated file is hashed against the source it came from.

  5. 05Separate the drift

    A moved source is a regenerate. A hand-edited twin is a decision for a person.

WHAT IT READS

  • A review interval and an owner per artifact
  • The batch run history
  • The hash of every generated twin and its source

WHAT IT CHECKS BEFORE IT SHIPS

  • Every artifact has an owner or is flagged as unowned
  • A failed batch run says what failed
  • A hand-edited twin is never silently overwritten
  • The board reports overdue counts rather than a health score
In production: freshness telemetry, batch boards, and a twin drift checker across both company systems.

The mechanism runs inside client systems. Everything on this page was regenerated for Apex Instruments, a company that does not exist. Client names, source files, and internal wording stay private.

What it producesWhat is being built next