technology_radar v1.0.0

name: technology_radar description: "Run a small technology radar: sweep sources for tools worth watching, score each on fit, maturity, cost, and risk, track end-of-life and security signals, and publish Adopt, Trial, Assess, Hold, or Drop verdicts on a set cadence. Triggers on technology radar, tech radar, adopt trial assess hold, stack review, tool evaluation, end of life tracking, or planning what to adopt or drop."

Technology Radar

Purpose

Keep a small team's stack deliberate. One short edition, published on a cadence, that says what to adopt, what to trial, what to watch, what to stop starting, and what to exit, with the evidence behind each call. Use when the stack has grown by accident, when a tool is near end of life, when a team keeps debating the same choices, or when leadership asks what the plan is for a category.

The model follows the Thoughtworks Technology Radar. Thoughtworks groups items, called blips, into four quadrants (Techniques, Platforms, Tools, and Languages and Frameworks) and four rings. This skill keeps those quadrants, keeps Adopt, Trial, Assess, and Hold, and adds Drop as a local exit verdict for owned technology. Thoughtworks now labels its outer ring Caution on its public radar, and its Build Your Own Radar tool still uses Hold. For an internal radar, Hold and Drop split two jobs that one ring does badly: Hold means do not start new work, Drop means plan the exit from work you already have.

Workflow

1. Set the cadence and freeze the scope. Default for a small team: a full edition quarterly, a one hour sweep monthly, and a short EOL and security check on owned items whenever a vendor advisory lands. Name the categories in scope this edition (for example databases, queues, frontend frameworks) and the owner who will sign the verdicts. An edition that tries to cover everything covers nothing well.
2. Inventory what you own. Pull deployed versions from package manifests, base images, infrastructure code, and SaaS consoles. Every owned item gets a row every edition, even if nothing changed. Record the version as deployed, not the latest release. EOL and CVE checks are version specific, so a wrong version makes the rest of the work worthless.
3. Sweep for candidates. Work the source list in references/sweep-sources.md. Check release notes, support policies, endoflife.date, NVD and CISA KEV, OpenSSF Scorecard for open source, CNCF stage where it applies, license files, and pricing pages. Add candidates that solve a named current problem, replace an item heading for Hold or Drop, or keep appearing in team discussions. A candidate with no problem attached waits for the next sweep.
4. Gather two sources per candidate. One source must speak to risk: an EOL date, a CVE record, a Scorecard result, or the license. One must speak to fit or maturity: release notes, named production use, or your own trial notes. Save URLs and the date checked for both. A row backed only by vendor marketing stays in Assess at best.
5. Score each candidate. Fill templates/candidates.csv. Score fit, maturity, cost, and risk from 1 to 5, higher is better on every column, so cost 5 means cheap to buy and run and risk 5 means low risk. Add the gate facts: days to end of life for the deployed version, KEV or critical unfixed CVE status, Scorecard aggregate if you ran it, whether your team has run it in production, and whether you own it today. Anchors are in the scoring reference below.
6. Run the scorer. Run python3 scripts/radar_score.py candidates.csv --out scored.csv --md edition-draft.md. The script applies the weights (fit 0.35, maturity 0.30, cost 0.15, risk 0.20), the ring cutoffs, and the gates, and prints a suggested ring with reasons for each row. Read references/worked-edition.md for a full run with hand checked math.
7. Debate the edges, not the whole chart. The scorer suggests, the team decides. Spend the review meeting on rows near a cutoff (within 0.25 of a ring boundary), rows where a gate overrode a high score, and rows anyone wants to move against the suggestion. Any override goes in the edition with the reason written down. Quiet, unanimous charts usually mean nobody checked the evidence.
8. Publish the edition. One page per ring plus a changes section. Each entry gets the verdict, the score, the gate facts if any, the next step, and an owner. For Trial entries, name the trial project, the time box, and the date the verdict gets revisited. For Drop entries, name the replacement path and the exit date. Archive the edition, the input CSV, and the scored output together so next quarter can diff against them.
9. Track movement between editions. In the changes section, list every item that moved rings, entered, or left, and why. An item that stays in Assess for three editions with no trial started leaves the radar. Thoughtworks fades blips that do not move. A small radar should be stricter, not looser.

Ring definitions

• Adopt: Proven for your context. Score 4.00 or higher, your team has run it in production, no gate applies. New work in this category starts here by default.
• Trial: Score 3.40 to 3.99, or a higher score capped by a gate. Worth a real project that can carry the risk, with a named owner and a revisit date. Thoughtworks requires production experience before Trial on its radar. On a small internal radar, Trial is where you earn that experience, so Trial entries must name the production or near production test.
• Assess: Score 2.60 to 3.39, or any score capped by a security gate. Interesting and worth a spike, a prototype, or watching. No production commitment yet.
• Hold: Score under 2.60, or an EOL gate on something you do not own. Do not start new work on it. Existing use can continue while you plan.
• Drop: Owned, and an exit gate applies: past end of life or under 90 days to it, unmaintained with no fix path, or a score under 2.0 with no recovery plan. The edition must carry a dated exit plan, not just the verdict.

Gates that override the score

• End of life under 90 days away, or already passed: Drop if owned, Hold if not.
• End of life 90 to 180 days away: capped at Trial. The edition note must name the upgrade or replacement plan.
• A CVE affecting your version listed in CISA KEV, or a critical CVE with no fix available: capped at Assess until the fix ships and has been out for one release cycle.
• OpenSSF Scorecard aggregate under 4.0, when a score exists: capped at Assess. No score at all is a note, not a gate. Closed source tools have no Scorecard, score their risk from advisories, support terms, and exit cost instead.
• No production use by your team: capped at Trial. Adopt is earned in your own stack, not borrowed from someone else's.

Scoring anchors

• Fit: 5 solves a current named problem with little adaptation. 3 solves it with real workarounds. 1 solves a problem the team does not have.
• Maturity: 5 proven in production at scale, stable release line, security backports. 3 active project, regular releases, some production users. 1 pre 1.0, single release, or no release in a year.
• Cost: 5 free or already paid, low run cost, easy exit. 3 mid tier license or real migration effort. 1 high license at your scale, high run cost, or hard exit with data locked in.
• Risk: 5 healthy maintainer spread, clear license, clean recent security record, easy replacement. 3 single vendor or small maintainer group with a good record. 1 recent critical incidents, license change, abandonment signals, or no viable replacement if it fails.

Output Contract

• A dated radar edition: one section per ring, each entry with verdict, weighted score, gate facts, evidence links with check dates, next step, and owner.
• The input candidates CSV and the scored CSV, archived with the edition.
• A changes section: entries that moved, entered, or left since the last edition, each with a one line reason.
• For every Trial: the test project, time box, and revisit date. For every Drop: the replacement path and exit date. An edition missing either is not finished.

Operating Rules

1. Evidence before opinion. Every verdict traces to at least two saved sources, one for risk and one for fit or maturity. If you cannot find the EOL date or the security record, say unchecked in the entry. Unchecked never reads as safe.
2. Score the version you run. Candidates are scored as a product plus version where EOL or CVE facts differ by version. A product can be Adopt on its current line and Drop on the old line you still run. Give those two rows separate entries.
3. Gates beat averages. A high weighted score never cancels an EOL date, a KEV listing, or an unfixed critical CVE. If the team overrides a gate anyway, the edition records who decided it and what risk they accepted.
4. Empty rings are fine. Do not place a candidate to balance the chart. A quarter with no Adopt and no Drop entries is a normal result.
5. Do not copy outside radars. The Thoughtworks Radar and analyst rankings are candidate sources and fit evidence. Their rings reflect their context. Your verdict comes from your scores, your gates, and your production experience.
6. Keep the edition short enough to read. Cap a small team edition at about 25 entries. Past that, split by category and run separate sweeps. Items cut for space go on a watch list, not in a longer edition.
7. Cadence is part of the product. Publish on the date even when little changed, and say what was checked. A skipped edition teaches the team the radar is optional, and the next sweep starts from stale facts.
8. Weights and cutoffs are local defaults. The 0.35, 0.30, 0.15, 0.20 weights, the ring cutoffs, and the 90 and 180 day EOL windows are this skill's defaults for a small team, not external standards. Tune them in the scorer and in this file together, and note the change in the edition that first uses the new values.