We tried this at Hats Protocol, I think you’ll find our approach very aligned! https://blog.hatsprotocol.xyz/organizational-graphs

We came at it from the perspective of DAOs, which was helpful at first but ultimately limiting. I think a non-blockchain version of this will take off. Tailscale is in a good position to do it.

Our earned insight is that you need to build the right primitive for delegation that works up and down the org. Our latest thinking on that is what we call a “Trust Zone” - more details here: https://blog.hatsprotocol.xyz/making-daos-work

You can ignore the “DAO” parts. Happy to answer any questions, I’m still very inspired by this line of inquiry.

Thanks for sharing!

I wrote this post some time ago, and more recently built a thing to do roughly this for my small business: https://github.com/42futures/firm

Had it in practice for about 4 months now and happy so far. It works for me, at my small scale. Hoping to share a follow-up with lessons learned soon.

Any non-digital system you describe "as Code" is not a source of truth, but a Source of Hope. The code describes the intended state, something has to reconcile it with reality.

This is the same as having it in unstructured documents. Which means the auditing is still required funny enough.

So yes, this could be done. I'd love to see what run in the CI/CD for a change. When someone works on the wrong thing, or breaks compliance IRL, how do you backport it into this? "Alice is a software engineer, and created this SaaS account with her email when the company was founded. The admin email can not be changed and she has admin even though another role should control that"

In the future, laying off half the company will be just one terraform apply away.

This is partly a description of the concept of the business ontology. Bob Muglia has been discussing this as the central problem to be solved in the data platform space for at least a decade. You could view the battle between the various vendors vying for a role in enterprise AI as really a battle over who owns the business ontology or semantic layer.

This article does a good job explaining https://metadataweekly.substack.com/p/ontologies-context-gra...

There’s plenty of software that does this sort of thing, often industry specific but plenty that aren’t. You don’t see it “as code” in the raw like this article wants mainly because a company doesn’t deal with this information in such a non-integrated way, they do so as part of a more integrated whole. Monolithic ERP suites are probably the best example, and when done well it really does make a whole host of things easier and more seamless, like compliance modules that run defined routines that track with policy as implemented in operational modules.

If it doesn’t run, it isn’t code.

But things that don’t run have much less overhead than code: you don’t need to test then, update them, maintain them, they can’t really “not work”, people will adapt if they don’t make sense.

I /love/ this idea, but I don’t think it’s practical. Documents and business practices are about arranging people into semi-predictable organizations. The computing units of those organizations are people, and people run on text, not code.

I think I see the problem… and a possible solution.

I think the main problem with attempting to document this is that the system would not be running off of it. Your infrastructure document is automatically read and drives the deploy (or whatever). But if you want to make a change to a human’s responsibilities, you don’t get the simplicity of updating your organization documentation and clicking “execute.” So this new documentation you propose would always be lagging documentation rather than the actual driver of organizational behavior.

But! What if it was? What if all the managers in an organization were AI systems? They would read diff in the org chart and it initiated the communication to the respective human employees.

I could imagine testing this in a coffee-shop level business right now in which the LLM is probably capable of all the strategy and management decisions needed to effectively run it, operating within the constraints of policies and procedures all cleanly laid out in documentation.

As a programmer and founder, I think the idea is incredible, I would just change the understanding of "Code", given that what we've been hearing most lately is that "a markdown file is all you need".

I think it's not too far-fetched to think about standards, cultures, guardrails, compliance, etc. being documented, versioned, but more importantly, verifiable and applicable. In natural language, no code needed.

My company has been working for some years now on usm.tools (https://usm.tools/public/landing/), based on very similar approach.

USM tools is based on Unified Service Management (USM) method, which provides the necessary concepts to take the the vision one step further. The core idea is similar however: everything a company does is a service, and services can be defined as data. The surprising finding from USM is that in practice it is possible to meaningfully define any service only through five types of processes.

As services are data, you can have multiple views on that data. And as all data is in standardized format, it becomes possible to make generic cross-references between USM and for example ISO27K as rules that refer to your data, and those rules can be evaluated. As a result, you can see your ISO27K compliance on a dashboard in real-time.