An evidence-backed intent dossier for every iRule, firewall rule, SNAT, virtual server and pool — why it exists, who asked for it, whether it still carries traffic — scored into a safe-to-decommission confidence with keep, review or decommission verdicts.
Every estate carries objects nobody dares delete: an iRule from a migration that finished years ago, an any-service allow whose requester has left, a pool that "might still be used". Config Archaeology reconstructs an intent dossier for each one — why does it exist, who asked for it, and does it still carry traffic? — and turns that evidence into a confidence that it is safe to decommission. Find it under Diagnostics → Config Archaeology (administrator access).
It covers F5 iRules, firewall rules, SNATs, virtual servers and pools (plus a generic other), and it is purely advisory: it reads inventory, history and tickets and writes nothing to any device.
An empty or unreachable source contributes nothing and is recorded as absent in the dossier's evidence trace, so a partly instrumented estate still gets a usable verdict.
1. Config history and change authorship. Versus scans the device's config snapshots (the oldest 60) for the lines that mention the object: the earliest snapshot carrying it gives first seen, and a change in those lines between consecutive snapshots gives last changed. The most recent detected-change record naming the object supplies the last author (from the device audit log), its change summary and the matched change number. Without snapshots, the object's own created/updated timestamps are used.
2. ITSM ticket correlation. Versus Desk tickets are matched three ways — a configuration-item link naming the object, a ticket linked to the device whose text names it, or the object name in a ticket's title or body — and listed with number, type, state and match method. The correlation also yields requested by, whether open tickets from the last 90 days still reference the object, and whether a decommission / cleanup ticket already exists.
3. Traffic and usage. Virtual servers use their stats history over a 30-day window (requests, peak connections); a VIP with no samples that is offline or disabled counts as no traffic. Pools use member connection and request counters. Firewall rules and SNATs use hit count and last-hit time: a hit inside the window means live traffic, zero hits ever means none. Device-level stats are only a weak "the box is live" fallback and never mark an object as in use.
The score starts at 50 and moves with each piece of evidence. Higher means safer to remove.
| Evidence | Adjustment |
|---|---|
| Traffic within 24 h / within 7 days | −45 / −40, and the object is pinned to keep |
| Traffic within 30 days / only older traffic | −28 / −15 |
| No traffic in 30 days | +30 |
| No traffic telemetry at all | +4, plus a risk factor to confirm out-of-band |
| Modified in the last 30 / 90 days | −15 / −6 |
| Long-lived (a year or more) and untouched for 6+ months | +12 |
| Open or recent tickets reference it | −20 |
| A decommission / cleanup ticket already exists | +15 |
| Only closed, old tickets reference it | −6 |
| No tickets at all | +6, plus a risk factor that intent is unattested |
| No author, no requester and no config history | +8 (fully orphaned) |
Traffic dominates: anything that served traffic in the past week is capped at 39 and can never be recommended for removal, whatever the tickets say. The full adjustment trail is stored with the dossier, so every score is explainable.
| Score | Recommendation | Meaning |
|---|---|---|
| 70–100 | Safe to decommission | No traffic in the window and no active owner or open ticket |
| 40–69 | Needs review | Mixed evidence — typically no traffic but a recent change or an open ticket |
| 0–39 | Keep — in active use | Serving traffic, or the evidence says someone still depends on it |
Every dossier also lists its risk factors — the reasons removal could hurt — such as Recently modified — someone is actively maintaining it or No ticket trail — original owner/intent is unattested.
The summary counts filter the list by verdict, alongside filter buttons and a search box (object, device or requester). Dossiers are ranked safest-first, each row showing its confidence bar, verdict chip, live-traffic indicator and last-changed age. Selecting one opens the dossier: the reconstructed intent narrative and owner; config history (first seen, last changed, last author, change reference, snapshots seen); traffic evidence; risk factors; and correlated tickets, each linking into Versus Desk.
Build dossier mines any object on demand: choose the type, enter its name and optionally scope to a device ID. The checkbox Fill gaps with representative evidence where the estate has no live data is for demos — a source that returned nothing is filled with deterministic, representative evidence, and the dossier records which sources were synthesised. Untick it for a real decision. Rebuild on an open dossier re-mines with that gap-filling on, so use Build dossier (unticked) for a strictly live rebuild.
The demo (python manage.py seed_archaeology) builds up to 32 dossiers — real discovered objects first, then a curated set of plausible names bound to real devices — and on the Versus demo estate lands at 6 keep / 17 review / 9 decommission. --clear removes them.
The REST API lives under /api/archaeology/intent-dossiers/: candidates/ (ranked safest-first, with min_score and limit), build/ ({object_type, object_ref, device_id?, synthesize?}), and the list itself, filterable by object_type, recommendation and device_id; DELETE on a dossier removes it.