Incident methodology v1.1

Frozen 2026-09-15. This page is versioned: the taxonomy is never widened silently — a change is a documented revision with a new version number.

Taxonomy v1.1

class	name	what it is	publication rule
1	Schema break	A breaking mutation in a server's declared tool contract.	Published with the downstream count stated as measured or as not measured — we do not withhold a dated observation for lack of a number we do not have.
2	Disappearance	The signature event: a tracked entity stops resolving.	Published on downstream weight; the series carries the launch.
3	Silent behavior change	The declared contract holds while observed behaviour changes.	Restrictive — only at high downstream weight.
4	Mass event	A correlated change across many entities in one observation window.	Always news.

Everything else is logged and not published. High volume raises the threshold, never the cadence.

When we do not have a number

Downstream reference count is not measured for this population — which is not the same as zero.

For MCP servers we do not yet have a dependency graph, so we cannot say how many other projects call a given server. Earlier we treated that as a reason to withhold the record. We no longer do: the observation is dated and checkable whether or not we can count who depends on it, and a register that waits for a number nobody has is a register that publishes nothing. Where the count IS measured, we state it; where it is not, we say so in those words.

A real downstream measurement — from manifests and configs, npm wrappers, and code references already in our capture — is being built. It is an improvement to these records, not a precondition for them.

Significance threshold

8.56 % of tracked MCP servers disappear per month — measured, not estimated.

Source: neg_observations.db, registry=mcp, 43-dygnsfönster 2026-07-22→2026-09-03, intervallcensurerat per L9, n=28 824. Measured 2026-09-03. This revised the prior assumption upward (UPP från antagandet 1,5–3 %/mån (~3–5×)). The measured rate is the volume ground for the threshold — never the publication cadence: the threshold is set high and gated on downstream weight, targeting 2–3 substantial incidents per week.

Tone rule (frozen)

We report what was observed to change, when, and what references the changed thing — never why anyone acted, and never who bears responsibility.

v1 counts downstream parties; it does not name them. The subject of an incident — the entity observed to change — is named by definition: that is a dated fact inside the notary boundary.

What this surface never does

We never rank. There is no "worst servers" list, no leaderboard, and no ordering by severity — not now and not later. A record is a record; a ranking would be a verdict, and verdicts are outside what we do.
We book changes in both directions. Tools added are recorded exactly like tools removed. A surface that only recorded losses would be a different thing than a register.
In this first series we record organisations and products only. Where a server is published under a personal account name we hold the observation but do not publish it, because the record does not need the person's name to be true.

The observed party's context is published alongside the record

If you operate something we have recorded, you can submit context through /dispute. Where we can confirm you control the source — a change in your own manifest, or mail from a domain tied to the server — your text is published next to the record within 72 hours, unedited by us, dated and linked. We do not summarise it, shorten it, or reply to it inline.

This is deliberate. A register that carries the observed party's own words beside the observation is a different object from one that does not.

What we cannot know

We do not know intent, and never report it.
We do not know the cause of a change — only that the observation differed.
Before a population's coverage start we hold no observation; that is a statement about our window, not about the entity.
Between two snapshots we report an interval, never a point date inside the gap.
A schema or behaviour class requires at least two dated observations of the same server; one snapshot cannot evidence a change.

Revision history

version	frozen	what changed and why
v1	2026-09-14	Första frysning: fyra klasser, mätt tröskel, frusen ton-regel.
v1.1	2026-09-15	Nedströmsgrenen öppnad. v1 krävde nedströmsvikt ≥ tröskel för klass 1, och för MCP-servrar finns ingen sådan mätning — regeln blockerade därmed publicering i väntan på ett tal ingen har. v1.1 gör klass 1 publicerbar MED EXPLICIT OSÄKERHET, med samma mening som redan står i varje post. Den riktiga nedströmsmätningen (manifest/configs, npm-wrappar, GitHub-referenser ur befintlig fångst) byggs separat och är en FÖRBÄTTRING, inte en förutsättning. Hellre 'vi vet inte' i tryck än en grind som väntar på ett tal ingen har.

These are factual observation records derived from dated snapshots of publicly declared, machine-readable material. They contain no assessment of fault, intent, or fitness for purpose. Corrections and context: /dispute.