We're leaving Substack in favor of Ghost, in order to get better customization. All of our previous Substack members have been migrated over. We're also using this new setup as our new website homepage.

One benefit for subscribers is that this gives more control over subscriptions. We've split our content into three streams[1]. You can select which you want emails for.

1. QURI. News/events/updates about the organization.

2. Software. Updates about Squiggle, Metaforecast, and more.

3. Research & Ideas. Our more theoretical writings on forecasting and epistemics.

One benefit of this is that it makes it possible to use our newsletter for users of Squiggle Hub and our other tools. Expect to see more announcements here soon!

As always, feedback on these changes is highly appreciated.

[1] It's three because this is what's allowed in our Ghost plan. We'll keep an eye on improvements to this later on.

• Support for value tags and decorators

• Interactive documentation and documentation updates

• Viewer improvements

This post describes the changes since Squiggle 0.8.6 that was released just over two months ago.

Soon after releasing 0.9.0, we introduced version 0.9.2, which included a few fixes and cleanup from 0.9.0. This post includes the changes for both.1

This post goes into detail about the new functionality. See the 0.9.0 Changelog and 0.9.2 Changelog for shorter summaries.

Tags and Decorators

In most programming languages, variables are mostly internal. You can rename any variable without changing the output of a program.

This is less so in some Squiggle, where the final state of top-level variables (plus the end expression) is the entire goal. “Variables” view in Squiggle output includes variable names next to their values.

But often you might prefer to use a terse name in code, and a more descriptive name in the output. With Squiggle 0.9.2, you can use @name decorator for this:

In this example, the value of dist variable is tagged with a custom name. The tag is attached to the value, and will be copied if you assign the value to a different variable:

But it will be erased on most other operations:

One important idea here is that tags allow you to store presentational properties of your values separately from computational properties.

For example, without tags, you could store that longer name together with dist by using dict = { value: 0.5 to 20, name: "..." }, and it would show decently (though not as great as a real @name tag!) in the viewer.

But then you'd have to remember to use dist.value instead of dist everywhere in your code.

With tags, you can keep using the value same as before; @name won’t affect the variable name in code, only in the viewer.

And there are more presentational properties than just names that we want to allow users to customize. Here are some others:

@doc, for longer, markdown-powered descriptions:

@showAs, to customize the value's visualization; it can be combined with Plots or Calculators.

For example, if you have a distribution, it could be convenient to show it as a Plot.dist, because you might want to override its xScale or some other properties. Without tags, you would have to construct the plot object and save it separately.

With tags, you can tag the distribution with a @showAs that transforms it to a plot. Then, the original dist object would stay available for further use:

There are several more builtin tags, explained in the new Tag API documentation.

Tag Meta-Programming

You can do meta-programming with tags.

The decorator syntax displayed above is just syntax sugar for a plain function call. The following two examples are equivalent:

Function Call Form

dist = Tag.name(0.5 to 20, "...")

Decorator Form

@name("...")
dist = 0.5 to 20

With explicit Tag.* calls you can tag values in places other than variable declarations.

You can also read tags in Squiggle code with Tag.getName, Tag.getDoc, etc.

To see more examples of real (and sometimes quite complicated) uses of tags, check out models by @mlao-pdx on Squiggle Hub.

Documentation Updates

We brought all of API documentation up to date by auto-generating it from the source code. Each standard library function definition now includes its own markdown description and examples, and function signatures are generated from standard library definitions too.

In addition, you can see the documentation inline by hovering over the function name in editor:

And if you return the function itself, without calling it, you'll see the documentation in the viewer, in some cases even with a small editor for its example:

Function signatures are improved. Old documentation used hand-written signatures that didn't match Squiggle syntax and sometimes didn't match the actual parameter types. Now they are generated from the internal definitions and the examples are validated.

Squiggle doesn't have a user-facing type system yet (though we do have parameter annotations for number ranges), so the new signatures are still not valid Squiggle code. But parameter names are frequently spelled out in addition to types, which should make things easier, and type names in signatures now match the builtin module names (Number, Dist, etc.).

Viewer improvements

We added several improvements to the viewer in this release.

First, here’s a new context menu that’s been added to variables:

Most of these actions are not new ("Show in Editor" and "Chart Settings" was moved from standalone icons that we used pre-0.9.0), but "Log to JS Console" is new and can be useful for low-level debugging in some cases.

Second, we did some general cleaning:

• Distributions are now previewed even in the collapsed state

• Variable colors in the viewer match the color in editor

• Collapse/expand icons look better

• Initial collapsed state heuristics are improved

Third, "Variables" and "Result" can be toggled with a dropdown, instead of being part of the tree.

We're trying to be clever about it, so that if you open the model that has the result, we start with "Result", but if there's no result then we pre-select "Variables".

This can misfire if you start with a non-empty result and then delete it, so don't forget to switch to "Variables" if that happens. Expect further improvements in this area.

Fourth, there are distribution chart improvements. Colors are new, some details are tuned based on the chart height, we show vertical lines for important percentiles (5, 50 , and 95), and summary table cells are hoverable.

Standard Library Improvements

Explaining all changes in details would be too verbose, so I'll just refer to the changelog.

One highlight is the improved support for dates and durations, which are explained in API docs for Date module.

Squiggle Hub Improvements

We also continued to improve Squiggle Hub, which is the best way to use and store Squiggle models.

• Imports and exports are stable and can be used starting from the 0.9.0 release.

• You can save models with a comment and then see that comment in the model's revision history.

• There’s a new global search. You can search for users, groups and models.

Note on our upgrade policy

When we release a new version of Squiggle, we go through all public models on Squiggle Hub, check that they're compatible with the new release, and upgrade them to the new version if they look fine. We’re trying to upgrade user’s models without breaking functionality. The process is semi-manual for now, but we plan to work more on automation in the future.

This automatic upgrading is done for public models. If you have any private models on Squiggle Hub, feel free to ask us for help upgrading. We can do it for you if you are okay with us seeing the models.

This release brings few breaking changes (mostly some minor functions), so upgrading from 0.8.6 has been very easy for us so far.

Going forward

The Squiggle Discord has been much more active than this Substack recently. We’ve been posting the product updates there as they are introduced to the Next branch, and we’ve been discussing ideas for future features. If you’d like to stay the most up-to-date on Squiggle matters, we suggest joining us there.

Donations are highly appreciated! Making a quality tool like this is a long journey. Donations are essential for this work. If you’re interested in being a supporter, and have any questions, do let us know. We’re happy to respond via emails or calls.

• Calculators. Make custom forms that wrap Squiggle functions, and send these forms to end-users. See some simple examples here:

  • https://squigglehub.org/models/ozziegooen/laptop-battery-cost

  • https://squigglehub.org/models/ozziegooen/cost-of-reading-calculator

  • https://squigglehub.org/models/ozziegooen/virus-model

  • In addition to using text inputs, you can also use check boxes, select dropdowns, and text areas.

    

• Many new builtin functions, especially in List.* and in Dist.* (see the full changelog)

• Squiggle Hub got support for imports and exports. These are experimental, but you can see a simple example below. We’ll continue to clean up this functionality in future releases.

  • https://squigglehub.org/models/quri/exports-example

  • https://squigglehub.org/models/quri/imports-example

Also, we've recently added support for picking Squiggle version in the playground and on Squiggle Hub. This means that you don’t need to worry as much about breaking changes, and you can test out models on different versions.

• In the playground, the version is always pinned (unless you pick "Next", which means "Latest unreleased version").

• On Squiggle Hub, we plan to eventually auto-update user models if we can be reasonably sure that new version is backward compatible.

We haven't updated existing Squiggle Hub models to 0.8.6 yet but will do this soon. You can do this manually on any model you own (change the version in editor menu and then save the model).

Full Changelog

https://www.squiggle-language.com/docs/Changelog/v0.8.6

Second, I’m holding a intimate Squiggle Introduction Workshop in Berkeley this Thursday, at FAR Labs. Come and practice estimating things you care about.

Sorry for the lack of other updates recently. Slava and I have been focused on Squiggle improvements, many of which we’ll be announcing shortly.

Note: We skipped v0.8.1 to v0.8.3 due to deployment issues.

@quri/squiggle-lang

Breaking changes

• This package is now ESM-only

• Remove Function.declare method (it was never documented and was replaced with annotations in 0.8.0 release)

New features

• Support for unicode sequences in strings; any JSON that doesn't include null values is now a valid value in Squiggle

• Apply logarithmic KDE on skewed distributions

@quri/squiggle-components

New features

• Playground viewer (and SquiggleViewer component) always shows both variables and the result

• Comments and strings render as markdown

• Line wrapping editor setting

Improvements

• Error boundary in SquiggleViewer; fatal errors won't crash the entire playground anymore

• In distribution charts, adjust PDF height on non-linear scales

• Better log scale error message

• Swap row/column order in table chart dimension

• Increase number precision in distribution summary tables

Function chart improvements

• Pick x scale points equidistantly on a mapped scale for non-linear scales

• Group numeric function errors (we were already grouping dist function errors, but not numeric)

• Don't draw cursor lines if cursor is outside of CartesianFrame

• Floating dist function previews

• Filter infinite values in dist functions

@quri/prettier-plugin-squiggle

• Fix NPM release (0.8.0 didn't include JS files)

• Don't wrap lambda body in extra {}

• Correctly indent lambda body

• Escape quotes in strings

• Fix capitalized keys formatting in dicts

• Preserve shorthand entries in dicts

@quri/ui

• GlobeIcon and LockIcon

Squiggle Hub

• Support for private models

• Various performance improvements

• Models are sorted by last updated time

• /status page with basic statistics

• Various minor improvements and bugfixes

Documentation website

• Documentation reorganization

• Guide for using Squiggle with language models

• Full-height playground

New Contributors

• @agucova made their first contribution in https://github.com/quantified-uncertainty/squiggle/pull/2232

Full Changelog: https://github.com/quantified-uncertainty/squiggle/compare/@quri/squiggle-components@0.8.0...0.8.1

Overview

Squiggle Hub is a platform for the creation and sharing of code written in Squiggle. As with Squiggle, Squiggle Hub is free and open-source. 

As a refresher, Squiggle is a simple programming language for probabilistic estimation that runs on Javascript. It begins with the syntax of Guesstimate, but generally adds a lot more functionality. See its launch post here for more information, or the website for the full documentation.

Squiggle Hub is a lot like a more powerful, but less visual, version of Guesstimate. We hope that it will eventually be much more valuable than Guesstimate is now. 

If you can use Guesstimate, you can basically use Squiggle. If you already use Guesstimate, try using the same syntax in Squiggle. It should mostly work.

All models on Squiggle Hub are public. We've produced several small ones so far, and a few friends have also written some. We're looking forward to seeing what others make!

Looking for Squiggle examples? We’ve organized some in the docs.

Key Links

• Squiggle Hub

• Squiggle Discord

• The Squiggle Language Homepage

• Squiggle Newsletter (Part of the QURI Newsletter)

Functionality

Squiggle (the language)

• Write functions that accept and return probability distributions. Squiggle generates automatic plots for these.

• You can provide explicit ranges for functions. This helps with the visualization, and ensures they won't be called outside that range. Like, appleStockPrice(t:[2023, 2060]).

• Custom plots for distributions and functions. Scales include linear, log, and symlog (like log, but with support for negative values). Symlog scales accept a parameter constant that you can use for adjusting the scale.

• Make custom tables of any data and functions, with Table.make({data, columns}).

• Automatic conversion of Monte Carlo samples to distribution plots, using KDE. In the cases where the distribution is heavily skewed, Squiggle does this with a log transformation. The result of this is often more accurate than using histograms. Combined with custom scales, Squiggle much better supports highly skewed distributions (i.e. “5 to 5M”)  than Guesstimate does. 

• Squiggle supports most of JSON. You can copy & paste JSON data and begin using it in Squiggle.

• Squiggle runs on Javascript. You can simply take Squiggle code and run it in your website, Observable, Obsidian, and more.[1] If you are making an application that uses probability distributions, you can use the Squiggle components directly. 

• Lots of performance enhancements, library additions, and bug fixes, since Squiggle's initial release.

• All the docs and grammar are consolidated here. You can use this to feed into Claude, for some Squiggle generation and assistance.

Squiggle Editor (The window on the left)

• With "Autorun", the output will update as you type. Turn this off if you want to run it manually.

• Adjust the number of Monte Carlo samples. It defaults to 1000, but you can change this in the settings. Also, there are a bunch of other toggles there to play with.

• A built-in Squiggle code formatter. Useful for lengthy files and for storing data.

• Function and variable autocomplete.

Squiggle Viewer (The window on the right)

• Click the arrows to open and close visualizations.

• Select any variable in the right view to "zoom in" on it. Very handy when working on particular estimates of a file!

• On hover, there's a "show in editor" button, that finds the source code to the variable in question.

• If your Squiggle file ends with a variable, this will be shown as the "Result." You'll still be able to see all of the other defined variables, but these will be collapsed when you open the model. Useful for selecting a few key findings for display purposes. 

• You can adjust the view settings for specific distributions.

• Squiggle strings are rendered in Markdown.

• If you write variable-level comments, with /** ... *, these will be displayed by their respective variables. Like with regular strings, these support Markdown.

Squiggle Hub (Outside the editor)

• See your full save/revision history.

• Access everything with a GraphQL API.

• Log in with Github or email.

Recommended Use Cases

Squiggle Hub is somewhat straightforward, but very general-purpose. Our main hope is that it will be used for effective altruist use cases, but we imagine there are many ways it could help do so. It will likely take time to see what’s best. 

Some examples of how we envision Squiggle Hub being used:

• Ovidia writes a Squiggle function that expresses her estimates of the value of technical AI alignment, AI policy, and biosafety, in the next 10 years.

• Eskil likes Ovidia’s estimates. He imports them in a model that prioritizes specific donation opportunities. Olivia’s estimates change over time, and Eskil’s correspondingly update.

• Karrie expresses her beliefs about the future of AI progress in a set of functions that predict several key stock prices and company valuations, over the next 10 years. Very reasonable assumptions lead to surprising implications for short-term stock purchases.

• Katia has a small priorities research organization. They produce a function, pIntervention(human, intervention), that takes in details of a human health intervention for a person, and outputs the expected value of that intervention.

• Akmad makes a big list of estimates of the value/disvalue of things he owns and activities he’s considering. He uses those estimates to inform his decisions. 

• Morten is an ML researcher. He experiments with ML agents that can predict Squiggle functions at scale, helping with human decision-making in a fairly understandable way.

• Galla organizes a bunch of data about EA interventions and organizations, and posts this data as JSON objects on Squiggle Hub. This can then be used as a mini-API, and used to update other Squiggle models.

• The forecasting platform ForecastsNow supports functional forecasts using Squiggle. People submit squiggle code for things like, “Each stock price at each point in time, for the next 30 years”, and this is formally tracked and scored as a forecast. 

• Organization ComputeForecastingResearch makes extrapolations of computation over time. They export these estimates as a Squiggle function that returns probability densities. This is later used in other models and formally updated and scored.

• Kayla makes a big estimation function of how overconfident all the above estimates are. Kayla has a trustworthy reputation. Others chose to use these estimates to adjust the others automatically.

• Yonah works to estimate the value of all of the estimates mentioned above. The people above adjust their work accordingly.

Future Work

We are planning to add numerous features. This includes:

• Models can import code from other models

  • Note: Even though you can’t formally import code now, you can still copy & paste code from other files. 

• Multi-file models

• Private models

• Simple support for years and dates

• Integration with apps such as Google Sheets, Guesstimate, Github, and more

• Better support for presenting / describing models

We've listed some of our planned features in this model.

For input on these or any other features, please connect with us on Discord or through the Github Discussion.

Relative Values

Squiggle Hub currently supports experimental relative values, with future improvements planned. These are currently partially broken and undocumented, we are in the process of improving it.

Theory: A Middle Path between Spreadsheets and Code Editors

Squiggle and Squiggle Hub are an interesting intersection between spreadsheets and programming environments.

Spreadsheets are typically made for:

• Broad user bases, much of which doesn’t program.

• Large lists of numbers and some numeric calculations.

• Editing experiences that feature rapid visual feedback.

• User-interactive math models and visualizations.

Meanwhile, programming environments typically are made for:

• Large codebases of fairly arbitrary executions.

• Programmers, with a fairly high-skill floor.

• Lots of interactions between libraries and external services.

• If there are GUIs, these are generally heavily customized and polished.

In comparison, Squiggle/Squiggle Hub are meant as a “middle path” between these two extremes.

• Medium-sized lists/arrays of numbers and numeric calculations.

• Editing experiences that feature rapid visual feedback.

• Support for small to medium-sized codebases. (Maybe <50k lines, including imports?)

• Limitations that promote consistency over flexibility. (As with spreadsheets, there are a fixed set of charts you can natively use - but the ones provided work fairly well). 

We think that this middle road is both neglected and promising. However, because it’s neglected, it’s taking time to design, and we expect it will take more time for users to figure out how to utilize it best.

Notebooks, like Jupyter, are one distinct option of a middle path. However, notebooks have significant limitations; they’re nice for editing and demos, but not great for being part of a larger codebase. We might add something like notebooks to Squiggle Hub later on, but wanted to begin with something else first. 

Team & Funding

Donations

You can support the development of Squiggle and Squiggle Hub by donating to QURI here. We are currently actively fundraising for the next year of development. Get in touch if you might be interested!

Organization and Funding

Squiggle is now the main project of The Quantified Uncertainty Research Institute. QURI is a 501(c)(3) primarily funded by the LTFF and SFF. QURI is fiscally sponsored by Rethink Priorities.

Contributors

Squiggle has very much been a collaborative effort. You can see a list of contributors here. Squiggle Hub has been developed by Slava Matyuhin and Ozzie Gooen.

[1] Right now, the online Observable and Obsidian support is for an old version of Squiggle. We plan on updating this eventually. If this is important for you, let us know.

As part of the preparation for more users, we’ve deprecated some syntax. This might break your models, so keep an eye on this (it should be easy to fix). We generally don’t intend to deprecate much between major version numbers, but this seemed like a reasonable time to make an exception.

@quri/squiggle-lang

Breaking changes

• SampleSet distributions are now used as the default.

  • This change is important because only SampleSet distributions handle correlations, and users expecting correlations got confused when the defaults were for symbolic distributions instead. If you want to use symbolic formats, you can, like: Sym.normal(5,2).

• a to b expressions always evaluate to lognormal distributions, limited to positive-only arguments.

  • Previously these changed to use normal distributions at values zero or less, and this confused users. https://github.com/quantified-uncertainty/squiggle/issues/1095

• |> pipes syntax is removed, in favor of the -> syntax.

  • We had two syntaxes that did the same thing, and wanted to clean this up.

• # comments support is removed, in favor of the // syntax.

• Renamed functions such as scaleLog, scalePow, etc. to Danger.mapYLog, Danger.mapYPow, etc.

  • These were infrequently used and prone to errors.

• Default sampleCount in squiggle-lang is now 1k, matching playground.

New features

• Parameter annotations: f(x: [0, 10]) see docs for details

• Plot.distFn and Plot.numericFn (Plot.fn is removed)

• Support for manual plot scales

• Support for docstrings. /** ... */ comments are displayed in the viewer

• List.reduceWhile function

• Dicts and bindings are ordered

• map callback supports an optional second index parameter

• Support for { foo, bar } shorthand in dictionaries

• Mixture correlations https://github.com/quantified-uncertainty/squiggle/pull/1732

Fixes

• Exponentiation is right-associative

• Units are whitelisted; 100blah is a syntax error

• Fixed error message when ternary condition is wrong

Performance improvements

• ~2x speedup on synthetic lambda-heavy benchmarks; similar improvements on real code, on average

@quri/squiggle-components

Breaking changes

• Many @quri/squiggle-lang APIs have changed, so this package should be updated at the same time as @quri/squiggle-components

• "Input variables" tab was removed; you can inject your JSON data directly into Squiggle instead

New features

• Movable divider between editor and graph view

• Support for new plots: Plot.scatter, Table.make and others

• New default tick format. This fixes an error that small numbers (0.01) were shown as 10m; #2007.

• Ability to "zoom in" on any variable in viewer; #1913

• "Find in editor" button in viewer

• Other various updates to the playground UI

Fixes

• Display Infinity as "Infinity"

• Fix shortcut tooltips on non-macs

• Charts filter out infinity values from the domain

• Improve tooltip for errors in editor

VS Code extension

• Improvements to syntax highlighter

@quri/prettier-plugin-squiggle

Initial release. Install this package to format any Squiggle code with https://prettier.io. Requires Prettier v3.

@quri/ui

Initial release with common UI components by QURI, used in squiggle-components and Squiggle Hub. Storybook

You probably shouldn't use this package directly if you don't work at QURI, because we don't have any stability guarantees and optimize for our convenience.

Other

• New documentation, now with search.

• We've started work on relative values functionality in Squiggle Hub. This is still fairly error-prone, we'll work on cleaning it up in the next few months.

Full changelog here

Online - This Thursday, May 11, 10:00 am – 11:00 am PDT

This Thursday, I’ll give an online presentation on our work for the Software, Data, and Tech Effective Altruism group. There should be ample time for questions and answers.

Estimating Everything Everywhere Always

A survey of the Quantified Uncertainty Research Institute's agenda to advance large estimation systems.  This agenda outlines a software-heavy paradigm meant to help make efficient progress on key epistemic questions.  Special attention on our estimation programming language Squiggle and estimating large utility functions.

Berkeley - Next Tuesday, May 16, 7 pm PDT

Next Thursday, Ben Goldhaber (QURI Board Member) and I are holding a small social in Berkeley. This is meant for professionals around EA/strategy/forecasting/probability. If you would like to attend, please leave a comment or email me at ozzie@quantifieduncertainty.org.

Several users have requested to be able to specify distributions based on 80th percentiles or 50th percentiles. Now you can write lines like,

normal({p10: 10, p90: 40})
lognormal({p25: 10, p75: 40})

If there’s interest in further flexibility, let us know. We could add this for all percentile combinations and provide similar support for other distributions.

One major technical change is that Squiggle is now built with ESM. This change significantly reduced our bundle size. There’s still a CommonJS build, but we’ll emphasize ESM over time.

Separately, the Playground now has syntax highlighting and supports autocomplete. Hopefully, this should make quick editing more painless.

Enjoy!

Full Changelog

The full changelog is here, but here’s the 0.7.0 part:

@quri/squiggle-lang

Language:

• New functions: List.concat, List.uniq, List.append, List.flatten, List.join, Dict.mapKeys.

• stdev and variance work for all kinds of distributions.

• Support for ==, != and + on strings.

• Support for trailing comma in arrays: arr = [5,6,] is now allowed.

• Plot.fn allows for programmatical control of min..max range in charts.

• Support for { p10: ..., p90: ... } and { p25: ..., p75: ... } in normal() and lognormal().

• Non-integer key lookups in arrays are now disallowed; arr[1.5] and arr[3/0] will result in error; previously non-integer keys got rounded to 0 or the closest integer.

• Fix for zero parameter function quirks; the checks are now stricter and some existing code might break.

• Fix for normal(5,2) * 0 special case.

• Fix for summary stats and inv function on pointMass distributions.

• Fix for inv and sample on discrete distributions.

JS API:

• sq function allows to embed Squiggle code in JS with syntax highlighting in VS Code (when VS Code extension is installed).

• value.asJS() method for easier conversion of results to JS values.

Other:

• ES6 modules build (we still provide CommonJS build as well).

@quri/squiggle-components

UI:

• New code editor based on Codemirror, with the improved syntax highlighting and auto-completion for variables and stdlib functions.

• Charts are now implemented in pure Canvas with D3 (instead of Vega), with some improvements in UI and rendering speed.

Other:

• This package is now ESM-only! We depend on D3, and D3 is ESM-only, so squiggle-components has to be ESM-only as well. If your project still uses CommonJS and you doesn't use Next.js or other smart transpiler, you might encounter problems. See this document for advice.

• Much smaller bundle size, thanks to removing some heavy dependencies.

• oneLine prop in SquiggleEditor removed (probably no one used it).

• I constructed the original Big List of Cause Candidates in December 2020.

• I spent some time thinking about the pipeline for new cause area ideas, not all of which is posted.

• I tried to use a bounty system to update the list for next year but didn't succeed.

• I found a researcher, Leo, to update the list in March 2022.

• In addition to the EA forum post, there is also an Airtable sheet, with filters for promisingness and other characteristics. This hasn't been updated since the original iteration in 2020. Initially, it was an experiment that could have been built upon, but it ended up being messier and thus abandoned.

As of now:

• I think the list is a fine resource as it is, and I intend to make sure that it continues to be updated.

• It is now more apparent to me that integrating this list into structures that could use it is probably as important as producing and updating the list in the first place.

• Some stakeholders known to me are:

  • Charity Entrepreneurship. Finding out whether they are in fact using it in their deliberations for deciding where to, and if it can be modified in order to be more useful to them, is probably a valuable step.

  • Various "longtermist incubators". These have generally completely failed to get off the ground, with the notable exception of Nonlinear, which e.g., has this well populated page with bounties.

  • The Center for Effective Altruism uses the original post as part of its Effective Altruism Handbook. As the list becomes longer, it’s possible that a lighter version might be more suitable as introductory material.

  • Possibly Open Philanthropy, though I doubt it.

• The Quantified Uncertainty Research Institute might not be an ideal institution for this, because the connection to forecasting and epistemics is a bit tenuous. But I think it will suffice for now.

• There is also a Cause Prioritization Wiki, with partially overlapping content and aims. It might be a good move to either:

  1. Move the Big List of Cause Candidates to that Wiki

  2. Combine contents of both sources into a different system, e.g., an Airtable

     The first step to decide this would be to create a list of options, with pros and cons for each one.

• Super linear is a new bounty portal that could be used to update this list and do related work in the upcoming year.

This concludes my thoughts for now.

We've used 99 Designs to come up with a logo and simple brand. This was our first time trying 99Designs. You can see the design brief, with all the design candidates, here.

Throughout this process, we've posted several surveys to collect feedback on logo options. Many thanks to all those who participated, the feedback was fairly decisive in our choices.

Key Deliverables

Reflections on the process with 99Designs

This was our first time using 99Designs. Overall, it seemed beneficial. It took more time than expected, mainly because we started with few ideas on what the logo should be. Many of the original options were all fox-based, likely because our homepage had a fox on it, even though we weren't particularly interested in fox logos.

This process was useful for getting a bunch of different iterations. We wound up getting 670 designs total. The downside is that most were very simple or derivative of one another. 99Designs has a set of "Senior" designers, but very few competed in this competition.

Once we had the final basic shape, we realized we would probably have to try color variations ourselves to figure out what to recommend. Below are some of the options we played with, for those curious. We like the idea of being able to change the colors a bit later on, perhaps for various applications.