Project Deviant · Registry Governance & Versioning Policy v1.0 · effective at registry publication · 2026

Registry
governance policy.

The procedural framework for the Fault Line Registry and the Failure Mode Typology. Defines who may add entries, what an entry must contain, how amendments and corrections work, how disputes are resolved, and how the registry's institutional integrity is maintained over time.

Purpose

What this policy does.

The Fault Line Registry and the Failure Mode Typology make structural claims that can only be evaluated against accumulated empirical observation over time. The credibility of either document depends not only on the quality of any individual entry but on the procedural integrity of the registry as an institution. The policy defines that institution.

The policy is short, deliberately. A document of this kind is most credible when it is small enough to read in full, and when its rules are simple enough that an observer can audit the registry against them without ambiguity. Where this policy is silent on a procedural question, the default is whichever course of action best preserves the registry's neutrality and verifiability.

The policy itself is subject to amendment under the same rules it imposes on registry entries. Amendments are recorded in the change log at the foot of this document with date, reason, and authorizing party. The current version is v1.0 as of registry publication.

Article I
Editorial authority
§1.1
The Deviant project maintains editorial authority over the Registry. Editorial authority means the practical responsibility for evaluating proposed entries, applying the inclusion criteria, drafting entries in the prescribed format, and publishing the result.
§1.2
Editorial authority is not a license to act arbitrarily. Every editorial decision must be defensible against the inclusion criteria and the procedural rules in this policy. The authority is to apply the rules, not to deviate from them.
§1.3
The project may, at its discretion, delegate editorial review to one or more contributors who agree in writing to apply this policy. Delegation does not transfer responsibility — the project remains accountable for every published entry.
§1.4
No external party — including funders, partners, regulators, or counsel — possesses editorial authority. Recommendations from external parties may be received and considered; they are not binding.
Article II
Entry submission and review
§2.1
Any party may submit a proposed entry for consideration. Submissions should follow the entry template published with the Registry and include the required public sources.
§2.2
Submissions are evaluated against the five inclusion criteria: public documentation, factual undisputedness, structural specificity, MBA-applicable contrast, and neutrality of language. An entry that fails any single criterion is rejected.
§2.3
Rejected submissions receive a brief written explanation citing the failed criterion. Explanations are not published, but are retained in case of subsequent dispute.
§2.4
Accepted submissions are drafted into the prescribed format by the project. The published wording is the project's, not the submitter's. Submitters do not retain veto rights over the published wording.
§2.5
The project may originate entries without external submission — for example, from contemporaneous monitoring of public sources. Self-originated entries are subject to the same five inclusion criteria as submitted entries.
Article III
Append-only integrity
§3.1
Once an entry is published, it cannot be removed. The Registry is append-only.
§3.2
An entry may be amended only to correct a factual error, to add information that strengthens the existing structural claim, or to record subsequent developments that materially alter the public record of the event itself.
§3.3
Every amendment is recorded as a numbered note attached to the entry, with date, reason, and the prior text of any modified passage. The history of changes is permanent and visible.
§3.4
Where a published entry is found to fail an inclusion criterion that would have prevented its original publication — for instance, if its factual basis is subsequently disputed in a way that meets the §IV definition — the entry is marked as "withdrawn" rather than removed. Withdrawn entries remain on the published page with their original text and a withdrawal note explaining the reason. The reader can still see what was claimed.
Article IV
Dispute resolution
§4.1
A dispute arises when an external party, in writing, asserts that a published entry contains a factual error, a category error, or a violation of the inclusion criteria.
§4.2
All disputes are evaluated against the original inclusion criteria and the supporting public sources cited in the entry. The project may consult additional sources as needed but may not rely on undisclosed information to decide a dispute.
§4.3
Dispute outcomes are one of: no action, amendment, or withdrawal. The outcome and its reasoning are recorded as an amendment note on the entry. The dispute itself, including the asserting party (with their consent) or an anonymized reference (without), is recorded in the entry's history.
§4.4
A disputing party who is not satisfied with the outcome may publish their own reasoning on any platform of their choosing. The project will link to such publications from the entry in question, where the publication is in good faith and otherwise meets the registry's neutrality standard.
§4.5
The project will not pursue legal action against parties who dispute entries in good faith, even where the dispute is incorrect on the facts. Free public dispute is the registry's accountability mechanism.
Article V
Conflicts of interest
§5.1
A conflict of interest exists where the project, the founder, or any delegated editorial contributor has a material financial or professional relationship with any party named in a proposed or published entry.
§5.2
Where a conflict exists, the relationship is disclosed in a footnote attached to the entry. Disclosure is the minimum action; recusal from drafting the entry may also be appropriate where the relationship is direct.
§5.3
The project does not solicit, accept, or anticipate payment for inclusion, exclusion, modification, or withdrawal of any entry. The Registry is not a paid surface.
Article VI
Amendment format
§6.1
Amendments are appended to the entry below the original published text, in a clearly delineated section labeled "Amendments". Each amendment is numbered sequentially within the entry.
§6.2
An amendment record contains five fields: amendment number, date, reason (one of: factual correction, additional information, subsequent development, dispute resolution), the modified or added text, and the prior text of any modified passage.
§6.3
The amendment example shown at right illustrates the required format.
Amendment record · example
Amendment02
Date2026-08-14
ReasonSubsequent development
ModifiedThe original entry stated the bankruptcy proceeding was ongoing. As of 2026-08-14, the proceeding has resulted in a confirmed plan of reorganization. The entry is amended to reflect this development. The structural exposure description and MBA contrast are unchanged.
Prior text"[Original passage, preserved verbatim for the record.]"
Article VII
Continuity and succession
§7.1
The Registry is intended to outlast any single project, founder, or maintainer. The current authority is the Deviant project; the framework anticipates that authority may transfer.
§7.2
In the event the Deviant project ceases active maintenance of the Registry, editorial authority may be transferred to a successor entity by written declaration, published with the Registry. The successor must accept the policy as a precondition of authority.
§7.3
If no successor accepts the policy, the Registry is preserved at its last published state and marked as "archived". Archived registries remain accessible. New entries may not be added; existing entries may not be amended.
§7.4
The Registry's permanent location is mirrored to at least one immutable storage layer (IPFS or equivalent) on each amendment. The hash of the most recent published state is included in the change log.
Principle

Why a small policy is the right policy.

The temptation, in writing rules for a new institution, is to imagine every possible procedural edge case and codify a rule for each one. This is the wrong instinct. A document of this kind is most credible when its rules are few, clear, and consistently followed. A policy that lists thirty exceptions invites the suspicion that the exceptions exist to be applied selectively.

The seven articles above describe a small system. The system imposes constraints on the project that the project will, in some cases, find inconvenient. The constraints are deliberate. An institution whose rules constrain only those it disagrees with is not an institution.

The policy will be amended where experience demonstrates that an article is unclear or insufficient. It will not be amended to accommodate any specific entry or dispute. Where this discipline is broken, the registry's credibility is broken with it. We are aware of this and accept the standard.