Login
You're viewing the front-end.social public feed.
  • Hazel Weaklyhazelweakly@hachyderm.io
    Sep 15, 2026, 2:00 PM

    Then there’s the question of how those obligations (and the fulfilling implementations) interact

    Changing an implementation in one spot can cascade and force a rewrite in every other system in the entire company. It’s not even hard! It’s actually considerably harder to *avoid* the “worst” case

    Naturally that actively disincentivises reuse, on top of reinforcing the notion that dynamic is bad and should be avoided at all costs

    The result: Copy and paste everything! Make every process static! Nothing is dynamic anywhere! Fully draw out the RACI chart! Single pane of glass! Centralisation!

    That has the effect of making it so that a single word change in an international regulation can result in either

    manual: changing a few paragraphs in a few documents, and maybe a few new documents

    automated: complete rewrite, building new platforms, multi year migrations, and re-orgs

    The CRA, for example, will cost many regulated enterprises millions. Almost all of it will be spent pointing to existing implementations and saying “already done”

    Millions, hundreds of people, untold hours, on what is effectively a no-op

    (Luckily the CRA is well written or it would be far worse)

    If you’ve ever wondered why “all the smart people” automate everything on their full stack multi cluster gitops everything-as-code agentic harness driven hype machines, yet regulated enterprises spend 100x more to go 100x slower on fax machines, paperwork, and mainframes…. Well, now you know

    💬 1🔄 0⭐ 0

Replies

  • Hazel Weaklyhazelweakly@hachyderm.io
    Sep 15, 2026, 2:00 PM

    *ahem* Pulling back a bit…

    The cost of doing “one thing” is extraordinarily high, and the cost of automating it is even higher, mostly because that automation does not scale and the implementation is typically not reusable in any capacity

    (For the more academically inclined, automating regulatory obligations and the supporting infrastructure is typically not reusable for the same reason that mathematical proofs don’t compose

    It scales poorly for the same reason. Implementing proofs is tedious, nuanced, laborious, and fragile)

    Which is a major reason why regulated companies don’t get nice things

    Highly resilient systems are complex by nature, resist categorification, and are illegible. Operating them requires dynamic management systems whose complexity exceeds the system they manage

    But regulation requires legibility!

    As a consequence, the more regulated a property is, the harder it is to achieve. Security? Resilience? Reliability? Performance? Trustworthiness?

    Those are properties. So, essentially by definition, regulating them makes them harder to achieve. It’s an inextricable paradox of legibility

    As an aside: This is not an anti regulation thread. But you need to understand the price you pay when you build a society that requires internationally trusted institutions for *every* supply chain

    Regardless, resolving the “having a property” vs “proving you have it” regulation/legibility paradox is a major unsolved problem in resilience engineering and software engineering

    I would argue it’s one of the most important unsolved problems of our era, and is woefully underinvested in
    Hopefully, the above helps explain why regulated industries move so slowly. It’s also an incredible testament to the power of automation: despite the exorbitant cost, it’s still worth it

    But it’s a very bitter price to pay! I hate paying it, and I don’t think the cost is inevitable or unavoidable

    💬 1🔄 0⭐ 0
  • Hazel Weaklyhazelweakly@hachyderm.io
    Sep 15, 2026, 2:00 PM

    Which brings us back to why I’m building this platform and designing it the way I am.

    It was originally a traditional policy engine, with an event system, tightly integrated into internal platforms. Very useful! But that only solves the scaling issue with implementation, not with legibility

    Automating the rest (legibility, transparency, certification, …), as it turns out, is the overwhelming majority of the pain: proving that you fulfil an obligation, proving you can’t bypass the automation, providing the evidence to auditors, along with measurements and testing plans…, and so on

    PAIN

    Now, people have tried to solve this before, many times. It’s never really been successful (to my knowledge) because the required building blocks haven’t been in place to make this possible

    (Unless you pull an AWS and rewrite everything from the hardware up and vertically integrate it all together)

    Solving this in the industry requires several specific and unusual things that all must be computationally verifiable, constructable, and composable

    Even worse, they need to be standardised and easily implemented at every layer, all the way down to hardware, all the way up to code on the client
    In the last year, all the moving parts seem to have come together just enough to make this a bit less absurd to attempt. But some of the standards are drafts, there are unsolved questions, and how to put it all together remains unknown

    Naturally, solving that unknown is exactly what I’m attempting

    Imagine: dynamic procedures, processes, and actions that are (by construction) attested, evidenced, transparent, and trustworthy

    In other words… Dynamic? No problem. Legible? Absolutely. Reusable? Of course. Regulation got tweaked? Seamless adaptation

    I’m idealistic, but I’m also optimistic

    💬 2🔄 0⭐ 0
  • 💬 0🔄 0⭐ 0
  • Eleanor Saittadymaxion@infosec.exchange
    Sep 16, 2026, 10:24 AM

    @hazelweakly
    Huh. I've been thinking about a version of this problem elsewhere, albeit not as deeply yet as this was kind of off to the side of the core of what I cared about. I'd love to hear more and/or chat about it

    💬 0🔄 0⭐ 0