How the data is maintained

Every answer Miles gives rests on a maintained dataset: annual fees, earning rates, credits, transfer partners and ratios, elite tiers, and current sign-up bonuses. This page is about that dataset: what is checked, what has to be true before a change lands, how quickly it reaches an answer, and where it can still be wrong. Miles is built and run by one person, so this page says “I”.

One source of truth

The dataset lives in a git repository, and every edit (mine, an automated one, one made through the editor, or a restore from a prior export) becomes a commit there before it reaches the site. The databases the site reads from are caches: delete one and it rebuilds from git within minutes.

That arrangement is what makes the changelog trustworthy rather than decorative. It is not a summary written afterward; it is the record of what changed, because there is no second way for a change to arrive.

What a change has to pass

The same structural checks run twice on every change: once before it is committed, and again in the pipeline that publishes it. They are the same code in both places, so the two cannot drift apart and disagree about what counts as valid. Both gates block a change that omits a required field, puts the wrong type in one, or sets a value outside what that field allows.

Two narrower checks also run. The editor and its automations block a card record that loses benefits by comparing the new file with the one before it. Other write paths do not have that comparison. A family-conflict check runs on both gates but warns rather than blocks. The program-name registry is enforced only by a test in the main application. It does not run before the dataset publishes.

A repair that bypasses a failing check records the reason and every waived check in its commit trailer. There is one exception. When the editor retires a benefit through its “mark as removed” action, the commit records no separate reason because that action is the reason.

Facts decide, prose explains

Anything that changes what Miles recommends lives in a real field with a fixed set of values: whether a card is available, whether it is closed to new applicants, what it earns and where. Notes and descriptions exist for you to read, not for the software to interpret.

That rule is written down because breaking it has cost real answers. Reading a status out of prose once put a closed card at the top of three “best card” pages, and a keyword match on a note (the word described a benefit, not the card) quietly removed a popular card from every recommendation surface.

Links can change without a dataset edit

A card can be correct in every field while its application link is dead, and no edit is involved, so nothing in the data looks wrong. Every link in the dataset is therefore swept on a schedule and each card change re-checks its own. A link is only called dead when it proves itself dead; issuers that refuse automated requests are reported as unverified rather than broken, because a refusal is not a 404.

Where this can still be wrong

Checks catch structure. They cannot catch an issuer change before the dataset records it:

• There is a window. Between a card changing and the dataset recording it, Miles will answer from what it last knew. The “checked” time at the top of this page shows when the automation that watches for changes last ran, not that every card was re-verified against its issuer that recently.
• Offers are targeted. A sign-up bonus in the dataset is the public one. What you are offered can be better or worse, and Miles cannot see it.
• Valuations are opinions. What a point is worth is a judgment, not a fact. Miles provides starting values, and you can change each one. Your values change the answers.
• Verify anything that costs you money. Before you apply for a card or transfer points, read the issuer’s own terms. Miles shows its arithmetic so you can check the reasoning; it is not a substitute for the fine print.

If you find something wrong, email [email protected]. A correction follows the normal dataset process and appears in the changelog when it is published.

Related: where answers come from covers how Miles picks between this dataset, your wallet, its reference library, and the open web. How Miles makes money covers who pays for all of it.