How to help
I maintain this alone, so each fact someone else checks is one I do not have to check myself. The smallest useful help is one corrected fact with its source. No account is needed for anything on this page. Nothing is sponsored, and nobody can pay to be listed.
futurisminstitute@gmail.comgithub.com/BentleyMoon/conscious-consumingAccount: none
Where to send it
There are three ways to send something, and all three reach me. Use whichever is least work for you.
| Route | What to send | Where |
|---|---|---|
| Name the decision, category or page, say what should change, and attach the source. | futurisminstitute@gmail.com | |
| Patch file | Make the change in your browser on the fact repair page. It saves a small JSON file on your computer and uploads nothing; email that file to the same address. | Fact repair |
| Pull request | The engine, the sourced data, the audits and the standard are all in the public repository. Open an issue or a pull request against any of it. | The public repository |
Plate IFig. 1. A useful correction email, with its four important parts numbered.
An example correction email
This example is made up, and the bank and the report are not real. The numbered parts are what let me check a correction without writing back to ask.
Subject: Correction
- Decision
- Choosing a bank1
- Option
- Example Bank
- Fact
- Green financing, shown as 98
- Should be
- 402
- Source URL
- https://example.org/report, p. 123
- As-of date
- June 2026
- Why
- The report counts fossil loans the old figure left out.4
- Name the decision. Which category, facts file, page or app is affected.
- Change one thing. The row, score, wording, relationship or option that should change, and to what.
- Attach the source. A link, a dataset, a method note or a public record, and the as-of date the fact was true. If the number is your own judgement, say so.
- Give the reason. Keep it visible so the next person can accept it, reject it or reverse it later.
What's happening. A good correction needs only these seven lines. The fact repair page puts the same fields into a file for you.
Why it matters. Every fact here carries a source, and the site says so on the front page. A correction that brings its own source keeps that true. One that does not has to wait until somebody finds one.
Devil's advocate. A sourced correction can still be wrong. A company's own sustainability report is a source, and it is also an advert. The catalogue's rule is to prefer the regulator's record or an independent test where one exists, and to read the company's own page as a lead. An old source still counts as a source, and the as-of date shows how old it is.
Rabbit hole. The rule every compatible app keeps, "Every judgement cites", is in the standard, beside the validator that checks it.
Corrections that turn out to be wrong are kept too, with their history.
What to include
One narrow correction is easier to check than a long list. Here is what each kind of help needs so someone else can verify it without guessing.
| If you are sending | Include |
|---|---|
| Correct a sourced claim | The category, the item, what should change, a source URL and an as-of date. |
| Add a missing option | The category and region, why people actually choose it, and the sources behind its scores. A new row helps only when it changes a decision. |
| Request a category | The decision, who needs it, 5 to 10 options people would recognise, and any open dataset or trusted source that could seed it. |
| Add an ownership or alternative link | Both ends, the relation, why it changes a decision, and the source or the calculation. The ownership map shows what these look like. |
| Build a compatible app | The subject, who would use it, where the starting facts come from, the license, and how a person's values file carries over. The standard has the rules. |
What does not help: affiliate pitches, scores with no source, copy from a brand's own marketing, "add more" with nothing named, and offers to pay for placement. There are no ads here, nobody can pay to rank, and nothing is placed for money.
Plate IIFig. 2. New subject brief. Four questions to answer before any code is written.
Write the decision before the code
Every app here ranks one kind of choice. Before building a new one, write down the choice and who it is for. Most of the work is in these four answers.
- Name the real choice. What should people rank, compare, switch, fund, avoid or adopt?
- Draft the starting facts. 8 to 20 options and 3 to 7 criteria, enough to test the subject properly.
- Say which values carry over. Which of a person's existing values apply in this subject, and which do not, so the app can say so.
- Plan how corrections arrive. How corrections, missing options, source disputes and copies of the facts will reach whoever maintains it.
Say what happened
If you used it for a real decision, three short answers tell me more than a feature request.
- Did it help?
- Did the decision get clearer, easier, or more confident?
- What was missing?
- An option, a stale source, a word that made no sense, a broken page, a category that should exist.
- Did you trust it?
- Where your trust went up or down: the evidence links, the scoring, the wording, privacy, or control over your values.
Other ways to help
- Test whether values files, facts files and group plans really work from one app to another, using the rules in the standard.
- Make ownership and alternatives easier to trace on the ownership map.
- Pay to keep the open version running. It is a static site with no accounts, and nobody pays to rank. The page for funders explains how.
Everything on this page works by passing files: an email, a patch, a pull request. There is no forum and no login. If one is ever added it will be optional, because the files have to keep working for one person on a laptop with no server.