The main problem here is that real people operate in fuzzy domains. Snapping them into place "with code" won't magically resolve the gray areas inherent to the most valuable real workflows.
Think about the prized "high agency worker." What makes them desirable is the willingness and ability to make well informed, unilateral decisions on matters that are likely not yet organizationally codified, or codified in a way that is "wrong" for the task at hand.
Also, the reason terraform works is because it is _operational_. As in, it's actual code that runs. If it was mere documentation, it would drift like nobody's business. In order to make "organizational code" operational, you would need enforcement (a compliance team?) manually keeping the documentation in sync with reality in all of the meat and thought spaces where real work happens.
The only place where this can plausibly be automated is in digital spaces. In fact, I'm surprised the article doesn't go there: "organizational code" starts feeling way more plausible as definition for AI agents than for real people, specifically because agents are operationalized in digital spaces, where enforcement can be automated.
This is not a new or novel idea. I proposed such a thing at the start of my career in tech, and repeatedly propose it when I feel I have ears willing to listen.
The problem - and I do mean the problem, the only problem - is the threat this poses to power dynamics in the organization.
Compliance people do not benefit from their outputs being readily searchable and indexed like this, because it means there’s less need for them. Executives and leaders do not benefit from this, because they’re increasingly hired specifically because of their knowledge of various compliance frameworks. The people whose power derives from this knowledge and expertise are overwhelmingly the people in charge of the company and its operations, and they benefit more from blocking it outright than implementing it.
Don’t get me wrong, I love this idea. I love transparency in organizations, because it makes it infinitely easier to identify and remediate problems beyond silo walls. It’s peak cooperation, and I am all for it.
I also do not see it happening at scale while competition is considered the default operating mode of society at large. That said, I would love to work for an organization placing importance on this degree of internal cooperation. I suspect I’d thrive there.
What prevents people from not doing what the policy says? Since neither "paper doc" policy nor "code policy" actually constrains humans from trying to exploit or work around the system, oversight and compliance still seem like messy human functions. Does this just become "more structured compliance documentation"? Which sounds nice, but not dramatically different.
And on the creation side, what prevents political fights over what goes into the "code policy" of exactly the same sort that lead to compromises or oddities in paper policies?
It constrains power and makes decisions auditable and holds those with power accountable to guidelines. Management doesn't like this paradigm for the very same reasons big tech platforms make conduct and moderation guidelines vague and nonspecific. It frees them up to remove, penalize, fire, and otherwise exert power for reasons they can't explicitly justify.
It's exactly the same paradigm the EU and countries around the world are avoiding - denying due process in things like freedom of press and expression, because they feel it allows them flexibility in suppressing and "managing" speech, people, and groups they deem problematic.
Having an explicit rule of law constrains the exercise of power. Those looking to wield power will never like that.
> The problem - and I do mean the problem, the only problem - is the threat this poses to power dynamics in the organization.
And expertise, to be fair. Documentation as code is what we in the software industry call testing/type systems. The vast majority of developers cannot even write a good test for their code (if they are willing to even try at all), let alone their eyes completely glazing over if you ask them to write, like, an Rocq proof. And that's people who live and die by code, not business people who are layers removed from the activity.
> I also do not see it happening at scale while competition is considered the default operating mode of society at large.
You don’t even need competition between people and orgs, just between solutions that work more-or-less equally but come with different second-order tradeoffs. Consider two approaches that solve a company’s problem equally but create different amounts of work for different people in the organization. Which solution to choose? Who gets to decide, based on what criteria? As soon as even a little scale creeps in this is inescapable.
> That said, I would love to work for an organization placing importance on this degree of internal cooperation. I suspect I’d thrive there.
I've been looking for such a org my entire career but recently resigned myself[1] to the fact it'll probably not happen unless I come into a situation when I can create it myself.
The first one is the classic. Don't know about the second one.
Power dynamics have been extensively investigated by the "Johnstone school" of improv, because humans are (mostly preconsciously i.e. usually are not but can become conscious about it) interested in power dynamics -- especially in situations where power balance is switching -- so this is the key if you want improvise acts that feel realistic and capture the audience attention.
To really understand it, I would recommend taking some improv classes that are based on Johnstone's teachings. But the book will give you the idea.
I tried digging around keith johnstone but i could only find theatrical improv which, unless it flies above my head, had very few to do with the workplace dynamics of real jobs. Unless the concept is to insist on the fact that adult life is just a play and treat your day like a space of randomness to disrupt the established roles ?
I think the closest that this has come is in the form of GitLab, which pretty famously did a ton of the corporate work in the format of a very open Handbook (https://handbook.gitlab.com/)
In the early years, it was extremely, extremely open and comprehensive. I've definitely looked through it when I wasn't sure how to handle something at work.
That's pretty cool. Wonder if it is deployed and updated religiously still. If they wanted to deploy an 'Agent' worker that source is goldmine for context.
I love the vision, but it glosses over the most important difference between Infrastructure and Companies.
Infrastructure as code is prescriptive. The code is the source of truth, and the world gets crested from it.
Company as code is descriptive. It is constantly catching up to meat-space, rather than creating it. Changes are gradual instead of instant roll-outs. Patterns change over time and only get documented later.
Making the company code prescriptive would require an insane amount of discipline that might be more stifling and restrictive than it is freeing.
Nailed it. I think about prescriptivism / descriptivism in terms of these archetypes:
- "Rule followers" think an org will be better off if everyone agreed on a set of rules to follow. At the boundaries, they will think about establishing new rules to clarify and codify new things. Charitably, I'd add that they might remove rules that are obsolete, but we all know this is not sufficiently true in practice: governments, for example, are much more likely to add new rules than to remove old ones.
- "Rule breakers" think that most rules are suggestions. At the boundaries, they will see rules other people are needlessly bound by, and translate those into strategic openings for whatever game they're playing. For better and for worse, start-up ecosystems are full of people like this.
Rule followers want to be told what's allowed, while rule breakers try to figure out what _should_ be allowed from first principles. At the extreme, they tug the world towards authoritarianism or towards anarchy.
This is obviously a spectrum, so everyone has both of these archetypes in them, albeit in different proportions (e.g. most people pay taxes, but almost no one drives the speed limit).
Isn't this essentially just trying to reinvent ERP (i.e. what SAP has built a 207 billion dollar company at time of writing on and 90% of fortune 500 companies along with endless other large organizations use).
One can argue that ERP as code is higher value than whatever it is right now, but to act like this is a totally new idea is insane.
I worked in a place where basically everything that happened in the company was implemented as actions within Lotus Notes.
While the choice of implementation and performance were abysmal (Notes was a great/the only choice when the decision was made but 25 years later not so much), the actual idea was amazing and it worked extremely well.
It's all cool as long as you keep all of this up to date, and that requires a lot of scrutiny and discipline.
Once I had to go through a security audit at a job I had. Part of it was to show managing secret keys and who had access to them. And then I realized that the list of people who had access to one key was different than the list of the code owners of the service I was looking at, which was yet different than the list of the administrators of that service. 3 different sources of truth about ownership, all in code, all out of sync.
I always thought of this as authority, accountability, and responsibility of a thing. Ideally one group or person has all three. In practice you’ll have many entities with some combination of the three.
If someone needs access to a secret, you would implement it in this DSL and commit that to the system. A side effect would run on that which would grant access to that secret. When you want to revoke access, you commit a change removing that permission and the side effect runs to revoke it.
I suspect hes designed a system for HIS company, which is in a data heavy industry. this doesnt apply to most other types of company, and I suspect when he tries to actually do it, it falls apart when he tries to define any requirement or obligation that stems from legislation. If the law was a coherent and unambiguous specification, thered be no problem, but the reality of it is messy and not so easily defined.
I do this, more or less, for my small law firm. Employee and client information are stored in Recfiles and accessed with GNU Recutils. Adding or changing is a pull request, and all sorts of GitHub actions run. Works pretty well!
+1 would love to see a video or read an extended write-up of how you implemented and work with your system on a daily basis, and what exactly it does for you
Wat, how have I never heard of this! Very cool. Do you have any insights you could share on your own setup, what worked well and what didn't? Are you just storing information in plaintext, or do you use some visualization libraries to make consuming the information a bit easier as well? Very curious about your setup.
I think that it is a narrow view of a "developer" that imagine reinventing what basically already exist in decade with HR/"people management" management software that are widely distributed.
It is sometimes also done by big ERP and basically available in any big directory and access management platform like Microsoft Entra ID (or whatever is the last current name) and co...
In some big companies, for expenses or performance reviews you have a terrible stack of relationship info and logic involved.
We could even say somehow that the first big entreprise software were creating with that kind of purpose for the modern IT area.
The worst limitation to all of this is users being lazy to input all the info that might be required, or updating it.
For example, how many of you never filled their "address" in their record in the big company internal directory portal because it looks useless and is not mandatory?
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.
Licensing it as AGPL-v3 throws up an interesting question - given the thing this produces is your company as code, if you use this does your entire company count as a larger work that would need to be open sourced? Or is there an explicit distinction between the "firmware" (excuse me) and the work product?
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"
A company is more than the function of it's org chart.
There's business description being uncaptured sporadically in every Slack message, watercooler moment and email. (two of those are much easier than the other).
If you boil someone's actual job down to a HR job spec and assume that will suffice... you'll produce both absurdly long HR job specs and still fail to capture the entirety of someone's role.
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.
Similarly, I've seen this in enterprise IAM software, but again as data, not as code.
Imagine a very large company that has a heterogeneous setup: say it has plain LDAP for *nix machines and AD for Windows. The IAM stuff has connectors for both, and encoding the org chart into that product enables it to synchronize that structure into both systems.
If you want this to extend to all compliance checkboxes, I think it'd be an endless can of worms.
How do you enforce (with code) that all new applications created by various teams get added to the right inventory? At some point a human has to determine if an application is in- or out-of-scope for certain restrictions.
If a compliance framework requires certain hashing algorithms for certain types of data, how does your company-as-code system enforce that?
What I see with compliance is that a lot of it is the framework saying "you must do X and Y and Z", and the solution is to write a document saying "employees must do X and Y and Z" then share it with everyone. Then you take a screenshot of that happening (if even possible - you might instead just swear that it's happening).
I guess what I'm getting at is that there's a huge human element here to begin with. If the article is proposing a structured language for declaring your company and policies, how is that different from a Word doc? That is, unless your structured language is actually interpreted by a program that is capable of enforcing what it says. And I think building that enforcement system would be quite hellish.
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.
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.
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.
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.
Would you be able to share more? I lead a tiny non-profit org doing data literacy mentoring and I've been meaning to move more of our process docs to Logseq. Although I probably don't need a tool of the level of sophistication of usm.tools, I could take inspiration from your core ideas for our homegrown system.
To understand the approach, you need to first understand the method it is based on.
I have written a simple introduction about it that you can download for free from simpleusm.com, no sign-up required.
Simple homegrown system for processes is not that difficult to do. You basically model the USM process model, templates as instances which you then copy as a basis for editing and make a UI around the editing.
You could even just use JSON files and git, but while the data model is not complex, it is still not simple enough for editing by hand in an editor.
Then the question is what is the benefit. I would say that just using USM to define your services is helpful.
By this approach you can build various stakeholders views to your services that are always up to date and do not require manual labor.
The interesting gap in this framing is that most "company as code" attempts model the org chart and stop there. But the actual operational DNA of a company is the implicit routing logic — how decisions get escalated, which context flows where, who has veto power over what. That stuff lives in peoples heads, not documentation.
IaC worked because infrastructure has well-defined primitives (servers, networks, storage). Organizations don't. The equivalent of a "terraform plan" for restructuring a team would need to model second-order effects on information flow, which is closer to simulation than declaration.
The GitLab handbook is the closest real example, but even that works because GitLab is extreme about async-first communication. The handbook IS the routing logic. Most companies couldn't do this because their real org structure doesn't match their formal one.
The softer approach to this I've implemented in the past is to ingest and link up org data (user accounts, groups, projects, etc) into one central DB and then provide an audit notifications or dashboards to authorized users. Examples:
- Slack user detected with full access that isn't associated with a staff-grouped LDAP account
- Group A in System X doesn't match the members of Group A in System Y)
- Service Z provisioned, but their associated customer account is deactivated
These kinds of violations _can_ be automatically synchronized in a variety of ways, but I've seen that result in politically embarrassing outcomes (e.g. Sensitive user X is fired, their Slack account is automatically deactivated, people notice before some kind of staff meeting can be held to talk about what's going on).
The approach described here - model things as graph - can really be applied to model any domains.
If you are into this type of modelling, you may find value in Mangle, a datalog-based logic programming language and deductive database library. You do not need to invent dozens of DSLs but can do it all in one. And without all the RDF trouble.
Interestingly, reading about Yegge's Gas Town got me thinking about this topic. Gas Town aims to create a "dark software factory" where agents organize themselves to build software autonomously with only high-level human direction, so Yegge created a weird rube goldberg fever dream of cats, preachers, diggers, mayors and god knows what else. But why? We already have real human organizations staffed and structured in particular ways that are able to deliver software, why not follow that pattern? With something like this, agents can start with a generic software dev shop and iterate on their own organization, instead of Yegge manually dreaming up what roles and relationships should exist.
"Code" is absolutely the wrong word here. There's nothing executable about it.
It's a model. And it will inevitably be incomplete and out of data, because the map is not the territory[1]
Of course, the same is true about the unstructured documents he laments, and whatever is done with those documents could probably sped up a lot this way, probably enough to justify the cost of building and maintaining it.
But the more advanced use cases he imagines run a big risk of making very costly decisions based on an incomplete or outdated model.
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.
- I'm not convinced the graph is necessarily cyclic. Often two codependents are actually dependent on some common bits and otherwise independent.
- this is essentially deterministic propagation of configuration (think dhall, jsonnet, etc) plus reconciliation loops for external state, terraform style — not dissimilar to how the rest of CI/CD should operate, in fact my view is this is an extension of CI/CD practices up the value stream.
I'm definitely strive for something like this when possible.
I agree that the company as code can be tested without too much risk if you think about as "model your world drawing a circle around what you own".
You can be your own auditor constantly so that you pre-answer questions you would ask in an audit.
I would advise against the always tempting "we are the everything platform" because that rafely scales and makes you a bottleneck. You won't be able to keep up. It's easier to model the tribal knowledge of your own world knowing where the frontiers are and that can even be a forcing function to simplify and reduce externalities.
Edit: make sure whoever works on it is pain point driven and solves things for themselves and then you will build just enough. A world that is more programmatic and can tolerate fuzzy translations (MCPs/LLMs) and where you can test (evals) the level of quality you need can make this cost effective.
> However, when describing and managing our company, we resort to digital paper and tidbits of info distributed across people in the building.
The perception that ISO/IEC 27001:2022 is simply an exercise in document creation and curation is frustrating. It is not, but an auditor cannot be in your company for a year or three, so the result is the next best thing: your auditor looks at written evidence, with things like timestamps, resumes, meeting minutes, agendas, and calendars, and concludes that based on the evidence that you are doing the things you said you're doing in your evidence reviews and interviews.
The consequence if you are not doing these things happens if you get sued, if you get yelled at by the French data protection regulator, or if you go bankrupt due to a security incident you didn't learn from, and your customers are breathing down your neck.
All of the documentation in the world doesn't mean you actually do the things you write down, but we have to be practical: until you consider these things, you aren't aware of them. You can read the standard and just do the best practices, and you'll be fine. The catch is that if you want the piece of paper, you go to an auditor, and people buy things because that paper means that there is now an accountability trail and people theoretically get in trouble if that turns out to be false.
It's like the whole problem with smart contracts is that you can't actually tether them to real world outcomes where the smart aspect falls apart (like relying on some external oracle to tell the contract what to do). Your customers care about ISO because your auditor was accredited by a body like ANAB to audit you correctly, and that reduces the risk of you botching some information security practice. This means that their data is in theory, more safe. And if it isn't, there is a lawsuit on the other end if things go awry.
You're citing the article mid-sentence. The full sentence is:
> Imagine if we could represent our entire organisational structure programmatically instead—not a static picture, but a living, breathing digital representation of our company that can be versioned, queried, tested, and automatically verified.
So yeah, the organisation is living and breathing by virtue of the humans inside of it.
But the representation of its organisational structure refers to a picture of an org chart.
Non-tech people also aspire to have the entire org structure represented digitally.
But in static, proprietary binary formats in file repositories that can only be manually queried.
Our code is already checked into version control and can be programmatically accessed via CI, agents, etc. Our software production environments can already be queried programmatically via APIs. Our issue trackers have hooks that react to support tickets, pull requests, CI. Then there's an airgap where the rest of the org sits with Word documents and pushes digital paper around. Artifacts delivered to customers that must be manually copied, attached, downloaded by hand.
The dream is that modern software development practices would propagate throughout companies.
I would probably adapt a slightly different strategy/structure... probably using a git repository with markdown files and a mix of front-matter and TS with a DSL library for rules processing.
The cold storage is a combination of directory structures and markdown files with appropriate front-matter. This could then be queryable directly, or via normalization into a database that represents the same data. By being markdown, you can write rules/policies in a longer/legalize format that Management/HR and Employees can read and understand... port to web layouts for looking at and searching while having a structure that is reasonably developer friendly... the relationships would be similar, but each entity would be represented with a markdown file with its' own front matter and references to other documents.
Two major factors I see a impediment to this:
1. Most management doesn't understand it and therefore won't champion it.
2. Those few that do understand it will resist it because it reduces the need for management and process.
This is similar to the Bible being in a dead language only understood by priests.
But how amazing would it be if everything from company policy to product specifications was in a format that could be programmatically accessed and tracked? When/if you needed a document you would access it from an artifactory where it had been generated and versioned automatically?
It may very well be that LLMs will push this idea to the forefront. PDFs and Word Docs suck for AI interaction. As we incorporate LLMs into our businesses it might be a natural progression to move toward databases, LaTex, code and source control for documentation and policy.
The New Testament is actually in Greek, if you go to any church in Greece they are reading from it in the original language and people understand it fine.
Modern Greek speakers can NOT understand ancient Greek. And modern Hebrew is NOT mutually intelligible with Aramaic. The OP is correct and the two responses are nonsense. Also, in the 1500s when the Bible was translated to English, very few Europeans spoke Latin and if they did it was a very different Latin from the translations from the Roman era (pre 500 or so). Languages change over time and the Latin spoken by the aristocrats in the 1500s was very very different from the Latin spoken by the Romans.
I simply made the observation that when you go to churches in Greece, they are speaking the original New Testament and people can understand it. Which part are you refuting, that the priest is reading the original text or that the parishioners can understand him?
It certainly sounds strange and unlike how any modern Greek person would speak, but it can be basically understood especially if you are a bit used to it. I’m not an expert but I think it’s probably a smaller gap than say Latin and modern Italian. Definitely a smaller gap than English and Old English, despite being more than twice as old!
Virtually none of the Bible was written in a currently-dead language. Only small bits were written in Aramaic, and Koine Greek and Biblical Hebrew are pretty much comprehensible to modern Greek and Hebrew speakers.
Even the Christian era of the Bible being distributed in Latin made perfect sense since it was originally mostly being distributed to people who spoke Latin with questionable accents (and where Latin was the language everyone who was literate was literate in).
I think documentation, in the form of code is the ultimate goal for everything. But, the problem of divergence remains. We already struggle to keep documentation on codebases (which we interact with on a daily) converged with the reality. On the business side, it's very difficulty to find the practicality of having these relationships documented, as it is a social problem. One thing for sure, is that it is hard to document social context in an business setting. Like, that one annoying guy that everyone avoids. It would be known socially, but these complex relationships cannot be written. Either way, I think it would be cool to reach this system eventually.
I always felt the idea of trying to align your code, policy, software and infrastructure so it's easy to do compliance is the bread and butter of devops and devsecops in a regulated environment,
Is this an article by someone who's just done ISO 27001 for the first time and realised that?
I feel like this is kind of missing the point that companies are mainly a group of humans and their roles and responsibilities matter to them emotionally. Managing those expectations and feelings can only be done by other humans that feel empathy (good managers) and abstracting such relationships onto something that can be "versioned, queried, tested, and automatically verified" might create a shitty soulless place to work.
Yes - the author's observations are not wrong. Companies, on paper, are logical. However, as one professor told us in college "All companies are perfect until you introduce the humans".
Humans are messy. Humans work outside of whatever system you create. You can codify all your things all you want, it simply will not capture the operational complexity of a business run by humans.
The problem needs to be flipped on its head. LLMs give us the capacity to do just that. It's far more accurate to analyze what the humans are doing, note deviations and follow up on those where regulatory compliance is required. This captures both written processes as well as their practical implementations.
Exactly this and its a blind spot in the article. LLM's / orchestrated specialist agents can query SOP's, policy docs, compliance docs. Having humans build these artifacts in code isn't really needed at this point. Maybe if there is an interim format LLM's can use that save tokens / time / etc. Wouldn't assume that looks exactly like exactly what human coders would have used the past though.
Anything can be used for the good or for the bad. Defining how the organization is structured and how it operates usually is usually not about how people really do their actual work -- unless there are safety etc. regulations that must be met. Many enterprises are in constant chaos, which stresses people out. Adding some structure to it helps to alleviate that stress. For example, if there is a good template to document something, you don't have to start from the scratch. Of course, you could also go all in automate all your "management", in order to avoid talking with your employees. I don't think that will end well.
This is exactly what model-based systems engineering tools like SysML v2 are designed for. Model-based systems engineering aims to generate _all_ engineering artifacts from a formal model.
Imagine it -- security policies, infrastructure, etc. all codified in a formal model.
- Push-button generation of ISO-27001 documentation.
- Push-button generation of Terraform.
- Push-button generation of SpiceDB policies.
- ...
There is _a lot_ of missing technology, but this is critically important because it will help us ensure regulatory compliance at far greater speeds in fields like nuclear and automotive. And it enables automated reasoning over the models, to make sure you're actually doing what you set out to do.
If I had the capacity to take on this kind of modeling project right now, I'd probably lean toward Prolog or something like an OWL/Protégé ontology. Then it could just metastasize to the limits of my time and neurochemistry.
Very narrow spec of how company can fit into code.Try Integrating ERP system in non-tech business. You will see how resistant the people are to use a software that streamline their business and need customization that fit their operation procedures or outright resistance because it would make things a lot easier and make them irrelevant.
On successful integration all they would use ERP system would be for signing in , chatting, producing invoices, the rest would still be done manually, if lucky in excel files.
The DSL described in this post really resonates with me. I recently worked on a programming language that uses similar structures [0]. It lets the user define entities and their shape (Role, OrganisationalUnit, Person in this post) and entries for those entities. It contains a small scripting API that can be used to derive information from these "facts". Company as code could definitely be implemented on top of this.
The OP doesn’t understand the “gray zone” corporations operate. Pretty much every interaction, decision and actions operate in this domain. Ambiguity and intentional compartmentalization on a need to know basis.
Amazon and Koch Industries are
are probably the significant companies that come closest to this level of description and prescription.
You'd need something like probabilistic programming language to model discretion.
You'd want some way to compare organizational forms -- minimally build vs buy, but preferably also control via monitoring+specification vs selection+incentive alignment.
You'd probably need the kind of sensors and telemetry that no one would like, to avoid drowning in book-keeping.
In the future there will be one giant AI on premise with many physical bodies made in our own image to micromanage the humans. All conversations are monitored, depending on the complexity of your query and who you are talking to tokens are deducted from your account. A complex double-entry book keeping system divides the tokens and quality of the response over the things the company should be doing. Things will be neither investor, employee nor customer centric but 100% AI centric.
Well developed and maintained Standard Operating Procedures (SOP) go along way towards repeatable human processes. The hard part is finding the organizational discipline to use/maintain them.
Is this not basically Azure Management Groups for policy rules, Entra ID for identity management linked to whatever HR system your organisation has? Since we're in the Microsoft world you'd probably sprinkle Cluedin or whatever it's called on top of it for mdm.
I don't necessarily recommend living in the Microsoft cloud, but it's what companies do in Denmark, so it's what I know.
This is perhaps a bit different, but Fossil supports storing more types of written company artifacts in the repo:
>One notable feature of Fossil is that it bundles bug tracking, wiki, forum, chat, and technotes with distributed version control to give you an all-in-one software project management system.
I've used to do something like this, on a smaller scale and dubbed it "organization as code". As long as you have good enough providers for Terraform/Pulumi you can declaratively specify a lot of the interconnected stuff in a company.
I built this around GitHub as the indentity provider as my interest was declaratively defining repository access control, while also being able to use users public ssh keys to (re)provision services to get them access automatically.
I've done the same thing and I would not call it anywhere near org-as-code either. An organization is much more than a list of responsibilities, people, and compliance requirements.
For the latter, we already have policy-as-code tooling that actually works.
Might be a second language thing. Organization for me is stronger related to the root word organize; label, classify, cluster, etc. than something pertaining to processes and procedures.
The cyclical relationship graph this article mentions is doable with Gel[1], my favorite database (the team building it recently got acquired by Vercel so the database is in community's hands now).
1. There are many organizations invested in keeping the disconnected status quo
2. The true things you want to connect are owned by giants that are slow and dont trust or need you
3. You need to play by the big players rules or get nowhere here
I have started learning cuelang and there was nice webinar style video where the GitHub policies where defined as code and deployed with terraform. I immediately thought that such thing would be very valuable at auditing.
Um.” Manfred finds it, floating three tiers down an elaborate object hierarchy. It’s flashing for attention. There’s a priority interrupt, an incoming lawsuit that hasn’t propagated up the inheritance tree yet. He prods at the object with a property browser. “I’m afraid I’m not a director of that company, Mr. Glashwiecz. I appear to be retained by it as a technical contractor with nonexecutive power, reporting to the president, but frankly, this is the first time I’ve ever heard of the company. However, I can tell you who’s in charge if you want.” “Yes?” The attorney sounds almost interested. Manfred figures it out; the guy’s in New Jersey. It must be about three in the morning over there. Malice—revenge for waking him up—sharpens Manfred’s voice. “The president of http://agalmic.holdings
.root.184.97.AB5 is http://agalmic.holdings
.root.184.97.201. The secretary is http://agalmic.holdings
.root.184.D5, and the chair is http://agalmic.holdings
.root.184.E8.FF. All the shares are owned by those companies in equal measure, and I can tell you that their regulations are written in Python. Have a nice day, now!”
thanks for the recommendation, I've put a hold on it for my library now.
This article reminds me of another book [1] called Holacracy where how a business is run is systematized according to other pre-defined principles. David Allen, a productivity trainer, used it at his own company for several years before eventually moving away from it because the ongoing overhead to keep its system up was too much.
I wonder if this system will end up like that as well. I love the idea, but I think humans operate at a squishier level than our computers do, there's a risk of 'massive bureaucratic dehumanization and inflexible processes' and the Iron Law of Organizations that make such efforts as that book and this article fraught with peril. Taylorism has its limits.
But hey, if this works, I'll be excited to see more businesses adopting better practices and less painful fumbling around trying to do practices in an organic or unplanned way.
Accelerando's algorithmic company structure and (near?)DDoS the corporate legal system is the one idea from Accelerando that has stuck with me the most over the 20 years since I first read it, and I came here to make the exact same reference.
(that, and the notion of Exocortex, which is what I've named some of my smartphones...)
It's a lovely idea of course, and I applaud anyone who manages to make progress in this area, but my condolences to all the others that have tried and failed. Perhaps the enabling tech could be improved, but we've had LDAP and the like for decades, and many orgs simply can't/won't build the business around the tech.
IMHO, the main issues are cultural, and culture change is hard once an org is established. Even new companies will face issues, because business culture at large gets carried forward through people and interactions. Good luck getting execs to learn and conform to anything, they're too busy emailing confidential Microsoft Office docs to unauthorized third parties.
Computers have the ability to provide wonderful features like transparency and accountability to orgs and business processes, but just like security, we typically choose not to invest in those areas unless forced. Perhaps AI will enable some change by providing a generic interface that brokers interactions between humans and the organization itself, analyzing all inputs before forwarding to a destination.
I love this idea despite the real world operational challenges - most people with governance responsibilities in organizations don't want to code, and code is often too precise to model messy social/organizational context without constant tweaking, tending, and exception management.
I'm an advocate for bringing software culture to GRC, or as it's sometimes called “GRC Engineering”. While there are plenty of products to automate evidence generation for auditors, the underlying policies and documents that they prescribe are usually still old-school Word/PDF-style boilerplate junk.
I'm working on an open source project for security policies/processes/standards that map back to underlying frameworks (e.g. SOC 2, GDPR, ISO 27001, etc.) Docs are Markdown with YAML frontmatter metadata, interlinks generated automatically, site is published via GitHub actions.
> I'm working on an open source project for security policies/processes/standards that map back to underlying frameworks (e.g. SOC 2, GDPR, ISO 27001, etc.) Docs are Markdown with YAML frontmatter metadata, interlinks generated automatically, site is published via GitHub actions.
> Would love to know if others find it useful or have built similar systems.
Yes, to both for over a decade now, and by now there are many so one doesn't need to rewalk the whole path, some are developed in open on GitHub.
Commercial firms have built on that for live monitoring of the mappings, although don't scratch at that too hard, it's generally mostly (a) self-selected subsets of controls, and (b) manually self-reported at the end of the day.
Have you Googled this or talked to large firms (e.g. banks) that care about avoiding footfalls with regularly scheduled regulator exams? Writing your own shows you grok the concept, many need (well paid!) help applying something off the shelf or from OSS.
In my research I haven’t come across the prior art you suggest exists. The trust centers you linked aren’t fungible with what I’m building with GraphGRC. The idea is to make all your security docs just a GitHub repo with structured markdown that permits useful automation (e.g. generating linked internal site, validating all docs have been “reviewed” annually by checking metadata, change control via PR, etc.)
There are plenty of GRC products out there and are popular for good reasons, but I don’t think any of them are Git/Markdown/developer-first.
Every few years some technocrat looks at the organizational chart of a company and yells "why is this not a machine yet". And then the next 5 years people have to come up with elaborate ways how to do the actual work inside the artificial abstraction that the technocrats create because of this.
Am I the only one who is mystified by this whole idea? People aren't CPU's. Good luck getting them to follow the code that you thought you were using to define their roles. On the contrary, what makes any complex system work is flexibility. And yes, if that calls into question the whole regulatory regime some companies (believe they) live under ... well, yes.
Also, would you even want it to? I've worked for companies with very rigorous compliance before. They are dead companies walking in most cases. As soon and their business model required/requires any significant change, they are toast. This is because these types of rules can't possibly cover all cases, just the ones the managers know about. Innovation requires flexibility and creativity and rules based systems are the opposite of that. By their very nature, they introduce the exact situations the rules can't cover.
The main problem here is that real people operate in fuzzy domains. Snapping them into place "with code" won't magically resolve the gray areas inherent to the most valuable real workflows.
Think about the prized "high agency worker." What makes them desirable is the willingness and ability to make well informed, unilateral decisions on matters that are likely not yet organizationally codified, or codified in a way that is "wrong" for the task at hand.
Also, the reason terraform works is because it is _operational_. As in, it's actual code that runs. If it was mere documentation, it would drift like nobody's business. In order to make "organizational code" operational, you would need enforcement (a compliance team?) manually keeping the documentation in sync with reality in all of the meat and thought spaces where real work happens.
The only place where this can plausibly be automated is in digital spaces. In fact, I'm surprised the article doesn't go there: "organizational code" starts feeling way more plausible as definition for AI agents than for real people, specifically because agents are operationalized in digital spaces, where enforcement can be automated.
Speaking about high agency workers, this Company as Code framework reminds me a lot of SaaSiroth introduced in https://youtu.be/dLTUqPue9sQ?si=OIxmP5_D-YZZD2UO&t=200 (KRAZAM: High Agency Individual Contributor).
The most productive workers follow the intent of procedures and use a risk based approach to following or not following the details.
This is not a new or novel idea. I proposed such a thing at the start of my career in tech, and repeatedly propose it when I feel I have ears willing to listen.
The problem - and I do mean the problem, the only problem - is the threat this poses to power dynamics in the organization.
Compliance people do not benefit from their outputs being readily searchable and indexed like this, because it means there’s less need for them. Executives and leaders do not benefit from this, because they’re increasingly hired specifically because of their knowledge of various compliance frameworks. The people whose power derives from this knowledge and expertise are overwhelmingly the people in charge of the company and its operations, and they benefit more from blocking it outright than implementing it.
Don’t get me wrong, I love this idea. I love transparency in organizations, because it makes it infinitely easier to identify and remediate problems beyond silo walls. It’s peak cooperation, and I am all for it.
I also do not see it happening at scale while competition is considered the default operating mode of society at large. That said, I would love to work for an organization placing importance on this degree of internal cooperation. I suspect I’d thrive there.
What prevents people from not doing what the policy says? Since neither "paper doc" policy nor "code policy" actually constrains humans from trying to exploit or work around the system, oversight and compliance still seem like messy human functions. Does this just become "more structured compliance documentation"? Which sounds nice, but not dramatically different.
And on the creation side, what prevents political fights over what goes into the "code policy" of exactly the same sort that lead to compromises or oddities in paper policies?
It constrains power and makes decisions auditable and holds those with power accountable to guidelines. Management doesn't like this paradigm for the very same reasons big tech platforms make conduct and moderation guidelines vague and nonspecific. It frees them up to remove, penalize, fire, and otherwise exert power for reasons they can't explicitly justify.
It's exactly the same paradigm the EU and countries around the world are avoiding - denying due process in things like freedom of press and expression, because they feel it allows them flexibility in suppressing and "managing" speech, people, and groups they deem problematic.
Having an explicit rule of law constrains the exercise of power. Those looking to wield power will never like that.
> The problem - and I do mean the problem, the only problem - is the threat this poses to power dynamics in the organization.
And expertise, to be fair. Documentation as code is what we in the software industry call testing/type systems. The vast majority of developers cannot even write a good test for their code (if they are willing to even try at all), let alone their eyes completely glazing over if you ask them to write, like, an Rocq proof. And that's people who live and die by code, not business people who are layers removed from the activity.
> I also do not see it happening at scale while competition is considered the default operating mode of society at large.
You don’t even need competition between people and orgs, just between solutions that work more-or-less equally but come with different second-order tradeoffs. Consider two approaches that solve a company’s problem equally but create different amounts of work for different people in the organization. Which solution to choose? Who gets to decide, based on what criteria? As soon as even a little scale creeps in this is inescapable.
> That said, I would love to work for an organization placing importance on this degree of internal cooperation. I suspect I’d thrive there.
I've been looking for such a org my entire career but recently resigned myself[1] to the fact it'll probably not happen unless I come into a situation when I can create it myself.
---
[1] <https://blog.webb.page/WM-081>
When/If you do want to create one yourself, there are a handful of tech cooperatives out there for inspiration: https://github.com/hng/tech-coops
> This is not a new or novel idea
Yep https://x.com/fduran/status/1134283398594387969
Any books about workgroup power dynamics ? i'm fascinated (morbidly in a way) by that
Harvard Business Review's Office Politics. Or any intro Industrial Psychology textbook.
Keith Johnstone: Impro
Is it ISBN-13: 978-0878301171?
Or ASIN B01K2J06SY
The first one is the classic. Don't know about the second one.
Power dynamics have been extensively investigated by the "Johnstone school" of improv, because humans are (mostly preconsciously i.e. usually are not but can become conscious about it) interested in power dynamics -- especially in situations where power balance is switching -- so this is the key if you want improvise acts that feel realistic and capture the audience attention.
To really understand it, I would recommend taking some improv classes that are based on Johnstone's teachings. But the book will give you the idea.
I tried digging around keith johnstone but i could only find theatrical improv which, unless it flies above my head, had very few to do with the workplace dynamics of real jobs. Unless the concept is to insist on the fact that adult life is just a play and treat your day like a space of randomness to disrupt the established roles ?
"Compliance" as we know it today is going away
Care to elaborate?
I think the closest that this has come is in the form of GitLab, which pretty famously did a ton of the corporate work in the format of a very open Handbook (https://handbook.gitlab.com/)
In the early years, it was extremely, extremely open and comprehensive. I've definitely looked through it when I wasn't sure how to handle something at work.
And that site is available as a git repository - on Gitlab of course:
https://gitlab.com/gitlab-com/content-sites/handbook
That's pretty cool. Wonder if it is deployed and updated religiously still. If they wanted to deploy an 'Agent' worker that source is goldmine for context.
I don't know about "religiously" but as of right now it was last updated 16 minutes ago:
https://gitlab.com/gitlab-com/content-sites/handbook
I love the vision, but it glosses over the most important difference between Infrastructure and Companies.
Infrastructure as code is prescriptive. The code is the source of truth, and the world gets crested from it.
Company as code is descriptive. It is constantly catching up to meat-space, rather than creating it. Changes are gradual instead of instant roll-outs. Patterns change over time and only get documented later.
Making the company code prescriptive would require an insane amount of discipline that might be more stifling and restrictive than it is freeing.
Nailed it. I think about prescriptivism / descriptivism in terms of these archetypes:
- "Rule followers" think an org will be better off if everyone agreed on a set of rules to follow. At the boundaries, they will think about establishing new rules to clarify and codify new things. Charitably, I'd add that they might remove rules that are obsolete, but we all know this is not sufficiently true in practice: governments, for example, are much more likely to add new rules than to remove old ones.
- "Rule breakers" think that most rules are suggestions. At the boundaries, they will see rules other people are needlessly bound by, and translate those into strategic openings for whatever game they're playing. For better and for worse, start-up ecosystems are full of people like this.
Rule followers want to be told what's allowed, while rule breakers try to figure out what _should_ be allowed from first principles. At the extreme, they tug the world towards authoritarianism or towards anarchy.
This is obviously a spectrum, so everyone has both of these archetypes in them, albeit in different proportions (e.g. most people pay taxes, but almost no one drives the speed limit).
Isn't this essentially just trying to reinvent ERP (i.e. what SAP has built a 207 billion dollar company at time of writing on and 90% of fortune 500 companies along with endless other large organizations use).
One can argue that ERP as code is higher value than whatever it is right now, but to act like this is a totally new idea is insane.
I worked in a place where basically everything that happened in the company was implemented as actions within Lotus Notes.
While the choice of implementation and performance were abysmal (Notes was a great/the only choice when the decision was made but 25 years later not so much), the actual idea was amazing and it worked extremely well.
> the actual idea was amazing and it worked extremely well.
What do you think are the reasons it worked so well? Any anecdotes of why it was so effective?
It's all cool as long as you keep all of this up to date, and that requires a lot of scrutiny and discipline.
Once I had to go through a security audit at a job I had. Part of it was to show managing secret keys and who had access to them. And then I realized that the list of people who had access to one key was different than the list of the code owners of the service I was looking at, which was yet different than the list of the administrators of that service. 3 different sources of truth about ownership, all in code, all out of sync.
> 3 different sources of truth about ownership
I see only 1.
Admin, access <> ownership.
I always thought of this as authority, accountability, and responsibility of a thing. Ideally one group or person has all three. In practice you’ll have many entities with some combination of the three.
I am sure mere access does not imply any kind of ownership.
Isn't the point that this is the source of truth?
If someone needs access to a secret, you would implement it in this DSL and commit that to the system. A side effect would run on that which would grant access to that secret. When you want to revoke access, you commit a change removing that permission and the side effect runs to revoke it.
From my experience, there is always a parallel process. But if you make the system painless enough, most of it will be in there, yeah.
> When you want to revoke access, you commit a change removing that permission and the side effect runs to revoke it.
For this to work, you’d need to also rotate the secret, or ideally issue one for each person (so that others don’t have to update their configs).
...but sometimes you can’t reliably automatically rotate the secret, because they could have used it for something in production.
I suspect hes designed a system for HIS company, which is in a data heavy industry. this doesnt apply to most other types of company, and I suspect when he tries to actually do it, it falls apart when he tries to define any requirement or obligation that stems from legislation. If the law was a coherent and unambiguous specification, thered be no problem, but the reality of it is messy and not so easily defined.
Made me laugh bc you’re right - there are a whole host of decisions that are better left undocumented and ambiguous.
This is not a bad idea but this person basically reinvented LDAP. Everything he wanted to do is already in LDAP, much already in Active Directory.
They started with their schema and everything they said just screamed Active Directory.
Right down to the low code interface for changes.
All they need to do now is slap AI on it and they'll have bags of cash delivered to their door.
LAIDBACK - Lightweight AI Directory Barely Actually Checking Krendentialz?
I do this, more or less, for my small law firm. Employee and client information are stored in Recfiles and accessed with GNU Recutils. Adding or changing is a pull request, and all sorts of GitHub actions run. Works pretty well!
+1 would love to see a video or read an extended write-up of how you implemented and work with your system on a daily basis, and what exactly it does for you
beyond the source controlled database, is it doing the same as what the article describes? ie enforces requirements etc
Wat, how have I never heard of this! Very cool. Do you have any insights you could share on your own setup, what worked well and what didn't? Are you just storing information in plaintext, or do you use some visualization libraries to make consuming the information a bit easier as well? Very curious about your setup.
I think that it is a narrow view of a "developer" that imagine reinventing what basically already exist in decade with HR/"people management" management software that are widely distributed. It is sometimes also done by big ERP and basically available in any big directory and access management platform like Microsoft Entra ID (or whatever is the last current name) and co...
In some big companies, for expenses or performance reviews you have a terrible stack of relationship info and logic involved.
We could even say somehow that the first big entreprise software were creating with that kind of purpose for the modern IT area.
The worst limitation to all of this is users being lazy to input all the info that might be required, or updating it. For example, how many of you never filled their "address" in their record in the big company internal directory portal because it looks useless and is not mandatory?
I’d love to reinvent an HRIS one day. Most examples I’ve seen are kinda painful to use.
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.
[flagged]
Are you a bot or bot-assisted? Repeating back the content of a comment and then asking a generic follow-up is a strange pattern.
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.
This is incredibly cool.
Licensing it as AGPL-v3 throws up an interesting question - given the thing this produces is your company as code, if you use this does your entire company count as a larger work that would need to be open sourced? Or is there an explicit distinction between the "firmware" (excuse me) and the work product?
Licensing generally applies only to the thing being licensed and not its output.
Otherwise all software written with a GPLv3 editor would also be GPLv3…or all software built with a GPLv3 compiler would be GPLv3. (Neither are true)
That's because the output isn't a derivative work of the licensed software.
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"
This sort of approach is likely intractable.
A company is more than the function of it's org chart.
There's business description being uncaptured sporadically in every Slack message, watercooler moment and email. (two of those are much easier than the other).
If you boil someone's actual job down to a HR job spec and assume that will suffice... you'll produce both absurdly long HR job specs and still fail to capture the entirety of someone's role.
> A company is more than the function of it's org chart.
Of course - but the org chart is context. It reflects how the work of individuals contributes to the whole (or at least, it should!)
Having all this in "code" means AI can put it into context.
In the future, laying off half the company will be just one terraform apply away.
To be fair I've seen some terraform fuck ups that that nearly did that already.
Fortunately AWS doesn't let you delete S3 buckets with files in them without emptying them first...
Or one AI agent tasked with optimizing the company finances.
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.
Similarly, I've seen this in enterprise IAM software, but again as data, not as code.
Imagine a very large company that has a heterogeneous setup: say it has plain LDAP for *nix machines and AD for Windows. The IAM stuff has connectors for both, and encoding the org chart into that product enables it to synchronize that structure into both systems.
If you want this to extend to all compliance checkboxes, I think it'd be an endless can of worms.
How do you enforce (with code) that all new applications created by various teams get added to the right inventory? At some point a human has to determine if an application is in- or out-of-scope for certain restrictions.
If a compliance framework requires certain hashing algorithms for certain types of data, how does your company-as-code system enforce that?
What I see with compliance is that a lot of it is the framework saying "you must do X and Y and Z", and the solution is to write a document saying "employees must do X and Y and Z" then share it with everyone. Then you take a screenshot of that happening (if even possible - you might instead just swear that it's happening).
I guess what I'm getting at is that there's a huge human element here to begin with. If the article is proposing a structured language for declaring your company and policies, how is that different from a Word doc? That is, unless your structured language is actually interpreted by a program that is capable of enforcing what it says. And I think building that enforcement system would be quite hellish.
Learn about dependent types and then hit an undecidable or incomplete problem lol
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.
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.
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...
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.
Would you be able to share more? I lead a tiny non-profit org doing data literacy mentoring and I've been meaning to move more of our process docs to Logseq. Although I probably don't need a tool of the level of sophistication of usm.tools, I could take inspiration from your core ideas for our homegrown system.
To understand the approach, you need to first understand the method it is based on.
I have written a simple introduction about it that you can download for free from simpleusm.com, no sign-up required.
Simple homegrown system for processes is not that difficult to do. You basically model the USM process model, templates as instances which you then copy as a basis for editing and make a UI around the editing.
You could even just use JSON files and git, but while the data model is not complex, it is still not simple enough for editing by hand in an editor.
Then the question is what is the benefit. I would say that just using USM to define your services is helpful.
By this approach you can build various stakeholders views to your services that are always up to date and do not require manual labor.
The interesting gap in this framing is that most "company as code" attempts model the org chart and stop there. But the actual operational DNA of a company is the implicit routing logic — how decisions get escalated, which context flows where, who has veto power over what. That stuff lives in peoples heads, not documentation.
IaC worked because infrastructure has well-defined primitives (servers, networks, storage). Organizations don't. The equivalent of a "terraform plan" for restructuring a team would need to model second-order effects on information flow, which is closer to simulation than declaration.
The GitLab handbook is the closest real example, but even that works because GitLab is extreme about async-first communication. The handbook IS the routing logic. Most companies couldn't do this because their real org structure doesn't match their formal one.
The softer approach to this I've implemented in the past is to ingest and link up org data (user accounts, groups, projects, etc) into one central DB and then provide an audit notifications or dashboards to authorized users. Examples:
These kinds of violations _can_ be automatically synchronized in a variety of ways, but I've seen that result in politically embarrassing outcomes (e.g. Sensitive user X is fired, their Slack account is automatically deactivated, people notice before some kind of staff meeting can be held to talk about what's going on).The approach described here - model things as graph - can really be applied to model any domains.
If you are into this type of modelling, you may find value in Mangle, a datalog-based logic programming language and deductive database library. You do not need to invent dozens of DSLs but can do it all in one. And without all the RDF trouble.
https://github.com/google/mangle
HN discussion https://news.ycombinator.com/item?id=33756800
Talk at REBASE 2025 "From Facts to Theories" https://youtu.be/UjOEHSZDBH8?si=qAjnkBQfPKMVaOPW
Societies across the planet can benefit from "Government as Code" for greater transparency and hopefully less corruption, fraud and waste.
Interestingly, reading about Yegge's Gas Town got me thinking about this topic. Gas Town aims to create a "dark software factory" where agents organize themselves to build software autonomously with only high-level human direction, so Yegge created a weird rube goldberg fever dream of cats, preachers, diggers, mayors and god knows what else. But why? We already have real human organizations staffed and structured in particular ways that are able to deliver software, why not follow that pattern? With something like this, agents can start with a generic software dev shop and iterate on their own organization, instead of Yegge manually dreaming up what roles and relationships should exist.
"Code" is absolutely the wrong word here. There's nothing executable about it.
It's a model. And it will inevitably be incomplete and out of data, because the map is not the territory[1]
Of course, the same is true about the unstructured documents he laments, and whatever is done with those documents could probably sped up a lot this way, probably enough to justify the cost of building and maintaining it.
But the more advanced use cases he imagines run a big risk of making very costly decisions based on an incomplete or outdated model.
[1]: https://en.wikipedia.org/wiki/Map%E2%80%93territory_relation
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.
Eminently doable, yes.
Two notes:
- I'm not convinced the graph is necessarily cyclic. Often two codependents are actually dependent on some common bits and otherwise independent.
- this is essentially deterministic propagation of configuration (think dhall, jsonnet, etc) plus reconciliation loops for external state, terraform style — not dissimilar to how the rest of CI/CD should operate, in fact my view is this is an extension of CI/CD practices up the value stream.
I'm definitely strive for something like this when possible.
> Has anyone tried this yet? If not, why not?
Yes (in a minimalistic TDD like way?). [1]
I agree that the company as code can be tested without too much risk if you think about as "model your world drawing a circle around what you own".
You can be your own auditor constantly so that you pre-answer questions you would ask in an audit.
I would advise against the always tempting "we are the everything platform" because that rafely scales and makes you a bottleneck. You won't be able to keep up. It's easier to model the tribal knowledge of your own world knowing where the frontiers are and that can even be a forcing function to simplify and reduce externalities.
- [1] https://alexhans.github.io/posts/series/evals/automate-audit...
Edit: make sure whoever works on it is pain point driven and solves things for themselves and then you will build just enough. A world that is more programmatic and can tolerate fuzzy translations (MCPs/LLMs) and where you can test (evals) the level of quality you need can make this cost effective.
> However, when describing and managing our company, we resort to digital paper and tidbits of info distributed across people in the building.
The perception that ISO/IEC 27001:2022 is simply an exercise in document creation and curation is frustrating. It is not, but an auditor cannot be in your company for a year or three, so the result is the next best thing: your auditor looks at written evidence, with things like timestamps, resumes, meeting minutes, agendas, and calendars, and concludes that based on the evidence that you are doing the things you said you're doing in your evidence reviews and interviews.
The consequence if you are not doing these things happens if you get sued, if you get yelled at by the French data protection regulator, or if you go bankrupt due to a security incident you didn't learn from, and your customers are breathing down your neck.
All of the documentation in the world doesn't mean you actually do the things you write down, but we have to be practical: until you consider these things, you aren't aware of them. You can read the standard and just do the best practices, and you'll be fine. The catch is that if you want the piece of paper, you go to an auditor, and people buy things because that paper means that there is now an accountability trail and people theoretically get in trouble if that turns out to be false.
It's like the whole problem with smart contracts is that you can't actually tether them to real world outcomes where the smart aspect falls apart (like relying on some external oracle to tell the contract what to do). Your customers care about ISO because your auditor was accredited by a body like ANAB to audit you correctly, and that reduces the risk of you botching some information security practice. This means that their data is in theory, more safe. And if it isn't, there is a lawsuit on the other end if things go awry.
> but a living, breathing digital representation of our company
It is breathing already, in the form of humans doing it.
No need to transform it into a static inflexible code thing.
You're citing the article mid-sentence. The full sentence is:
> Imagine if we could represent our entire organisational structure programmatically instead—not a static picture, but a living, breathing digital representation of our company that can be versioned, queried, tested, and automatically verified.
So yeah, the organisation is living and breathing by virtue of the humans inside of it.
But the representation of its organisational structure refers to a picture of an org chart.
Non-tech people also aspire to have the entire org structure represented digitally.
But in static, proprietary binary formats in file repositories that can only be manually queried.
Our code is already checked into version control and can be programmatically accessed via CI, agents, etc. Our software production environments can already be queried programmatically via APIs. Our issue trackers have hooks that react to support tickets, pull requests, CI. Then there's an airgap where the rest of the org sits with Word documents and pushes digital paper around. Artifacts delivered to customers that must be manually copied, attached, downloaded by hand.
The dream is that modern software development practices would propagate throughout companies.
Automate all the things!
I would probably adapt a slightly different strategy/structure... probably using a git repository with markdown files and a mix of front-matter and TS with a DSL library for rules processing.
The cold storage is a combination of directory structures and markdown files with appropriate front-matter. This could then be queryable directly, or via normalization into a database that represents the same data. By being markdown, you can write rules/policies in a longer/legalize format that Management/HR and Employees can read and understand... port to web layouts for looking at and searching while having a structure that is reasonably developer friendly... the relationships would be similar, but each entity would be represented with a markdown file with its' own front matter and references to other documents.
Just my own thoughts on this.
Two major factors I see a impediment to this: 1. Most management doesn't understand it and therefore won't champion it. 2. Those few that do understand it will resist it because it reduces the need for management and process.
This is similar to the Bible being in a dead language only understood by priests.
But how amazing would it be if everything from company policy to product specifications was in a format that could be programmatically accessed and tracked? When/if you needed a document you would access it from an artifactory where it had been generated and versioned automatically?
It may very well be that LLMs will push this idea to the forefront. PDFs and Word Docs suck for AI interaction. As we incorporate LLMs into our businesses it might be a natural progression to move toward databases, LaTex, code and source control for documentation and policy.
The New Testament is actually in Greek, if you go to any church in Greece they are reading from it in the original language and people understand it fine.
Modern Greek speakers can NOT understand ancient Greek. And modern Hebrew is NOT mutually intelligible with Aramaic. The OP is correct and the two responses are nonsense. Also, in the 1500s when the Bible was translated to English, very few Europeans spoke Latin and if they did it was a very different Latin from the translations from the Roman era (pre 500 or so). Languages change over time and the Latin spoken by the aristocrats in the 1500s was very very different from the Latin spoken by the Romans.
I simply made the observation that when you go to churches in Greece, they are speaking the original New Testament and people can understand it. Which part are you refuting, that the priest is reading the original text or that the parishioners can understand him?
It certainly sounds strange and unlike how any modern Greek person would speak, but it can be basically understood especially if you are a bit used to it. I’m not an expert but I think it’s probably a smaller gap than say Latin and modern Italian. Definitely a smaller gap than English and Old English, despite being more than twice as old!
Virtually none of the Bible was written in a currently-dead language. Only small bits were written in Aramaic, and Koine Greek and Biblical Hebrew are pretty much comprehensible to modern Greek and Hebrew speakers.
Even the Christian era of the Bible being distributed in Latin made perfect sense since it was originally mostly being distributed to people who spoke Latin with questionable accents (and where Latin was the language everyone who was literate was literate in).
I think documentation, in the form of code is the ultimate goal for everything. But, the problem of divergence remains. We already struggle to keep documentation on codebases (which we interact with on a daily) converged with the reality. On the business side, it's very difficulty to find the practicality of having these relationships documented, as it is a social problem. One thing for sure, is that it is hard to document social context in an business setting. Like, that one annoying guy that everyone avoids. It would be known socially, but these complex relationships cannot be written. Either way, I think it would be cool to reach this system eventually.
I always felt the idea of trying to align your code, policy, software and infrastructure so it's easy to do compliance is the bread and butter of devops and devsecops in a regulated environment,
Is this an article by someone who's just done ISO 27001 for the first time and realised that?
I feel like this is kind of missing the point that companies are mainly a group of humans and their roles and responsibilities matter to them emotionally. Managing those expectations and feelings can only be done by other humans that feel empathy (good managers) and abstracting such relationships onto something that can be "versioned, queried, tested, and automatically verified" might create a shitty soulless place to work.
Yes - the author's observations are not wrong. Companies, on paper, are logical. However, as one professor told us in college "All companies are perfect until you introduce the humans".
Humans are messy. Humans work outside of whatever system you create. You can codify all your things all you want, it simply will not capture the operational complexity of a business run by humans.
The problem needs to be flipped on its head. LLMs give us the capacity to do just that. It's far more accurate to analyze what the humans are doing, note deviations and follow up on those where regulatory compliance is required. This captures both written processes as well as their practical implementations.
Exactly this and its a blind spot in the article. LLM's / orchestrated specialist agents can query SOP's, policy docs, compliance docs. Having humans build these artifacts in code isn't really needed at this point. Maybe if there is an interim format LLM's can use that save tokens / time / etc. Wouldn't assume that looks exactly like exactly what human coders would have used the past though.
Anything can be used for the good or for the bad. Defining how the organization is structured and how it operates usually is usually not about how people really do their actual work -- unless there are safety etc. regulations that must be met. Many enterprises are in constant chaos, which stresses people out. Adding some structure to it helps to alleviate that stress. For example, if there is a good template to document something, you don't have to start from the scratch. Of course, you could also go all in automate all your "management", in order to avoid talking with your employees. I don't think that will end well.
You are describing essentially a healthy company.
You're on a tech news website as a reminder.
This is exactly what model-based systems engineering tools like SysML v2 are designed for. Model-based systems engineering aims to generate _all_ engineering artifacts from a formal model.
Imagine it -- security policies, infrastructure, etc. all codified in a formal model.
- Push-button generation of ISO-27001 documentation.
- Push-button generation of Terraform.
- Push-button generation of SpiceDB policies.
- ...
There is _a lot_ of missing technology, but this is critically important because it will help us ensure regulatory compliance at far greater speeds in fields like nuclear and automotive. And it enables automated reasoning over the models, to make sure you're actually doing what you set out to do.
If I had the capacity to take on this kind of modeling project right now, I'd probably lean toward Prolog or something like an OWL/Protégé ontology. Then it could just metastasize to the limits of my time and neurochemistry.
Very narrow spec of how company can fit into code.Try Integrating ERP system in non-tech business. You will see how resistant the people are to use a software that streamline their business and need customization that fit their operation procedures or outright resistance because it would make things a lot easier and make them irrelevant.
On successful integration all they would use ERP system would be for signing in , chatting, producing invoices, the rest would still be done manually, if lucky in excel files.
The DSL described in this post really resonates with me. I recently worked on a programming language that uses similar structures [0]. It lets the user define entities and their shape (Role, OrganisationalUnit, Person in this post) and entries for those entities. It contains a small scripting API that can be used to derive information from these "facts". Company as code could definitely be implemented on top of this.
[0] https://thalo.rejot.dev/blog/plain-text-knowledge-management
The OP doesn’t understand the “gray zone” corporations operate. Pretty much every interaction, decision and actions operate in this domain. Ambiguity and intentional compartmentalization on a need to know basis.
Amazon and Koch Industries are are probably the significant companies that come closest to this level of description and prescription.
You'd need something like probabilistic programming language to model discretion.
You'd want some way to compare organizational forms -- minimally build vs buy, but preferably also control via monitoring+specification vs selection+incentive alignment.
You'd probably need the kind of sensors and telemetry that no one would like, to avoid drowning in book-keeping.
Overall, what would the benefit be?
In the future there will be one giant AI on premise with many physical bodies made in our own image to micromanage the humans. All conversations are monitored, depending on the complexity of your query and who you are talking to tokens are deducted from your account. A complex double-entry book keeping system divides the tokens and quality of the response over the things the company should be doing. Things will be neither investor, employee nor customer centric but 100% AI centric.
Well developed and maintained Standard Operating Procedures (SOP) go along way towards repeatable human processes. The hard part is finding the organizational discipline to use/maintain them.
Is this not basically Azure Management Groups for policy rules, Entra ID for identity management linked to whatever HR system your organisation has? Since we're in the Microsoft world you'd probably sprinkle Cluedin or whatever it's called on top of it for mdm.
I don't necessarily recommend living in the Microsoft cloud, but it's what companies do in Denmark, so it's what I know.
This is perhaps a bit different, but Fossil supports storing more types of written company artifacts in the repo:
>One notable feature of Fossil is that it bundles bug tracking, wiki, forum, chat, and technotes with distributed version control to give you an all-in-one software project management system.
https://fossil-scm.org/home/doc/trunk/www/whyallinone.md
The images really detract from the subject.
I've used to do something like this, on a smaller scale and dubbed it "organization as code". As long as you have good enough providers for Terraform/Pulumi you can declaratively specify a lot of the interconnected stuff in a company.
I built this around GitHub as the indentity provider as my interest was declaratively defining repository access control, while also being able to use users public ssh keys to (re)provision services to get them access automatically.
I've done the same thing and I would not call it anywhere near org-as-code either. An organization is much more than a list of responsibilities, people, and compliance requirements.
For the latter, we already have policy-as-code tooling that actually works.
Might be a second language thing. Organization for me is stronger related to the root word organize; label, classify, cluster, etc. than something pertaining to processes and procedures.
I wrote a little on this same topic, automating away compliance with evidence, back in 2018 [1]. Some might find it interesting.
[1] "A Universal Lemma For Compliance" https://blog.eutopian.io/a-universal-lemma-for-compliance/
The cyclical relationship graph this article mentions is doable with Gel[1], my favorite database (the team building it recently got acquired by Vercel so the database is in community's hands now).
---
[1] <https://www.geldata.com>
isn't this what HRIS/ERP systems do under the hood? or am I missing something here?
1. There are many organizations invested in keeping the disconnected status quo 2. The true things you want to connect are owned by giants that are slow and dont trust or need you 3. You need to play by the big players rules or get nowhere here
I have started learning cuelang and there was nice webinar style video where the GitHub policies where defined as code and deployed with terraform. I immediately thought that such thing would be very valuable at auditing.
Surely, in just about every company today, all of the examples in the article are already handled by databases and SQL?
I recommend book Accelerado by Charlie Stross:
Um.” Manfred finds it, floating three tiers down an elaborate object hierarchy. It’s flashing for attention. There’s a priority interrupt, an incoming lawsuit that hasn’t propagated up the inheritance tree yet. He prods at the object with a property browser. “I’m afraid I’m not a director of that company, Mr. Glashwiecz. I appear to be retained by it as a technical contractor with nonexecutive power, reporting to the president, but frankly, this is the first time I’ve ever heard of the company. However, I can tell you who’s in charge if you want.” “Yes?” The attorney sounds almost interested. Manfred figures it out; the guy’s in New Jersey. It must be about three in the morning over there. Malice—revenge for waking him up—sharpens Manfred’s voice. “The president of http://agalmic.holdings .root.184.97.AB5 is http://agalmic.holdings .root.184.97.201. The secretary is http://agalmic.holdings .root.184.D5, and the chair is http://agalmic.holdings .root.184.E8.FF. All the shares are owned by those companies in equal measure, and I can tell you that their regulations are written in Python. Have a nice day, now!”
thanks for the recommendation, I've put a hold on it for my library now.
This article reminds me of another book [1] called Holacracy where how a business is run is systematized according to other pre-defined principles. David Allen, a productivity trainer, used it at his own company for several years before eventually moving away from it because the ongoing overhead to keep its system up was too much.
I wonder if this system will end up like that as well. I love the idea, but I think humans operate at a squishier level than our computers do, there's a risk of 'massive bureaucratic dehumanization and inflexible processes' and the Iron Law of Organizations that make such efforts as that book and this article fraught with peril. Taylorism has its limits.
But hey, if this works, I'll be excited to see more businesses adopting better practices and less painful fumbling around trying to do practices in an organic or unplanned way.
[1] https://www.holacracy.org/blog/dac-ceo-reflects-on-holacracy...
Accelerando's algorithmic company structure and (near?)DDoS the corporate legal system is the one idea from Accelerando that has stuck with me the most over the 20 years since I first read it, and I came here to make the exact same reference.
(that, and the notion of Exocortex, which is what I've named some of my smartphones...)
Massively complex cells of living organisms have their entire functionality encoded in DNA, so why can't a business encode their functionality, too?
>Reimagining organisational structure *for the digital age.*
If you're just now thinking about it in this context, then you're about two decades too late.
It's a lovely idea of course, and I applaud anyone who manages to make progress in this area, but my condolences to all the others that have tried and failed. Perhaps the enabling tech could be improved, but we've had LDAP and the like for decades, and many orgs simply can't/won't build the business around the tech.
IMHO, the main issues are cultural, and culture change is hard once an org is established. Even new companies will face issues, because business culture at large gets carried forward through people and interactions. Good luck getting execs to learn and conform to anything, they're too busy emailing confidential Microsoft Office docs to unauthorized third parties.
Computers have the ability to provide wonderful features like transparency and accountability to orgs and business processes, but just like security, we typically choose not to invest in those areas unless forced. Perhaps AI will enable some change by providing a generic interface that brokers interactions between humans and the organization itself, analyzing all inputs before forwarding to a destination.
I love this idea despite the real world operational challenges - most people with governance responsibilities in organizations don't want to code, and code is often too precise to model messy social/organizational context without constant tweaking, tending, and exception management.
I'm an advocate for bringing software culture to GRC, or as it's sometimes called “GRC Engineering”. While there are plenty of products to automate evidence generation for auditors, the underlying policies and documents that they prescribe are usually still old-school Word/PDF-style boilerplate junk.
I'm working on an open source project for security policies/processes/standards that map back to underlying frameworks (e.g. SOC 2, GDPR, ISO 27001, etc.) Docs are Markdown with YAML frontmatter metadata, interlinks generated automatically, site is published via GitHub actions.
The code is at https://github.com/engseclabs/graphgrc, and you can see an example published site here https://graphgrc.engseclabs.com.
Would love to know if others find it useful or have built similar systems.
> I'm working on an open source project for security policies/processes/standards that map back to underlying frameworks (e.g. SOC 2, GDPR, ISO 27001, etc.) Docs are Markdown with YAML frontmatter metadata, interlinks generated automatically, site is published via GitHub actions.
> Would love to know if others find it useful or have built similar systems.
Yes, to both for over a decade now, and by now there are many so one doesn't need to rewalk the whole path, some are developed in open on GitHub.
Commercial firms have built on that for live monitoring of the mappings, although don't scratch at that too hard, it's generally mostly (a) self-selected subsets of controls, and (b) manually self-reported at the end of the day.
Product examples: https://delve.co or https://safebase.io/products/trust-center
Applied example: https://trust.openai.com
Have you Googled this or talked to large firms (e.g. banks) that care about avoiding footfalls with regularly scheduled regulator exams? Writing your own shows you grok the concept, many need (well paid!) help applying something off the shelf or from OSS.
In my research I haven’t come across the prior art you suggest exists. The trust centers you linked aren’t fungible with what I’m building with GraphGRC. The idea is to make all your security docs just a GitHub repo with structured markdown that permits useful automation (e.g. generating linked internal site, validating all docs have been “reviewed” annually by checking metadata, change control via PR, etc.)
There are plenty of GRC products out there and are popular for good reasons, but I don’t think any of them are Git/Markdown/developer-first.
This is essentiality the concept of LDAP/Active Directory.
man, I can't wait to wrangle a giant YAML file to be able to take a sick day!
Cybernetics
Every few years some technocrat looks at the organizational chart of a company and yells "why is this not a machine yet". And then the next 5 years people have to come up with elaborate ways how to do the actual work inside the artificial abstraction that the technocrats create because of this.
Am I the only one who is mystified by this whole idea? People aren't CPU's. Good luck getting them to follow the code that you thought you were using to define their roles. On the contrary, what makes any complex system work is flexibility. And yes, if that calls into question the whole regulatory regime some companies (believe they) live under ... well, yes.
Also, would you even want it to? I've worked for companies with very rigorous compliance before. They are dead companies walking in most cases. As soon and their business model required/requires any significant change, they are toast. This is because these types of rules can't possibly cover all cases, just the ones the managers know about. Innovation requires flexibility and creativity and rules based systems are the opposite of that. By their very nature, they introduce the exact situations the rules can't cover.