Work/How it learnsTerms explained in the pattern
DropRenew: a renewal engine measured against real sales, and a knowledge base that argues with it.
DropRenew tells a domain owner, name by name, whether a renewal fee is worth paying. It learns in two ways. Every verdict is recorded with the version of the engine that made it, then compared with what the owner did and what the name later sold for, and the engine changes only when a person approves. Alongside that, it reads what domain investors say in public and turns their claims into ideas it can test against real sales.
Every week
The decision loop
A weekly committee, a scored core with a model as referee, and a person at the gate.
-
A scored engine, not a single opinion
Each domain is scored on a set of forces: what the name is worth as a brand, how it fits the owner's themes and cohorts, what the market has paid for comparable names, demand signals inbound and forward, traffic and history, and risk. Some forces are arithmetic over data. Others, brandability among them, are judged by a model. Forces sit in weight tiers from primary down to a whisper, and two vetoes short-circuit everything: a trademark collision, and a funded offer on a name about to expire.
How it is built- Every force writes its contribution to the verdict row, so any verdict can be explained force by force.
- Renewal cost enters through an expected-value lens, and confidence bands separate a clear call from a marginal one.
- Weights live in a versioned configuration, never in code.
-
The model is the referee, not the judge
Most verdicts are arithmetic. A model is consulted only when high-tier forces point in opposite directions, and its prompt is versioned and A/B tested like any other component.
How it is built- Four routing paths: veto, arithmetic, model on conflict, model as fallback.
- The referee prompt carries a version number and has been through a paired A/B test over a few hundred past decisions.
- The committee runs weekly on a schedule. Each verdict freezes its result and its evidence snapshot on the decision row.
-
Overrides are evidence, not commands
The owner accepts, overrides or snoozes. An override is filed with a reason category, free text, and how far it reverses the engine. By design it is reported and attributed immediately, and used for tuning only once the real outcome confirms it.
How it is built- An override records a reason category (missing evidence, weighting, timing, wrong data, not actionable), free text, and its size: a hard flip across keep and drop, or an adjustment.
- Design rule: overrides are judgment labels. Report them now, tune on them only once the outcome confirms them.
-
Outcomes are the ground truth
Offers, sales and re-registration checks are appended to each decision. A monthly post-mortem treats a dropped name that someone else registered and put to use as a confirmed engine error. The golden set is labelled by the market, not by opinion.
How it is built- Realised outcomes are appended to the decision row and read by a monthly post-mortem job.
- Golden-set labels come from the market: a sale well above the renewal fee means keep; a dead or dropped name means drop. The harvesting agent's rule: AI collects, AI never selects.
- A manifest of a few hundred labelled decisions is the held-out set every proposal is measured on.
-
Signals with a memory
Several force inputs are stored so that comparable sales, market signals, trademark filings and emerging vocabulary can be matched by meaning as well as by token. Today's matching is token rules, chosen after testing showed embeddings do not separate coined names; the vector columns are in place for the signals where meaning does help.
How it is built- Vector columns on the comparables, market-signal, trademark and vocabulary tables.
- Trademark matching is deliberately rule-based.
- A conformity check is designed to compare a verdict against the knowledge base's corroborated claims before it is shown.
-
Proposals, not auto-tuning
The harness can re-score every past decision under candidate weights and search for a better configuration. It is allowed a small, bounded number of parameter moves per run, must clear a ship bar on a held-out split, and then a person runs it in shadow and reads a blast-radius report before approving.
How it is built- Every parameter set is a versioned engine configuration, and every verdict is stamped with the version that made it.
- The harness re-scores history under candidate weights and reports which forces flip verdicts.
- The ship bar is a fixed gain in balanced accuracy or a fixed cut in expected-value regret, without worsening the other beyond a small tolerance.
At arm’s length
The knowledge loop
What the industry says in public, harvested at scale, and held at arm's length from the engine until tested.
-
Harvest
Interviews, blog archives and show transcripts from the domain-investing world, pulled with purpose-built tools. Forums are deliberately left out.
How it is built- Interview shows, industry blogs and video archives: about 3,300 documents and 3.8 million words, all extracted.
- One harvester per source type: HTML archives, playlists, transcripts.
-
Extract, verify, merge
An LLM extracts claims, each anchored to a timestamp or paragraph. A second, independent model re-checks one claim in ten for fidelity. New claims are merged against existing ones as enrich, dispute, refine or new.
How it is built- Pipeline stages: harvest, register, extract, fidelity check, merge, numbers, validate, audit.
- About 21,000 items across practices, facts, interpretations, claims and mechanisms. About 1,600 are corroborated by two or more independent publisher-and-voice pairs.
- Similarity is keyword and entity overlap, one file per claim. No embeddings, on purpose.
-
Claims have a lifecycle
A claim starts single-source. It becomes corroborated when a second independent publisher and voice say the same thing, contested when sources disagree, and tested once the eval harness has adopted or refuted it. Numbers get their own book, so a figure quoted across the industry can be checked for consensus.
How it is built- Lifecycle: single-source, corroborated, contested, tested (adopted or refuted).
- A numbers book tracks the figures quoted across the industry, with a consensus flag when independent sources agree.
- Every new source enters through the same register, extract and fidelity steps.
-
The KB proposes; the eval disposes
Nothing from the corpus is injected into a prompt. A knowledge item becomes a hypothesis, the hypothesis becomes an eval run, and only a passing run can become a new engine version. The first three industry beliefs back-tested against a real portfolio were all refuted. Corroborated claims also feed the roadmap: what the industry agrees on shapes what gets built next, while only tested claims change the engine.
How it is built- Constants in code carry a citation to the claim they rest on.
- The first back-test: three industry beliefs against a live portfolio of about 300 names, three refuted.
- An engine-versus-knowledge-base alignment audit read several hundred items and filed the disagreements.