Platform
Five pillars over one operational record.
The command center, the service graph, incident response, runbooks and the evidence packet are not five products behind one login. They are designed to read from and write to the same per-tenant record: the graph an agent reasons over is the graph a runbook's blast radius is computed from, and the actions that record captures are what an audit packet exports.
Below is what an operator does with each pillar, using the journeys written into the specification, because they are more specific than any feature list we could write. Beside each one is what is actually built. One pillar runs today for the human workflow, three are partly built, and one, the runbook language, is a design with no code behind it.
At a glance
What is built, pillar by pillar.
Same legend as our internal audit. Implemented means running code on a real runtime path. Partial means real code with named gaps. Specified means a design we have committed to and have not built. Every tag on this page is checked against the repository, not against the specification.
- 01Operations command centerPartial
- 02Event intelligence and the service graphPartial
- 03Incident and crisis operationsImplemented
- 04Runbook automationSpecified
- 05Compliance and evidence automationPartial
The journeys quoted under each pillar are specification material. They describe the product being built. They are not recordings of a running system, and no part of this page describes a customer.
Pillar 01
Operations command center
One surface where an executive, a responder and a compliance officer each see the slice of operational reality they are accountable for, off the same data. The executive question is whether anything Tier-0 is at risk and whether it crosses a reporting threshold. The responder question is the timeline and the current owner. Moving between those lenses is designed to preserve your filters, so changing the question does not mean rebuilding the view.
The journey, from the specification
09:14 on a Monday. The top of the command center reads: stable, 47 of 49 Tier-0 services, two at risk. The CFO clicks the at-risk badge and sees the payments service degraded, the revenue exposure per minute, EU customers affected, mitigation in progress, projected resolution 09:35, and no DORA reportable threshold breached. One more click drops into the responder lens: timeline, agent recommendations, current responder. Ninety seconds, then the laptop closes.
The specification's revenue figure ($42K per minute) illustrates what the card computes from service tiering you supply. It is an example of what the surface displays, not a customer outcome. There are no customers yet.
Build state of the parts
- Implementedtelemetry-service, websocket-service
Event intake and live streaming to the operations surface.
- Implementedweb/dashboard/incidents
Responder view: incident list, incident detail, timeline.
- Partialroutes exist, logic thin
Executive and compliance lenses, business impact on every incident card, filter state preserved across lenses.
Pillar 02
Event intelligence and the service graph
The graph is the substrate an agent reasons over and the runbook compiler computes blast radius against. It will hold services, their dependencies, where each edge came from, when it was last verified and how much confidence to place in it. Without that, an agent is string-matching logs and a runbook's blast radius is whatever its author typed. This is the load-bearing gap in the current build, and we are not going to describe it as anything else.
The journey, from the specification
A deploy to auth-service triggers a 4xx spike in checkout. The SRE opens the incident and the dependency view shows auth-service to token-service to checkout-api, with the token-service edge marked freshness 8 minutes ago, source telemetry. They ask what else depends on auth-service and get 14 services back, ranked by Tier-0 criticality. They roll back. Six weeks later, that exchange is what shows an assessor CC7.2 was operating, because the question, the answer and the rollback were all recorded when they happened.
Graph freshness under 15 minutes p95 for any Tier-0 service, and a blast-radius query returning ranked services with citations under 500ms p95, are design targets, Spec §6.2.
Build state of the parts
- Implementedasset-service, integrations/servicenow
Asset inventory and ServiceNow CMDB synchronisation.
- Specifiednot built
Dependency traversal and blast-radius query with citations back to graph evidence.
- Specifiednot built
Freshness reconciliation between CMDB and telemetry, with source, last-verified time and confidence on every edge.
Pillar 03
Incident and crisis operations
Declare an incident, assign a commander, run the timeline, notify the people who need to know, close it out. This surface looks like the on-call tool you already run, deliberately: nobody wants to relearn a rota during a P1. What differs is underneath. What an agent read, what it proposed, who approved it and what changed in production are meant to land in the record as they happen, rather than being reconstructed from channel scrollback a quarter later.
The journey, from the specification
P1 declared at 14:02, commander assigned by policy, war room opened. The remediation agent proposes a runbook, rollback the last deploy to checkout-api, carrying a blast radius of service class covering eight downstream services, a rollback strategy of restore last known good deploy, an estimated cost, and the approval it requires under the Tier-0 deploy rollback policy. The commander approves and the action executes. The ledger records the input hashes, the retrieval set, the model version, the prompt, the response, the approver, the blast radius and the outcome. Resolved at 14:18, post-incident review drafted at 14:25.
The tag beside this pillar covers the human workflow, which runs today. The agent and the ledger in that journey do not exist yet, as the parts list states.
Build state of the parts
- Implementedcrisis-service
Declare, commander assignment, incident timeline, close-out.
- Partialpublic status page absent
Status updates and multi-channel notification during an incident.
- Implementedcrisis-service
On-call schedules, rotations, escalation policies and SLA-breach checks.
- Specifiednot built
Agent proposals, approval gates, and a ledger entry for every executed action.
Pillar 04
Runbook automation
A runbook here is designed to be a typed program, not a shell script. Every step will declare its preconditions, its blast radius, its cost and how it rolls back, and a program that fails static verification will not run. Blast radius will be computed from the graph on every execution rather than taken from whatever the author claimed when they saved it. This is the whole reason an agent can be allowed near production: a model can emit this language, and a model cannot be trusted to emit shell.
The journey, from the specification
An SRE asks for a runbook that restarts the checkout pods when the error rate spikes. The agent generates the program and the compiler answers with what it will do: blast radius service-scoped, checkout deployment, eight pods; rollback re-scales to the current replica count; approval required from SRE on-call under the service blast-radius class; estimated cost zero; preconditions error rate above 5% sustained for five minutes and no deploy in progress. The SRE accepts. Two days later the first execution passes static verification, approval, execution and post-action validation, and every one of those steps is in the record.
The workflows dashboard in the product references runbooks today. There is no language, no compiler and no execution runtime behind it. This pillar is greenfield.
Build state of the parts
- Specifiednot built
Language, compiler, static verifier, blast-radius computer, executor, rollback runtime.
- Specifiednot built
Agent-generated runbooks held to the same static verification as human-written ones.
Pillar 05
Compliance and evidence automation
The point of the ledger is to make evidence a by-product of running operations instead of a collection exercise that starts when the audit is booked. The control models for SOC 2, ISO 27001, HIPAA and DORA are in the service today. The chain underneath them is not. The design is that an audit packet for a framework and a period is reproducible byte for byte from the same ledger range, so an assessor can pick one control at random and trace a single artifact back to the telemetry, the model version, the prompt and the approver behind it.
The journey, from the specification
Two weeks before a SOC 2 Type II audit. The framework dashboard shows 47 of 52 controls satisfied, four at risk, one failing: CC9.2, vendor management, three vendor reviews missed in Q3. The officer clicks remediate. The evidence agent collects the missing artifacts from the connected systems, files them under CC9.2, and the ledger records that it did. Then: audit packet, SOC 2, Q3. The auditor opens it, picks a control, follows one piece of evidence to its source, and is done.
Frameworks named here are the ones your assessor holds you to. StaidKit does not hold a SOC 2 report of its own. Its first audit is ahead of general availability.
Build state of the parts
- Implementedcompliance-service
SOC 2, ISO 27001, HIPAA and DORA control models.
- Partialcollectors exist, storage has placeholders
Evidence collection from Datadog, ServiceNow and cloud providers.
- Specifiednot built
Hash-chained ledger and byte-reproducible audit packet export.
What changes
The same Tuesday, with a record behind it.
A pillar is only worth reading about if it changes an hour of your week. Here is the hour.
How the day runs now
You declare the incident in the paging tool, pull dependencies from a CMDB nobody fully trusts, run the fix from a terminal, and write it up afterwards from the channel scrollback. The blast radius was a judgement call made at 02:00. At audit time someone reassembles what happened by hand, out of four systems and their own memory of it.
How it is designed to run
The same incident, except the dependency answer carries its source and its age, the fix is a typed program whose blast radius was computed rather than claimed, the approval is attached to the action instead of living in a thread, and the write-up is a by-product of having done the work. Audit prep becomes a query over a date range.
Most of the parts that make the second column true are marked specified above. That is the honest shape of the product today, and it is where a design partner changes the order. How the graph, the ledger and the runbook language fit together.
Design partner programme
Decide which of these pillars gets built first.
We are recruiting five design partners. If you run on-call today and assemble your audit evidence by hand, the parts marked specified above are the ones we most want you to shape, in the order that matters to what you actually have to prove.