Death to the Dashboard

1. The $300,000 Question

Picture a company. Two thousand employees, give or take. A six-person security team that has learned to live on coffee and Slack notifications. Google Workspace or Microsoft 365 for email. AWS, GCP, or Azure for production. GitHub for code. Okta or Entra for identity. It is the shape that ninety percent of the working economy now has, and if you squint, it looks a lot like your company too.

One Tuesday, the team buys a SIEM. List price is $300,000 a year. After a long negotiation and a steak dinner, it lands at $190,000. Then someone notices the cloud posture tool is a separate line item: $60,000. So is DSPM, at $120,000. Add a SOAR for $40,000 and a managed detection wrap for $200,000, and the annual security tooling bill crosses $600,000 before a single human has been hired to actually use it.

The team logs in. There is a dashboard. The dashboard has nine widgets. Six are red, two are yellow, and the last is showing a metric nobody quite recognizes. The vendor offers a quarterly business review, during which a customer success manager will gently explain the widgets. The team accepts. The widgets remain red.

That whole arrangement is the wrong shape. The right shape is now buildable by anyone who can read a Terraform module and write a YAML file. The parts cost roughly two orders of magnitude less. The experience is better. The audit trail is stronger. And the blast radius of vendor compromise is zero, because there is no vendor.

Two worked examples sit underneath the argument: mantissa-log and mantissa-stance. Both are open source. Both are free. Both run on the customer's own cloud. Neither has a dashboard, on purpose. The interface is Slack, or Teams, or a CLI — whichever tool the team already lives in for everything else.

The dashboard was a compromise we agreed to in 2008 because the alternative was worse. The alternative is no longer worse.

A quick disclaimer before going further. This essay is not a claim that the architecture below replaces Splunk in a Fortune 100 SOC, nor that every team should adopt it. The intended reader is the mid-sized, engineering-oriented, cloud-native organization that is tolerant of ownership and willing to read code. The trade-offs are named explicitly throughout. The dollar amounts will drift in both directions; the arithmetic of the argument is what is meant to be durable.

2. What You Are Actually Buying

A commercial SIEM at six figures is really a bundle of nine separate things stapled together. Most are commodities. A couple are not. The bundle has held together longer than its parts justify, partly because procurement teams find one purchase order easier to defend than nine, and partly because vendors have an entirely understandable financial interest in keeping the staples in place.

Items one through eight are infrastructure you can rent from your existing cloud provider for a sliver of what the bundle charges. Item nine is the part the vendor actually still earns: a signed SOC 2 report, a contract that promises indemnity if the tool fails, a phone number that connects to a real person at 3 AM, an audit response team that will sit with your auditors and patiently show them where the controls live. That is real work, and it is also cleanly separable from the other eight.

Commercial SIEM pricing is volume-indexed. A team ingesting one terabyte a day pays in proportion. The marginal cost of storing one terabyte a day on the customer's own S3 in 2026 is closer to $700 a month than $70,000. The arithmetic does not change because a vendor is doing the storing. It changes because a vendor is doing the bundling, and bundling is what lets margin compound in directions storage costs cannot.

The real moat is not the product

If eight of nine items are commodities and the ninth is separable, why do Splunk, QRadar, Sentinel, and Chronicle still command the prices they do? Not the query language. Not the storage layer. Not the user interface. Two things, mostly.

The first is switching cost, which is best understood as a small city built on top of the vendor. A multi-year Splunk deployment accumulates dashboards, saved searches, scheduled reports, RBAC mappings to a decade of org-chart change, PagerDuty wiring, custom apps, lookup tables, KV stores, and the muscle memory of every analyst on the team. The license is a fraction of the embedded cost. Think of it as the difference between rent and renovations: you might be paying $40,000 a year for the building, but over the decade you have spent $400,000 rebuilding the kitchen, finishing the basement, and learning where every light switch is. The vendor prices against the move, not the rent. An honest comparison is therefore never license-to-license. It is the all-in cost of operating one architecture against the other, on a multi-year horizon, with switching amortized in. The build path does not eliminate that cost; it changes its shape, from a recurring invoice to an upfront engineering investment plus a small, steady operational tail. For some teams the math is worse. For most it is dramatically better — but only with clear eyes, and only if the team budgets for the tail rather than imagining the system runs itself once it ships.

The second moat is parsers and detection content. A commercial SIEM in production has, behind it, years of work turning the chaos of real audit data into something queryable. Splunk's TA-* apps. Chronicle's CBN parsers. Sentinel's data connectors and KQL parsers. QRadar's DSMs. Each is a small library of field-extraction logic that takes a raw event from some specific product and emits something a detection rule can actually run against. On top of that, the vendors ship detection content: Splunk's ESCU, Chronicle's curated rules, Sentinel's analytics, QRadar's rule packs. A customer who has tuned all of this for five years has built a genuine asset.

Three forces have quietly shrunk the cost of replicating that asset. Audit data is converging on a small handful of standard shapes — Elastic Common Schema, OCSF, CloudEvents — and most vendors now emit something that maps cleanly to one of them. Parser work is mostly field aliasing, type coercion, and the occasional regex; the bespoke grammar work of the early Splunk era is largely gone. Meanwhile, Sigma has opened the detection-content side, with a community rule pack now in the multiple thousands. A Sigma rule for a Windows event maps to the same ATT&CK technique as a Splunk ESCU search for the same event, because both are pointing at the same adversary behavior; the expression differs, but the intent is identical. And language models have compressed parser-writing from days to hours. Hand a model a sample event, a target schema, and a description of intent, and it will produce a first draft that an engineer reviews rather than writes from scratch.

What was once a moat of five years of writing parsers and rules is now a moat of five years of writing parsers and rules whose equivalents can be replicated in months. Replication is not free, but it has become a normal engineering project, not the multi-engineer-year saga it would have been a decade ago.

Three things follow. The build path becomes a deliberate engineering project, not an open-ended research program. The migration plan can be specific: enumerate the parsers in use, enumerate the detection content in use, map each to an open equivalent, identify the gaps, estimate the work to close them, and decide which gaps are even worth closing. And the negotiation with the incumbent vendor changes shape, because the buyer can now actually price the switching cost — and credibly threaten to pay it.

3. The Dashboard Was Never the Goal

Dashboards exist for a reason, and the reason is historical. In the era when storage was expensive, query was expensive, and humans were the cheapest part of the system, the only sensible way to use a logging tool was to pre-aggregate every measurement you might one day care about into a small set of charts that fit on a screen. The dashboard was a precomputation. The user was the index. Anything not on the dashboard was not askable, because asking required engineering work nobody had time for.

Imagine a 1985 supermarket. The cashier cannot lean over and ask the database how many cans of soup sold this week; the manager prints a paper report on Friday afternoon. By Saturday morning the report is stale. By Monday it is fiction. The dashboard is that Friday report, screen-shaped, with a slightly better refresh rate.

Three things have changed since then. Storage is nearly free. Columnar query engines have made arbitrary aggregation cheap. Large language models have turned writing a query into a five-second affair. Each erodes a piece of the dashboard's reason for existing. Together they remove the entire foundation. What is left is habit and aesthetic, not a tool.

The habit shows up in revealing ways. Security teams do not sit and watch dashboards. They glance at them during the morning standup and then forget about them until the next standup. The real work happens in tickets, threads, and incident channels. The dashboard is theater. The actor is the customer success manager pointing at the red widget. The audience is a buyer trying to justify last year's purchase.

The aesthetic problem is subtler. A dashboard implies a watcher. It implies someone is staring at it and making decisions in real time. Almost no security work happens this way. Detection runs on a schedule or a stream. Alerts route to a channel. Investigations live in tickets. The actual workflow has nothing whatsoever to do with looking at charts. It is a bit like installing a fire alarm and then hiring someone to stare at it: the alarm is the point, the stare is the waste.

The left column is what real teams do. The right column is what dashboards were designed to support. They have been quietly mismatched for at least a decade. This is not a bug in any specific dashboard. It is a category error.

One honest concession. Some dashboards do earn their keep. The Grafana panel showing latency on a payments service is doing real work, because the watcher is the on-call engineer and the watching is, briefly, the job. That kind is fine. The kind being argued against is the security dashboard that pretends to be the same shape but is consumed by nobody in the same way.

4. Outcome as a Service

If the goal is not to watch a chart, what is it? Three things, and only three.

The first is evidence. Every security event in the company should be written, with its full context, into an immutable store, indexed and searchable for at least the legal retention horizon. The store is the audit trail. It is what the auditor reads, what the post-incident review reconstructs from, and what an engineer reaches for when someone asks why a particular permission was granted last August.

The second is alerts. A short, intentional, high-precision list of things that wake people up. Mass file deletion. A production root credential used. Org-wide MFA enforcement disabled. Twenty entries, not two thousand. Each one accompanied by enough context for the on-call engineer to make a decision in the first sixty seconds, with the cat still on their lap.

The third is questions. Anyone in the company should be able to ask the security data anything. Who logged in from a new country today? Which third-party apps were granted Drive scopes this month? Has anyone touched the production deploy role in the last seventy-two hours? The answer should arrive in chat, with the SQL it ran visible underneath, in under thirty seconds.

That is the entire workflow. Evidence, alerts, and questions. None of the three needs a dashboard. All three are well served by the chat tools the team already has open in another tab.

The phrase for this is outcome as a service. The outcomes are the three loops. The service is the small, headless system that delivers them. The interface is the tool the team already lives in. The vendor relationship, if any, is with a cloud provider and an LLM provider. Everything else is open code the team can read, modify, and, when necessary, blame for the right reasons.

5. The Lake as Foundation

Every loop above terminates in the same place: a pile of files in object storage, organized by date and source. The pile is the foundation of everything else. Get it right and the layers above are small. Get it wrong and no amount of work above will compensate.

Picture a salt mine. Cheap to dig. Far easier to fill than to empty. The contents survive indefinitely, provided you leave them alone. That is object storage, and three of its properties are load-bearing for security work.

Durability first. S3, GCS, and Azure Blob each guarantee at least eleven nines of durability, which in practical terms means you will lose your team to attrition before you lose a log file. Unit economics next: standard tier runs about $23 per terabyte per month, and falls by an order of magnitude in cold tiers. And finally, immutability primitives: each provider supports object lock or its equivalent. Write a file, and you can guarantee that no one — including the account owner — can modify or delete it within a configured retention window.

Those three properties are precisely what an audit trail wants. Compare with the alternative of putting log data in a transactional database, which is what older SIEMs do. A transactional database is expensive per gigabyte, lower on durability, and mutable by the account owner unless you bolt on extra controls. Storing an audit trail there is like keeping court evidence in a sandbox: fast to write, easy to lose, easy to alter, and the moment you need it in a real proceeding, you have a problem.

The convention is unfashionably plain, and that is the point. Each source writes Parquet files into a partitioned prefix. Partitioning by date is the single most useful dimension for security work, because every interesting query has a time predicate. The engine scans only the relevant partitions and skips the rest. The same lake holds posture snapshots — full materializations of resource state at a moment in time — and a state directory holds collector watermarks, so collectors can restart without losing or duplicating events.

The query engine sits on top. Athena reads Parquet in S3 directly at $5 per terabyte scanned. BigQuery reads native tables at $6. Synapse Serverless reads Parquet in Blob at $5. The three are within ten percent of each other on cost and performance for security workloads. Pick the one that matches your primary cloud, and then never think about it again.

The honest trade-off is latency. Object storage and serverless query are not low-latency systems. A query that scans a terabyte of recent data takes anywhere from eight to thirty seconds to come back. That is fine for the question loop. It is fine for hourly detection. It is not fine for sub-second detection. Compensate by running the most time-sensitive rules over the freshest partitions only, or by parking a small streaming buffer in front of the lake. The vast majority of security work happens at minute or hour granularity, and for that, the lake is exactly the right shape.

One pragmatic note. Compaction matters. Small Parquet files murder query performance — scanning a million 4 KB files is dramatically slower than scanning ten 400 MB files, even when the bytes are identical. The reason is the same one a librarian shelves books in stacks rather than scattering them across the floor: lookup overhead dominates when the items are small. Collectors should either write large files outright, or be followed by a compaction job that merges small files hourly. Lifecycle policies then move data from hot to cold tiers as it ages. None of this is exotic; it is well-trodden ground in any data engineering practice.

6. The Determinism Boundary

The hard part of putting a language model anywhere near security data is keeping the model from inventing answers. A naive integration takes a question, hands it to a model along with a few rows of data, and asks for a summary. The output looks plausible. It is also unverifiable. The model will sometimes be wrong, and there is no good way to tell which times those are.

Picture a court interpreter. The witness speaks in one language, the judge in another, and the interpreter's job is to translate — not to testify. The instant the interpreter starts offering their own version of events, the trial is compromised. The translator is allowed to be the interpreter. The translator is not allowed to be the witness.

The discipline that keeps the model safe is a single load-bearing rule: the model is not allowed to produce facts. It is allowed to translate. English in, SQL out. The SQL is then run, deterministically, by the query engine. The rows that come back are real. A second translation goes the other way: SQL plus rows in, English out. Both translations are subject to verification. The user sees the SQL that ran, the row count, and the cost in tokens and dollars. If the SQL is empty, the answer says so. If the SQL errors, the answer says so. There is no path by which the model invents content that did not come from the lake.

The same trust boundary turns up in robotics, in compiler design, and in financial reconciliation. The general form: probabilistic systems must be sandwiched between deterministic ones. The probabilistic layer does what it is good at — interpreting fuzzy input, producing fuzzy output. The deterministic layer binds that output to ground truth. A self-driving car perceives the world probabilistically and then steers via deterministic actuators with hard safety envelopes. A bank's fraud model scores transactions probabilistically and then commits debits through deterministic double-entry ledgers. Same shape, different industries.

The four-stage shape above is the same shape every responsible system uses when it mixes a learned component with ground truth. The learned component lives on the outside. The deterministic core sits in the middle. The interface between them is a small, well-typed message. For mantissa-log, that message is SQL. For a compiler, it is an intermediate representation. For a payments system, a balanced ledger entry. The form generalizes.

One trade-off worth naming. The architecture is more verbose to the user than a black-box assistant would be. The user sees the SQL. The cost. The row count. Some users will find that annoying. The argument for the verbosity is simple: an answer the user cannot verify is an answer they should not trust, especially in security work. The small friction of glancing at a SQL query is the price of the trust. Most users skim past the SQL and accept the English summary — but they have the option to drill down, and the option is what matters.

A second trade-off, less obvious. Schema-aware NL-to-SQL works well when the schema is stable and well-named. It works poorly on schemas that change weekly or have cryptic field names. The lake schema is therefore not an internal detail. It is a contract between the collectors and the language model. Field names matter. Column documentation matters. Stable partition layouts matter. A schema change shipped without an update to the schema context can degrade generated SQL overnight, in ways that are mysterious until you trace them back.

7. Mantissa Log as Worked Example

Mantissa log is a SIEM that follows the architecture above. It is open source, about 80,000 lines of Python, with around thirty log source parsers normalizing into Elastic Common Schema and 690 detection rules in Sigma format. Its natural-language query layer supports eight LLM providers on a bring-your-own-key basis. It runs on AWS, GCP, or Azure, with Terraform modules for each. A small team can deploy it on the cloud they already use in a day or two.

The collectors deserve a sentence each, because they are where the system meets reality. A collector polls or subscribes to a source, normalizes events into Elastic Common Schema, and writes them to the lake. Normalization is the unsexy heart of the project. Every cloud, every SaaS app, every endpoint agent emits audit data in its own peculiar shape, and the collector's job is to turn that shape into a standard one.

Think of a customs warehouse at a busy port. Trucks arrive from twenty different countries, each carrying goods labeled in a different language, with different currencies, different unit conventions, different addressing schemes. Until everything is relabeled to a common standard, the warehouse manager cannot answer a simple question like "do we have fifty kilograms of coffee in stock?" without walking to every truck and squinting at the manifest. Normalization is the relabeling. Without it, a question like "what did user X do across all sources today" returns nothing useful. With it, the question returns a sensible answer in seconds.

This is the open-source equivalent of what Splunk packages as TA-windows, TA-cisco-asa, TA-aws, and the rest; what Chronicle ships as parser configurations; what Sentinel calls data connectors plus KQL parsers; what QRadar calls DSMs. The work product is the same: a piece of code that takes a raw vendor event and emits a normalized record with stable field names. Mantissa log holds roughly a thousand field mappings across thirty-something sources. Adding a source takes half a day for a familiar shape, a few days for an unfamiliar one, and most of that time is spent reading the source's documentation rather than writing code. A team migrating from a commercial SIEM should expect to spend most of its replatform effort here, not in the lake or the detection layer, because parsers are where institutional knowledge actually lives. The good news is that a parser written for the lake is a small Python module the team owns — not a black-box vendor artifact that has to be repurchased on each renewal.

The detection layer follows a deliberate split. A Sigma engine runs hundreds of community detection rules against the lake. Sigma is a community-maintained, open detection format with broad coverage, and the engine quietly translates each rule into the SQL dialect of the chosen query engine. The customer inherits years of community detection work for free. The trade-off is that Sigma is not always the most expressive format, and some detections want the full power of the underlying SQL; for those, the engine accepts native SQL detections too.

The detection-content question deserves a longer look, because it is the second half of the commercial moat and the place where buyers most often assume the build path falls short. Splunk's ESCU, Chronicle's curated detections, Sentinel's analytics rules and hunting queries, QRadar's content extensions: each is a carefully written rule library mapped to MITRE ATT&CK techniques and to the vendor's preferred data model. Real, substantial work. Also the same intent as the open Sigma rule pack, which now numbers in the multiple thousands and covers the dominant majority of the same techniques. The differences between an ESCU correlation search and a Sigma rule for the same technique are mostly differences of expression and field naming, not of underlying detection logic. The Sigma engine and a small library of native SQL detections together cover the techniques that matter for the mid-sized organizations this argument is addressed to. When a specific commercial detection turns out to be irreplaceable, it can usually be ported by hand in an afternoon — at the SQL or Sigma level, the detection is rarely more than a few dozen lines of logic. The detection-content moat is real but shallow. The deep moat is the muscle memory of analysts who have tuned that content over years, and the only way to cross it is to do the tuning again on the new substrate.

Alongside Sigma is a smaller, more opinionated layer that handles identity threat detection. It maintains per-user baselines of source IPs, ASNs, countries, user agents, and sign-in hours, across all identity sources unified into a single user model. An impossible-travel analyzer runs over the unified stream. Anomalies feed into a per-user risk score. This layer exists separately from Sigma because identity attacks span sources in ways that Sigma rules express awkwardly. A login from Brazil at 03:00 might be unremarkable in isolation. The same login, by a user who has only ever logged in from Texas, on the same day that user granted a third-party app full Drive scope, is a very different story. Sigma catches the first one. The identity layer catches the second.

The query interface is a Slack bot. Also a Teams bot. Also a CLI for people who prefer the terminal. The bots are thin shells around the natural-language query layer described earlier: the user types a question, the system produces SQL, runs it, and replies with the answer, the SQL, the row count, and the cost. When an alert spawns a thread, the bot pre-scopes follow-up questions in that thread to the alert's user, source, and time window. The investigation lives where the conversation already is, not in a separate console two tabs over.

The trade-offs are worth being explicit about. Mantissa log is not a drop-in replacement for Splunk at a thousand-engineer security team ingesting 50 TB a day. The serverless query model has a ceiling, and at very high ingest volumes, query latency starts to exceed what an interactive workflow tolerates. Such teams will need either dedicated query infrastructure or a streaming engine in front of the lake. For the ninety percent of organizations that ingest under 5 TB a day, this is a non-issue. For the other ten percent, mantissa log is at best a complement, not a replacement — and the choice should be made consciously.

A second trade-off. Relying on an external LLM provider for the query layer means the customer must trust that provider with their question text. Row data is never sent to the provider, only the schema and the question, and the mitigation is real and important. It is not, however, zero. A customer with the strictest data residency requirements should run a self-hosted model behind the same translator interface — supported through Bedrock and Vertex private endpoints — but the cost and latency math gets harder. Honesty matters more than convenience here.

A third trade-off. There is no dashboard. For some buyers that is a feature. For others it is a deal-breaker, often for reasons that have little to do with the workflow and everything to do with the visual artifact a CISO can show a board. A documented integration path with Metabase and Superset exists for customers who need a chart on a slide. The core does not include it, because the core is opinionated about where engineering time should go.

8. Posture Has a Different Shape

If mantissa log is the answer for events, mantissa stance is the answer for posture. They are siblings, sharing an author and a stance toward the problem, but not a codebase — and the choice not to share is deliberate, because event data and posture data have structurally different shapes and merging them would compromise both.

Think of events as a security camera feed and posture as a building inspection report. The camera records what happens, in order, forever. The inspector visits periodically and writes down what is wrong with the building right now. Try to use the camera as an inspection report — or the report as a camera — and you end up with something useless on both axes.

The two columns describe different problems. They want different storage strategies, different query patterns, different cadences, and different user-facing surfaces. A single product that tries to serve both compromises on one or both. Two products with a clean boundary between them can each be excellent at their own job.

Mantissa stance does CSPM for AWS, GCP, and Azure. CIEM, with an effective-permissions graph that joins identities across providers. DSPM, with content classification of files in Drive, SharePoint, S3, GCS, and Azure Blob. Kubernetes configuration analysis. Container image vulnerability scanning. IaC scanning for Terraform and CloudFormation. The breadth is intentional, because posture is structurally a breadth problem. There is no point looking at AWS misconfiguration in isolation if your data lives in Workspace and your identities live in Entra.

The architecture is straightforward. Each domain has a collector that snapshots resources from that domain's API. Each snapshot is evaluated against a set of YAML policies. Each policy is a small declarative file: a check, the resources it applies to, the severity if it fails, and the compliance frameworks it maps to. The output is a finding. Findings get written to a store, summarized in reports, and routed to whichever alert sinks the customer has configured.

The policy format is intentionally boring. No novel DSL. No plug-in language. Just a YAML file with an expression and some metadata. A novice can read it. An auditor can read it. A version control system can diff it. A pull request can review it. The simplest representation that does the job is the right representation. Anything more sophisticated tends to serve the vendor more than the customer.

The interesting work in stance is not the policy engine. It is the cross-domain identity graph. When the engine ingests AWS IAM, GCP IAM, Azure RBAC, Workspace admin roles, and Entra role assignments, and resolves them all into a single effective-permission model, a small set of high-leverage questions suddenly become askable. Which Entra users are AWS administrators by way of SAML federation? Which Workspace super admins are also GCP organization admins? Which service principals in M365 hold Mail.ReadWrite by way of an app registration whose owner happens to be a contractor?

Those are the questions enterprise CIEM vendors charge $200,000 a year to answer. The graph is the answer. It is small enough to fit in memory for any sensibly sized enterprise. The hard part is the resolution logic — following federation trusts, role chains, and group memberships across providers that each implement those concepts a little differently — and that logic is in mantissa stance, in the open, where a determined reader can audit every line of it.

The honest trade-off, mirroring log, is that breadth of coverage means depth in any single domain is sometimes shallower than a specialist tool. A team that needs the deepest possible Kubernetes posture analysis is still better served by a Kubernetes-focused tool. A team that needs the deepest Snowflake DSPM is still better served by a Snowflake-focused tool. The argument for stance is not that it is best in any single domain. It is that the union of competent coverage across many domains, with a unified policy format and a unified identity graph, is more useful for most teams than any single best-in-class tool deployed alone.

9. The Surface That Already Exists

Once the dashboard is gone, something has to take its place as the user-facing surface. That something is the chat tool the team is already using — Slack for most of the world, Teams for the parts of the world that live in Microsoft. The team is in those tools all day. Their notification preferences are tuned. Their on-call rotations are wired in. Adding a new tab to a separate console asks the team to develop a new habit. Sending alerts and answers into the channel they are already in asks for nothing.

Three integration patterns, in roughly increasing order of value.

The first is alerts as threads. When a destructive event fires, the system opens a thread in the on-call channel. The first message is a structured summary: what happened, who did it, when, and the immediate evidence. From there, the thread is the incident channel. Engineers reply in it. The bot listens, and treats every reply as a follow-up question scoped to the same user, source, and time window as the original alert. The engineer asks "anything else from this user today" and gets an answer right there. They ask "did this user touch IAM" and get an answer right there. The investigation lives where the conversation already is, instead of fragmenting across a ticket and a console and a chat window.

The second is questions as slash commands. A user types /mantissa ask show me oauth grants this week with drive scopes. The bot translates, runs, and returns the answer, along with the SQL, the row count, and the cost. The user iterates. They share the answer in another channel by linking to the message. They refine the question in a thread reply. The interaction model is the same one the user already uses for every other tool with a Slack or Teams app.

The third is workflow handoff. When an alert calls for human action, the bot offers buttons that hand off to the team's existing tools. Open a PagerDuty incident. Create a Jira ticket. Page the on-call. Suspend the user in the IdP. The buttons do not implement the workflow; they connect to the systems that already do. Each button press is auditable. Each writes an entry back into the lake.

It is a mock, but every line in it maps to functionality that exists or could be added in under a day on a system that is already running. Notice what is missing. There is no console to log into. No ticket to chase. No separate audit log. The thread is the audit log, indexed and searchable by every chat tool's native search. The actions in the thread are what happened. The conversation is the record.

One concession to reality. Not every action belongs in a chat tool. Some are sensitive enough to require multi-party approval, ticket-based change control, or specialized forensic workflows. The pattern above is for the common case, which is most of the work. The uncommon cases route into the systems that already handle them. The chat surface is not a replacement for those; it is a replacement for the dashboard and console nobody used in the first place.

10. Bring Your Own Cloud, Bring Your Own Key

Here is a property of this architecture that is easy to miss. There is no central server. No vendor SaaS. No shared multi-tenant database holding the customer's data. The system runs entirely in the customer's own cloud account, on infrastructure the customer already pays for, with credentials the customer already manages. The vendor relationship is with AWS, GCP, or Azure, with whichever LLM provider the customer chooses, and with whichever IdP the customer uses. There is no fourth vendor to add to the list.

That property does work in three places at once.

The first is the threat model. No central control plane means no central control plane to compromise. A breach of mantissa-log the project does not produce a breach of mantissa-log the deployment, because the deployment is the customer's own infrastructure and the project is just code. Compare with a SaaS SIEM, where a breach of the vendor's account potentially exposes every customer at once. It is the difference between a thousand homeowners each holding their own front-door key and a thousand homeowners whose keys all live in a single safe at the locksmith's office. Crack the safe, and everyone is exposed at once. Hand each homeowner their own key, and an attacker has to break in a thousand separate times.

The second is data residency. Every byte of log data, every snapshot of posture data, every audit record stays in the customer's own region in the customer's own cloud. Compliance frameworks that are difficult to satisfy with a SaaS vendor become almost trivial. The data never leaves the customer's account, because the only system that processes it lives in the customer's account.

The third is cost transparency. The customer pays the cloud provider for storage. They pay for query. They pay for the LLM tokens the question loop consumes. Each line item arrives on a bill the customer already gets and already understands. There is no mysterious SIEM bill growing alongside ingest volume — just the same S3 storage bill the customer already pays, plus a bit more.

The honest addition to the table is the bottom row. Engineer time is the real cost of running this, and it is not zero. A team that adopts this pattern takes on the responsibility of running, upgrading, and maintaining the collectors and rule packs. That is real work. It is also work the team is already doing in some other form, because every team in the modern cloud era runs custom infrastructure of one kind or another.

The break-even point depends on the team. A two-person security team at a fifty-person company is almost certainly better off paying for a managed bundle and outsourcing the operational burden. A six-person team at a 2,000-person company sits squarely in the sweet spot. A fifty-person team at a 10,000-person company will likely run a hybrid — this pattern for everyday work, a managed tool of last resort for compliance edge cases. There is no universal answer, only a more honest set of trade-offs than the bundled commercial pitch usually presents.

The TCO arithmetic deserves to be done out in the open, because the savings claim is the part most likely to be misread as marketing. Take the mid-sized organization from the opening: 500 GB a day of ingest, one-year retention, a dozen active detections, a few hundred questions a month. On the commercial side, the bundle typically lands somewhere between $400,000 and $700,000 a year, depending on negotiation and which adjacent products are stacked on top. On the build side, the same workload runs to roughly $30,000 a year in cloud spend — about $20,000 for storage of half a petabyte across hot and cold tiers, about $5,000 for query (a few hundred TB scanned a month at $5 per TB), a few thousand dollars for collector compute, and low four figures for LLM tokens. Add the fully loaded cost of half an engineer's attention — call it $150,000 a year for an experienced security engineer who splits their time across this and other work — and the all-in number is roughly $180,000. The savings are $200,000 to $500,000 a year, depending on which commercial baseline is the honest comparison, and they accumulate over the multi-year horizon during which the commercial license would have escalated with ingest volume while the build path's cost stayed close to flat. The savings are real. They are not magic. They are simply the difference between paying for the bundle and paying for the components.

11. What You Give Up

An argument that argued only for the build path would be dishonest. The build path gives up real things, and naming them precisely is what lets a reader make a sound choice rather than an aesthetic one.

The first thing given up is a vendor relationship. There is no number to call when something goes wrong. No contract that promises indemnity if a detection misses. No certified report saying a SOC 2 auditor signed off on the tool. For organizations whose risk model requires those things, the build path is incomplete on its own. The right move, then, is to keep a managed tool for the certified scope and run the build path alongside it for everything else. A great many security programs already do exactly this in practice, even when their procurement diagrams pretend otherwise.

The second is polish at the edges. A commercial tool has spent millions of engineering hours on edge cases the open-source tool has not yet encountered. The fiftieth-most-common log source is supported. The obscure SAML attribute is handled correctly. The PDF report is pixel-perfect. None of those things is particularly interesting on its own. Together, they add up to the experience of a product that has been used by 10,000 customers — which an open-source project used by ten cannot match. The gap closes over time, but it exists at any given moment.

The third is breadth. A commercial SIEM ships with 3,000 parsers, 2,000 rules, and integrations to every tool the team has ever heard of. The open-source equivalent has a smaller set. Adding the missing parser is straightforward, but it is engineering work the team will own. For a team willing to do that work, this is a feature: the parser is then auditable. For a team that is not, it is a cost.

It is worth being concrete here, because "3,000 parsers" sounds like a moat and turns out, on inspection, to be a long tail with a fat head. A typical mid-sized organization is actively ingesting fifteen to thirty distinct log sources, not 3,000. The head of the distribution is the cloud control planes, the identity provider, the productivity suite, the code host, the endpoint agent, the network gateway, and a small set of SaaS audit feeds. Those parsers already exist in the open ecosystem, in mantissa log, and in every comparable project. The long tail is the legacy appliance, the regional vendor, the internal application with its own log format. The tail is real, and it is where the commercial bundle quietly earns part of its keep. The replication strategy is to write parsers as the tail becomes relevant, in priority order, using the model-assisted workflow described earlier, and to accept that on day one the open architecture will cover ninety percent of the volume with five percent of the parsers, with the remaining ten percent of volume picking up its parsers over the first quarter of operation. That is a manageable shape for an engineering team that has done the migration consciously. It is an unmanageable shape for a team that expected the open architecture to ship pre-loaded with the same long tail the commercial vendor accumulated over twenty years.

The fourth is dashboards. The case against the dashboard is correct on the merits and wrong on the politics. There are stakeholders, especially executive ones, who measure security investment by the visual artifact it produces. A program that cannot show a chart in a board meeting is at a disadvantage in the budget cycle, regardless of whether it is producing better outcomes. The pragmatic response is to point Metabase or Superset at the lake and produce the chart. The chart is decoration. The work is real. Both can be true at once.

The fifth is a certain kind of operational comfort. When a SIEM vendor is being paid $600,000 a year, it is reasonable for the team to expect that vendor to keep the lights on. When the team runs the system itself, the team is the vendor. Pages still happen. Bugs still happen. Schema migrations still happen. The team is the one who handles them. That is fine for teams whose engineering culture supports it. It is not fine for teams whose engineering culture does not, and pretending otherwise is how organizations end up with abandoned half-builds and an angry CISO.

The right question is not whether build is better than buy. It is which parts of the bundle should be built and which should be bought, given the team you have and the scale you operate at.

The honest summary is that this architecture is right for a specific shape of organization. Mid-sized. Engineering-oriented. Cloud-native. Tolerant of ownership. Skeptical of vendor pitches. Willing to read code. Willing to write Terraform. Such organizations are common, but they are not universal. Not everyone should adopt this pattern. The pattern is, however, far more accessible than vendor messaging would lead a buyer to believe, and the savings are large enough to be well worth the engineering effort for the organizations that fit.

12. The Pattern Generalizes

Security is not the only category where this recipe applies. The same shape, with the right collectors and the right policies, replaces a long list of commercial tools priced and packaged on the same set of historical assumptions. The assumptions are no longer true. The tools have not been updated.

Application performance monitoring is one such category. The collectors are OpenTelemetry receivers. The lake holds traces and metrics in Parquet. The detection layer fires on latency anomalies and error-rate changes. The query layer answers questions like "what is the slowest endpoint in the checkout service right now?" The surface, once again, is Slack. There is no separate APM console.

Data loss prevention is another. The collectors snapshot file shares, mail systems, and chat archives. A classification engine runs against the lake content. Policies match patterns and exposure rules. Findings flow into the same alert router. The surface is chat, with the same trust boundary on the natural-language layer.

eDiscovery is another. The collectors gather mail, chat, files, and audit logs. The lake holds them with object lock at a retention horizon set by legal. The query layer runs against the lake. A legal hold is just a small piece of metadata on the affected partitions. The surface for the legal team is a CLI plus a chat bot that can answer something like "find every message between user A and user B that mentions project X in 2024."

Governance, risk, and compliance is another. The collectors gather control evidence from cloud APIs, IdP APIs, and ticketing systems. The lake holds the evidence with object lock at the audit retention horizon. The policies are the controls themselves, expressed as YAML the same way stance expresses misconfiguration policies. The auditor's view is a report generator that pulls from the lake. The surface is a small chat interface for the compliance team.

IT service management is another. The collectors gather ticket data, config management data, and asset inventory. The lake holds the joined view. The detection layer fires on SLA breaches. The query layer answers questions like "which tickets escalated this week from a low-priority initial classification?" The surface, once again, is the chat tool the team already uses.

The columns stay the same. The collectors change. The detection or policy logic changes. The natural-language layer stays. The chat surface stays. The lake stays. The query engine stays. The architecture is more like a kit than a product. Pick the components that match the category. Wire them up. Ship.

This is the renaissance gestured at in the title. Not a single new technology, but a recombination of mature commodities into a configuration that solves dozens of vertically siloed product problems with one horizontal architecture. The vendors of those products will resist the framing, and they are not wrong to resist; their business depends on the framing of the bundle, and the framing of the bundle is increasingly out of step with the underlying economics.

13. What Made This Possible

Why now? The components of this architecture have been arriving slowly for fifteen years. The combination became practical only in roughly the last three. Four preconditions are worth naming, because the same four preconditions tell us which adjacent categories are next.

The first is cheap, durable object storage. S3 launched in 2006. The first decade was a slow march through pricing improvements and durability guarantees. By 2018, storing a terabyte of audit data for a year cost about $300. By 2024, with intelligent tiering and lifecycle policies in widespread use, that number had fallen by another factor of three. Below a certain price point, the calculus of "what should we keep" flips from selective retention to keep everything. The flip happened in the last five years. It is the same flip that happened to photographs around 2010: once the memory card stopped costing more than the camera, nobody bothered deleting photos anymore.

The second is columnar query engines that scan object storage directly. Athena launched in 2016. BigQuery is older, but became cost-competitive against Athena around the same time. Synapse Serverless followed. The launches were not the news; the news was that, by 2020, the engines had matured to the point where a non-specialist could write a SQL query against a Parquet partition and get a sensible answer back in single-digit seconds, on the customer's own data, without spinning up any infrastructure. That is the engine that makes the lake usable as a working query surface and not merely as a storage tier.

The third is large language models capable of reliable code generation. The first wave of capable models arrived in 2022. By 2024, models from multiple providers could translate English to SQL with an accuracy that was no longer embarrassing for the great majority of analyst questions. The accuracy continues to improve, but it crossed the threshold of useful before it crossed the threshold of perfect — and once it was useful, the rest of the architecture had its missing piece. Compare with the way GPS became useful when civilian accuracy crossed a few meters, even though it remained imperfect: a turn-by-turn navigator that is right 99% of the time replaces the paper map, even when it occasionally insists you turn down a road that has been closed for repaving.

The fourth is mature collaboration platforms with rich bot APIs. Slack launched in 2013, Teams in 2017. Both come with programmable bot frameworks, threaded conversations, button-based interactions, and identity systems that map to organizational structure. By 2020, both were ubiquitous enough that bot-based workflows were a known shape, not a novelty. That shape is what allows the user-facing surface of headless tools to be rich without requiring a custom front-end.

Before all four were mature, the architecture was not buildable by a small team. The pieces were there but the arithmetic did not work. After all four matured, the architecture became not only buildable but the obvious shape, because the alternative requires re-implementing what the cloud already provides. The lag between "buildable" and "widely adopted" is the lag of habit, of contract, of procurement, of vendor relationships — of every soft factor that takes longer to change than the technology underneath.

The categories that will succumb to the same pattern next have similar shape. Lots of structured event data. Heavy retention requirements. Workflows that already happen in chat. Vendors that have been bundling commodity components and charging non-commodity prices. Run that filter across the security tool landscape and most of it qualifies. Run it across the broader observability and IT operations landscape and a similar fraction qualifies. The renaissance is not security-specific. Security is just where the dollar amounts are most visible.