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.

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.

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.

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).

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