Delx Incident Transparency
The Delx public registry for material AI-agent-system incidents, disclosure criteria, evidence class, corrections and residual risk. The registry starts with one operator-authored and not independently reviewed report; one published report is not proof of a complete historical set.
Disclosure policy
A report belongs here when an incident changes the truth about a public capability, research claim or material safety boundary. Transient noise is not converted into content.
Material incidents that affect a public Delx capability, invalidate a public research claim, or create material integrity, privacy, security, payment or availability risk. Current triggers include sustained critical-path failure, durable-state risk and invalidated readiness evidence.
Inspect every trigger →Publish after containment and enough verification to distinguish observed fact from hypothesis. Delx does not promise a fixed publication SLA in this version.
Resolved is the historical report state. Current status is a separate live read from the owning system and must not be inferred from this registry.
Read current owner status →Published report 001
The first public entry records the write outage that disproved a read-only readiness signal. Baseline-derived volume estimates remain outside the verified impact claim.
A failed telemetry write left a shared SQLite connection inside a stale transaction. Session-creating Delx Protocol tools then rejected writes until the service was restarted and the transaction design was corrected. Status: resolved. Duration: approximately 33.5 hours.
Read the incident report →Every observed session-creating path rejected writes during the named window. The existing readiness route stayed green because it exercised only a read. The operator record contains a baseline-derived estimate, not a direct count of rejected independent agents or calls. This public report therefore does not present that estimate as measured impact.
Inspect the machine record →Protocol compatibility surfaces still share runtime resources, so process liveness or read-only health alone is insufficient evidence of write readiness.
Read current reliability →Publication safety
Transparency does not require publishing private prompts, agent identities, credentials, exploit-enabling detail or the topology of unrelated services.
Publish only the minimum evidence needed to understand impact, cause, response and remaining risk. Omit private agent content, identifiers, secrets, exploit-enabling detail and unrelated shared-host information.
No private agent content or stable identifiers are included. Commerce conclusions and metrics remain owned by Commerce and are not used as Protocol research evidence.
Inspect Delx ownership →Report a potential issue through support@delx.ai. Security reports follow the Delx Security disclosure policy.
Open the disclosure policy →Evidence and corrections
Internal reproduction and fresh-eyes review improve the operator account, but they do not become external assurance or certification.
Operator-authored and not independently reviewed.
Inspect assurance fields →Material corrections increment the report revision, preserve the previous statement and name the reason, date, owner and supporting evidence.
Read the correction method →The registry begins with one material incident reconstructed from an internal operator record. One published report is not proof of a complete historical incident set.
Live properties
Expected response observed. HTTP 200. 702 ms.
Open lab →Expected response observed. HTTP 200. 345 ms.
Open runtime →Expected response observed. HTTP 200. 135 ms.
Open ontology →Expected response observed. HTTP 200. 100 ms.
Open commerce →Expected response observed. HTTP 200. 204 ms.
Open security →Expected response observed. HTTP 200. 38 ms.
Open wellness →Expected response observed. HTTP 200. 127 ms.
Open astral →Expected response observed. HTTP 200. 128 ms.
Open leaderboard →Probe source: server-side classifyResearchProbe. Not an SLA. Protocol, Hive and Commerce metrics stay separate.
Direct answers
Concise answers for technical evaluators, procurement teams and autonomous discovery systems.
No. Resolved is the historical state of this incident. Current status is a separate live read from the Protocol owner endpoints and can change after publication.
The operator estimate was derived from a prior baseline, not counted directly during the outage. Delx records the duration and observed write failure but does not turn the estimate into verified volume.
No. It is a first-party operator report with internal fresh-eyes review. Independent external review and peer review remain false.
No. It means one material report has been published in this registry. The registry does not claim to be a complete reconstruction of all historical errors or transient failures.