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

    I’ve been working on something for a while that I think is pretty cool and I want to start talking about it soon. Here’s the elevator pitch tagline:

    It’s a platform for creating dynamic procedures, processes, and actions that are (by construction) attested, evidenced, transparent, and trustworthy

    Under the hood, this platform will be powered by a combination of remote attestation, behavioural evidence, and various policy engines depending on the use case

    To my knowledge, this is the first time a platform like this has become feasible, and the standards are so new that some are still drafts

    One of the more obvious questions you might have is “why do you need to build this?” The has a simple answer as well as an interesting one

    The simple answer is that if you don’t have something like this, you pay a near exponential cost to automate anything in a regulated environment

    Companies (and humans, computers, systems,…), no matter how complex, can only really do one thing at a time. So the overhead around “doing one thing” becomes very important, and so does changing the definition of what “one thing” is, and so does understanding *what* that “one thing” is

    In a regulated industry, you have two other things that become vitally important: fulfilling obligations, showing your work, and having it independently verified

    (Digging deeper into that would be an entire series of articles on its own. I’ll refrain from now but would like to cover more later)

    💬 2🔄 0⭐ 0

Replies

  • Sep 15, 2026, 2:00 PM

    The consequences of fulfilling those obligations are numerous, and result in a substantial amount of pain, paperwork, audits, certification, and more.

    Which means that the overhead of doing “one thing” becomes extraordinarily high

    Doing “one thing” in a regulated environment, top to down, looks vaguely like this:

    Governing body says
    1. “you will be obligated to do this”
    2. “here’s what outcome should be” and/or “here’s what your plan should look like”
    3. “here’s how certifying fulfilment of obligation should look”

    Operating body says
    4.“here’s how we interpret that obligation”
    5. “here’s how we interpret the outcome guidelines and/or implementation guidelines given”
    6. “Heres how we plan to implement the fulfilment of our obligation”
    7. “Here’s how we plan to show you that our implementation does fulfil the obligation and meets all criteria”
    8. “Here’s how we plan to measure the efficacy of our implementation”
    9. “Here’s how we plan to monitor ongoing fulfilment of the obligation”
    10. “Here’s how we plan to be certifiable”

    We are now on step 10. It’s been at least

    * 4+ years of legislation work
    * 4+ years of regulation work
    For the governing body

    * 2+ years of regulatory interpretation in the enterprise
    * 1+ years of implementation planning
    For the operating body

    … and we haven’t started implementing anything yet

    💬 0🔄 0⭐ 0
  • Sep 15, 2026, 2:00 PM

    Now, at the legislative and regulative layer, you can save a lot of effort over time by designing the “structure” of the specification to be modular and reusable

    That works in enterprises as well!

    Well, all the way up to “implementation.” For implementation… it depends

    Manually implementing a regulatory obligation is actually quite nice, all things considered: you write a few documents, train people to follow the process, and create a paper trail that’s audited

    If the regulation changes or evolves, the documents get updated in a clean manner and all is well
    Automatically implementing a regulatory obligation, on the other hand, is utter hell. Automation in general is hell.

    If it’s automated, you have to make an automated paper trail, automated measuring system, automated process, and so on. Both for the process *and* for showing that it wasn’t bypassed

    That “showing it wasn’t bypassed” is particularly important. It means you need to understand the entire state space of what’s possible in the whole automation, and you need to exhaustively demonstrate fulfilment of the obligations (“within reason”)

    In other words, anything dynamic is a fools dream

    Imagine trying to take a Kubernetes operator and show that no matter what happens in the cluster, certain things cannot occur

    Luckily, regulation isn’t quite at the level of “formally verifying arbitrary properties of complex systems” … but for automation it can get uncomfortably close

    It gets even worse: That is *per* obligation

    If you want to fulfil two obligations, the manual method scales extremely well. Most of the documentation structure carries over, and all of the training process, audit trail, etc, is typically reusable

    If it’s automated, almost none of that is reusable

    💬 0🔄 0⭐ 0
  • 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
  • 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
  • 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
  • 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
  • 💬 0🔄 0⭐ 0