Thread by @patio11

A lot of complexity in the tax code comes it using a mishmash of type systems.

Why is it hard calculating what someone's income tax is? Well, when you dig into it, income isn't an integer. It's an arbitrary object which can support a stupidly high number of interfaces.

The tax code, your tax return, and your accountant's tax preparation practices all have to impose a type system upon your income objects, at run-time. And this is where a huge amount of the complexity comes in.

This is true of many, many objects which are relevant in tax.

You'd think that at least corporations have a good type system. C corps, S corps, LLCs. Three types! We have at most three branches to the if statement, right?

Oh boy.

Let's start with "C corp and LLCs are classes but S corps are an interface."

Except that's also a lie. C corps are actually a family of ~50 trees of abstract classes, most (but not all) of which have one implementation. Ditto LLCs.

Object relationships, where to start.

An LLC can be shareholder in a corporation which is a shareholder in a corporation which is a member of an LLC which is a member of the first LLC in this sentence.

One of the benefits of Atlas is, while working within a structure which exists in the world, we get to make some simplifying assumptions by fiat.

For example: all Atlas companies, at present, are Delaware C corps. That reduces dimensionality by a factor of over 100.

So when we're building a tax product, or working with accountants and telling them to write procedures for working with thousands of Atlas companies, we can bake in the knowledge that we only have to address the complexity possible in Atlas companies, not in the untyped world.

As of the day when we started Atlas, we just created Delaware C corps.

Over time, the hope is that "an Atlas company" implements the interface "Delaware C corp" (or similar) where you need that to plug into legacy infrastructure, but is transformatively better.