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.

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.

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.

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.

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.

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.

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.

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 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"

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.

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

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.

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.

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.

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

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.

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.

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.

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.

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.

It is breathing already, in the form of humans doing it.

No need to transform it into a static inflexible code thing.

    - 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

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.

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.

Is this an article by someone who's just done ISO 27001 for the first time and realised that?

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

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.

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.

I don't necessarily recommend living in the Microsoft cloud, but it's what companies do in Denmark, so it's what I know.

[0] https://thalo.rejot.dev/blog/plain-text-knowledge-management

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?

>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

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.

[1] "A Universal Lemma For Compliance" https://blog.eutopian.io/a-universal-lemma-for-compliance/

---

[1] <https://www.geldata.com>

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.

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!”

If you're just now thinking about it in this context, then you're about two decades too late.

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.