This article shows how to implement a SAML federation from an ASP.NET Core Identity application using Sustainsys.Saml2.AspNetCore2. Entra ID is used to implement the SAML authentication and the users can authenticate from the tenant.

Code: https://github.com/damienbod/DuendeEntraSaml

Setup

Three components are used to implement this demo, a web application that authenticates using OpenID Connect, an ASP.NET Core OpenID Connect server using Duende, and a SAML application that authenticates using Entra ID and an Enterprise Application. The web client understands only OpenID Connect and uses the claims returned from the authentication process. Duende IdentityServer acts as a gateway for Entra ID identities. The application uses SAML.

SAML client

The Sustainsys.Saml2.AspNetCore2 Nuget package is used to implement the SAML client. Duende IdentityServer uses this to implement the external authentication federation. The settings are read from a configuration and the properties must match the settings form the Entra ID tenant Enterprise application. After a successful authentication, the claims principal is stored in a secure HTTP only cookie.

        var samlTenantId = builder.Configuration["Saml:TenantId"];
        var samlMetadataLocation = builder.Configuration["Saml:MetadataLocation"]
            ?? $"https://login.microsoftonline.com/{samlTenantId}/federationmetadata/2007-06/federationmetadata.xml";
        var samlIdpEntityId = builder.Configuration["Saml:IdpEntityId"] ?? $"https://sts.windows.net/{samlTenantId}/";
        var samlSpEntityId = builder.Configuration["Saml:SpEntityId"] ?? "https://localhost:5021/Saml2";
        var samlReturnUrl = builder.Configuration["Saml:ReturnUrl"] ?? "https://localhost:5021/";

        // Load this depending on your environment, change the code as required. For example, you can load it from Azure Key Vault or from a secure location.
        var samlToolkitCertificatePath = Path.Combine(builder.Environment.ContentRootPath, "MicrosoftEntraSAMLToolkit.cer");
        var samlIdentityProviderCertificate = LoadIdentityProviderCertificate(samlToolkitCertificatePath);

Client authentication setup using SAML:

// https://docs.duendesoftware.com/identityserver/ui/login/saml-provider/
// https://learn.microsoft.com/en-us/entra/identity/saas-apps/saml-toolkit-tutorial
// https://github.com/Sustainsys/Saml2
builder.Services.AddAuthentication()
     .AddCookie("samlcookie")
     .AddSaml2(Saml2Defaults.Scheme, "entra-saml-idp", options =>
     {
         options.SignInScheme = "samlcookie";
         options.SPOptions.ValidateCertificates = false;
         options.SPOptions.EntityId = new EntityId(samlSpEntityId);
         options.SPOptions.ReturnUrl = new Uri(samlReturnUrl);

         var idp = new Sustainsys.Saml2.IdentityProvider(
             new EntityId(samlIdpEntityId), options.SPOptions)
         {
             MetadataLocation = samlMetadataLocation,
             LoadMetadata = true,
             //AllowUnsolicitedAuthnResponse = true
         };

         if (samlIdentityProviderCertificate is not null)
         {
             idp.SigningKeys.AddConfiguredKey(samlIdentityProviderCertificate);
             Log.Information(
                 "Loaded SAML signing certificate from {CertificatePath}. Thumbprint: {Thumbprint}",
                 samlToolkitCertificatePath,
                 samlIdentityProviderCertificate.Thumbprint);
         }
         else
         {
             Log.Warning("SAML signing certificate file not found or invalid: {CertificatePath}", samlToolkitCertificatePath);
         }

         LoadIdentityProviderMetadata(idp, samlMetadataLocation);

         options.IdentityProviders.Add(idp);
     });

The SAML metadata is loaded using a helper method called LoadIdentityProviderMetadata. This loads the metadata as defined by the Entra ID Enterprise Application. The certificate is downloaded from the Entra ID Enterprise Application and loaded from a file. This should be improved if implemented in a production environment.

private static void LoadIdentityProviderMetadata(Sustainsys.Saml2.IdentityProvider idp, string metadataLocation)
{
    try
    {
        var metadata = MetadataLoader.LoadIdp(metadataLocation);
        idp.ReadMetadata(metadata);

        Log.Information(
            "Loaded SAML metadata from {MetadataLocation}. Signing key count: {SigningKeyCount}",
            metadataLocation,
            idp.SigningKeys.Count());
    }
    catch (Exception ex)
    {
        Log.Warning(ex, "Failed to load SAML IdP metadata from {MetadataLocation}", metadataLocation);
    }
}

private static X509Certificate2? LoadIdentityProviderCertificate(string certificatePath)
{
    try
    {
        if (!File.Exists(certificatePath))
        {
            return null;
        }

        return X509CertificateLoader.LoadCertificateFromFile(certificatePath);
    }
    catch (Exception ex)
    {
        Log.Warning(ex, "Failed to load SAML certificate from {CertificatePath}", certificatePath);
        return null;
    }
}

SAML client setup Entra ID

Note: If you are setting this up in an Entra ID tenant, always use OpenID Connect rather than SAML. SAML should only be used where OpenID Connect is not available.

The Microsoft Entra SAML Toolkit is used to set up the Entra Enterprise Application. The properties must be configured to match the ASP.NET Core Identity application. The Entra Enterprise Application is used for single sign-on.

Start the SAML authentication

The SAML authentication is started using a Challenge request for the correct scheme. The scheme is passed in the items and used in the external callback.

app.MapGet("/login/entra-saml", async (HttpContext context) =>
{
    await context.ChallengeAsync(Saml2Defaults.Scheme, new AuthenticationProperties
    {
        RedirectUri = "/ExternalLogin/Callback", // where to go after successful login
        Items = { ["scheme"] = Saml2Defaults.Scheme }
    });
});

The authentication can be started from the UI.

<a class="btn btn-primary" href="/login/entra-saml">
    Sign in with Entra ID (SAML)
</a>

External Callback claims mapping using ASP.NET Core Identity

When the SAML authentication is completed, the Callback method handles the result. This sets up the user account and creates a claims principal for the user and the result is returned back to the web application.

public async Task<IActionResult> OnGet()
{
    // read external identity from the temporary cookie
    var result = await HttpContext.AuthenticateAsync("entraidcookie");

    if (result.Succeeded != true)
    {
        result = await HttpContext.AuthenticateAsync("adminentraidcookie");
    }

    if (result.Succeeded != true)
    {
        result = await HttpContext.AuthenticateAsync("samlcookie");
    }

    if (result.Succeeded != true)
    {
        throw new InvalidOperationException($"External authentication error: {result.Failure}");
    }

    var externalUser = result.Principal ??
        throw new InvalidOperationException("External authentication produced a null Principal");

    if (_logger.IsEnabled(LogLevel.Debug))
    {
        var externalClaims = externalUser.Claims.Select(c => $"{c.Type}: {c.Value}");
        _logger.ExternalClaims(externalClaims);
    }

Notes

SAML can be used to implement external federation in any ASP.NET Core application. This works like the OpenID Connect setup, just a bit more complicated and less supported. I used Entra ID as an example. Entra ID Enterprise applications implemented using OpenID Connect is a better choice for this.

Links

https://docs.duendesoftware.com/identityserver/saml

https://github.com/DuendeSoftware/samples/tree/main/IdentityServer/v8/SAML

https://learn.microsoft.com/en-us/entra/external-id/direct-federation

https://github.com/Sustainsys/Saml2

https://learn.microsoft.com/en-us/entra/architecture/auth-saml

https://learn.microsoft.com/en-us/entra/identity/saas-apps/saml-toolkit-tutorial

https://docs.duendesoftware.com/identityserver/usermanagement/getting-started

https://docs.duendesoftware.com/identityserver/usermanagement/identityserver-integration

https://zitadel.com/docs/guides/integrate/identity-providers/azure-ad-saml

https://learn.microsoft.com/en-us/entra/external-id/direct-federation

https://github.com/jitbit/AspNetSaml

https://github.com/Sustainsys/Saml2

https://learn.microsoft.com/en-us/entra/architecture/auth-saml

In digital operations management, AI agents give organizations a competitive edge by reducing incident volume and accelerating recovery. The potential for transformation is real, but only when agents are deployed against a single targeted use case, rather than simply adding an “AI layer” to existing capabilities.

One practical area where enterprise AI agents can reshape traditional workflows is site reliability engineering (SRE), where the standard operating model is reactive and human-centric. This model carries a heavy cost, burdening engineers with repetitive toil that swallows their time and can lead to burnout. 

SRE AI agents offer a way to change how site reliability engineers work, turning them from “doers” manually managing operations to “managers” leading a team of agents that proactively drive operational improvements.

From runbooks to root cause analysis: where agents help most

There are five practical ways SRE AI agents can lighten the load on engineering teams:

1. Working autonomously

Traditional SRE work is guided by the runbooks that engineers write and update. After receiving an alert, engineers log in, run diagnostics, apply fixes, and, where possible, build automation to speed up remediations of similar incidents in the future. Even when automation is added, the incident management process relies on a human to manage it end-to-end. 

SRE AI agents change that. After ingesting an alert and understanding its context – for example, correlating a memory-spike alert with a recent update or deployment – they can execute actions to solve routine issues autonomously.

2. Building memory from operations data

SREs rely on considerable firsthand experience to piece together an incident and its contributing factors. But as digital systems grow more complex, that institutional knowledge becomes much harder to scale. If a subject matter expert is unavailable, the organization loses access to the necessary knowledge to resolve the incident quickly.

“Working at machine speed to process this data, AI agents can make appropriate recommendations and even repair issues themselves in the case of low-risk, routine problems.”

SRE AI agents trained on real, historical incident data can draw from prior incidents and the corresponding actions taken to quickly diagnose and remediate repeat issues. Working at machine speed to process this data, AI agents can make appropriate recommendations and even repair issues themselves in the case of low-risk, routine problems.

3. Eliminating toil

Engineers put a great deal of time and effort into automating manual, repetitive tasks to reduce toil, but automation isn’t the same as autonomy. These automated workflows still need an engineer to trigger the start and assess the outputs. 

SRE AI agents go a step further and eliminate entire classes of toil altogether, such as autonomously restarting a downed service without needing to be scripted or triggered by a human first.

4. Proactive approach

SRE teams spend much of their time in firefighting mode, reactively fixing issues rather than improving long-term systems health and reliability. With an SRE AI agent managing incidents, engineers gain time to focus on reinforcing system resilience, enhancing observability, and strengthening architecture for the future. 

“As agents take on more of the day-to-day work of incident management, the SRE role evolves from tactical fixer to strategic decision-maker.”

As agents take on more of the day-to-day work of incident management, the SRE role evolves from tactical fixer to strategic decision-maker.

5. Shifting humans to context engineering

Engineers bring deep technical knowledge of systems, scripting languages, and infrastructure tools. That expertise doesn’t disappear with agents; it moves up a level. Instead of running commands themselves, engineers use their knowledge to train AI agents about their environment: the tools they can use, the actions they can take safely, and their relevant service dependencies. Engineers’ roles shift from execution to setting the guardrails within which the AI agents operate.

The new role of the SRE

SREs face a constant uphill struggle against being overwhelmed. To fight this, some organizations have set strict toil limits for engineers. However, toil limits still force engineers to spend up to half of their working time manually resolving incidents. 

The underlying workload doesn’t disappear; it simply gets capped rather than solved. SRE AI agents shift engineers from technology practitioners manually remediating breakages to strategic operators overseeing a suite of AI agents.

“The underlying workload doesn’t disappear; it simply gets capped rather than solved. SRE AI agents shift engineers from technology practitioners, to strategic operators overseeing a suite of AI agents.”

The new shape of the roles changes how engineers experience their work day-to-day, with reduced stress and burnout risk, more mental space for innovation, system improvements, and other high-value work that brings real value to the organization, not just keeps it afloat.

The post 5 ways SRE AI agents are set to augment human capabilities appeared first on The New Stack.

A few days ago I wrote about build-time AI vs run-time AI, after the Thoughtworks Future of Software Development Retreat in Engelberg - three days in June, convened by Martin Fowler and Thoughtworks, following an earlier gathering in Utah in February. Two write-ups are out now: Martin’s closing fragment and the official Thoughtworks report. Five headline findings, of which the first is the one that matters here: code generation is no longer the bottleneck - verification is. Agents can produce code, specs, tests and infrastructure faster than any team can trust it. The trick is - how to match the generated code’s tests to the generated code’s prod source.

My post was a 3×2 table. I’ve been thinking about it since, and the table wasn’t really getting accross what I wanted it to. Too many things sat awkwardly across the line, and the interesting distinctions were happening inside the cells rather than between them.

So Claude and I made a chart instead. It’s here, and it has toggles so you can play with it. 15 years ago I was using AngularJS for interactivty within SVG, and today I don’t ask Claude what it picked. Indeed Claude would have said yes to any of 50 JS/TS techs.

The axis that took the longest

I started with “artefact surface”: versioned artifacts on the left, operational state on the right. Two halves, four quadrants, done. My biases toward source control systems were clear - which I what I wanted.

It wasn’t two halves though. Pure chat has no versioned artifact and doesn’t touch operational state. Media synthesis has a library - durable, real, yours - that nothing downstream reads. And agents like OpenClaw don’t have a surface so much as an absence of one: whatever the machine can reach by whatever means … which is why I’ve not tried one of the many claws.

The version I settled on runs through six waypoints:

Chat Log → Versioned Artifacts → Media Library → Change Specific → Change Anything → Become

The ordering isn’t reach, and it isn’t persistence. It’s what’s left behind that someone can inspect. A transcript you can read. A commit that gets reviewed before it counts. Assets in a library. Records other biz systems depend on. Traces wherever the thing happened to reach. And then ultimately “Become” rightmost.

Persistence rises, then does something strange

If you follow the waypoints expecting durability to climb steadily, you’ll be wrong twice.

A chat log is less durable than a generated video file. And a media library is arguably more durable than a commit while being far less connected - nothing downstream reads it, which is why it sits where it does rather than further right. Durability and consequence aren’t the same axis, and conflating them is how you end up thinking Sora and alike are more consequential than Dependabot.

What “Become” means

The last waypoint is the one I keep coming back to. Someone built an operating system that was all AI - no code for the file editor, no code for the browser, no code for the spreadsheet. Just a model behaving editor-ly on demand. I’ll add the link when I can find it again.

My first instinct was that nothing survives there. That’s wrong. If the AI-generated word processor saves a .docx file, the file is on a filesystem, as real as one written by actual code.

Two artifacts are in play and “Become” splits them:

• The output: your .docx file. Survives fine.
• The producer: the word processor itself. Doesn’t exist as reviewable code, and may not be the same word processor next time you open the document.

And the sharper edge: with real code, save either worked or threw an exception. Here, “Saved!” is generated text. The file might be there. Might be elsewhere. Might not exist. You can’t read the save path to check, because there is no save path. You’re verifying from outside, every time.

Sam Ruby, on what survived contact: “rigor doesn’t vanish when the agent writes the code - it migrates. Upstream into specifications, down into test suites treated as first-class artifacts.” His sharper claim is that the oracle - the objective, and how you evaluate whether you met it - is the asset that can’t be delegated. Implementation can be generated and thrown away; the oracle can’t.

Which gives me a cleaner way to say what Become is. Not the absence of code - the absence of an oracle. Nothing independent left to check the output against.

That’s not the absence of an artifact. It’s the absence of any guarantee about one, which is worse. Perhaos thats absence you’d notice. See “side story” at the bottom about how the industry does historicaly like things that work but bobody can explain how precesiley - with the risk being “if it breaks, can it be fixed and how long will that take and what guarantees.”

The overlays

The chart has three toggle rows, and the reason they’re overlays rather than axes is that none of them are positional. They cut across.

Containment - Augmented, Harnessed, Unharnessed. Augmented is the bottom of the chart, and it’s mostly classic products with a model bolted into an existing deterministic frame. Zapier didn’t get displaced by LLMs; it became a distribution channel for them. The model fills a slot; the workflow around it stays developer-defined. That’s the deployment pattern most organisations actually reach for, and it’s the least discussed.

I’m using “harness” in roughly Thoughtworks’ sense - the scaffolding round an agent - though I care less about how well it’s built than whether it exists at all, and whether anything checks the output before it counts. That’s a looser test than theirs, which is why the Harnessed lasso picks up commercial CRM and support agents where the vendor built the rig rather than you. The rig is still there. You just didn’t assemble it, and can’t see much of it.

When it goes wrong - the four MTTD/MTTR regimes. Mean time to detect and mean time to repair are independent, and people conflate them constantly. Fast/fast is CI linters and autocomplete: wrong is visible immediately and costs seconds. Fast/slow is a Zapier job that mangled 10,000 records overnight - you know by morning, and unwinding takes a week.

Slow/slow is where it gets uncomfortable. Data enrichment writing a plausible summary into a CRM field. Nobody notices for months. By then humans have read it and trusted it, it’s been exported into reports, and there’s no git revert for “this record has been quietly wrong since March.”

Note that MTTR correlates with the x-axis - versioned artifacts are revertable by construction - but MTTD doesn’t correlate with anything on the chart. Detection time is a property of how the output gets consumed, not of what the system is. That’s why it needed its own overlay.

This is the retreat’s “verification is the bottleneck” finding wearing different clothes. If verification is what’s scarce, then MTTD is just the measure of how long unverified output sits around being trusted. The chart’s slow-detect region is where verification isn’t happening at all - not because it’s hard, but because nobody scheduled it.

The Thoughtworks report gets to a recommendation I’d endorse from a different direction:

Adopt a risk-tiered autonomy model per system or component (cobot-style human oversight vs. dark-factory-style full automation), explicitly based on risk, reversibility and blast radius - do not apply a single autonomy policy uniformly across a portfolio.

Reversibility and blast radius are precisely what the x-axis and the MTTx overlay are measuring. If you want a risk-tiered autonomy model, you need a way to see which tier a given system is actually in - and “it’s agentic” doesn’t tell you. Dependabot and OpenClaw are both agents. They’re nowhere near each other on any dimension that matters for setting a policy.

Human veto - before it counts, after the fact, or not at all.

I got this one wrong first time. I had the whole chat column as “human-free,” reasoning that there’s no PR, no approval workflow, no review artifact. But chat has the tightest veto on the chart: you read every token before anything happens, and rejection costs one prompt. I’d confused the absence of a formal review process with the absence of oversight. They’re not the same thing, and the informal one is often stronger.

Kief Morris, writing up the same retreat, reduces the whole thing to: “how much do we let an agent decide, and how do we stay confident in what it does?” His ops teams keep a narrow remit - “diagnose, yes; decide, no.” That’s a veto boundary drawn inside a single system, which my chart can’t show; one dot per product doesn’t have the resolution. He also found line-by-line code review had stopped working as a guardrail, with rigor migrating upstream to acceptance criteria and downstream to automated checks. Worth holding against my “before it counts” lasso: the gate is there, but it may not be carrying the weight we assume it is.

Ian Cooper’s gears make the same point from another angle: he drives in high gear for boilerplate and drops to low gear when certainty falls or the blast radius grows - auth, payments. So it isn’t just that the veto boundary sits inside a system rather than around it. It moves, hour to hour, with the same tool in the same hands. My chart gives each dot one veto state and holds it there.

Kief and I were at the same three-day event. Showing him the open source thing I’ve been building in exactly his space was in my top five must-dos for the trip. I flew home without having done it. Forty sessions (albeit multi-track) and plenty of hallway time, and the one conversation I’d specifically planned was the one I missed.

Only two dots are genuinely veto-free, both at the right-hand end, and they fail differently. OpenClaw’s defects get found late and can’t be cleanly undone. The AI-native applications one is worse in an odd way - there’s no defect to point at, because there’s no code to diff against intent. You just sense that something is off - “uncanny valley” in the modern age.

Abby Bangser makes a point I hadn’t considered: “removing humans from the loop also removes organisational and product learning.” The veto isn’t only a correctness mechanism. It’s where people find out what the system actually does - which is the apprenticeship problem arriving by a side door.

Caveats

Dot placement is editorial, not measured. I’d defend the clusters and the general diagonal; I would not defend any individual coordinate to two decimal places. The chart is a thinking tool, not a dataset.

The Media Library island property is a fact about today’s integrations, not about the technology. The moment someone wires generated assets into a publishing pipeline, that dot slides right. Integrations by another name.

And the whole right-hand end is thinly evidenced - one shipping product and one experiment. That’s the nature of drawing a chart about where things are going rather than where they’ve been.

Have a play with it. The overlays combine - Augmented plus slow/slow detect is the combination I find most interesting, and it isn’t the one anyone is writing threads about.

Others who wrote it up

Worth your time, and I’ve only borrowed from some of them above: Ivett Ördög on whether agents should maintain codebases like engineers or regenerate them like compilers - the question my x-axis is really about; David Whitney on why “almost always working isn’t enough”, and code mattering more rather than less; Bartosz Ocytko on software factories and the handoff points where humans still sit; Giles Edwards-Alexander on “Optimisers vs Learners” as two organisational shapes, and on learning being the constraint now rather than delivery; Andrew Harmel Law asking which of our practices were rafts we can put down.

Footnote: a reversibility I’m not measuring

Mathias Verraes argues for keeping the ability to “revert from agentic code generation to human engineering.” That’s a reversibility my chart doesn’t measure - not undoing a change, but undoing a way of working. The x-axis says nothing about whether you can walk back from a waypoint once you’re standing on it.

Side Story

In the mid-1990s, at the University of Sussex, researcher Adrian Thompson used a genetic algorithm to repeatedly reconfigure a Xilinx FPGA until it evolved a circuit that could distinguish between two audio tones. Instead of producing a neat digital design, evolution exploited subtle analogue properties of the physical silicon timing delays, capacitance and other quirks to create a solution that worked but was largely incomprehensible to its creators and often depended on the characteristics of that specific chip. The result was a striking demonstration that evolutionary search can discover highly effective solutions beyond human intuition, but it was never adopted for telecoms or other safety-critical industries because engineers could neither fully explain nor reliably verify its behaviour across different devices, temperatures and operating conditions. In the end, its greatest strength finding unconventional solutions unconstrained by human assumptions was also the reason it could not satisfy industries that require predictable, reproducible and certifiable designs. Are we back in that risk place now?

So far this series has covered what sprawl is, where it comes from organizationally and technically, and the shadow, rogue, and zombie APIs that hide in the gaps. In this fifth post I want to answer the question an executive will eventually ask: so what? Why does this actually matter to the business? The answer comes in three flavors–security, cost, and consistency–and I want to give each its due, because organizations tend to fixate on the first and lose the most to the second and third.

The security cost is the one everyone leads with, and it is real. Security weaknesses and data breaches are a risk for every kind of enterprise, not just the obvious healthcare and finance targets, and APIs and their endpoints are among the most commonly targeted attack vectors. This is especially true for the shadow and zombie APIs that never met your security standards in the first place. In a 2024 survey, SALT found that 63% of respondents had experienced security incidents due to unmonitored or inadequately secured APIs. That is not a fringe number–that is a majority. And the mechanism is always the same: a lack of visibility, monitoring, and a consistent security standard makes it impossible for your team to actually secure the estate. You can buy the best locks in the world and it does not matter, because the problem is the window you do not know exists. To mitigate this you need a comprehensive catalog of every API and endpoint, and you need every one of them held to a real security standard. There is no securing your way around an incomplete inventory.

The second cost is inefficiency, and this is the one that quietly does the most damage precisely because it never triggers an incident report. When developers cannot discover the internal APIs that already exist, they build the function again. Now you have two or more APIs doing overlapping work, each consuming infrastructure, each carrying gateway and management fees, each needing to be maintained. That is money spent twice for one capability. Layer on the developer hours–not just the hours spent building the redundant thing, but the ongoing hours engineers pour into discovering, documenting, maintaining, and repairing the sprawl itself. Every one of those hours is an hour not spent on work that actually moves the business forward. Sprawl is a tax on your best people’s time, and unlike a breach, nobody ever sends you the invoice. You just quietly get less from your engineering organization than you paid for.

The third cost is the one I think is most underrated: ecosystem inconsistency. Predictable, consistent APIs are the foundation of an efficient, well-managed ecosystem, and inconsistency corrodes that foundation in ways that compound. Take a small, concrete example. Imagine an API provider that uses both 0/1 and true/false for boolean values across different endpoints. Trivial, right? Except that inconsistency now has to be handled by every single consumer, and it snowballs the moment other layers get involved. Feed inconsistent specs into a code-generating system and you get broken SDKs. Ship inconsistent error-response shapes across your endpoints and every consumer’s retry logic and troubleshooting gets harder, because the error they got from endpoint A does not look like the error they got from endpoint B. Multiply these little inconsistencies across a sprawling estate that nobody standardized, and you have an ecosystem that is exhausting to build against–which, ironically, pushes teams to build yet another API rather than integrate with the messy existing ones. Inconsistency feeds sprawl, and sprawl feeds inconsistency.

The fix for that third cost is worth naming precisely, because it is not the same as the fixes for the first two. A shared type registry, standardized style guides, consistent rules, and disciplined documentation management are what prevent these inconsistencies from ever entering the ecosystem. If boolean is defined once, in one place, and every API references that shared definition, the 0/1 versus true/false problem cannot happen. This is the reusability argument I make constantly–the value of a shared, referenced set of schema definitions is not aesthetic tidiness, it is that it makes a whole class of expensive inconsistency structurally impossible.

I want to put a number on the stakes, because it helps. The average cost of a data breach is around USD 4.4 million, and that is the figure that gets budgets approved. But I would argue the breach number, dramatic as it is, actually undersells the total cost of sprawl. The breach is the rare catastrophic event. The inefficiency and inconsistency are the daily, grinding, uninvoiced losses–redundant infrastructure you pay for every month, engineering hours you burn every sprint, integrations that take longer and break more often than they should, and the slow erosion of trust from both internal and external consumers who cannot rely on your APIs to behave predictably. Add all of that up over a year and, for most large organizations, the everyday cost of sprawl dwarfs the expected cost of the occasional breach.

That is the honest business case, and it is why the back half of this series is about the fixes. In the next post I will start with governance–the standards, ownership, API-first design, and automated gates that keep sprawl from forming in the first place. Then I will finish with the management side: discovery, inventory, and gateways–the operational muscle for finding the sprawl you already have and keeping it under control. The costs are real, but so are the remedies, and none of them require anything more exotic than deciding to know your own APIs.

I saw recently saw a blog post (which annoyingly I can't find any more, but I'll link it if I do), showing off a web component that if I recall correctly, would show (or hide) it's contents depending on a browser feature (I'd guess using the @supports query).

That reminded me that I wrote a web component that I use quite a bit (particularly with FFConf), which should really be called do-when, but it's not, it's (stupidly) called when-do (the dash, I guess, being a comma in my head).

The component says: when a time occurs or passes, do a what: show, hide or scroll-to.

You can get the code from github - which also includes an interactive demo that lets you try the settings.

What it is

A small web component to toggle on or off depending on wall clock (date) time without affecting the visual layout (with it's own element).

Use case

I've been using this web component on the FFConf event pages for a number of years to reveal the ticket button if a visitor is sitting on the page (though I appreciate that's unlikely!).

<when-do what="hide" datetime="{ticket-live}">
<p>Tickets live at {nice-ticket-live}</p>
</when-do>
<when-do what="show" datetime="{ticket-live}">
<p>Buy <a href="…">now</a>
</when-do>

I've also used the what="scroll" for our schedule page, to automatically scroll to the current speaker.

Though I do appreciate my "battle testing" has been rather limited, so if you use this and spot bugs, please let me know!

API

• what="show|hide|scroll" - the component also throws an exception if a non valid string is used
• datetime="isodate" - recommended that you include the timezone, ie. "2026-09-13T10:00Z" is 10am on 13th September on UTC
• apply="classname" optional class name to apply to the when-do element when it activates, useful if you wanted to transition your contents into view, or highlight the newly scrolled element

How it works/styling

The web component makes use of display: contents to prevent itself from modifying the visual layout.

Due to this display method, it means you can't style the element directly, in that styling has no effect.

If you want to style the contents when the element is active, such as when it has been scrolled into view, it's recommended you wrap the child elements it a parent element, such as a div.

You can also use the apply property to indicate the current when-do has activated.

AI wasn't used in any part of this web component (which is also why the demo page is so ugly).

Originally published on Remy Sharp's b:log