A Canadian payroll dependency chart

I know one L.A.-based company that hires tons of remote Canadians, especially in engineering, because they're cheaper...but they're essentially a payroll/business accounting company.

This kind of thing is the bread and butter of SaaS companies though.

It's also exactly the kind of thing companies _wouldn't_ use open source for because if the code gets the tax law wrong they have nobody to transfer liability to. Once you have a corporate entity backing a subscription service, insurance underwriters can understand what's going on and you can finally manage your risks.

No, the only real "gotcha" is some employees have their match on a vesting schedule and you lose the non-vested portion of the money if your employment ends before the vesting schedule. These are typically not that very long - a few years.

From the looks of it that's been generated by `circo`, which is part of GraphViz and describes itself as a “filter for circular layout of graphs” and

       circo  draws graphs using a circular layout (see Six and Tollis, GD '99
       and ALENEX '99, and Kaufmann and Wiese, GD '02.)  The  tool  identifies
       biconnected  components  and draws the nodes of the component on a cir‐
       cle. The block‐cutpoint tree is then laid out using a recursive  radial
       algorithm.  Edge  crossings within a circle are minimized by placing as
       many edges on the circle's perimeter as possible.   In  particular,  if
       the  component is outerplanar, the component will have a planar layout.
       If a node belongs to multiple non‐trivial biconnected  components,  the
       layout puts the node in one of them. By default, this is the first non‐
       trivial component found in the search from the root component.

> If they had to read their own document, it would probably be far better written.

Perhaps not; I've always had a strong impression, whenever reading documents derived from tax policy, that the "architecture" of such documents is the way it is mainly for maintainability.

Which is to say: the effective tax code at any given moment, is the emergent result of the interactions of all the current tax laws on the books. And there are many such laws. And those individual laws can be updated or repealed; and new laws can also come in that, through a few simple statements, make sweeping changes to the meanings of other laws.

As such, the tax-filing instructions, ideally, have to be constructed in such a way that they cope efficiently with someone being able to pull a single jenga-block out of the tower that is tax law, that topples over a whole slew of other instructions and definitions. The team of tax lawyers and technical writers that maintain the instructions should not have to sit down and rewrite every instruction on every schedule/form, just because one of the core definitions changes. Because that's gonna happen a lot! Every year, even!

If I was in charge of a team of (automation-minded) lawyers and technical writers maintaining the tax-filing instruction repository, I'd probably, ideally, want to factor out the instructions into separate modular files per law — with each file acting as a sort of Aspect-Oriented equivalent of Javadoc. (Or, actually, something very much like Inform 7. See e.g. https://i7-examples.github.io/Bronze/source_1.html)

So you'd see:

• Paragraphs that interpolate definitions as constants from other laws' modules;

• paragraphs that have implicit AOP hooks for other laws' modules to inject additional language into;

• the ability of a law to override specific sentences or wording of the language of the laws so far;

...and so forth.

This would be hell to read, but it'd sure make the job of dealing with changes in the law easy. (And it wouldn't be something you'd really read anyway — more often, it'd be something you'd carefully poke at, while watching the compiled result change live in a split pane. Like writing LaTeX in LyX.)

---

To be clear, I don't imagine that any existing set of tax-form language is actually maintained using some weird AOP DSL.

Rather, I imagine that the maintainers are manually doing the same business process that use of such an AOP DSL would formalize.

They're maintaining a very non-intuitive "storage architecture" for all the instructions that go into these forms, to minimize re-working when the law changes; and then — mostly manually, but maybe with a bit of Excel — collating them together into new schedules and forms each year.

And it's that "storage architecture" — despite not being something as rigid as source code — that still nevertheless forces the language of the instructions into the form you see at tax-filing time, with the weird grammatical shapes, the distant definitions, etc.