Status

Generated at build time from the published artifacts — there is no service behind this page, and no number on it that was not derived from what the catalog actually served. Last generated 2026-10-11.

Each number carries its definition and what it would take to move it without improving the catalog. That second column is the honest half: a metric you can improve by making the catalog worse is a metric that will eventually be improved that way.

Reporting something urgent

There is no published security channel yet, so the 72-hour commitment below cannot be invoked by anybody who does not already know who to write to. That is a gap and it is said here rather than left to be found: the process is written and the address is not. Until there is one, a report goes to the repository owner directly.

What	Now	Definition	What moving it would take
Records published	30	Records that passed every blocking gate and are served from /v1/index.untrusted.json, at any trust level.	Publish more records. That is the catalog improving, which is why this number is here and not on its own.
At T2 or above	100%	The share of published records whose computed trust is T2 or higher, which is what /v1/index.json contains. Trust is computed from evidence at read time and decays; it is never assigned.	A record reaches T2 by passing every gate with a verified publisher. There is no way to raise this that is not a record getting better or a publisher getting verified.
Upstream changed or gone	not measured	Records whose source has moved on: upstream_state is `changed` or `gone`. A record can be perfectly valid and still describe a procedure its source has since rewritten.	Deleting the affected records would lower it, and would also lower the record count beside it. The pair is published together for that reason.
Median age of the trust judgement	0 days	Days since the trust level of each record was computed, at the median. Trust decays after 180 days, so this says how close the catalog is to that edge.	Recomputing trust lowers it, and recomputing is exactly the work this number exists to prompt.
Filled target × trigger cells	16	Distinct (target, trigger) pairs across the 50 most-covered targets. It measures spread rather than volume: ten records about one target and one trigger fill one cell.	Adding a record for a pair nobody covers. That is coverage improving.
Ingested records with a P1 proposal	not measured	Of the records an adaptation batch has seen, the share that reached a P1 proposal. The rest were refused by their licence, kept as P0 because the procedure does not decompose, or dropped as not runbooks. A proposal is not a publication: nothing here has been reviewed by counting it.	Proposing for records that should have stayed P0 raises it and lowers the acceptance rate beside it, which is why the review queue's correction rate belongs on this page too.
Adaptations awaiting review	not measured	Proposals a person has not yet accepted, kept as P0 or dropped. An unreviewed adaptation is never published, so this queue growing is a reason to add reviewers, improve the inference or narrow the intake — never to lower the bar.	Dropping proposals unread would empty it and show up as a collapse in the acceptance rate published beside it.
Accepted after correction	not measured	Of accepted adaptations, the share where the reviewer changed something the pipeline had proposed. Answering a question the pipeline asked is not a correction: it asked precisely because it did not know.	Proposing less would lower it by asking more questions instead, which shows up as a longer queue and more actions per acceptance.
Client-side search index	16003	Bytes of the records payload in /v1/search-index.json — the part a reader would download to search — against a 524288-byte budget. The payload rather than the file, because the file carries this measurement and measuring it would change it. Faceted search is client-side over this file, which is what keeps the "no mandatory database" rule true; past the budget that stops being the cheap option it was designed to be and /catalog has to fall back to a search endpoint.	Publishing fewer records lowers it, and lowers the record count beside it. Shortening descriptions lowers it and makes the catalog worse to read.
Median age of the latest attestation	not measured	Days since the most recent attestation on each attested record, at the median. An attestation is a signature over a run bound to a content hash, and it is what carries a record above T2.	Issuing attestations lowers it, and an attestation is a signed claim about a real run — the work it measures is the work itself.
Records failing a blocking gate	0	Findings at error severity from the last run of §15's autogate chain over every record in the catalog. A record with one does not publish, so this number is normally zero and is worth publishing precisely because of that.	Fixing the records lowers it. Removing a gate would too, which is why the gate list is published beside the number and a gate is removed only by changing the code that every caller shares.
Takedowns answered later than 72 hours	not measured	Requests to the security channel where the gap between the request and the action passed 72 real hours — weekends included, since a leaked credential does not wait for Monday. Counted from the public log in moderation/takedowns.json.	Answering faster lowers it. Not recording a request would too, which is why the request count is published beside it and the log is append-only.
Days since the unpublish was rehearsed	36 days	The day a record was published for the purpose and withdrawn as a real request would withdraw it, checked from outside against every surface that carried it. Recorded in the public log, counted apart from real requests so it never flatters the response time.	Rehearsing more often improves it, and rehearsing is the thing being measured — there is no way to move this that is not the control being exercised. Rehearsing against a record nothing else touches would be the cheap version, which is why what was touched is written in the log entry.
Moderation queue growth per week	not measured	Items opened last week minus items closed, against the threshold §15 calls healthy. Growth rather than size: a large queue that is not growing is a backlog, and a small one that doubles weekly is a project about to have one.	Closing items lowers it, and closing items is the work. Rejecting is a decision and counts; ignoring does not — after seven business days an unreviewed record publishes itself at the bottom of the ladder.
Searches returning nothing	not measured	The share of searches that matched no record, in aggregate. The queries themselves are never stored (§17): what is useful is the rate, and the rate is what is kept.	Returning weak matches instead of nothing would lower it while making search worse, which is why it is published beside coverage rather than alone.

Not measured

Nothing here is reported as zero. An unmeasured number and a good one look identical when both are printed as 0, and only one of them is true.

Upstream changed or gone: No upstream has been checked on this checkout, so there is nothing to count. upstream_state is written when a record is made and stays current until pnpm reindex says otherwise; reporting zero would claim the catalog looked and found every source where it left it.
Ingested records with a P1 proposal: No adaptation batch has run against this checkout, so there is nothing to take a share of. Reporting zero would say every ingested record failed to promote.
Adaptations awaiting review: No adaptation batch has run against this checkout, so there is no queue to measure. Reporting zero would claim an empty queue.
Accepted after correction: Nothing has been accepted yet, so there is nothing to take a share of. Reporting zero would claim the inference has never been wrong.
Median age of the latest attestation: No record carries an attestation yet. A median of zero over an empty set would read as every record having been attested today.
Takedowns answered later than 72 hours: No request has been recorded. That is what an empty log means and it is not the same as a channel that answered everything on time.
Moderation queue growth per week: No queue snapshot was taken. An empty queue and an unwatched one look identical from here, and only one of them is good news.
Searches returning nothing: Search runs in the reader's browser over a published file, so nobody sees the queries and nobody counts them — which is the arrangement, not an oversight. This becomes a number if an endpoint is ever deployed, and stays absent until then: reporting zero would claim every search succeeds.

The same numbers as JSON: /v1/status.json. The moderation policy they are measured against: /v1/moderation.json.